7、SIP訊息：

SIP協議是一個基於文字的協議，使用UTF-8字符集（RFC2279[7]）。

一個SIP訊息既可以是一個從客戶端到伺服器端的請求，也可以是一個從伺服器端到客戶端的一個應答。

即使在字符集上和語法細節上有所不同，請求（7.1）還是應答（7.2）訊息都基於RFC2822格式的。（SIP允許包頭域不是標準的RFC2822包頭域）。這兩種訊息型別都由一個起始行，一個或者多個包頭域，一個可選的訊息中文組成。

一般訊息＝                          起始行

*訊息包頭

CRLF

[訊息正文]

起始行＝                                    請求行/狀態行

起始行、每一個包頭行，空行、都必須由回車換行組成（CRLF）。即使訊息中文沒有，也必須有一個空行跟隨。

除了在字符集上的區別以外，很多SIP的訊息和包頭域的格式都同HTTP/1.1一樣。我們在這裡就不重複它的語法和語義了，我們用[HX.Y]來標誌HTTP/1.1規範（RFC2616[8]）的X.Y節的描述。

SIP並非一個HTTP的超集或者擴充套件。

7．1 請求

SIP請求是根據起始行中的Request-Line來區分的。一個Request_line包含方法名字，Request－URI，用單個空格（SP）間隔開的協議版本。

Request-Line由CRLF結束。除了用作行結束標誌以外，不允許CR或者LF出現在其他地方。在其他域中，不允許出現線形的空白（liner whitespace LWS）

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

Method: 這個規範規定了6中方法：REGISTER用於登記聯絡資訊，INVITE，ACK,CANCEL用於建立會話，BYE用於結束會話，OPTIONS用於查詢伺服器負載。SIP擴充套件、標準RFC追加可能包含擴充套件的方法。

Request-URI: Request-URI是一個SIP或者SIPS URI，他們在19.1節由描述。也可以是一個通用的URI(RFC 2396[5])。它標誌了這個請求所用到的使用者或者服務的地址。Request-URI禁止

SIP 元素可以支援除了SIP或者SIPS之外所規定的Request-URIs。比如”tel” URI模式（RFC 2806[9]）。SIP元素可以用他們自己的機制來轉換non-SIP URIs到SIP URI，SIPS URI或者其他什麼格式的URI。

