韩国美女内部vip视频,免费看美女视频的app

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

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

　　1、SIP呼叫請求響應(yīng)中的100 Trying

　　首先，我們針對請求呼叫中的100 Trying做一個簡單的背景介紹。在SIP呼叫中，下一跳服務(wù)器或UAS收到UAC的請求以后，對客戶端UAC發(fā)送一個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呼叫流程圖如下：

　　比較詳細(xì)的100 Trying響應(yīng)消息如下。這里提醒一下一些基礎(chǔ)讀者，100 Trying會完全拷貝INVITE中的Call-ID，F(xiàn)rom，To，CSeg，和VIA頭值，這里沒有SDP內(nèi)容長度，因此也沒有SDP消息。

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

報(bào)告一個處理流程
以1XX為響應(yīng)回復(fù)
無任何結(jié)果狀態(tài)

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

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

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

　　關(guān)于那個網(wǎng)絡(luò)層的介紹，我們在以前的歷史文章中有非常完整的介紹，讀者可以查閱歷史文檔來學(xué)習(xí)，也可以通過網(wǎng)上的其他資料來學(xué)習(xí)，這里不做過多解讀�，F(xiàn)在，我們僅對涉及SIP傳輸?shù)膖ransport layer 所使用的TCP和UDP進(jìn)行簡單分析來說明如何支持SIP的可靠性傳輸。使用TCP傳輸時(shí)，SIP通過TCP需要和對方檢查，進(jìn)行握手協(xié)商。如果對方確認(rèn)已經(jīng)準(zhǔn)備好接收數(shù)據(jù)，那么發(fā)送方發(fā)送INVITE消息，對端成功接收。如果TCP確認(rèn)后，接收方在接收過程中沒有收到完整的數(shù)據(jù)，則丟棄，重新傳輸一次。因此，TCP協(xié)議就是人們常說的可靠傳輸協(xié)議，因?yàn)樗梢员ＷC傳輸?shù)目煽啃�，因�(yàn)樾枰暾膮f(xié)商過程，數(shù)據(jù)丟失需要重新傳輸，因此可靠性增加，但是和UDP相比，其傳輸速度相對比較慢。

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

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

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

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

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

　　上面，我們討論了SIP發(fā)送INVITE和重傳時(shí)的定時(shí)器和100 Trying的處理機(jī)制。實(shí)際上，因?yàn)楦鞣N網(wǎng)絡(luò)問題，在傳輸過程中，INVITE丟失是經(jīng)常發(fā)生的事情。因此，需要UAC不斷發(fā)送INVITE，直到定時(shí)器超時(shí)。在INVITE傳輸過程中使用了七次重傳來控制整個INVITE重傳過程，其定時(shí)器共耗費(fèi)總時(shí)長為32秒。這里需要注意的是，每次定時(shí)器計(jì)時(shí)時(shí)長是上一個定時(shí)器的2倍時(shí)長。在SIP 傳輸?shù)亩〞r(shí)器中，主要涉及了三個定時(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)系。以下具體示例中各個INVITE傳輸所耗費(fèi)的時(shí)長。

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

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

　　5、Sip Retransmission原因和必要性

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

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

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

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

　　錯誤的終端配置選項(xiàng)導(dǎo)致呼叫錯誤，重新重新傳輸?shù)目赡苄�。有時(shí)，終端配置錯誤的選項(xiàng)。例如，在配置選項(xiàng)中輸入的是192.168.0.22 IP地址，事實(shí)上，終端的IP地址是192.168.0.23。

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

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

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

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

　　在網(wǎng)絡(luò)重傳過程中，傳輸過程中也可能出現(xiàn)很多問題，導(dǎo)致傳輸?shù)馁|(zhì)量問題。幾個影響傳輸?shù)囊蛩匕ǎ壕W(wǎng)絡(luò)時(shí)延，傳輸數(shù)據(jù)損壞，傳輸數(shù)據(jù)丟失等問題。為了保障傳輸?shù)目煽啃裕芯咳藛T對定時(shí)器T1做了算法優(yōu)化，實(shí)現(xiàn)靈活自適應(yīng)的調(diào)整方式。以下是關(guān)于使用可調(diào)整T1定時(shí)器的一些測試數(shù)據(jù)和SST（Session Start-up Time）之間的關(guān)系：

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

　　以上的研究討論了很多關(guān)于一般的IP網(wǎng)絡(luò)，基本上沒有討論目前最新的無線網(wǎng)絡(luò)，例如IMS，3G/4G網(wǎng)絡(luò)部署中。在Hanane Fathi的關(guān)于3G研究論文中，作者對在3G無線網(wǎng)絡(luò)中SIP創(chuàng)建的時(shí)延優(yōu)化做了多種比較測試，使用了TCP/UDP傳輸方式，對T1定時(shí)器的靈活調(diào)整，通過SIP/H323協(xié)議測試對比，作者的論文結(jié)論也說明使用定時(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消息的糾錯機(jī)制或混合型的ARQ模型來修正SIP消息，提升SIP消息創(chuàng)建的效率，盡量避免SIP消息在無線網(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ā)表的論文比較早一些，現(xiàn)在很多新的基于互聯(lián)網(wǎng)，云計(jì)算的技術(shù)也進(jìn)入了商業(yè)環(huán)境中。所以，云計(jì)算為SIP消息傳輸優(yōu)化提供了更多的方式，因?yàn)榛谠朴?jì)算的部署方式可以支持更大的靈活性和網(wǎng)絡(luò)的彈性，使得傳輸效率更高。

　　思科在很多產(chǎn)品中支持了Reliable User Data Protocol （RUDP），通過RUDP來保證傳輸?shù)目煽啃�。RUDP中也使用了 Forward error correction（FEC）這樣的糾錯機(jī)制來修正SIP消息，提升傳輸?shù)男�。這里的FEC的機(jī)制基本上和Hanane Fathi的論文討論的糾正機(jī)制非常相似。關(guān)于RUDP的細(xì)節(jié)，讀者可以查閱ABHILASH THAMMADI的論文。以下是一個RUDP的架構(gòu)介紹示例：

　　7、總結(jié)

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

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

　　參考資料：

　　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