久久久久女人精品毛片_淺析SIP響應消息100 Trying的作用和傳輸機制 - 文章精選

　　SIP協(xié)議是目前語(yǔ)音呼叫中最重要的協(xié)議之一。所以，在SIP呼叫中我們會(huì )看到呼叫流程中多個(gè)處理流程的交互。在呼叫請求中，系統技術(shù)人員在使用排查根據排查問(wèn)題時(shí)會(huì )看到一個(gè)服務(wù)器端（UAS）響應的消息-100 Trying。大部分VOIP系統用戶(hù)和技術(shù)人員可能沒(méi)有注意或者忽略了它的作用，也沒(méi)有真正深究它背后的其他相關(guān)要素。如果系統出現了呼叫故障的問(wèn)題時(shí)，一些技術(shù)人員也僅僅停留在表面的故障問(wèn)題，根據非常表面的表象來(lái)排查問(wèn)題，沒(méi)有從根本上來(lái)了解其真正的作用。事實(shí)上，100 Trying是請求響應處理中非常重要的核心步驟，它決定了呼叫可靠性傳輸的結果。那么，很多用戶(hù)就會(huì )問(wèn)，100 Trying到底在try什么？如果要回答這個(gè)問(wèn)題，我們必須從最底層的OSI網(wǎng)絡(luò )七層說(shuō)起，一直到SIP傳輸定時(shí)器來(lái)解釋100 Trying所扮演的角色和其作用。

　　筆者通過(guò)以下各個(gè)部分來(lái)淺析100 Trying所扮演的角色，作用和相關(guān)技術(shù)節點(diǎn)處理方式。我們將討論 100 Trying的背景知識，OSI網(wǎng)絡(luò )協(xié)議的相關(guān)話(huà)題，TCP/UDP對SIP傳輸的處理方式，SIP定時(shí)器對可靠性的支持機制，SIP 重傳和定時(shí)器處理流程，以及優(yōu)化方式討論，發(fā)生SIP重傳的幾種原因等相關(guān)話(huà)題進(jìn)行一個(gè)比較初淺的討論。

　　1、SIP呼叫請求響應中的100 Trying

　　首先，我們針對請求呼叫中的100 Trying做一個(gè)簡(jiǎn)單的背景介紹。在SIP呼叫中，下一跳服務(wù)器或UAS收到UAC的請求以后，對客戶(hù)端UAC發(fā)送一個(gè)100 Trying，表示對端已經(jīng)收到請求，正在進(jìn)行下一步的處理（具體處理什么流程，完全取決于UAS本身）。在RFC3261中有對100 Trying如下定義：

This response indicates that the request has been received by the
next-hop server and that some unspecified action is being taken on
behalf of this call （for example, a database is being consulted）.
This response, like all other provisional responses, stops
retransmissions of an INVITE by a UAC. The 100 （Trying） response is
different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.

　　具體的SIP呼叫流程圖如下：

　　比較詳細的100 Trying響應消息如下。這里提醒一下一些基礎讀者，100 Trying會(huì )完全拷貝INVITE中的Call-ID，From，To，CSeg，和VIA頭值，這里沒(méi)有SDP內容長(cháng)度，因此也沒(méi)有SDP消息。

　　在RFC3261中，1XX響應消息是Provisional response（臨時(shí)響應），在上面的100 Trying也說(shuō)明，UAS回復UAC，UAS正在處理收到的請求，僅返回一個(gè)臨時(shí)響應消息，通知UAC而已，沒(méi)有說(shuō)明任何狀態(tài)。當然，在臨時(shí)響應消息中，也包括了180，181和183等其他的響應消息。臨時(shí)響應消息具有以下幾個(gè)方面的特征：

報告一個(gè)處理流程
以1XX為響應回復
無(wú)任何結果狀態(tài)

　　2、網(wǎng)絡(luò )七層協(xié)議OSI

　　基于網(wǎng)絡(luò )協(xié)議的技術(shù)討論都離不開(kāi)關(guān)于OSI模型的討論。在SIP語(yǔ)音呼叫中，協(xié)議協(xié)商也同樣需要討論這些問(wèn)題。

　　對應OSI網(wǎng)絡(luò )模型的結構，具體到SIP應用環(huán)境中，我們可以看到以下網(wǎng)絡(luò )結構。

