SIP中文版.doc

7．1 請求

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

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

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

Method: 這個(gè)規(guī)范規(guī)定了6中方法：REGISTER用于登記聯(lián)系信息，INVITE，ACK,CANCEL用于建立會話，BYE用于結(jié)束會話，OPTIONS用于查詢服務(wù)器負(fù)載。SIP擴(kuò)展、標(biāo)準(zhǔn)RFC追加可能包含擴(kuò)展的方法。

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

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

SIP-Version：請求和應(yīng)答消息都包含當(dāng)前使用的SIP版本，這個(gè)遵循[H3.1](類似HTTP用SIP替代，用SIP/2.0替代HTTP/1.1)中關(guān)于版本的規(guī)定，版本依賴，升級版本號。一個(gè)應(yīng)用，發(fā)出的SIP消息一定包含了SIP-Version “SIP/2.0”。這個(gè)SIP版本串是大小寫不銘感的，但是在實(shí)現(xiàn)中必須發(fā)送大寫。

不像HTTP/1.1,SIP把版本號當(dāng)作一個(gè)文本串處理。在實(shí)現(xiàn)上，這個(gè)應(yīng)該不會有區(qū)別。

7．2應(yīng)答

SIP應(yīng)答和SIP請求的區(qū)別在于在START-LINE中是否包含一個(gè)STATUS-LINE。一個(gè)status-line在由數(shù)字表達(dá)的status－code之前，是一個(gè)協(xié)議的版本串，每一個(gè)元素之間用一個(gè)單個(gè)SP（空格）分開。

除了最后用作結(jié)束標(biāo)志以外，CR/LF不允許出現(xiàn)在其他地方。

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

Status-Code 是一個(gè)3位的數(shù)字result code，用來標(biāo)志處理請求的一個(gè)結(jié)果。Reason-Phrase是一個(gè)簡短的Status-Code的說明。Status-Code是為了能自動(dòng)處理使用的，但是Reason-Phrase是用來給用戶看得。一個(gè)客戶端并不要求一定要顯示或者解釋這個(gè)Reason-Phrase。本文檔建議輸出這個(gè)reason-phrase,實(shí)現(xiàn)中可以選擇其他文本，比如用請求包頭中指定的合適語言來顯示。

status－code的第一個(gè)數(shù)字表示了應(yīng)答的類型。接下來兩個(gè)數(shù)字并不作分類使用。基于這個(gè)原因，任何status code在100到199的可以統(tǒng)稱位”1xx應(yīng)答”，類似的，在200到299的可以統(tǒng)稱位”2xx應(yīng)答”，依此類推。SIP/2.0允許6類應(yīng)答：

1xx：臨時(shí)應(yīng)答－請求已經(jīng)接收，正在處理這個(gè)請求。

2xx：成功處理－請求已經(jīng)成功接收，并且正確處理了這個(gè)請求。

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

4xx：客戶端錯(cuò)誤－－請求包含錯(cuò)誤的格式或者不能在這個(gè)服務(wù)器上完成。

5xx：服務(wù)器錯(cuò)誤－服務(wù)器不能正確的處理這個(gè)顯然合法的請求。

6xx：全局錯(cuò)誤－請求不能被任何服務(wù)器處理。

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

7.3 頭域

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

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

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

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

7.3.1 頭域格式。

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

        field-name:field-value

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

在消息頭中，允許在冒號的左右有任意個(gè)數(shù)的空白；但是，在實(shí)現(xiàn)中，建議避免域名和冒號中間有空格，并且建議在冒號和值之間使用單個(gè)空格（SP）。

        Subject:         lunch

        Subject    :     lunch

        Subject         :lunch

        Subject: lunch

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

頭域可以擴(kuò)展成為多行的，只要在每一個(gè)附加行前邊用至少一個(gè)SP或者水平TAB(HT)打頭就可以了。這種多行的頭域在行結(jié)尾并且在下一行之前的空白SP（或者HT）將被認(rèn)為是一個(gè)單個(gè)的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!

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

在實(shí)現(xiàn)上，必須能夠既能夠處理多個(gè)頭域行的情況，也必須能夠處理用逗號分割的合并的單個(gè)頭域行的情況。

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

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>

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

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

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

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

和

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

相同。

Content-Disposition: session;handling=optional

和

content-disposition: Session;HANDLING=OPTIONAL

相同。

下邊的兩個(gè)頭域不相同：

Warning: 370 devnull “Choose a bigger pipe”

Warning: 370 devnull “CHOOSE A BIGGER PIPE”