CSeq 頭的目的是對事務(wù)確認和排序。它由一個(gè)序列號和一個(gè)method構成。這個(gè)method 必須匹配請求的method。對于dialog之外的非-注冊請求，此序列號碼是一個(gè)任意值。這個(gè)序列號碼必須是一個(gè)可表達的值，此值是一個(gè)32-bit unsigned 整數，并且它必須少于 2**31。只要它遵守以上指南，客戶(hù)端可以使用任意機制選擇CSeq頭。
Section 12.2.1.1 討論了在dialog中CSeq的構成方式。
例如：
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
Max-Forwards頭支持一個(gè)有限的躍點(diǎn)數，此躍點(diǎn)數是一個(gè)請求從此路徑開(kāi)始的初始點(diǎn)到傳輸到最終目的地經(jīng)過(guò)的躍點(diǎn)。它由一個(gè)整數構成，每經(jīng)過(guò)一個(gè)躍點(diǎn)，躍點(diǎn)數會(huì )自動(dòng)減少一個(gè)數字。如果這個(gè)Max-Forwards值在抵達請求的最終目的地前降低到0，它將會(huì )被拒絕，同時(shí)返回一個(gè)483（Too Many Hops） 錯誤響應。
UAC必須在每個(gè)請求中插入一個(gè)Max-Forwards頭，發(fā)起的請求中初始的這個(gè)值應該是70。 這個(gè)數值已經(jīng)足夠大，可以保證在一個(gè)SIP網(wǎng)絡(luò )環(huán)境中沒(méi)有環(huán)路時(shí)請求不會(huì )被丟棄，但是有時(shí)環(huán)路發(fā)生的時(shí)候可能也沒(méi)有消耗很多的代理資源。用戶(hù)可以選擇比較低的值設置，但是一定要注意，UA需要了解此網(wǎng)絡(luò )拓撲環(huán)境。
8.1.1.7 Via
Via頭值表示一個(gè)傳輸方式，這個(gè)傳輸方式實(shí)際上是響應消息發(fā)送到地址，這個(gè)地址是針對事務(wù)和確認來(lái)說(shuō)的。只有下一跳的傳輸選擇以后，Via頭才能被添加（參考使用流程[4]）。
當UAC創(chuàng )建一個(gè)請求后，它必須在請求中插入一個(gè)Via。協(xié)議名稱(chēng)和協(xié)議版本必須是SIP 和2.0。 Via 頭必須包含一個(gè)branch參數。這個(gè)參數用來(lái)確認被這個(gè)請求創(chuàng )建的事務(wù)。這個(gè)參數支持客戶(hù)端和服務(wù)器端。
無(wú)論是從空間和時(shí)間角度來(lái)看，branch參數在這個(gè)UA發(fā)送的所有請求中具有唯一性。這個(gè)規則對CANCEL和non-2xx響應的ACK是例外。就像我們在下面討論的一樣，CANCEL 請求的branch參數和這個(gè)請求被取消的參數是一樣的。同樣，在Section 17.1.1.3的討論中，一個(gè)對non-2xx響應的ACK響應也有同樣的branch ID，這個(gè)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必須按照規范的格式來(lái)處理，它必須以字符"z9hG4bK"開(kāi)頭。這七個(gè)字符是一種比較神奇的處理方式（7被認為可以支持足夠的資源，以便保證和舊規范RFC 2543兼容，舊規范沒(méi)有選擇這個(gè)數值，所以不會(huì )導致沖突），因此，收到這個(gè)請求的服務(wù)器端可以決定通過(guò)這種方式來(lái)構建branch ID。
Via頭的maddr，ttl，和其他請求將在傳輸層處理（Section 18）。
對于代理來(lái)說(shuō)，Via處理方式在Section 16.6Item 8 和Section 16.7 Item 3說(shuō)明。
8.1.1.8 Contact
Contact頭提供一個(gè)SIP或SIPS URL，這個(gè)URL用來(lái)聯(lián)系指定的UA示例的后續的請求。這個(gè)頭必須是現存狀態(tài)，并且在請求中包含完整的SIP或者SIPS URL，可以支持dialog創(chuàng )建。在此規范中定義的methods，它們僅包括INVITE請求。對于這些請求來(lái)說(shuō)，Contact的范圍是全局的。這也表示，Contact頭值包含一個(gè)URL，UA通過(guò)這個(gè)URL接收請求，并且這個(gè)URL必須是有效的，甚至可以使用在后續的請求中，這些請求已經(jīng)不在dialog范圍內的請求。
如果Request-URI或最頂部的Route 頭值中包含了一個(gè)SIPS URL，這個(gè)Contact也必須包含一個(gè)SIPS。
關(guān)于更多Contact頭域的說(shuō)明，參考Section 20.10。
8.1.1.9 Supported and Require
如果UAC支持拓展功能的話(huà)，服務(wù)器端可以支持對此的響應，UAC應該在請求中列出一個(gè)可選標簽tags來(lái)表示可支持的拓展功能，可選擇并且參考（Section 19.2）。
列出的可選標簽必須來(lái)源于在標準規范RFC中定義的拓展。這樣做的目的是服務(wù)器端防止客戶(hù)端強制使用非標準的，或廠(chǎng)家定義的功能接收服務(wù)。在一個(gè)請求中，測試類(lèi)的和信息類(lèi)的RFC拓展明確說(shuō)明不能使用在Supported頭中，因此，我們經(jīng)常看到使用由廠(chǎng)家定義的拓展。
如果UAC希望堅持讓服務(wù)器理解這個(gè)拓展功能，UAC堅持使用這個(gè)拓展的話(huà)，UAC必須在請求中插入一個(gè)Require頭，這個(gè)頭在可選標簽中列出來(lái)表示需要服務(wù)器端支持這個(gè)拓展。
如果UAC希望在代理中堅持使用這個(gè)拓展功能的話(huà)，并且需要在代理路徑理解這個(gè)拓展的話(huà)，UAC必須在請求可選標簽列表中插入一個(gè)Proxy-Require頭表示需要代理支持的拓展。
就像剛才在Supported頭使用說(shuō)明的一樣，在Require和Proxy-Require頭中的可選標簽所支持的拓展必須來(lái)自于標準RFC定義的拓展。
關(guān)于更多Contact頭域的說(shuō)明，參考Section 20.10。
待續……
關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx，FreeSBC技術(shù)文檔：www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk / FreePBX / FreeSBC中國合作伙伴，官方qq技術(shù)分享群（3000人）：589995817