　　關(guān)于那個(gè)網(wǎng)絡(luò )層的介紹，我們在以前的歷史文章中有非常完整的介紹，讀者可以查閱歷史文檔來(lái)學(xué)習，也可以通過(guò)網(wǎng)上的其他資料來(lái)學(xué)習，這里不做過(guò)多解讀。現在，我們僅對涉及SIP傳輸的transport layer 所使用的TCP和UDP進(jìn)行簡(jiǎn)單分析來(lái)說(shuō)明如何支持SIP的可靠性傳輸。使用TCP傳輸時(shí)，SIP通過(guò)TCP需要和對方檢查，進(jìn)行握手協(xié)商。如果對方確認已經(jīng)準備好接收數據，那么發(fā)送方發(fā)送INVITE消息，對端成功接收。如果TCP確認后，接收方在接收過(guò)程中沒(méi)有收到完整的數據，則丟棄，重新傳輸一次。因此，TCP協(xié)議就是人們常說(shuō)的可靠傳輸協(xié)議，因為它可以保證傳輸的可靠性，因為需要完整的協(xié)商過(guò)程，數據丟失需要重新傳輸，因此可靠性增加，但是和UDP相比，其傳輸速度相對比較慢。

　　下面，我們再來(lái)介紹一下使用UDP傳輸SIP消息的流程。UDP傳輸數據時(shí)，它本身不會(huì )對雙方的狀態(tài)進(jìn)行檢查，直接對對端發(fā)送數據。數據丟失也不支持任何重傳機制，因此，UDP是一種非可靠傳輸協(xié)議。但是，UDP傳輸速度相比TCP就會(huì )快很多，沒(méi)有協(xié)商時(shí)間產(chǎn)生的消耗。既然UDP是不可靠的傳輸協(xié)議，那么，為什么SIP仍然使用UDP作為默認的傳輸協(xié)議？如果不能保證其數據傳輸的可靠性，SIP怎么保證數據傳輸的可靠性？事實(shí)上，SIP通過(guò)定時(shí)器的方式來(lái)實(shí)現可靠性傳輸機制。接下來(lái)，我們將討論使用定時(shí)器來(lái)保證SIP傳輸的可靠性。

　　3、關(guān)于SIP呼叫請求中的定時(shí)器

　　在SIP協(xié)議中，為了保證可靠性傳輸，SIP支持了三種機制實(shí)現可靠性傳輸，它們包括：重轉定時(shí)器，遞增的CSeq和ACK確認。因為篇幅的關(guān)系，我們今天僅討論定時(shí)器的機制，其他兩種機制讀者可以自己學(xué)習。事實(shí)上，在定時(shí)器機制中，SIP就使用了100 Trying了實(shí)現可靠性傳輸。如果沒(méi)有100 Trying，雙方的協(xié)商沒(méi)有辦法繼續進(jìn)行。當然，其他的響應也可以對請求做出一個(gè)確認，但是100 Trying是一個(gè)非常合理簡(jiǎn)單的辦法對初始時(shí)確認進(jìn)行處理的方式。

　　讓我們根據以上圖例來(lái)了解一下定時(shí)器的處理機制。這里，我們假設了3次重復發(fā)生INVITE消息，途中可能遇到的兩種基本的故障。首先，當UAC對UAS發(fā)送INVITE消息時(shí)，定時(shí)器1同時(shí)啟動(dòng)，并且定時(shí)器開(kāi)始計時(shí)。如果第一個(gè)INVITE請求在定時(shí)器1參數設置時(shí)間內超時(shí)，INVITE請求在中途丟失，說(shuō)明可能出現了其他問(wèn)題。接下來(lái)，UAC端則馬上啟動(dòng)第二個(gè)定時(shí)器，并且進(jìn)行超時(shí)設置，第二次發(fā)送的INVITE抵達UAS服務(wù)器端后，UAS馬上返回一個(gè)100 Trying 臨時(shí)響應消息，通知UAS收到了INVITE請求，正在進(jìn)行下一步處理。但是，因為各種網(wǎng)絡(luò )原因，可能UAS發(fā)送的100 Trying在定時(shí)器2超時(shí)設置的時(shí)間內沒(méi)有返回到UAC端，100 Trying也可能在路徑中丟失，UAC沒(méi)有收到100 Trying。因此，在定時(shí)器2超時(shí)后，UAS馬上又啟動(dòng)了第三個(gè)定時(shí)器，同時(shí)再次發(fā)送INVITE消息。這次UAS再次發(fā)送100 Trying，UAC也在超時(shí)設置范圍內收到了100 Trying, 整個(gè)請求的可靠性傳輸成功處理。當然，在實(shí)際SIP交互過(guò)程中，INVITE請求不僅僅使用了三個(gè)定時(shí)器來(lái)處理可靠性測試，實(shí)際上，在INVITE的可靠性傳輸中使用了七次重傳加定時(shí)器來(lái)控制整個(gè)傳輸過(guò)程。下面，我們具體介紹這七個(gè)定時(shí)器計時(shí)的處理流程。

