【文章內(nèi)容簡(jiǎn)介】 ；如果這個(gè)字符串被用來(lái)構(gòu)造一個(gè) SIPS URI 的用戶部分，則用戶希望進(jìn)行安全的通信，同時(shí)用戶名將在 @符號(hào)右側(cè)所示的主域中被解析 。 SIP URI 中 @符號(hào)右側(cè)通常是請(qǐng)求發(fā)起方 的主域，它使本地主域能夠處理外發(fā)請(qǐng)求。此外，如果用戶輸入的是一個(gè)電話號(hào)碼，且UA 不會(huì)指定由某個(gè)主域來(lái)解釋該號(hào)碼，這時(shí)可以使用 tel URL，從而使請(qǐng)求消息所經(jīng)過(guò)的每一個(gè)主域都可以處理它。例如：一個(gè)來(lái)到機(jī)場(chǎng)的用戶可能登錄機(jī)場(chǎng)的外撥代理服務(wù)器并通過(guò)它發(fā)送請(qǐng)求，如果用戶輸入 ”411”（美國(guó)本地電話查號(hào)臺(tái)號(hào)碼），那么該號(hào)碼應(yīng)由機(jī)場(chǎng)的外撥代理服務(wù)器來(lái)分析和處理，而不是用戶的本地主域。此時(shí)正確構(gòu)造的 URI 應(yīng)該是“ tel:411”。 請(qǐng)求消息的 To 標(biāo)簽標(biāo)識(shí)了一個(gè)對(duì)話中的對(duì)端，如果對(duì)話沒(méi)有建立，標(biāo)簽就不應(yīng)當(dāng)出現(xiàn)。對(duì)話之外的請(qǐng)求消息中不可以包含 To 標(biāo)簽（ tag）。 關(guān)于 To 頭字段參見(jiàn)本規(guī)范 節(jié)。下例是一個(gè)有效的 To 頭字段： To： Carol sip： From 頭字段 From 頭字段是指示請(qǐng)求發(fā)起方的邏輯標(biāo)識(shí)，它可能是用戶的注冊(cè)地址。 From 頭字段包含一個(gè) URI和一個(gè)可選的顯示名稱。 SIP 實(shí)體用它來(lái)決定如何處理一個(gè)請(qǐng)求（如呼叫自動(dòng)拒絕）。由于不是邏輯名YD — 7 稱，因此 From URI 不包含 IP 地址或 UA 所在主機(jī)的全稱域名（ FQDN）。 From 頭字段中允許包含一個(gè)顯示名稱。如果一個(gè) UAC 需要隱藏自己的身份，它可以使用“ Anonymous”作為顯示名稱和一個(gè)語(yǔ)法正確但沒(méi)有任何意義的 URI。（如 sip:） 通常，某個(gè) UA 產(chǎn)生的請(qǐng)求消息中的 From 頭字段值是由用戶或用戶本地主域的服務(wù)器預(yù)先設(shè)置的。如果 UA 被多個(gè)用戶所共用，那么它可以有多個(gè)可切換的用戶配置文件，每一文件中含有某一用戶的URI。請(qǐng)求消息的接收者要對(duì)發(fā)送者進(jìn)行鑒權(quán)，以確認(rèn)發(fā)送者身份與 From 頭字段相一致。關(guān)于鑒權(quán)參見(jiàn)本規(guī)范第 22 章。 From 頭字段中必須包含一個(gè)新的由 UAC 選定的 “ tag”參數(shù)。 關(guān)于 From 頭字段參見(jiàn)本規(guī)范 節(jié)。例如： From: ”Bob” sips:。 tag=a48s From: sip:。 tag=887s From: Anonymous sip:。 tag=hyh8 CallID 頭字段 CallID 頭字段是用來(lái)將消息分組的唯一性標(biāo)識(shí)。本協(xié)議規(guī)定，在一個(gè)對(duì)話中， UA 發(fā)送的所有請(qǐng)求消息和響應(yīng)消息都必須有同樣的 CallID。一個(gè) UA 每次注冊(cè)所用的 CallID 也應(yīng)是一樣的。 當(dāng) UAC 產(chǎn)生一個(gè)新的對(duì)話外請(qǐng)求時(shí)，除非被某些方法指定，否則它必須為這個(gè)請(qǐng)求消息選擇一個(gè)在空間上和時(shí)間上都是全局唯一的 CallID 頭字段。所有的 SIP UA 都必須保證它所產(chǎn)生的 CallID 不會(huì)與其它 UA 所產(chǎn)生的相同。當(dāng) UA 收到某些失敗的響應(yīng)后，請(qǐng)求會(huì)根據(jù)響應(yīng)的內(nèi)容修改并重發(fā)，這些重發(fā)的請(qǐng)求不作為新請(qǐng)求處理，因而也就不需要新的 CallID 頭字段。 本規(guī)范建議使用 RFC1750 中的加密隨機(jī)標(biāo)識(shí)符生成方法來(lái)生成 CallID。 具體實(shí)現(xiàn)可 采 用localid@host 的形式。 CallID 對(duì)大小寫敏感，需逐字節(jié)的進(jìn)行比較。 加密隨機(jī)標(biāo)識(shí)符方法在一定程度上能防范黑客的會(huì)話攻擊，并降低了無(wú)意中產(chǎn)生 CallID 沖突的可能性。 CallID 的選擇不需要通過(guò)人機(jī)接口和預(yù)先設(shè)定值來(lái)實(shí)現(xiàn)。 關(guān)于 CallID 頭字段參見(jiàn)本規(guī)范 節(jié)。下例是一個(gè)有效的 CallId： CallID： Cseq 頭字段 CSeq 頭字段用于標(biāo)識(shí)事務(wù)并對(duì)事務(wù)進(jìn)行排序。它由一個(gè)請(qǐng)求方法 和一個(gè)序列號(hào)組成，請(qǐng)求方法必須與對(duì)應(yīng)的請(qǐng)求消息類型一致。對(duì)話外的非 REGISTER 請(qǐng)求，序列號(hào)值可以是任意的。但它必須可被表示成一個(gè) 32 位的無(wú)符號(hào)整數(shù)，且小于 231。只要符合以上規(guī)則，客戶端可以用任何方式來(lái)選擇 Cseq頭字段值。 關(guān)于如何構(gòu)造在對(duì)話中發(fā)送的請(qǐng)求消息的 CSeq 頭字段參見(jiàn)本規(guī)范 節(jié)。下例是 Cseq 頭字段： CSeq： 4711 INVITE MaxFowords 頭字段 YD — 8 MaxFowords 頭字段限定一個(gè)請(qǐng)求消息在到達(dá)目的地之前允許經(jīng)過(guò)的最大跳數(shù)。它包含一個(gè)整數(shù)值，每經(jīng)過(guò)一跳，這 個(gè)值就被減一。如果在請(qǐng)求消息到達(dá)目的地之前該值變?yōu)榱悖敲凑?qǐng)求將被拒絕并返回一個(gè) 483（跳數(shù)過(guò)多）錯(cuò)誤響應(yīng)消息。 UAC 必須在它發(fā)起的每個(gè)請(qǐng)求中都插入 MaxFowords 頭字段，值為 70。在任何不出現(xiàn)回路的 SIP網(wǎng)絡(luò)中，選擇該值為 70 足夠大的保證一個(gè)請(qǐng)求消息不被丟棄，且在有回路的情況下，這個(gè)值也不會(huì)太大而過(guò)分浪費(fèi)代理服務(wù)器的資源。 UA 只有知道網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)時(shí)，才可以謹(jǐn)慎地選擇更小的跳數(shù)值。 Via 頭字段 Via 頭字段定義 SIP 事務(wù)的下層（傳輸層）傳輸協(xié)議，并標(biāo)識(shí)響應(yīng)消息將要被發(fā)送的位置。只有當(dāng)?shù)竭_(dá)下一 跳所用的傳輸協(xié)議被選定后，才能在請(qǐng)求消息中加入 Via 頭字段值。 本協(xié)議規(guī)定，當(dāng) UAC 生成請(qǐng)求消息時(shí)，它必須在其中插入一個(gè) Via 頭字段。 Via 頭字段的協(xié)議名稱和協(xié)議版本必須分別為“ SIP”和“ ”。 Via 頭字段中必須包含一個(gè)“ branch”參數(shù)，該參數(shù)用來(lái)標(biāo)識(shí)由當(dāng)前請(qǐng)求所建立的事務(wù)。該參數(shù)既用在客戶端也用在服務(wù)器端。 對(duì)于某個(gè) UA 發(fā)出的所有請(qǐng)求，它們的 branch 參數(shù)值在空間和時(shí)間上必須全局唯一的。但有兩種情況例外：一是 CANCEL 請(qǐng)求，以后會(huì)說(shuō)明 CANCEL 請(qǐng)求的 branch 參數(shù)與它所要取消的那個(gè)請(qǐng) 求的branch 參數(shù)是一樣的；另一個(gè)是對(duì)非 2xx 響應(yīng)的 ACK 請(qǐng)求，參見(jiàn)本規(guī)范 節(jié)，這種情況下 ACK請(qǐng)求與相關(guān)的 INVITE 請(qǐng)求有著同樣的 branch ID，它所要確認(rèn)的就是該 INVITE 的響應(yīng)。 branch ID 參數(shù)的唯一性特點(diǎn)使它能被用作事務(wù)的 ID，但并不在 RFC2543 的討論范圍之內(nèi)。 SIP 實(shí)體在插入 branch ID 時(shí)，必須以 ”z9hG4bK”開(kāi)頭。這 7 個(gè)字符是“ magic cookie”（ 7 個(gè)字符足以保證不會(huì)與舊的 RFC2543 實(shí)體的選取值相同），這樣 SIP 服務(wù)器在收到請(qǐng)求消息 時(shí)，就能確定現(xiàn)在的branch ID 是全局唯一。另外， branch ID 參數(shù)的準(zhǔn)確格式由具體的實(shí)現(xiàn)定義。 Via 頭的 maddr、 ttl、以及 sentby 部分在傳輸層對(duì)請(qǐng)求消息進(jìn)行處理時(shí)進(jìn)行設(shè)置，參見(jiàn)本規(guī)范第 18章。 關(guān)于代理服務(wù)器對(duì) Via 頭字段的處理參見(jiàn)本規(guī)范 節(jié)和 節(jié)。 Contact 頭字段 Contact 頭字段指定一個(gè) SIP 或 SIPS URI，后續(xù)請(qǐng)求可以用它來(lái)聯(lián)系到當(dāng)前 UA。任何能夠建立對(duì)話的請(qǐng)求消息中都必須有 Contact 頭字段，并且該頭字段中只能含有一個(gè) SIP 或 SIPS URI。 在本規(guī)范定義的請(qǐng)求方法中，只有 INVITE 能建立對(duì)話。對(duì)這些能建立對(duì)話的請(qǐng)求， Contact 的作用范圍是全局的。也就是說(shuō)， Contact 頭字段值中包含的 URI 是 UA 希望用來(lái)接收請(qǐng)求的地址，即使用在任何對(duì)話外的后續(xù)請(qǐng)求消息中，該 URI 也必須有效。 如果請(qǐng)求消息的 RequestURI 或頂端 Route 頭字段值中包含了 SIPS URI，那么在 Contact 頭字段中也必須包含一個(gè) SIPS URI。 關(guān)于 Contact 頭字段參見(jiàn)本規(guī)范 節(jié)。 Supported 和 Require 頭字段 如果 UAC 支持某些 SIP 協(xié)議的擴(kuò)展，并且這些擴(kuò)展可被服務(wù)器用來(lái)構(gòu)成請(qǐng)求的響應(yīng)，那么 UAC應(yīng)在請(qǐng)求消息中包含一個(gè) Supported 頭字段，列出這些擴(kuò)展的選項(xiàng)標(biāo)簽。 YD — 9 只有在 RFC 規(guī)范中定義的擴(kuò)展所對(duì)應(yīng)的選項(xiàng)標(biāo)簽?zāi)軌蛟?Supported 頭字段中列出。在實(shí)驗(yàn)性和信息性 RFC 中定義的擴(kuò)展禁止在 Supported 頭字段中使用。 如果 UAC 要求 UAS 必須理解某項(xiàng)擴(kuò)展以便處理它所發(fā)出的請(qǐng)求，它必須在請(qǐng)求消息中插入一個(gè)Require 頭字段，并列出此擴(kuò)展的選項(xiàng)標(biāo)簽。如果 UAC 希望在請(qǐng)求中使用某項(xiàng)擴(kuò)展，并要求請(qǐng)求消息經(jīng)過(guò)的所有代理服務(wù)器都能理解 此擴(kuò)展，它必須在請(qǐng)求消息中插入一個(gè) ProxyRequire 頭字段，并列出此擴(kuò)展的選項(xiàng)標(biāo)簽。 同 Supported 頭字段一樣， Require 和 ProxyRequire 頭字段中的選項(xiàng)標(biāo)簽所對(duì)應(yīng)的擴(kuò)展也必須是在標(biāo)準(zhǔn) RFC 的后續(xù)規(guī)范中定義的。 消息的其它部分 在新的請(qǐng)求消息生成且上述頭字段被正確構(gòu)造之后，可加入任何其它的可選頭字段和請(qǐng)求方法所要求的特定頭字段。 SIP 請(qǐng)求消息中可包含一個(gè)按 MIME 格式編碼的消息體。無(wú)論請(qǐng)求中包含的消息體類型如何，都必須構(gòu)造某些頭字段以表征消息體的內(nèi)容。這部分頭字段的內(nèi)容參 見(jiàn)本規(guī)范 節(jié)到 節(jié)。 請(qǐng)求消息的發(fā)送 首先確定請(qǐng)求消息的發(fā)送目的地。除非另有本地策略，目的地址必須按照 RFC3263 中的 DNS 過(guò)程確定：如果 Route 頭字段中路由集的第一個(gè)實(shí)體是個(gè)嚴(yán)格的路由器，（請(qǐng)求消息按本規(guī)范 節(jié)所述構(gòu)造）， RFC3263 中的過(guò)程必須被應(yīng)用于請(qǐng)求消息的 RequestURI；否則， RFC3263 中的過(guò)程應(yīng)用于請(qǐng)求消息中的第一個(gè) Route 頭字段值，若沒(méi)有 Route 頭字段出現(xiàn)則 RFC3263 中的過(guò)程仍然應(yīng)用于請(qǐng)求消息的 RequestURI。其輸出結(jié)果是個(gè)可以發(fā) 送的目標(biāo)地址有序集，其中每一項(xiàng)是個(gè)由地址、端口號(hào)以及傳輸協(xié)議構(gòu)成的三元組。不論用哪個(gè) URI 作為 RFC3263 過(guò)程的輸入，如果 RequestURI 指定一個(gè) SIPS資源， UAC 就必須把這個(gè) URI 當(dāng)作 SIPS URI 來(lái)解析。 本地策略可指定其它目標(biāo)地址集。如果 RequestURI 中包含的是 SIPS URI，那么同該地址集中的任何目的地址聯(lián)系都必須使用 TLS。此外，如果請(qǐng)求消息中不含 Route 頭字段，那么對(duì)該地址集中的地址沒(méi)有其它限制。當(dāng)指定一個(gè)外撥代理服務(wù)器時(shí)，這樣做比預(yù)設(shè)路由集簡(jiǎn)單。但是，本規(guī)范建議用只含 單個(gè) URI 的預(yù)設(shè)路由集來(lái)指定外撥代理服務(wù)器。如果請(qǐng)求消息中含有 Route 頭字段，那么請(qǐng)求消息應(yīng)當(dāng)發(fā)送到最頂端 Route 頭字段值所指示的位置；也可發(fā)送到任何其它的服務(wù)器。只要 UA 確認(rèn)這些服務(wù)器遵循本規(guī)范中對(duì) Route 和 RequestURI 的處理策略。本規(guī)范建議，配置了外撥代理服務(wù)器的 UAC 應(yīng)該嘗試將請(qǐng)求發(fā)往第一個(gè) Route 頭字段值所指的位置，而不是將所有消息都發(fā)往外撥代理服務(wù)器。 這保證了那些不向請(qǐng)求消息中加入 RecordRoute 頭字段值的外撥代理服務(wù)器能從后續(xù)請(qǐng)求的傳輸路徑上離開(kāi)。使那些不能解析第一 個(gè) Route URI 的終端可以將此任務(wù)委托給外撥代理服務(wù)器。 對(duì)于有狀態(tài) SIP 實(shí)體， UAC 應(yīng)當(dāng)遵循 RFC3263 中定義的過(guò)程嘗試目標(biāo)地址集中的每個(gè)地址，直到聯(lián)系上某個(gè)服務(wù)器。每次嘗試都會(huì)建立新的事務(wù)，因而每個(gè)新請(qǐng)求的最頂端 Via 頭字段值都不同，其中包含著新的 branch 參數(shù)。此外， Via 頭字段中的 transport 值也要根據(jù)不同的目標(biāo)服務(wù)器來(lái)設(shè)置。 響應(yīng)消息處理 響應(yīng)消息先由傳輸層處理，然后上傳到事務(wù)層。經(jīng)事務(wù)層處理后再將其上傳給事務(wù)用戶（ TU）。 TU對(duì)響應(yīng)消息的處理主要依賴于請(qǐng)求方法，但是一些基本處理方 法則同具體的請(qǐng)求方法無(wú)關(guān)。 事務(wù)層錯(cuò)誤 YD — 10 某些情況下，從事務(wù)層返回的并不是 SIP 消息，而是事務(wù)層錯(cuò)誤消息。當(dāng) TU從事務(wù)層收到超時(shí)錯(cuò)誤消息時(shí)，對(duì)該消息的處理必須同 408（請(qǐng)求超時(shí)）狀態(tài)碼。如果事務(wù)層報(bào)告的是嚴(yán)重錯(cuò)誤，通常是UDP 方式下的嚴(yán)重 ICMP 錯(cuò)誤或 TCP 連接失敗所致，則該消息的處理同 503（業(yè)務(wù)不可用）狀態(tài)碼。 無(wú)法識(shí)別的響應(yīng)消息 對(duì)無(wú)法識(shí)別的最終響應(yīng)， UAC 必須將之等價(jià)于所屬響應(yīng)類別的 x00 響應(yīng)碼，且 UAC 必須能夠處理所有響應(yīng)類別的 x00 響應(yīng)碼。例如：如果 UAC 收到了一個(gè)無(wú)法識(shí)別的響應(yīng)碼 431，那么它能 斷定自己發(fā)出的請(qǐng)求消息出錯(cuò)，因而對(duì)該 431 碼的處理同 400（錯(cuò)誤請(qǐng)求）響應(yīng)碼。但對(duì)于任何無(wú)法識(shí)別的非 100臨時(shí)響應(yīng)的處理必須同 183 響應(yīng)（會(huì)話處理中）。 UAC 必須能夠處理 100 和 183 響應(yīng)。 多 Via 頭字段值 如果某個(gè)響應(yīng)消息中出現(xiàn)了多個(gè) Via 頭字段值， UAC 應(yīng)當(dāng)丟棄該響應(yīng)。 在標(biāo)識(shí)請(qǐng)求發(fā)起者的 Via 頭字段值之前出現(xiàn)了其它的 Via 頭字段值，表明消息在傳送過(guò)程中發(fā)生了路由錯(cuò)誤，或者已被破壞。 3xx 響應(yīng)碼處理 客戶端在收到重定向響應(yīng)時(shí)，應(yīng)基于相應(yīng)的重定向的請(qǐng)求消息的 Contact 頭字段中的 URI 來(lái)構(gòu)造一個(gè)或 多個(gè)新的請(qǐng)求消息。這同在 和 節(jié)中代理服務(wù)器遞歸處理 3xx 類響應(yīng)的過(guò)程類似?？蛻舳说哪繕?biāo)地址集中最初只有一個(gè) URI，即初始請(qǐng)求的 RequestURI。如果客戶端要根據(jù)初始請(qǐng)求的一個(gè) 3xx