一区二区三区毛片免费,505047.com

　　8.1.1.5 CSeq

　　CSeq 頭的目的是對事務確認和排序。它由一個序列號和一個method構成。這個method 必須匹配請求的method。對于dialog之外的非-注冊請求，此序列號碼是一個任意值。這個序列號碼必須是一個可表達的值，此值是一個32-bit unsigned 整數(shù)，并且它必須少于 2**31。只要它遵守以上指南，客戶端可以使用任意機制選擇CSeq頭。

　　Section 12.2.1.1 討論了在dialog中CSeq的構成方式。

　　例如：

　　CSeq: 4711 INVITE

　　8.1.1.6 Max-Forwards

　　Max-Forwards頭支持一個有限的躍點數(shù)，此躍點數(shù)是一個請求從此路徑開始的初始點到傳輸?shù)阶罱K目的地經(jīng)過的躍點。它由一個整數(shù)構成，每經(jīng)過一個躍點，躍點數(shù)會自動減少一個數(shù)字。如果這個Max-Forwards值在抵達請求的最終目的地前降低到0，它將會被拒絕，同時返回一個483（Too Many Hops）錯誤響應。

　　UAC必須在每個請求中插入一個Max-Forwards頭，發(fā)起的請求中初始的這個值應該是70。這個數(shù)值已經(jīng)足夠大，可以保證在一個SIP網(wǎng)絡環(huán)境中沒有環(huán)路時請求不會被丟棄，但是有時環(huán)路發(fā)生的時候可能也沒有消耗很多的代理資源。用戶可以選擇比較低的值設置，但是一定要注意，UA需要了解此網(wǎng)絡拓撲環(huán)境。

　　8.1.1.7 Via

　　Via頭值表示一個傳輸方式，這個傳輸方式實際上是響應消息發(fā)送到地址，這個地址是針對事務和確認來說的。只有下一跳的傳輸選擇以后，Via頭才能被添加（參考使用流程[4]）。

　　當UAC創(chuàng)建一個請求后，它必須在請求中插入一個Via。協(xié)議名稱和協(xié)議版本必須是SIP 和2.0。 Via 頭必須包含一個branch參數(shù)。這個參數(shù)用來確認被這個請求創(chuàng)建的事務。這個參數(shù)支持客戶端和服務器端。

　　無論是從空間和時間角度來看，branch參數(shù)在這個UA發(fā)送的所有請求中具有唯一性。這個規(guī)則對CANCEL和non-2xx響應的ACK是例外。就像我們在下面討論的一樣，CANCEL 請求的branch參數(shù)和這個請求被取消的參數(shù)是一樣的。同樣，在Section 17.1.1.3的討論中，一個對non-2xx響應的ACK響應也有同樣的branch ID，這個ID和INVITE響應它的是一樣的。

　　The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543.

　　branch ID必須按照規(guī)范的格式來處理，它必須以字符"z9hG4bK"開頭。這七個字符是一種比較神奇的處理方式（7被認為可以支持足夠的資源，以便保證和舊規(guī)范RFC 2543兼容，舊規(guī)范沒有選擇這個數(shù)值，所以不會導致沖突），因此，收到這個請求的服務器端可以決定通過這種方式來構建branch ID。

　　Via頭的maddr，ttl，和其他請求將在傳輸層處理（Section 18）。

　　對于代理來說，Via處理方式在Section 16.6Item 8 和Section 16.7 Item 3說明。

　　8.1.1.8 Contact

　　Contact頭提供一個SIP或SIPS URL，這個URL用來聯(lián)系指定的UA示例的后續(xù)的請求。這個頭必須是現(xiàn)存狀態(tài)，并且在請求中包含完整的SIP或者SIPS URL，可以支持dialog創(chuàng)建。在此規(guī)范中定義的methods，它們僅包括INVITE請求。對于這些請求來說，Contact的范圍是全局的。這也表示，Contact頭值包含一個URL，UA通過這個URL接收請求，并且這個URL必須是有效的，甚至可以使用在后續(xù)的請求中，這些請求已經(jīng)不在dialog范圍內(nèi)的請求。

　　如果Request-URI或最頂部的Route 頭值中包含了一個SIPS URL，這個Contact也必須包含一個SIPS。

　　關于更多Contact頭域的說明，參考Section 20.10。

　　8.1.1.9 Supported and Require

　　如果UAC支持拓展功能的話，服務器端可以支持對此的響應，UAC應該在請求中列出一個可選標簽tags來表示可支持的拓展功能，可選擇并且參考（Section 19.2）。

　　列出的可選標簽必須來源于在標準規(guī)范RFC中定義的拓展。這樣做的目的是服務器端防止客戶端強制使用非標準的，或廠家定義的功能接收服務。在一個請求中，測試類的和信息類的RFC拓展明確說明不能使用在Supported頭中，因此，我們經(jīng)常看到使用由廠家定義的拓展。

　　如果UAC希望堅持讓服務器理解這個拓展功能，UAC堅持使用這個拓展的話，UAC必須在請求中插入一個Require頭，這個頭在可選標簽中列出來表示需要服務器端支持這個拓展。

　　如果UAC希望在代理中堅持使用這個拓展功能的話，并且需要在代理路徑理解這個拓展的話，UAC必須在請求可選標簽列表中插入一個Proxy-Require頭表示需要代理支持的拓展。

　　就像剛才在Supported頭使用說明的一樣，在Require和Proxy-Require頭中的可選標簽所支持的拓展必須來自于標準RFC定義的拓展。

　　關于更多Contact頭域的說明，參考Section 20.10。

　　待續(xù)……