　　4、SIP請求中的重新傳輸和定時(shí)器設置

　　上面，我們討論了SIP發(fā)送INVITE和重傳時(shí)的定時(shí)器和100 Trying的處理機制。實(shí)際上，因為各種網(wǎng)絡(luò )問(wèn)題，在傳輸過(guò)程中，INVITE丟失是經(jīng)常發(fā)生的事情。因此，需要UAC不斷發(fā)送INVITE，直到定時(shí)器超時(shí)。在INVITE傳輸過(guò)程中使用了七次重傳來(lái)控制整個(gè)INVITE重傳過(guò)程，其定時(shí)器共耗費總時(shí)長(cháng)為32秒。這里需要注意的是，每次定時(shí)器計時(shí)時(shí)長(cháng)是上一個(gè)定時(shí)器的2倍時(shí)長(cháng)。在SIP 傳輸的定時(shí)器中，主要涉及了三個(gè)定時(shí)器：

Timer A	initially T1	17.1.1.2	INVITE request retransmission interval, for UDP only
Timer B	64*T1	17.1.1.2	INVITE transaction timeout timer

Timer E

initially T1

17.1.2.2

Non-INVITE request retransmission interval, UDP only

在以上的圖例中，介紹了定時(shí)器T1和定時(shí)器B的關(guān)系。以下具體示例中各個(gè)INVITE傳輸所耗費的時(shí)長(cháng)。

　　這里的定時(shí)器僅是針對INVITE請求來(lái)說(shuō)的，其他非INVITE method可能需要更多的定時(shí)重傳數量。例如，呼叫方首先發(fā)送Bye消息的傳輸則最多需要11次傳輸，也是共耗時(shí)32秒（定時(shí)器B）。這里讀者一定要注意，前面4次傳輸的定時(shí)器時(shí)長(cháng)是以2倍時(shí)長(cháng)增加。從第五次開(kāi)始，定時(shí)器是以4秒的方式遞增，它們的計時(shí)方式是不一樣的。

　　另外需要說(shuō)明的是，在INVITE重傳過(guò)程中，消息內容是一樣的，任何頭都沒(méi)有發(fā)生改變，包括Call-ID， CSeq等。在流程介紹中，筆者沒(méi)有針對專(zhuān)門(mén)的Timer做細節介紹，事實(shí)上，T1的處理在RFC3261中有明確的定義（17.1.1.1），T1的預估的RTT默認是500 ms。還有一種情況是涉及到定時(shí)器B。一些用戶(hù)反映為什么系統總是在差不多30秒的時(shí)候就自動(dòng)掉線(xiàn)。很多情況下，因為防火墻或NAT沒(méi)有正確配置，定時(shí)器B在32秒執行了超時(shí)掛斷。這里，筆者沒(méi)有討論RTT時(shí)延和相關(guān)原因的問(wèn)題，事實(shí)上，RTT時(shí)延也會(huì )導致傳輸超時(shí)。讀者可查閱其他關(guān)于RTT的文章。

　　5、Sip Retransmission原因和必要性

　　根據上面章節的介紹，在實(shí)際生產(chǎn)環(huán)境中，事實(shí)上，SIP重傳是一個(gè)正常的處理流程。那么，為什么會(huì )發(fā)生重新傳輸的問(wèn)題呢？因為網(wǎng)絡(luò )環(huán)境中各種問(wèn)題導致了重新傳輸。包括主要的幾個(gè)原因：

