久久久中文字幕,少妇裸体婬交免费视频,亚洲国产亚洲片在线观看播放

　　8.1.1.5 CSeq

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

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

　　例如：

　　CSeq: 4711 INVITE

　　8.1.1.6 Max-Forwards

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

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

　　8.1.1.7 Via

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

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

　　無(wú)論是從空間和時(shí)間角度來(lái)看，branch參數(shù)在這個(gè)UA發(fā)送的所有請(qǐng)求中具有唯一性。這個(gè)規(guī)則對(duì)CANCEL和non-2xx響應(yīng)的ACK是例外。就像我們?cè)谙旅嬗懻摰囊粯�，CANCEL 請(qǐng)求的branch參數(shù)和這個(gè)請(qǐng)求被取消的參數(shù)是一樣的。同樣，在Section 17.1.1.3的討論中，一個(gè)對(duì)non-2xx響應(yīng)的ACK響應(yīng)也有同樣的branch ID，這個(gè)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ī)范的格式來(lái)處理，它必須以字符"z9hG4bK"開(kāi)頭。這七個(gè)字符是一種比較神奇的處理方式（7被認(rèn)為可以支持足夠的資源，以便保證和舊規(guī)范RFC 2543兼容，舊規(guī)范沒(méi)有選擇這個(gè)數(shù)值，所以不會(huì)導(dǎo)致沖突），因此，收到這個(gè)請(qǐng)求的服務(wù)器端可以決定通過(guò)這種方式來(lái)構(gòu)建branch ID。

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

　　對(duì)于代理來(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示例的后續(xù)的請(qǐng)求。這個(gè)頭必須是現(xiàn)存狀態(tài)，并且在請(qǐng)求中包含完整的SIP或者SIPS URL，可以支持dialog創(chuàng)建。在此規(guī)范中定義的methods，它們僅包括INVITE請(qǐng)求。對(duì)于這些請(qǐng)求來(lái)說(shuō)，Contact的范圍是全局的。這也表示，Contact頭值包含一個(gè)URL，UA通過(guò)這個(gè)URL接收請(qǐng)求，并且這個(gè)URL必須是有效的，甚至可以使用在后續(xù)的請(qǐng)求中，這些請(qǐng)求已經(jīng)不在dialog范圍內(nèi)的請(qǐng)求。

　　如果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ù)器端可以支持對(duì)此的響應(yīng)，UAC應(yīng)該在請(qǐng)求中列出一個(gè)可選標(biāo)簽tags來(lái)表示可支持的拓展功能，可選擇并且參考（Section 19.2）。

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

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

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

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

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

　　待續(xù)……