SIP中文版.doc

7．1 請求

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

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

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

Method: 這個規(guī)范規(guī)定了6中方法：REGISTER用于登記聯系信息，INVITE，ACK,CANCEL用于建立會話，BYE用于結束會話，OPTIONS用于查詢服務器負載。SIP擴展、標準RFC追加可能包含擴展的方法。

Request-URI: Request-URI是一個SIP或者SIPS URI，他們在19.1節(jié)由描述。也可以是一個通用的URI(RFC 2396[5])。它標志了這個請求所用到的用戶或者服務的地址。Request-URI禁止包含空白字符或者控制字符，并且禁止用”<>”括上。

SIP 元素可以支持除了SIP或者SIPS之外所規(guī)定的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)中關于版本的規(guī)定，版本依賴，升級版本號。一個應用，發(fā)出的SIP消息一定包含了SIP-Version “SIP/2.0”。這個SIP版本串是大小寫不銘感的，但是在實現中必須發(fā)送大寫。

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

7．2應答

SIP應答和SIP請求的區(qū)別在于在START-LINE中是否包含一個STATUS-LINE。一個status-line在由數字表達的status－code之前，是一個協(xié)議的版本串，每一個元素之間用一個單個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的可以統(tǒng)稱位”1xx應答”，類似的，在200到299的可以統(tǒng)稱位”2xx應答”，依此類推。SIP/2.0允許6類應答：

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

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

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

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

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

6xx：全局錯誤－請求不能被任何服務器處理。

21節(jié)定義了詳細的代碼說明。

7.3 頭域

SIP頭域和HTTP頭域在語法和語義上都比較類似。特別的，SIP頭域遵循[H4.2]關于消息頭的語法的定義，并且遵循多行的擴展頭域的規(guī)則。(后者 is specified in HTTP with implicit whitespace and folding)。這個規(guī)范遵循RFC2234[10]，并且把清晰的空白和封裝作為內在的語法規(guī)則。

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

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

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

7.3.1 頭域格式。

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

        field-name:field-value

消息頭的正則語法在25節(jié)中有介紹介紹。

在消息頭中，允許在冒號的左右有任意個數的空白；但是，在實現中，建議避免域名和冒號中間有空格，并且建議在冒號和值之間使用單個空格（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定義的語法）。也就是意味著必須可以將同一個域名的多個頭域在不改變消息語義的前提下，改換表達成為一對”域名: 域值”；這個轉換是通過順序增加每一個域的域值，域值之間用逗號分割。這個規(guī)則有幾個例外，就是WWW-Authenticate,Authorization,Proxy-Authenticate,和Proxy-Authorization頭域。多個頭域行可以在消息頭中出現，但是由于他們的語法并不遵循7.3中定義的通用格式，所以，他們并不能合并成為單個頭域行。

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

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

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>

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

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

雖然在域值里邊可以有任意數量的parameter-name/parameter-value對，但是不能允許有相同的parameter-name存在（唯一性）。除了特別指出的頭域之外，頭域中的域名、域值、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”