網(wǎng)絡(luò )原因，可能因為網(wǎng)絡(luò )擁塞或者其他的數據路由問(wèn)題導致數據丟失，所以需要重新傳輸。從呼叫方到被呼叫方的數據可能經(jīng)過(guò)不同的網(wǎng)絡(luò )和路由環(huán)境，導致數據丟失，定時(shí)器重新啟動(dòng)，出現重新傳輸。網(wǎng)絡(luò )原因包括了很多方面的因素，例如，網(wǎng)絡(luò )繁忙，路由器問(wèn)題，帶寬問(wèn)題，硬件故障等問(wèn)題。

　　網(wǎng)絡(luò )防火墻過(guò)濾了呼叫請求。很多企業(yè)用戶(hù)都設置了防火墻來(lái)保障企業(yè)內網(wǎng)的安全。如果防火墻沒(méi)有過(guò)濾了SIP端口的話(huà)，呼叫方的INVITE會(huì )一直被過(guò)濾掉，呼叫方也可能一直對被呼叫方發(fā)送請求。

　　呼叫了錯誤的地址。呼叫方可能輸入了錯誤的呼叫地址或者地址格式不支持，導致錯誤呼叫，因此SIP INVITE會(huì )不斷重新發(fā)送。

　　錯誤的終端配置選項導致呼叫錯誤，重新重新傳輸的可能性。有時(shí)，終端配置錯誤的選項。例如，在配置選項中輸入的是192.168.0.22 IP地址，事實(shí)上，終端的IP地址是192.168.0.23。

　　呼叫過(guò)程中，INVITE就會(huì )要求發(fā)送響應消息到192.168.0.22的地址，最后仍然是不可達的地址。因此，可能導致INVITE重新傳輸。

　　6、SIP傳輸定時(shí)器優(yōu)化討論

　　我們在前面的章節中，討論了SIP傳輸協(xié)議使用時(shí)帶來(lái)的問(wèn)題和定時(shí)器的關(guān)系等問(wèn)題討論。在最后的討論中，我們針對SIP傳輸過(guò)程中比較重點(diǎn)的問(wèn)題-SIP定時(shí)器做一些說(shuō)明。根據很多研究機構和學(xué)術(shù)機構發(fā)布的研究論文中，很多研究更多專(zhuān)注于定時(shí)器的算法的優(yōu)化。

　　根據筆者前面介紹的，T1定時(shí)器默認設置為500ms是相對比較可靠的設置，B 定時(shí)器設置為32ms是符合一般網(wǎng)絡(luò )環(huán)境的。但是，如果設置T1時(shí)間相對較小，或者B定時(shí)器相對較小的話(huà)，整個(gè)SIP服務(wù)器端或者IPPBX本身對SIP transaction的時(shí)間要求就會(huì )比較少，對系統內存資源的壓力就會(huì )減少很多。例如，在關(guān)于A(yíng)sterisk的系統優(yōu)化解決方案中，官方建議設置B定時(shí)器的設置為6400 ms。

　　在網(wǎng)絡(luò )重傳過(guò)程中，傳輸過(guò)程中也可能出現很多問(wèn)題，導致傳輸的質(zhì)量問(wèn)題。幾個(gè)影響傳輸的因素包括：網(wǎng)絡(luò )時(shí)延，傳輸數據損壞，傳輸數據丟失等問(wèn)題。為了保障傳輸的可靠性，研究人員對定時(shí)器T1做了算法優(yōu)化，實(shí)現靈活自適應的調整方式。以下是關(guān)于使用可調整T1定時(shí)器的一些測試數據和SST（Session Start-up Time）之間的關(guān)系：

　　吞吐量和可調整定時(shí)器T1/默認定時(shí)器之間的優(yōu)化關(guān)系測試數據：

　　以上的研究討論了很多關(guān)于一般的IP網(wǎng)絡(luò )，基本上沒(méi)有討論目前最新的無(wú)線(xiàn)網(wǎng)絡(luò )，例如IMS，3G/4G網(wǎng)絡(luò )部署中。在Hanane Fathi的關(guān)于3G研究論文中，作者對在3G無(wú)線(xiàn)網(wǎng)絡(luò )中SIP創(chuàng )建的時(shí)延優(yōu)化做了多種比較測試，使用了TCP/UDP傳輸方式，對T1定時(shí)器的靈活調整，通過(guò)SIP/H323協(xié)議測試對比，作者的論文結論也說(shuō)明使用定時(shí)器的方式確實(shí)提高了傳輸效率：

