【導(dǎo)讀】本標(biāo)準(zhǔn)以RFC3261等文檔為依據(jù)，針對(duì)我國(guó)具體要求制定而成。

　　

【正文】 Cseq 頭字段相等。本規(guī)范要求， Via 頭字段不但 值必須要相等，各個(gè)值之間的順序也必須保持一致。 如果請(qǐng)求消息中包含 To 標(biāo)簽，那么響應(yīng)消息的 To 頭字段必須與請(qǐng)求消息的 To 頭字段相等。然而，如果請(qǐng)求消息的 To 頭字段不包含標(biāo)簽，那么響應(yīng)消息中 To 頭字段的 URI 必須與請(qǐng)求消息中 To 頭字段的 URI 相等；此外， UAS 必須在響應(yīng)消息的 To 頭字段中添加一個(gè)標(biāo)簽（ 100 響應(yīng)例外，因?yàn)?100 響應(yīng)中可以沒(méi)有標(biāo)簽），這是為了標(biāo)識(shí)正在應(yīng)答的 UAS，也許會(huì)成為一個(gè)對(duì)話 ID 的組成部分。同一個(gè)請(qǐng)求的所有響應(yīng)必須使用同一個(gè)標(biāo)簽，包括臨時(shí)響應(yīng)和最終響應(yīng)（ 100 響應(yīng)仍然例外）。關(guān)于產(chǎn)生標(biāo)簽 的過(guò)程參見(jiàn)本規(guī)范 節(jié)。 重定向服務(wù)器 代理服務(wù)器負(fù)責(zé)請(qǐng)求消息的路由。某些體系結(jié)構(gòu)下可能需要降低它們的負(fù)荷，并提高信令傳輸通道的魯棒性，這時(shí)可依靠請(qǐng)求重定向來(lái)達(dá)到目的。 重定向即服務(wù)器用響應(yīng)消息將某一請(qǐng)求的路由信息返回給客戶端，從而使服務(wù)器既起到了幫助選路的功能，又可以不用處理由該請(qǐng)求所導(dǎo)致的更多消息往來(lái)。當(dāng)請(qǐng)求的發(fā)起者收到重定向響應(yīng)后，它將基于收到的 URI 發(fā)送新的請(qǐng)求。重定向通過(guò)把 URI 信息從網(wǎng)絡(luò)的核心傳遞到邊緣而使網(wǎng)絡(luò)獲得了相當(dāng)大的擴(kuò)展升級(jí)能力。 重定向服務(wù)器邏輯上由一個(gè)服務(wù)器端事務(wù)層和一個(gè)能夠 訪問(wèn)某種定位服務(wù)的事務(wù)用戶組成。有關(guān)注冊(cè)服務(wù)器及定位服務(wù)參見(jiàn)本規(guī)范第 10 章。定位服務(wù)器實(shí)質(zhì)上是一個(gè)數(shù)據(jù)庫(kù)，它包含單個(gè) URI 到一個(gè)或多個(gè)聯(lián)系地址之間的映射，通過(guò)這些聯(lián)系地址就能找到 URI 所對(duì)應(yīng)的用戶或?qū)嶓w。 重定向服務(wù)器自己不發(fā)送任何 SIP 請(qǐng)求。在收到除 CANCEL 以外的請(qǐng)求時(shí)，重定向服務(wù)器可以拒絕它，或者通過(guò)定位服務(wù)獲得一個(gè)可選地址列表并返回一個(gè) 3xx 最終響應(yīng)。對(duì)格式正確的 CANCEL 請(qǐng)求，重定向服務(wù)器應(yīng)返回 2xx 響應(yīng)。該響應(yīng)將結(jié)束被取消請(qǐng)求的 SIP 事務(wù)。重定向服務(wù)器維護(hù)整個(gè) SIP事務(wù)的狀態(tài)。客戶端檢測(cè)重 定向服務(wù)器之間發(fā)生的轉(zhuǎn)發(fā)循環(huán)。 當(dāng)重定向服務(wù)器返回某個(gè)請(qǐng)求的 3xx 響應(yīng)時(shí)，它在 Contact 頭字段中裝入一個(gè)地址列表（含一個(gè)或多個(gè)可選地址）。 Contact 頭字段值中還可能提供“ expires”參數(shù)，以指明 Contact 數(shù)據(jù)的有效期。 YD — 15 Contact 頭字段包含了可供發(fā)送的 URI，這些 URI 給出了新的目標(biāo)位置或新的用戶名，或者只簡(jiǎn)單地指定了一些其它的傳輸參數(shù)。 301（永久移動(dòng)）或 302（臨時(shí)移動(dòng)）響應(yīng)可能會(huì)給出與初始請(qǐng)求一樣的目標(biāo)位置和用戶名，同時(shí)又指定另外的傳輸參數(shù)，比如一個(gè)不同的服務(wù)器地址或多播地址， 或者將SIP 消息的傳輸方式從 UDP 改為 TCP 或從 TCP 改為 UDP，等等。 然而，重定向服務(wù)器決不能將請(qǐng)求重定向到一個(gè)與請(qǐng)求的 RequestURI 相同的 URI 地址。如果重定向的目的地 URI 所指并非當(dāng)前重定向服務(wù)器，它可能將請(qǐng)求向重定向目的地轉(zhuǎn)發(fā)，或用一個(gè) 404（未找到）響應(yīng)來(lái)拒絕請(qǐng)求。 如果客戶端在使用一個(gè)外撥代理服務(wù)器，而該外撥代理實(shí)際上在重定向請(qǐng)求，這時(shí)就可能出現(xiàn)無(wú)限重定向循環(huán)。 Contact 頭字段值也可能指示與原始被叫不同的資源位置。例如，一個(gè)連接到 PSTN 網(wǎng)關(guān)的 SIP 呼叫可能需要發(fā)送一個(gè)特定 的錄音通知。 響應(yīng)消息的 Contact 頭字段可能包含任何指示被叫位置的 URI 類(lèi)型 , 而并不僅限于 SIP URI。例如，它可能包含電話、傳真、或 irc （如果它們已被定義） URI，或一個(gè)“ mailto：”（ RFC2368[32]中定義）URL。 Contact 頭字段值的 expires 參數(shù)指出了該值中包含的 URI 地址的有效期。這個(gè)參數(shù)的值是以秒為單位計(jì)算的。如果沒(méi)有提供該參數(shù)，那么 URI 地址的有效期由 Expires 頭字段值來(lái)確定。格式錯(cuò)誤的有效期值應(yīng)被視為 3600 來(lái)處理。 這是為了適度提供對(duì) RFC2543 的后向兼容性，因?yàn)樵?RFC2543 中允許 Expires 頭字段包含絕對(duì)時(shí)間。如果收到了用絕對(duì)時(shí)間表示的有效期值，它將被認(rèn)為格式錯(cuò)誤并缺省地用 3600 代替。 如果請(qǐng)求中包含不能理解的內(nèi)容（包括不可識(shí)別的頭字段， Require 中任何未知的選項(xiàng)標(biāo)簽，甚至請(qǐng)求方法名等），重定向服務(wù)器必須忽略它們并繼續(xù)進(jìn)行重定向處理。 5 請(qǐng)求的取消 CANCEL 用于取消客戶端發(fā)送的前一個(gè)請(qǐng)求。特別是當(dāng)要求 UAS 終止對(duì)被取消請(qǐng)求的處理，并對(duì)那個(gè)請(qǐng)求產(chǎn)生一個(gè)錯(cuò)誤響應(yīng)。對(duì)于 UAS 已經(jīng)給出了最終響應(yīng)的請(qǐng)求， CANCEL是無(wú)效的。因此， CANCEL主要用于取消服務(wù)器端需要長(zhǎng)時(shí)間才能給出響應(yīng)的請(qǐng)求。 CANCEL 請(qǐng)求最適合于 INVITE 請(qǐng)求，因?yàn)樗鼤?huì)需要很長(zhǎng)的時(shí)間來(lái)產(chǎn)生響應(yīng)。在這種情況下，如果 UAS 收到了針對(duì) INVITE 的 CANCEL 請(qǐng)求，但還沒(méi)有為之發(fā)出最終響應(yīng)，則 UAS 將 ”停止振鈴 ”，然后用一個(gè)特定的錯(cuò)誤響應(yīng)（一個(gè) 487）來(lái)應(yīng)答INVITE。 代理服務(wù)器和 UAC 都可以產(chǎn)生并發(fā)送 CANCEL 請(qǐng)求。這兩部分內(nèi)容分別參見(jiàn)本規(guī)范第 15 章和 節(jié)。 有狀態(tài)的代理服務(wù)器應(yīng)當(dāng)應(yīng)答收到的 CANCEL，而不是簡(jiǎn)單地轉(zhuǎn)發(fā)從下游實(shí)體收到的響應(yīng)。因此，由于 CANCEL“跳”到每一個(gè)有狀態(tài)的代理服務(wù)器時(shí)都會(huì)被應(yīng)答，所以它是個(gè)“逐跳”（ hopbyhop）YD — 16 的請(qǐng)求。 客戶端行為 CANCEL 請(qǐng)求不應(yīng)當(dāng)用于取消非 INVITE 請(qǐng)求。 非 INVITE 請(qǐng)求會(huì)立刻被響應(yīng)，發(fā)出 CANCEL 來(lái)取消一個(gè)非 INVITE 請(qǐng)求通常將會(huì)產(chǎn)生競(jìng)爭(zhēng)。 下列過(guò)程用于構(gòu)造一個(gè) CANCEL 請(qǐng)求消息： CANCEL 請(qǐng)求的 RequestURI， CallID, To, CSeq 的數(shù)字部分，以及 From頭字段，包括各個(gè)標(biāo)簽，都必須與被取消請(qǐng)求的對(duì)應(yīng)部分相同?？蛻舳水a(chǎn)生的 CANCEL必須只能有一個(gè) Via 頭字段值，并與被取消請(qǐng)求的頂端 Via 值相匹配。這些頭字段值的一致性使得CANCEL 請(qǐng)求能與被取消的請(qǐng)求相匹配。但是， Cseq 頭字段中“ method”部分的值必須是 ”CANCEL”，以保證 CANCEL 請(qǐng)求能夠被識(shí)別并在一個(gè)它自己的事務(wù)中被處理。 如果被取消請(qǐng)求包含一個(gè) Route 頭字段， CANCEL 請(qǐng)求中必須包含此 Route 頭字段的值。 這個(gè)要求是為了讓無(wú)狀態(tài)代理服務(wù)器能夠正確地路由 CANCEL 請(qǐng)求。 CANCEL 請(qǐng)求不能包含任何 Require 或 ProxyRequire 頭字段。 一旦 CANCEL 請(qǐng)求構(gòu)造完畢，客戶端應(yīng)當(dāng)檢查是否已收到了被取消請(qǐng)求（下文將統(tǒng)稱(chēng)為原請(qǐng)求）的任何響應(yīng)消息（臨時(shí)的或最終的）。 如果還沒(méi)有收到臨時(shí)響應(yīng)消息，那么 CANCEL 請(qǐng)求不能發(fā)送，而是一直等待，直到一個(gè)臨時(shí)響應(yīng)到來(lái)。如果原請(qǐng)求已經(jīng)產(chǎn)生了一個(gè)最終響應(yīng)，由于 CANCEL 對(duì)已經(jīng)產(chǎn)生了最終響應(yīng)的請(qǐng)求是無(wú)效的，那么 CANCEL 請(qǐng)求也不應(yīng)當(dāng)發(fā)送，既然。當(dāng)客戶端決定要發(fā)送 CANCEL 時(shí)，它為該請(qǐng)求創(chuàng)建一個(gè)客戶端事務(wù)，并將 CANCEL 消息和目的地址、端口、以及傳輸方式一起傳遞給新創(chuàng)建的事務(wù)。 CANCEL 請(qǐng)求的目的地址、端口和傳輸方式必 須與原請(qǐng)求的相同。 如果允許在收到響應(yīng)消息之前發(fā)送 CANCEL 請(qǐng)求，那么服務(wù)器端有可能在收到原請(qǐng)求之前先收到CANCEL 請(qǐng)求。 對(duì)應(yīng)于原請(qǐng)求的事務(wù)和 CANCEL 請(qǐng)求的事務(wù)都將獨(dú)立完成。但是，一個(gè)執(zhí)行請(qǐng)求取消的 UA 不能依賴(lài)于收到原請(qǐng)求的 487 響應(yīng)消息來(lái)進(jìn)行后續(xù)處理，因?yàn)樽駨?RFC2543 標(biāo)準(zhǔn)， UAS 將不會(huì)產(chǎn)生 487 響應(yīng)。如果在 64*T1 秒 (T1 在 節(jié)中定義 )內(nèi)沒(méi)有收到原請(qǐng)求的最終響應(yīng)，那么 UAC 應(yīng)認(rèn)為原請(qǐng)求已經(jīng)被取消，并終止原請(qǐng)求的事務(wù)處理。 服務(wù)器端行為 CANCEL 方法請(qǐng)求服務(wù)器端的事務(wù) 用戶（ TU）取消一個(gè)未決的事務(wù)。事務(wù)用戶假定原請(qǐng)求的方法是除了 CANCEL 或 ACK 之外的任何一個(gè)，并進(jìn)行事務(wù)匹配，匹配到的事務(wù)將被取消。匹配規(guī)則參見(jiàn)本規(guī)范 節(jié)。 服務(wù)器如何處理 CANCEL 請(qǐng)求依賴(lài)于服務(wù)器的類(lèi)型。無(wú)狀態(tài)代理服務(wù)器將簡(jiǎn)單地轉(zhuǎn)發(fā)請(qǐng)求；有狀態(tài)代理服務(wù)器會(huì)對(duì)其做出應(yīng)答并產(chǎn)生自己的 CANCEL 請(qǐng)求； UAS 將對(duì) CANCEL 請(qǐng)求做出應(yīng)答。關(guān)于代理服務(wù)器對(duì) CANCEL 的處理方式參見(jiàn)本規(guī)范 節(jié)。 UAS 首先按 節(jié)所述的基本規(guī)則對(duì) CANCEL 進(jìn)行處理。由于 CANCEL 請(qǐng)求是逐跳處理的并 且不YD — 17 能重傳，所以 UAS 不能對(duì)它們發(fā)出質(zhì)詢（ Challenge）來(lái)得到在 Authorization 頭字段中攜帶的證書(shū)（ Credentials）。 CANCEL 請(qǐng)求不包含 Require 頭字段。 然后， UAS 對(duì) CANCEL 請(qǐng)求進(jìn)行事務(wù)匹配。如果依據(jù)上述的過(guò)程沒(méi)有找到匹配的事務(wù)，那么 UAS應(yīng)當(dāng)用一個(gè) 481 響應(yīng) (事務(wù)或呼叫方不存在 ) 來(lái)應(yīng)答 CANCEL 請(qǐng)求。如果匹配到了原請(qǐng)求的事務(wù)，那么UAS 的處理行為將取決于是否已經(jīng)發(fā)送了對(duì)原請(qǐng)求的最終響應(yīng)。如果響應(yīng)已經(jīng)發(fā)送，那么 CANCEL 請(qǐng)求不影響對(duì)原請(qǐng)求的處理，也不影響任何會(huì) 話狀態(tài)和原請(qǐng)求的響應(yīng)。如果最終響應(yīng)沒(méi)有發(fā)送，那么 UAS的處理方式將取決于原請(qǐng)求的類(lèi)型。如果原請(qǐng)求是一個(gè) INVITE， UAS 應(yīng)立即對(duì)它發(fā)送 487（請(qǐng)求終止）響應(yīng)。而對(duì)本規(guī)范中定義的任何其它的請(qǐng)求方法， CANCEL 請(qǐng)求對(duì)它們的事務(wù)處理都不起作用。 不管原請(qǐng)求的類(lèi)型是什么，只要 CANCEL 匹配到了一個(gè)現(xiàn)存的事務(wù)， UAS 都要用一個(gè) 200（ OK）響應(yīng)來(lái)應(yīng)答 CANCEL 請(qǐng)求。這個(gè)響應(yīng)要遵循 節(jié)中的過(guò)程構(gòu)造，注意 CANCEL 響應(yīng)的 To 標(biāo)簽應(yīng)當(dāng)與原請(qǐng)求響應(yīng)的 To 標(biāo)簽相同。 CANCEL 的響應(yīng)消息被傳遞給一個(gè)服務(wù)器端 事務(wù)以便發(fā)送。 10 章沒(méi)有 6 注冊(cè)（暫缺） 7 查詢能力 OPTIONS 用于一個(gè) UA 向另外一個(gè) UA 或者代理服務(wù)器查詢對(duì)方的能力。這讓客 戶機(jī)不必向?qū)Ψ健罢疋彙本涂梢垣@得對(duì)方地下列信息：包括支持的方法、內(nèi)容類(lèi)型、擴(kuò)展名、以及編解碼方法等等。例如，客戶機(jī)要在 INVITE 中插入 Require 頭字段之前，并不確定目的地 UAS 是否支持Require 中所列的選項(xiàng)，則客戶機(jī)就可以使用 OPTIONS 方法看目的地 UAS 回應(yīng)的 Supported 字段中是否包括這個(gè)選項(xiàng)以確定對(duì)方是否支持它。所有的用戶代理都應(yīng)支持 OPTIONS 方法 。 OPTIONS 請(qǐng)求的目標(biāo)由 RequestURI 來(lái)指定，它可以指定另外一個(gè) UA 或者 SIP 服務(wù)器。 如果 OPTIONS 發(fā)送到一個(gè)代理服務(wù)器，那么 RequestURI 的設(shè)置方法就如同 REGISTER 請(qǐng)求，其中沒(méi)有用戶部分。 服務(wù)器收到的 OPTIONS 請(qǐng)求中的 MaxForwards 頭字段的值是 0，那么它可以響應(yīng)這個(gè)請(qǐng)求，而不必考慮 RequestURI 的值。這種處理如同 HTTP/，可以用作“路徑”功能，通過(guò)發(fā)送一系列包含遞增的 MaxForwards 值的 OPTIONS 請(qǐng)求來(lái)來(lái)查詢路徑中每個(gè)服務(wù)器的 能力。 如果 OPTIONS 沒(méi)有響應(yīng)，事務(wù)層就返回一個(gè)超時(shí)錯(cuò)誤來(lái)表明目標(biāo)不可達(dá)。 發(fā)送 OPTIONS 請(qǐng)求也可以作為已建立的對(duì)話的一部分，可以詢問(wèn)對(duì)等體的能力以備將來(lái)的對(duì)話所用。 OPTIONS 請(qǐng)求的構(gòu)造 如何構(gòu)造 OPTIONS 請(qǐng)求參見(jiàn)本規(guī)范 中構(gòu)建 SIP 請(qǐng)求的規(guī)則。 OPTIONS 請(qǐng)求中可以包括一個(gè) Contact 頭字段。 YD — 18 OPTIONS 請(qǐng)求中應(yīng)包括一個(gè) Accept 頭字段，該字段指明在所收到的響應(yīng)中， UAC 支持的消息體的類(lèi)型。一般情況下，該字段被設(shè)置成用來(lái)描述 UA 媒體能力的格式，例如 SDP (application/sdp)。 OPTIONS 的響應(yīng)的范圍是初始請(qǐng)求的 RequestURI。然而，只有 OPTIONS 請(qǐng)求作為已建立的對(duì)話的一部分發(fā)送時(shí)，后續(xù)的請(qǐng)求才能夠被產(chǎn)生 OPTIONS 響應(yīng)的服務(wù)器收到。 OPTIONS 請(qǐng)求的例子如下： OPTIONS sip: SIP/ Via: SIP/。branch=z9hG4bKhjhs8ass877 MaxForwards: 70 To: sip: From: Alice sip:。tag=1928301774 CallID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: sip: Accept: application/sdp ContentLength: 0 OPTIONS 請(qǐng)求的處理 如何構(gòu)造 OPTIONS 響應(yīng)參見(jiàn)本規(guī)范 中 SIP 響應(yīng)的構(gòu)造方法。響應(yīng)碼的選擇同 INVITE 請(qǐng)求。即，當(dāng) UAS 準(zhǔn)備接受呼叫時(shí)返回響應(yīng) 200 (OK)， ,UAS 忙時(shí)返回響應(yīng) 486 (正忙 )。這樣，用 OPTIONS 來(lái)確定 UAS 的基本狀態(tài)并指出該 UAS 是否接受 INVITE 請(qǐng)求。 在對(duì)話中收到