艹美女视频,最小比基尼美女视频,在线观看美女视频免费大全

　　在以前的講座中，我們使用了一些拓撲圖說明了SIP的呼叫環(huán)境，但是我們還沒有涉及到最終落得的PSTN技術。PSTN大家已經(jīng)非常熟悉了，我們以前和現(xiàn)在的大部分時間使用PSTN的話務服務，它包括模擬線路和數(shù)字線路的服務。在我們的講座中，我們主要介紹的是SIP相關技術，對于PSTN我們不做過多的介紹。我們就目前SIP和PSTN的場景結合相關的幾個技術要點做一些介紹，這些要點包括SIP和PSTN之間的呼叫流程，關于早期媒體流，Early Offer和Delayed Offer和SIP Gateway。

　　1、SIP和PSTN是目前結合最為緊密的語音呼叫流程，我們分別介紹一下從SIP到PSTN，從PSTN到SIP兩種呼叫的信令和媒體交互的過程。

　　SIP呼叫PSTN的流程，通過DNS或者ENUM查詢號碼歸屬地，然后發(fā)起呼叫。

　　圖例中使用的是SS7局端網(wǎng)關：

　　PSTN 呼叫SIP的流程，圖例中使用的是SS7網(wǎng)關處理。

　　SIP呼叫PSTN的呼叫失敗的流程：

　　SIP呼叫PSTN，SIP信令的跟蹤消息：

　　SIP-PSTN跟蹤的消息流程如下：

UA終端對所注冊的Proxy 發(fā)起一個INVITE請求。
Proxy 回復了一個407 authentication 認證要求，需要UA 發(fā)送用戶密碼。
UA 收到 407 響應，然后發(fā)送一個ACK通知Proxy。
UA再次發(fā)送一個INVITE 到所注冊的Proxy，并且這次攜帶了UA的用戶密碼。
Proxy 收到UA發(fā)送的用戶賬號信息，對被呼叫方發(fā)送呼叫信息，然后返回UA一個 100 trying，通知UA正在呼叫被呼叫方，等待對方響應。
Proxy對UA響應一個183 消息，包含對端的振鈴狀態(tài)信息和早期媒體流。
Proxy對UA響應200 OK，表示對端已經(jīng)應答此呼叫。
UA 發(fā)送一個ACK消息，然后打開媒體，創(chuàng)建媒體路徑。開始正式媒體互通以后，雙方之間的語音正式建立。其中一方掛機，一定時間后，Proxy發(fā)送Bye消息，結束呼叫流程。

　　2、Early Media也叫早期媒體流，這是SIP到PSTN呼叫過程中經(jīng)常遇到的一個技術術語。在SIP/PSTN網(wǎng)絡中引入早期媒體流的功能最主要解決兩個方面的問題：

　　接聽前避免呼叫接聽時的前一段語音丟失的問題，或提供語音留言等功能服務。如果增加了早期媒體流的播放，就可以增加了用戶體驗，用戶不會感覺電話被打斷。

　　有時，呼叫方可以通過早期媒體流來訪問媒體流中提供的語音IVR或者其他基于DTMF的服務功能。運營商或者企業(yè)客戶可以提供其他的服務類別讓用戶選擇。

　　簡單來說，就是在雙方“真人”會話還沒有正式開始之前，對呼叫方播放的一個語音廣播。早期媒體流是一個非常有用的功能，通常用戶可以通過自定義的方式，對呼叫到播放一個公司語音消息或者其他自定義的語音提示。當然，在早期媒體流也支持視頻文件播放，不僅僅是語音文件。早期媒體流可能是被呼叫方發(fā)起也可能是呼叫方發(fā)起。如果是呼叫方發(fā)起的話，可能發(fā)送到是一個雙音頻的語音。通常，我們說的早期媒體流被呼叫方發(fā)起的語音。

　　根據(jù)上述的描述，用戶也可能遇到一個“第一句話”的問題，如果發(fā)起呼叫的終端是SIP，對端終端是模擬電話的話，有時可能丟模擬終端第一部分語音的。如果被呼叫方是模擬終端，接聽以后，用戶可能直接拿起電話就開始講話。但是，此時，SIP終端可能還沒有收到Proxy返回的200 OK消息，也還沒有發(fā)送ACK消息到Proxy，媒體流的連接路徑并沒有打開，SIP終端沒有接收到語音內(nèi)容，所以就丟失了模擬終端第一次講話的語音內(nèi)容（這里，模擬終端講話-How are you today 就丟失了）。在一段時間后，SIP終端收到200 OK, 然后發(fā)送ACK，媒體通道正式建立以后，雙方才能聽到對方真正的語音交互內(nèi)容。