Therefore, the adaptive timer is efficient for optimizing
the performance of signaling protocols in general. The
performance of SIP using the adaptive timer could be
improved by using some compression schemes to reduce the
size of the SIP messages.

　　另外，Hanane Fathi也建議使用SIP消息的糾錯機制或混合型的ARQ模型來(lái)修正SIP消息，提升SIP消息創(chuàng )建的效率，盡量避免SIP消息在無(wú)線(xiàn)網(wǎng)絡(luò )環(huán)境中重新發(fā)送：

Also, error correction mechanisms or hybrid ARQ
schemes could improve the performance of VoIP session
setup time by correcting the SIP messages and avoiding
retransmissions on the wireless link.

　　Hanane Fathi發(fā)表的論文比較早一些，現在很多新的基于互聯(lián)網(wǎng)，云計算的技術(shù)也進(jìn)入了商業(yè)環(huán)境中。所以，云計算為SIP消息傳輸優(yōu)化提供了更多的方式，因為基于云計算的部署方式可以支持更大的靈活性和網(wǎng)絡(luò )的彈性，使得傳輸效率更高。

　　思科在很多產(chǎn)品中支持了Reliable User Data Protocol （RUDP），通過(guò)RUDP來(lái)保證傳輸的可靠性。RUDP中也使用了 Forward error correction（FEC）這樣的糾錯機制來(lái)修正SIP消息，提升傳輸的效率。這里的FEC的機制基本上和Hanane Fathi的論文討論的糾正機制非常相似。關(guān)于RUDP的細節，讀者可以查閱ABHILASH THAMMADI的論文。以下是一個(gè)RUDP的架構介紹示例：

　　7、總結

　　在本文章的討論中，筆者介紹了關(guān)于100 Trying在SIP傳輸過(guò)程中的重要和其角色。首先，筆者介紹了SIP 初始請求中使用的100 Trying的狀態(tài)，然后介紹了定時(shí)器控制機制來(lái)保證UDP傳輸時(shí)100 Trying的協(xié)商機制。接下來(lái)，筆者介紹了SIP 重傳中的定時(shí)器和超時(shí)的設置和其工作流程，然后介紹了為什么進(jìn)行SIP消息的重新傳輸，以及幾個(gè)主要的原因。最后，筆者討論了關(guān)于SIP傳輸中優(yōu)化的建議，特別是對T1定時(shí)器的靈活調整帶來(lái)的效率的提升，RUDP技術(shù)架構的介紹。

　　總結，通過(guò)在SIP 請求中使用100 Trying，然后T1定時(shí)器和B定時(shí)器可以保證UDP傳輸環(huán)境下的可靠性傳輸，100 Trying起到了非常重要的作用。在具體的定時(shí)器細節方面，很多研究表明通過(guò)優(yōu)化定時(shí)器也可以提升傳輸效率。當然，目前很多基于云計算的技術(shù)也非常成熟，這些技術(shù)也可以實(shí)現網(wǎng)絡(luò )的優(yōu)化，讀者本身資源的局限性沒(méi)有對很多新的技術(shù)進(jìn)行分析討論，讀者可以進(jìn)行進(jìn)一步的消息補充這方面的知識。

　　參考資料：

　　https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

　　Sureshkumar V，Measuring SIP Proxy Server Performance

　　S. M. Chakraborty，Optimization of SIP Session Setup Delay for VoIP in 3G Wireless Networks

　　ABHILASH THAMMADI，https://krex.k-state.edu/dspace/bitstream/handle/2097/11984/AbhilashThammadi2011.pdf?sequence=5

　　http://www.cs.rochester.edu/~kshen/csc257-fall2007/lectures/lecture11-rdt.pdf

　　file:///D:/Documents/Downloads/electronics-07-00295.pdf

　　https://www.sciencedirect.com/science/article/pii/S0022000010001194

　　https://www.smartvox.com/what-are-sip-timers/

　　https://link.springer.com/content/pdf/10.1007%2F978-3-642-40552-5_8.pdf

　　https://blogs.asterisk.org/2016/12/21/sip-timers-t1-and-b-affect-performance/

　　https://tools.ietf.org/id/draft-ietf-sipping-early-disposition-03.txt