07. SIP Messages

목차

---

7.1 Requests

7.2 Responses

7.3 Header Fields

7.3.1 Header Field Format

7.3.2 Header Field Classification

7.3.3 Compact Form

7.4 Bodies

7.4.2 Message Body Length

7.5 Framing SIP Messages

 

SIP Message

• text based protocol
  
• UTF-8 charset
  
• request, response

         generic-message  =  start-line
                             *message-header
                             CRLF                             <-- 반드시 들어가 야 함
                             [ message-body ]
         start-line       =  Request-Line / Status-Line

 

 

7.1 Requests^#

Request-Line = Method SP Request-URI SP SIP-Version CRLF

• Method :  REGISTER, INVITE, ACK, CANCEL, BYE, OPTION
  
• Request-URI : SIP, SIPS, general URI, unescaped spaces 또는 control caracter를 포함하면 안됨(MUST NOT), "<>"로 싸여 있으면 안됨(MUST NOT)
  
• SIP-Version : 사용하는 SIP의 버전, 이 규격서를 따를 경우는 "SIP/2.0"을 적어줘야 함(MUST), case-insensitive 하지만 구현시 대문자로(MUST)

끝은 무조건 CRLF로 사용 - CR이나 LF는 허용되지 않음

7.2 Responses^#

    Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

• 
  

  Status-LIne

  
  
  
  
  • 3-digit integer, request의 결과를 알 수 있음
    
  • 
    

    first digit는 Status-Code에서 정의한 response의 class를 의미

    
    
    
    
    • 1xx : Provisional
      
    • 2xx : Success
      
    • 3xx : Redirection
      
    • 4xx : Client Error
      
    • 5xx : Server Error
      
    • 6xx : Global Failure
  
  
• 
  

  Reason-Phrase 

  
  
  
  
  • Status code에 대한 간단한 문자열 설명
    
  • Accept-Language 헤더 필드에서 선언한 다른 언어 사용 가능(MAY)

 

 

7.3 Header Fields^#

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

• HTTP 헤더 필드와 비슷
  
• RFC 2234를 따름 (whitespace, folding를 제외)
  
• Comma-separated list : 같은 필드 네임에 대한 값을 comma를 이용하여 한 필드에 적을 수 있음, 값이 "*" 일 경우 제외

 

7.3.1 Header Field Format^#

헤더 필드는 다음과 같은 형식을 가짐

field-name: field-value

• 콜론 사이의 임의의 양의 whitespace가 올 수 있음
  
• 구현시는 field name과 콜론사이는 space를 주지 않고 콜론과 field-value 사이에는 하나의 SP를 구어야 함
  
• 헤더 필드는 multiple line으로 확장 가능, link break와 이후 whitespace는 SP로 처리
  
• 다른 헤더 필드들 사이의 순서는 의미가 없음
  
• 헤더필드의 순서를 proxy 처리 순서(Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization)으로 적어 추는 것을 추천함(RECOMMENDED)
  
• 같은 헤더 필드의 순서는 중요함
  
• 같은 헤더 필드들을 하나의 헤더필드로 결합 가능해야 함(MUST) - WWW-Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization 헤더 필드 제외, 하나의 헤더 필드로 결합하면 안됨(MUST NOT)
  
• 구현시 multiple header field rows의 처리를 위해서 singple-value-per-line과 comma-separated가 모두 가능 해야 함(MUST)

 

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

• 헤더의 field-vale는 헤더마다 다른 정의를 가짐
  
• parameter pair(parameter-name, parameter-value)들은 세미 콜론으로 구분
  
• 임의의 수의 parameter pair가 올 수 잇음
  
• parameter name은 헤더 필드에 한번 이상 올 수 없음(MUST NOT)
  
• 비교시 case-insensitive : parameter names, parameter values, tokens
  
• quoted string은 case-sensitive 함

 

다음의 표현은 같은 의미를 가짐

      Subject:            lunch
      Subject      :      lunch
      Subject            :lunch
      Subject: lunch               <- 추천

 

다음의 두 헤더필드는 동일 함

      Subject: I know you're there, pick up the phone and talk to me!
      Subject: I know you're there,
               pick up the phone
               and talk to me!

 

다음 블럭들은 모두 동일한 의미를 가짐 (Route 헤더 필드의 값들의 순서가 동일)

      Route: <sip:alice@atlanta.com>
      Subject: Lunch
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Subject: Lunch

      Subject: Lunch
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
             <sip:carol@chicago.com>

 

다음 블럭들은 모두 다른 의미를 가짐 (Route 헤더 필드의 값들의 순서가 다름)

      Route: <sip:alice@atlanta.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:bob@biloxi.com>
      Route: <sip:alice@atlanta.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
             <sip:bob@biloxi.com>

다음은 동일한 표현들임

       Contact: <sip:alice@atlanta.com>;expires=3600
       CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

       Content-Disposition: session;handling=optional   
       content-disposition: Session;HANDLING=OPTIONAL

 

다음은 다른 표현임

 Warning: 370 devnull "Choose a bigger pipe"
 Warning: 370 devnull "CHOOSE A BIGGER PIPE"

 

7.3.2 Header Field Classification^#

특정 헤더 필드는 request나 response에만 올 수 있음

request header field, response header field라 부름

만약 매칭 되지 않는 곳에 header field가 나타 난다면 무시해야 함(MUST)

 

7.3.3 Compact Form^#

common header field name들은 추약형으로 표현이 가능

메시지의 의미 없이 긴 header field name을 줄 일 수 있음

하나의 메시지에 long form, short form이 나올 수 있음 (MAY)

구현시 각각의 header field에 대하여 long form, short form 둘다 가능 하도록 해야 함(MUST)

 

 

7.4 Bodies^#

request : method에 따라 body가 올 수 있음

response : request method와 response status에 따라 body의 종류와 해석이 가능, 모든 response들은 바디를 가지고 있을 수도 있음(MAY)

 

7.4.1 Message Body Type

• 
  

  Content-Type header field

  
  
  
  
  • 메시지 body의 Internet media 타입을 표시 하여야 함(MUST)
  
  
• 
  

  Content-Encoding header field

  
  
  
  
  • body가 enconding 되어 있다면 반드시 encoding을 표시 되어야 함(MUST)
    
  • Content-Type header field에서 인지 가능한 character set이라면 생략 가능
  
  
• 
  

  multpart

  
  
  
  
  • MIME 타입이 올 수도 있음(MAY)
    
  • request가 body에 multpart를 가지고 있으나 remote가 Accept header field에 multpart를 포함하지 않았다면 non-multipart 메시지 바디처럼 세션 디스크립션을 보내야 함(MUST)
  
  
• 
  

  Binary body or body part

  
  
  
  
  • 메시지 바디에 바이너리나 바디의 일부분이 포함 될 수 있음(MAY)
    
  • sender는 특정 charset parameter를 사용하지 않음

 

7.4.2 Message Body Length^#

Content-Length header field : body의 길이를 body로 표현

HTTP/1.1의 "chunked" transfer encoding은 SIP에서 사용 되지 않아야 함(MUST)

 

 

7.5 Framing SIP Messages^#

HTTP와 달리, UDP와 같은 unreliable한 datagram protocol들이 구현 되어 짐

Stream-oriented의 경우는 start-line전의 CRLF는 무시해야 함(MUST)

Content-Length header field는 스트림에서 SIP 메시지의 끝을 알아내는데 사용함