　　因為RFC3261僅支持了簡單的早期媒體流處理機制，除了上面提到的丟失語音以外，可能會導致其他的問題，例如帶寬問題和安全問題，forking 分拆問題。例如，如果呼叫方的INVITE消息經(jīng)過forked以后，可能最終到達幾個不同的終端，幾個不同的終端同時對呼叫方發(fā)送早期媒體流的話，可能導致呼叫方接收失敗或者迷惑。如果早期媒體流是視頻的話，呼叫方終端可能完全不能接收幾個不同的早期媒體流文件處理。

　　事實上，根據(jù)最近的SIP標準和一些技術研究，早期媒體流的功能實現(xiàn)有幾個方面的問題需要進一步配合各種環(huán)境來解決，以下三個方面的因素需要大家最進一步的研究：

　　IPPBX和終端兼容性的問題。IPPBX和網(wǎng)關關于早期媒體流支持的方式問題，例如是否支持Early Offer或Delayed Offer 方式。

　　Forked INVITEs的問題。如果經(jīng)過了INVITE 經(jīng)過分拆以后，如何處理不同session返回的消息。這些技術細節(jié)涉及到了不同的服務器或者提供商，所以，早期媒體流會發(fā)生完全不同的變化。另外，很多SIP服務器對按續(xù)處理和并行處理的方式對早期媒體流有不同的路由策略，這些策略也會影響早期媒體流的處理。

　　NAT和防火墻的問題。公司防火墻可能對IP地址和端口做了處理，這樣也會影響。

　　在處理早期媒體流媒體丟失的問題上，理論上，目前有兩種不同的解決方案，用戶可以自己去做進一步的了解：

Early-Media Solution Model with Disposition-Type: Early- Session
Early-Media Solution Model with P-Early-Media：Header

　　以上兩種方式各有其利弊，并且涉及了很多網(wǎng)絡環(huán)境中的不可確定的因素，這里不做進一步的敘述。

　　4、Early Offer和Delayed Offer是關于SDP協(xié)商中涉及的一個發(fā)送協(xié)商方式，簡單來說，由誰發(fā)送SDP的問題。因為兩種方式通過不同的流程提供了SDP包含的消息，所以導致兩種方式的SDP協(xié)商機制也完全不同。以下圖例的終端SDP表示了所支持的編碼能力，此圖例中支持了PCMU，1016，和GSM，視頻編碼包括：H261和H263。

　　下面，我們看看兩種方式的流程過程。Early offer 的流程方式：發(fā)起呼叫的終端通過INVITE攜帶了SDP的消息，包括了支持的語音編碼，接收方選擇其中一種所支持的編碼，然后開始進行媒體交互。

　　Delayed Offer 通常是終端發(fā)起INVITE消息時，SDP沒有攜帶任何編碼支持能力，由對端提供編碼支持能力，通知終端使用所支持的編碼，這樣的話，運營商控制著編碼的支持能力。大家在很多實際環(huán)境中也經(jīng)常遇到過類似的場景，為了保證語音質(zhì)量和帶寬的最佳要求，運營商要求使用G.729來支持編碼傳輸，終端PBX只能采用G.729 支持服務。運營商返回了200 OK，并且說明使用的編碼。在圖例中，運營商通知終端使用G.729, PBX 根據(jù)運營商要求采用G.729. 最后，媒體創(chuàng)建成功，開始正式語音通話。

　　除了以上兩種發(fā)送協(xié)商的方式以外，在SDP交互中，還涉及到了 Offer/answer exchanges 的一個協(xié)商流程，在協(xié)商過程中涉及了雙方接聽呼叫的動作順序，業(yè)務流程變化引起的Updated，這樣也可能導致發(fā)送到SDP消息會有updated 發(fā)生。具體協(xié)商過程和指導，請用戶參考RFC3264 標準。

　　5、SIP Gateway負責SIP信令到PSTN的交互，媒體流交互的設備。在以下的圖例中，SIP/SDP會轉換成ISDN/ISUP信令；RTP/RTPC媒體流則會轉換成TDM語音通道。當然，目前的E1網(wǎng)關或者單機服務器（帶語音卡）都可以實現(xiàn)以下SIP Gateway的功能要求。SIP網(wǎng)關技術是一個非常復雜的技術要點，需要用戶自己去不斷摸索和使用才能獲得比較全面的了解。這里，我們不做更多介紹。