CSeq 頭的目的是對事務確認和排序。它由一個序列號和一個method構(gòu)成。這個method 必須匹配請求的method。對于dialog之外的非-注冊請求，此序列號碼是一個任意值。這個序列號碼必須是一個可表達的值，此值是一個32-bit unsigned 整數(shù)，并且它必須少于 2**31。只要它遵守以上指南，客戶端可以使用任意機制選擇CSeq頭。
Section 12.2.1.1 討論了在dialog中CSeq的構(gòu)成方式。
例如：
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
Max-Forwards頭支持一個有限的躍點數(shù)，此躍點數(shù)是一個請求從此路徑開始的初始點到傳輸?shù)阶罱K目的地經(jīng)過的躍點。它由一個整數(shù)構(gòu)成，每經(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ù)值，所以不會導致沖突），因此，收到這個請求的服務器端可以決定通過這種方式來構(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支持拓展功能的話，服務器端可以支持對此的響應，UAC應該在請求中列出一個可選標簽tags來表示可支持的拓展功能，可選擇并且參考（Section 19.2）。
列出的可選標簽必須來源于在標準規(guī)范RFC中定義的拓展。這樣做的目的是服務器端防止客戶端強制使用非標準的，或廠家定義的功能接收服務。在一個請求中，測試類的和信息類的RFC拓展明確說明不能使用在Supported頭中，因此，我們經(jīng)�？吹绞褂糜蓮S家定義的拓展。
如果UAC希望堅持讓服務器理解這個拓展功能，UAC堅持使用這個拓展的話，UAC必須在請求中插入一個Require頭，這個頭在可選標簽中列出來表示需要服務器端支持這個拓展。
如果UAC希望在代理中堅持使用這個拓展功能的話，并且需要在代理路徑理解這個拓展的話，UAC必須在請求可選標簽列表中插入一個Proxy-Require頭表示需要代理支持的拓展。
就像剛才在Supported頭使用說明的一樣，在Require和Proxy-Require頭中的可選標簽所支持的拓展必須來自于標準RFC定義的拓展。
關(guān)于更多Contact頭域的說明，參考Section 20.10。
待續(xù)……
關(guān)注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx，F(xiàn)reeSBC技術(shù)文檔：www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk / FreePBX / FreeSBC中國合作伙伴，官方qq技術(shù)分享群（3000人）：589995817
