SIP協議解析與實現(c和c 使用osip) 3

第三章 SIP訊息

SIP是一個基於文本的協議，它使用UTF-8字元集（RFC2279）。一個SIP訊息可以是一個用戶端發給伺服器端的請求，也可以是一個伺服器端發給用戶端的應答。

無論是請求（RFC3261第7.1節）還是應答（RFC3261第7.2節）都是基於RFC2822描述的格式。只是在字元集和一些文法細節上有些差異。所有類型的訊息都由一個開始行（start-line）,一個或多個頭頭域，一個標識頭域結束的空行，和一個可選的訊息體（message-body）組成。
generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line
        
開始行、頭域和頭域結束都必須由換行斷行符號符（CRLF）終止。注意，即使沒有訊息體，也要有頭域標識結束的空行。

除了上述的字元集不同外，絕大多數SIP訊息和頭域的文法都與HTTP/1.1相同。但是，SIP不是HTTP的擴充。

第一節 請求

SIP請求的開始行是一個請求行（Request-Line）。一個請求行包含方法名（Method）、一個請求URI（Request-URI）和一個協議版本（SIP-Version）。它們之間用空格（SP）分割。

請求行以CRLF結束。請求行中，除了最後的CRLF外，不允許出現CR或者LF。各個元素中不允許有線性空格（表示一個或多個連續的空格LWS）。
Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

方法：這裡定義六種方法，REGISTER用於註冊聯絡資訊。INVITE、ACK和CANCEL用於構建會議。BYE用於終止會議。OPTIONS用於查詢服務器的能力。SIP的擴充協議可能定義其它的方法。

Request-URI：請求URI是一個在RFC3261第19.1或RFC2396中描述的SIP URI或SIPS URI。它指出一個請求發送給一個使用者或者一個服務的地址。請求RUI必須不包含空格和控制字元，它必須不被嵌套在"<>"之內。
SIP元素可能支援模式不是“sip”或“sips”的URI。如RFC2806中描述的URI模式“tel”。SIP元素可以支援處理非“sip”和“sips”模式的URI。

SIP-Version：請求和應答訊息都包含當前使用的SIP版本。目前這個版本資訊必須是"SIP/2.0"。

第二節 應答

SIP應答的開始行是一個狀態行（Status-Line）.一個狀態行由一個協議版本（SIP-Version），緊接著一個表示狀態代碼（Status-Code）的數字和一個短語（Reason-Phrase）組成。它們用空格分割。除了最後的CRLF，不允許有CR或LF出現。
Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

狀態代碼是一個三位的整數，表示對請求的應答。短語是對狀態代碼進行一個簡短的描述。狀態代碼是自動設定的，而短語是使用者人為設定的。一個使用者不需要看到短語。

狀態代碼的最高位元字定義應答的分類。後兩位元字沒有分類意義。任何狀態代碼在100~199之間的應答稱為"1xx應答"，任何狀態代碼在200~299之間的應答稱為"2xx應答"，以此類推。SIP/2.0允許最高位為6個數字：
 1xx：臨時的---已經接收到請求，繼續向後傳送該請求。
 2xx：成功---請求已經成功的接收到、被理解且被接受。
 3xx：重新導向---為了完成請求，需要進一步處理。
 4xx：用戶端錯誤---請求包含錯誤的文法或者在這個伺服器不能完成。
 5xx：伺服器錯誤---一個顯然無效的請求，伺服器處理錯誤。
 6xx：全域錯誤---請求在任何伺服器都無法完成。
 
RFC3261第21節定義了這些類別並對每個狀態代碼進行了描述。

第三節 頭域

SIP頭域在文法和語義上都與HTTP頭域類似。文法格式如下：
header  =  "header-name" HCOLON header-value *(COMMA header-value)、
如果有多個相同名稱的頭域，可以將他們合并成一個頭域，頭域的值用逗號分割。
頭域符合在RFC2822第2.2節介紹的一般頭域的格式。每個頭域由頭網域名稱稱後面加一個冒號和頭域的值組成。在RFC3261第25節詳細介紹了訊息頭的文法。在冒號的兩邊可以有任意多個空格。但是通常在頭網域名稱稱和冒號之間避免使用空格，而在冒號和頭域值之間使用一個空格。
      Subject:            lunch
      Subject      :      lunch
      Subject            :lunch
      Subject: lunch
上面這些頭域都是有效並且他們是等價的。但是最後一個頭域格式是被推薦使用的。

一個頭域可以被擴充至多行。每個擴充的行至少要以一個空格或tab（HT）開始。這些空格或者tab被視為一個空格。所以下面這些頭域是等價的：
      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!

不同頭網域名稱稱的頭出現的先後順序並不重要。但是推薦將Proxy 伺服器需要處理的頭域（如Via, Route, Record-Route, Proxy-Require, Max-Forwards, 和Proxy-Authorization）放在訊息的頂部，以便加快解析效率。具有相同頭網域名稱稱的頭域的先後順序是重要的。在一個訊息中可以有多行頭網域名稱稱相同的頭域出現。這時，它與一個頭域行和多個以逗號分割的頭域值是等價的。如果採用多個相同頭域值的頭域行，那麼它必須是容易被合并成單行的頭域，且訊息的語義不會因此而被改變。合并的時候，每個後出現的頭域行的值被加在單行頭域值的最前面，並用逗號與其它值分割。WWW-Authenticate, Authorization, Proxy-Authenticate, 和 Proxy-Authorization頭域除外。如果它們出現多個相同的頭網域名稱稱的頭域，它們不能被合并。下面每組頭域都是等價的：

   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: <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>
            
頭域的值可以使UTF-8的數字、空格、符號、分隔字元或者引用字串（帶雙引號的字串）。一些頭域在最後附加一系列以分好分割的參數名稱、參數值對：
   field-name: field-value *(;parameter-name=parameter-value)
雖然參數個數是沒有限制的，但是每個參數名稱只能出現一次。

頭域是不區分大小寫。除非特殊情況，頭網域名稱稱、頭域值、參數名稱、參數值都不區分大小寫。符號經常是小寫。除非特殊說明，引用字串是區分大小寫。例如：
   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"

   
第四節 頭域分類

一些頭域只對請求或只對應答有意義。它們分別被稱為要求標頭域或者應答頭域。如果一個在訊息中出現的頭域不符合它的分類（例如一個要求標頭域出現在應答訊息中），那麼它必須被忽略。RFC3261第20節定義了各個頭域的分類。

第五節 簡潔格式

SIP支援對一般頭網域名稱稱的縮寫形式。這對於不能傳輸大資料時會很有用處（例如，當使用UDP時，超過傳輸單元最大值MTU）。這些縮寫形式在RFC3261第20節定義。縮寫形式的頭網域名稱稱和長頭網域名稱稱可以同時出現在一個訊息中，並且語義不變。