SIP-Version：請求和應答訊息都包含當前使用的SIP版本，這個遵循[H3.1](類似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中關於版本的規定，版本依賴，升級版本號。一個應用，發出的SIP訊息一定包含了SIP-Version “SIP/2.0”。這個SIP版本串是大小寫不銘感的，但是在實現中必須傳送大寫。

不像HTTP/1.1,SIP把版本號當作一個文字串處理。在實現上，這個應該不會有區別。

7．2應答

SIP應答和SIP請求的區別在於在START-LINE中是否包含一個STATUS-LINE。一個status-line在由數字表達的status－code之前，是一個協議的版本串，每一個元素之間用一個單個SP（空格）分開。

除了最後用作結束標誌以外，CR/LF不允許出現在其他地方。

status-line                         = SIP-VERSION SP STATUS-CODE SP Reasong-Phrase CRLF

Status-Code 是一個3位的數字result code，用來標誌處理請求的一個結果。Reason-Phrase是一個簡短的Status-Code的說明。Status-Code是為了能自動處理使用的，但是Reason-Phrase是用來給使用者看得。一個客戶端並不要求一定要顯示或者解釋這個Reason-Phrase。本文件建議輸出這個reason-phrase,實現中可以選擇其他文字，比如用請求包頭中指定的合適語言來顯示。

status－code的第一個數字表示了應答的型別。接下來兩個數字並不作分類使用。基於這個原因，任何status code在100到199的可以統稱位”1xx應答”，類似的，在200到299的可以統稱位”2xx應答”，依此類推。SIP/2.0允許6類應答：

1xx：臨時應答－請求已經接收，正在處理這個請求。

2xx：成功處理－請求已經成功接收，並且正確處理了這個請求。

3xx：重定向－還需要附加的操作才能完成這個請求，本請求轉發到其他的伺服器上處理。

4xx：客戶端錯誤－－請求包含錯誤的格式或者不能在這個伺服器上完成。

5xx：伺服器錯誤－伺服器不能正確的處理這個顯然合法的請求。

6xx：全域性錯誤－請求不能被任何伺服器處理。

21節定義了詳細的程式碼說明。

7.3 頭域

SIP頭域和HTTP頭域在語法和語義上都比較類似。特別的，SIP頭域遵循[H4.2]關於訊息頭的語法的定義，並且遵循多行的擴充套件頭域的規則。(後者 is specified in HTTP with implicit whitespace and folding)。這個規範遵循RFC2234[10]，並且把清晰的空白和封裝作為內在的語法規則。

[H4.2]也定義了具有相同域名的多個頭域，他們的值是用逗號分開的列表，可以合併到一個頭域中。這個也適用於SIP，但是細節上略有不同，因為語法不同。實際上，任何SIP的包頭語法都是基於如下正規化的：

header ＝ “ header-name” HCOLON header-value *(COMMA header-value)

這個允許合併在具有同一個域名的多個頭域，到一個用逗號分割的單個頭域中。Contact頭域除了當域值是”*”之外，都允許用逗號分割的列表。

7.3.1 頭域格式。

頭域遵循在RFC2822的2.2節定義的通用頭域格式。每一個頭域都由一個域名加上冒號（”:”）和域值組成。

                                          field-name:field-value

訊息頭的正則語法在25節中有介紹介紹。

在訊息頭中，允許在冒號的左右有任意個數的空白；但是，在實現中，建議避免域名和冒號中間有空格，並且建議在冒號和值之間使用單個空格（SP）。

                                          Subject:         lunch

                                          Subject    :     lunch

                                          Subject         :lunch

                                          Subject: lunch

所以，上面的都是合法的，也是相等的，但是最後一種是我們所推薦的。

頭域可以擴充套件成為多行的，只要在每一個附加行前邊用至少一個SP或者水平TAB(HT)打頭就可以了。這種多行的頭域在行結尾並且在下一行之前的空白SP（或者HT）將被認為是一個單個的SP字元。所以，下邊的例子是相等的：

                                          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!

頭域中的不同域名的相關順序並沒有什麼意義。雖然如此，我們還是強烈建議與路由相關的域（VIA,ROUTE,Record-Route,Proxy-Require,Max-Forwards,Proxy-Authorization等等）放在訊息頭的最前邊，這樣可以提高處理的速度。相同域名的域之間的順序非常重要。只有當單個頭域的域值是可以用逗號分割的列表的時候，才可以表達成為同一個域名的多個頭域（這就是說，如果遵循7.3定義的語法）。也就是意味著必須可以將同一個域名的多個頭域在不改變訊息語義的前提下，改換表達成為一對”域名: 域值”；這個轉換是通過順序增加每一個域的域值，域值之間用逗號分割。這個規則有幾個例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization頭域。多個頭域行可以在訊息頭中出現，但是由於他們的語法並不遵循7.3中定義的通用格式，所以，他們並不能合併成為單個頭域行。

在實現上，必須能夠既能夠處理多個頭域行的情況，也必須能夠處理用逗號分割的合併的單個頭域行的情況。

下邊的幾組頭域是相等的：

                                         Route: <sip:[email protected]>

                                         Subject: Lunch

                                         Route: <sip:[email protected]>

                                         Route: <sip:[email protected]>

Route: <sip:[email protected]>, <sip:[email protected]>

                                         Route: <sip:[email protected]>

                                         Subject: Lunch

                                         Subject: Lunch

                                         Route: <sip:[email protected]>, <sip:[email protected]>

                                                 <sip:[email protected]>

下邊各組是合法的，但是並不相等。

Route: <sip:[email protected]>

Route: <sip:[email protected]>

Route: <sip:[email protected]>

Route: <sip:[email protected]>

Route: <sip:[email protected]>

Route: <sip:[email protected]>

Route: <sip:[email protected]>,<sip:[email protected]>,<sip:[email protected]>

每一個頭域值的格式是依賴於它的頭域名的。他可以是任意順序的TEXT-UTF8字元，也可以是一個空格，標記，分隔符，引號括起來的字串的組合。很多頭域都回附帶一個通用的域值格式。這個域值格式是由分號分開的引數名和引數值的組合：

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

雖然在域值裡邊可以有任意數量的parameter-name/parameter-value對，但是不能允許有相同的parameter-name存在（唯一性）。除了特別指出的頭域之外，頭域中的域名、域值、parameter name parameter-value都是大小寫不敏感的。標記詞始終是大小寫不銘感的。除非有特別的指定，引號串的字串是大小寫敏感的。例如：

                                         Contact: <sip:[email protected]>;expires=3600

和

                                         CONTACT: <sip:[email protected]>; 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 頭域分類。

有一些頭域是僅僅在請求（或者應答）中有效的。這些頭域叫做請求頭域或者應答頭域。如果訊息中的頭域與這個訊息的型別不匹配（比如在應答訊息中出現的請求頭域），這個頭域必須被忽略。20節定義了每一個頭域的分類。

7.3.3 縮寫格式

SIP提供了一個用縮寫格式來表達通用頭域名字的機制。這個有助於避免訊息過大而導致通訊層無法傳輸（比如在UDP傳輸的時候超過了最大傳輸單元(MTU)）。這個縮寫格式在20節定義。

縮寫格式的訊息頭域名字可以在不改變訊息語義的情況下替代較大的訊息頭域名字。在單個訊息中，頭域名字既可以用長的格式，也可以用縮寫格式。在實現中，必須同時支援對長名字和縮寫名字的處理。

7.4包體

請求資訊，包括這個規範以後的擴充套件的新請求，都可以包含一個訊息正文體。對訊息正文體的解釋依賴域請求的方法（請求型別）。對於應答訊息來說，請求方法和應答狀態（response status code）決定了訊息正文體的格式。所有的應答訊息都可以有一個訊息正文體（body）。

7.4.1 訊息正文型別(MessageBodyType)

訊息中的internet媒體類別必須在Content-Type頭域中指明。如果訊息正文（body）通過某種形式的編碼（encoding），比如壓縮等等，都必須在Content-Encoding 頭域中指明，否則Content-Encoding域必須忽略。如果可行，訊息體的字符集作為Content-type頭域的值的一部分表達。

在RFC2046[11]中定義的多部分”multipart” MIME型別可以在訊息體中應用。在由多部分組成的訊息體傳送的時候，如果接受方的實現中，包頭域的Accept域中，不包含多部分的標記，那麼傳送方必須傳送一個非多部分的session description。

SIP訊息可以包含二進位制的包體或者部分包體。如果傳送方沒有其他顯示的字符集引數指出，媒體的文字”text”子型別會是預設的字符集”UTF-8”。

7.4.2 訊息體長度

在Content-Length頭域中存放了包體的位元組長度。第20.14節講述了本域的詳細解釋。

HTTP/1.1的“chunked”傳輸編碼方式並不適用於SIP。（備註：chuncked編碼傳輸方式是通過把訊息正文體分為一系列的塊來傳輸的，每一塊有它自己的大小標記）

7.5 分幀的SIP訊息（Framing SIP Messages）

不同於HTTP的是，SIP實現可以使用UDP或者其他非可靠傳輸協議。每一幀包括一個請求或者應答。第18節講述了非可靠傳輸的應用。

在處理以面向流的通訊為基礎的SIP訊息的時候，必須忽略在開始行之前的CRLF[H4.1]。

Content-Length頭域用來確定每一個SIP訊息在通訊流中的結束位置的。在基於面向流通訊基礎上的SIP訊息一定要使用這個頭域。

 Implementations that send requests

containing multipart message bodies MUST send a session description

as a non-multipart message body if the remote implementation requests

this through an Accept header field that does not contain multipart.