[RFC 3261] CHAPTER 7. SIP Messages

CHAPTER 7. SIP Messages

 

SIP 메세지 기본 구조

• Start-Line → Request / Response 를 구분할 수 있다.
• Header Field → From, To, Call-ID 등 메타데이터를 포함하고 있다.
• CRLF(\\r\\n) → 빈 줄 (필수)
• Message Body

 

(7.1) Requests

Method

contact 정보를 등록하기 위한 REGISTER, 세션 설정을 위한 INVITE, INVITE에 대한 response을 확인하기 위한 ACK , 세션을 취소하기 위한 CANCEL, 세션 종료를 위한 BYE, 서버에 해당 기능에 대해 쿼리하기 위한 OPTIONS 6가지 방법이 존재한다.

 

Request-URI

• request의 목적지 주소
• SIP / SIPS URI 또는 non-SIP-URI 사용 가능하다.

SIP-Version (항상 대문자)

• SIP 메세지를 보내는 애플리케이션은 항상 SIP/2.0을 포함해야 한다.
• 전송할 때는 반드시 대문자로 보내야 한다.

 

(7.2) Responses

Reason-Phrase → 설명 문구

Status-Code

1xx (Informational)	요청 메세지를 수신하여 요청 메세지 처리가 계속되고 있음을 알림.	- 180 Ringing - 183 Session Progress
2xx (Success)	요청한 동작이 성공적으로 수신되고 이해되어 수용되었음을 알림.	- 200 OK
3xx (Redirection)	요청 메세지를 완료하기 위해 수행해야 될 동작이 더 있음을 알림.	- 301 Moved Permanently - 302 Moved Temporarily
4xx (Client Error)	요청 메세지에 잘못된 구문이 포함되어 있거나 해당 서버에서 처리할 수 없음을 알림.	- 400 Bad Request - 408 Request Timeout
5xx (Server Error)	요청 메세지는 유효하나 서버가 수행할 수 없음을 알림.	- 500 Server Internal Error - 503 Service Unavailable
6xx (Global Failure)	요청 메세지가 어떤 다른 서버에서도 수행할 수 없음을 알림.	- 600 Busy Everywhere - 603 Decline

 

 

(7.3) Header Fields

header = "header-name" HCOLON header-value *(COMMA header-value)

• 같은 이름의 헤더들을 한 줄로 합쳐도 된다.
• Contact 헤더도 여러 주소를 한 줄에 쓸 수 있지만, 값이 *인 경우는 예외이다.

 

(7.3.1) Header Field Format

• SIP에서 헤더 필드가 여러 줄로 이어질 때, 두 번째 줄부터는 반드시 SP(=Space) 또는 탭으로 시작해야 한다.
• 프록시 처리에 필요한 header field(예: Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization)는 메세지 상단에 표시하여 빠른 구분 분석을 용이하게 한다.

동일한 필드명

• 같은 이름의 header field가 여러 줄 존재할 경우, 이들의 순서는 의미를 갖는다.
  • 여러 줄로 작성할 수 있는 경우는 comma-separated list 문법을 따를 경우에만 허용된다.
  • 각 줄을 콤마로 연결해 하나의 field로 합칠 수 있어야 하며, 의미(= 순서)가 바뀌어선 안 된다.
• 이 네 가지는 문법이 콤마-리스트 형식이 아니므로, 여러 줄이 있어도 하나로 합치면 안 된다.
  • 예외: WWW-Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization
• 구현체는 Route, Via처럼 같은 이름의 필드가 한 줄에 콤마로 나와도, 여러 줄로 나와도 모두 처리할 수 있어야 한다.

다음 예시는 모두 동일한 의미를 지닌다.

 

field-name: field-value *(;parameter-name=parameter-value)

• 헤더 field-value 형식은 각 header-name 마다 따로 정의된다.
• field-name과 토큰(= 공백이나 특수 문자가 없는 연속된 단어)은 대소문자를 구분하지 않는다.
  • 특별히 명시되지 않았다면, 필드 값/파라미터 이름/값도 대소문자를 구분하지 않는다.
• 헤더 필드 내에서는 같은 parameter-name이 반복되면 안 된다.
  • 예: ;expires=3600;expires=7200

 

(7.3.2) Header Field Classification

(7.3.3) Compact Form

 

SIP는 공통의 헤더필드명을 약어로 표현하는 메커니즘을 제공한다.

 

(7.4) Bodies

Content-Type, Content-Encoding, Content-Length 등이 있다.

 

(7.4.1) Message Body Type

• 메세지 본문의 MIME 타입(= 미디어 타입)은 반드시 Content-Type 헤더를 통해 명시해야 한다.
  • multipart MIME 타입(= 여러 개의 body part)을 쓸 생각이라면,
    • 상대방이 Accept 헤더에 multipart를 허용하지 않았다면, non-multipart 형식으로 세션 설명을 보내야 한다.
• 인코딩이 되어있다면, 반드시 Content-Encoding 헤더 필드에 명시해야 한다.
  • 명시하지 않은 경우, 기본적으로 UTF-8로 간주

(7.4.2) Message Body Length

• byte 단위로 표시되며, Content-Length 헤더 필드에 표기된다.
• HTTP의 chunked 전송 방식은 SIP에서는 사용 금지이다.

 

(7.5) Framing SIP Messages

• SIP는 UDP를 사용할 수 있으며, datagram(패킷)은 하나의 request나 response를 전송한다.
• TCP와 같이 스트림 지향 전송을 사용하는 경우,
  • SIP 메세지를 처리하는 구현은 CRLF를 무시해야 한다.
    • TCP는 여러 SIP 메세지가 하나의 연결로 연달아 들어올 수 있기에 CRLF 만으로는 메세지 경계를 구분할 수 없다.
    • Content-Length 헤더 필드는 SIP 메세지의 끝을 찾는 데 사용되기에, 반드시 있어야 한다.