　　8.1.1.5 CSeq

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

　　Section 12.2.1.1 討論了在dialog中CSeq的構(gòu)成方式。

　　例如：

　　CSeq: 4711 INVITE

　　8.1.1.6 Max-Forwards

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

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

　　8.1.1.7 Via

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

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

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

　　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被認(rèn)為可以支持足夠的資源，以便保證和舊規(guī)范RFC 2543兼容，舊規(guī)范沒有選擇這個數(shù)值，所以不會導(dǎo)致沖突），因此，收到這個請求的服務(wù)器端可以決定通過這種方式來構(gòu)建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。

　　關(guān)于更多Contact頭域的說明，參考Section 20.10。

　　8.1.1.9 Supported and Require

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

　　列出的可選標(biāo)簽必須來源于在標(biāo)準(zhǔn)規(guī)范RFC中定義的拓展。這樣做的目的是服務(wù)器端防止客戶端強(qiáng)制使用非標(biāo)準(zhǔn)的，或廠家定義的功能接收服務(wù)。在一個請求中，測試類的和信息類的RFC拓展明確說明不能使用在Supported頭中，因此，我們經(jīng)�？吹绞褂糜蓮S家定義的拓展。

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

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

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

　　關(guān)于更多Contact頭域的說明，參考Section 20.10。

　　待續(xù)……