雖然SIP到PSTN呼叫的技術(shù)已經(jīng)逐漸被純SIP網(wǎng)絡(luò)替代，筆者也已經(jīng)發(fā)布過很多這些方面的內(nèi)容，而且網(wǎng)絡(luò)上已經(jīng)有各種資源介紹關(guān)于SIP-PSTN的知識內(nèi)容，并且有一些內(nèi)容也非常具體。但是，為了新IP企業(yè)通信網(wǎng)絡(luò)整體內(nèi)容的完整性，筆者認為還是有必要回顧一些基礎(chǔ)的知識點，特別是目前仍然存在的很多PSTN-SIP之間呼叫存在的問題，例如早期媒體流的問題，仍然困擾著很多用戶。因此，筆者希望幫助更多讀者能夠系統(tǒng)了解從傳統(tǒng)PSTN呼叫到SIP呼叫的知識體系。在以下的討論中，筆者將介紹SIP到PSTN呼叫的核心框架和節(jié)點設(shè)備，PSTN到SIP之間呼叫的處理流程（RFC3666），SIP-PSTN的映射碼，早期媒體流定義以及相關(guān)背景說明，在請求分叉處理環(huán)境中早期媒體流處理存在的問題，關(guān)于早期媒體流部署中網(wǎng)關(guān)模式和應(yīng)用服務(wù)器模式的討論，以及早期媒體流策略選擇等話題進行分享。
1PSTN-SIP網(wǎng)絡(luò)概覽
首先，讀者需要大概了解一下關(guān)于SIP-PSTN的處理框架。在以上的SIP-PSTN基本框架概覽中，用戶端設(shè)備通過安全設(shè)備SBC支持到SIP服務(wù)提供商的網(wǎng)絡(luò)中，然后通過SIP代理服務(wù)器以及定位服務(wù)查詢到相應(yīng)的地址，轉(zhuǎn)發(fā)到SIP/PSTN網(wǎng)關(guān)，最后到相應(yīng)的PSTN交換機。通過PSTN交換機最后路由到IPPBX/PBX或者其他的非SIP終端的用戶中。在SIP到PSTN的呼叫過程中，SIP消息到網(wǎng)關(guān)，再到PSTN交換機，以及到最終的終端電話都經(jīng)過了信令交互和語音RTP的交互過程。
RFC3666是一個非常核心的規(guī)范說明。RFC3666規(guī)范對SIP到PSTN呼叫流程做了詳細介紹。如果讀者有興趣的話，可以參考RFC3666-2章節(jié)內(nèi)容。根據(jù)以上圖例，結(jié)合RFC3666，在SIP到PSTN呼叫中，在RFC3666中介紹了ENUM查詢，此查詢用來查找SIP呼叫方呼叫PSTN終端時，ENUM轉(zhuǎn)化呼叫號碼到標準的ENUM格式的號碼。除了正常的SIP到PSTN的呼叫以外，SIP到PSTN呼叫還描述了三種SIP到PSTN失敗的呼叫處理流程，包括PSTN端的處理，PSTN端釋放的處理和ANM超時處理等不同的呼叫失敗的場景。提醒讀者，這些失敗呼叫的處理流程才是SIP系統(tǒng)運維人員應(yīng)該特別關(guān)注的地方，這樣可以方便用戶通過流程和規(guī)范說明依據(jù)規(guī)范建議來排查問題。以上介紹的是SIP到PSTN的呼叫處理流程。以下圖例是PSTN到SIP的呼叫流程，處理流程如下：
在PSTN呼叫SIP流程中，呼叫處理經(jīng)過了18個步驟，用戶的模擬/數(shù)字終端發(fā)起呼叫，通過PSTN交換機，創(chuàng)建IAM，ISUP消息，然后到PSTN/SIP網(wǎng)關(guān)，經(jīng)過網(wǎng)關(guān)的ISUP和SIP消息映射，最后路由到SIP代理服務(wù)器，然后代理服務(wù)器通過定位服務(wù)呼叫到SIP終端話機。具體呼叫詳情，讀者可以參考RFC3666-3章節(jié)，這里不再做過多解釋。另外，在PSTN到SIP端的呼叫中，除了以上成功的呼叫以外，PSTN到SIP端呼叫還有六種失敗呼叫的流程處理的說明，包括了SIP錯誤處理，SIP忙狀態(tài)處理，SIP錯誤和不同振鈴的協(xié)同，呼叫方終止呼叫等處理流程。
在RFC3666中，除了PSTN到SIP之間的呼叫流程的說明以外，它還說明了PBX到SIP端的呼叫，具體包括SIP到ISDN PBX的呼叫和PBX到SIP的呼叫流程。如果讀者需要特別了解PBX-SIP的呼叫的話，可以參考RFC3666-2.2和RFC3666-3.3章節(jié)。另外，在很多應(yīng)用場景中，呼叫方和被呼叫方之間因為明顯特定的要求，它們PSTN到PSTN之間的雙方之間的呼叫可能還要通過SIP代理服務(wù)器網(wǎng)絡(luò)。這樣的呼叫需要經(jīng)過22個步驟的處理流程。
2PSTN-SIP錯誤碼映射說明
錯誤碼是SIP或者PSTN用來提示錯誤消息的標識碼，SIP和PSTN錯誤碼有一個錯誤碼映射關(guān)系，讀者需要對其有一定的了解。
3早期媒體流背景說明
除了關(guān)于SIP和PSTN之間的交互流程以外，筆者再浪費一點時間補充說明早期媒體流使用的必要性。在涉及到SIP和PSTN網(wǎng)絡(luò)之間的通信中，為了避免一些問題發(fā)生，從技術(shù)角度引入了一個概念，它被稱之為早期媒體流。在PSTN規(guī)范中沒有早期媒體流的概念。在PSTN網(wǎng)絡(luò)中，當呼叫方撥號以后，媒體流通道也直接被創(chuàng)建，呼叫方就可以聽到遠端被呼叫方的振鈴音。早期媒體流為用戶提供了一個可能，在雙方真正開始通話之前，使用自定義的振鈴音或者其他企業(yè)語音文件替代系統(tǒng)默認的振鈴音。關(guān)于早期媒體流的具體應(yīng)用場景，讀者可以閱讀筆者歷史文章：SIP系列講座-SIP-PSTN-1 和
在關(guān)于早期媒體流的討論中，另外一個需要讀者必須注意到是Clipping的問題。Clipping(沿切割)問題是一個比較常見的在PSTN網(wǎng)絡(luò)和SIP網(wǎng)絡(luò)之間呼叫中可能發(fā)生的問題。當用戶聽到振鈴以后，直接接聽呼叫時，開始說話的前一段可能會出現(xiàn)語音丟失的問題。因為是SIP到PSTN呼叫，如果沒有早期媒體流作為一種補償緩存方式的支持的話，很多時候SIP用戶端可能還沒有收到 200 OK, 因此也沒有創(chuàng)建媒體流通道，所以語音丟失就會發(fā)生。因此導(dǎo)致SIP用戶可能就聽不聽語音通話的前期部分語段，丟失第一個單詞或者音節(jié)。這種尷尬的情況比較影響用戶體驗。如果是一般的呼叫，用戶都可以接受這種現(xiàn)象。但是，如果是比較重要的通話或者具有商業(yè)性質(zhì)的通話，這種問題就會讓用戶感到非常尷尬。因此，早期媒體流問題需要一些機制來處理。
使用早期媒體流也可以支持更多的業(yè)務(wù)功能。有時雖然被呼叫方終端還沒有接聽呼叫，早期媒體流也支持對呼叫方播放忙音或者其他提示音。因此，早期媒體流在SIP和PSTN網(wǎng)絡(luò)中幫助雙方避免一些問題發(fā)生，雙方能夠獲得比較好的折中的用戶體驗。我們先了解早期媒體流的處理流程。以下是一個早期媒體流處理的流程示例：
在以上的呼叫流程中，SIP終端發(fā)起呼叫請求以后，PSTN交換機對網(wǎng)關(guān)返回ACM，然后網(wǎng)關(guān)先對SIP終端發(fā)送183 消息。然后，PSTN交換機會對PSTN終端振鈴，發(fā)送回鈴音，網(wǎng)關(guān)轉(zhuǎn)換成早期媒體流RTP流發(fā)送到SIP終端。一旦模擬話機應(yīng)答了呼叫，PSTN交換機會返回ANM，網(wǎng)關(guān)則返回 200 OK給SIP代理服務(wù)器和終端。然后，PSTN交換機傳輸真正的雙向語音流媒體，SIP端則創(chuàng)建RTP流，最后，雙方才開始真正的語音通話過程。這里需要注意，為了避免Clipping的發(fā)生，SIP終端發(fā)送請求時，其請求攜帶的SDP也必須能夠支持播放收到的RTP流，甚至于沒有收到200 OK之前也可以播放其早期媒體。
4早期媒體流處理存在的問題和兩種部署機制的討論
早期媒體流的使用雖然幫助用戶實現(xiàn)了更好的呼叫體驗，但是可能會產(chǎn)生其他的問題。在RFC3261規(guī)范中，早期媒體流僅支持了簡單的早期媒體流機制，這種處理機制存在很多問題，這些問題和分叉呼叫，安全等相關(guān)。它不能滿足大部分的應(yīng)用場景的要求。為了彌補RFC3261在早期媒體流機制中針對請求分叉呼叫中出現(xiàn)的問題，在早期媒體流處理方式方面針對部署機制的局限性增加了更多的部署機制。RFC3960使用了網(wǎng)關(guān)模式和應(yīng)用服務(wù)器模式支持早期媒體流部署，此規(guī)范中的網(wǎng)關(guān)模式和應(yīng)用服務(wù)器模式改善了對早期媒體流在復(fù)雜環(huán)境中的支持。但是，不幸的是，RFC3960中的網(wǎng)關(guān)模式仍然對分叉呼叫支持存在一些問題。因為目前很多的SIP實體對象不能支持應(yīng)用服務(wù)器模式，所以，網(wǎng)關(guān)模式部署方式仍然有存在的必要。相對網(wǎng)關(guān)模式，早期媒體流的應(yīng)用服務(wù)器部署方式解決了網(wǎng)關(guān)模式存在的一些問題。它通過早期會話分解模式來處理早期媒體流部署。我們再進一步簡單介紹一下網(wǎng)關(guān)模式的概念和應(yīng)用服務(wù)器模式的功能原理。
簡單來說，網(wǎng)關(guān)模式是使用offer/answer 模式來管理早期媒體流。如果最終響應(yīng)是200 OK響應(yīng)，早期媒體流會轉(zhuǎn)化為正常通話的媒體流。如果最終響應(yīng)是非200 OK響應(yīng)，則直接簡單結(jié)束早期會話。關(guān)于offer/answer 模式的詳解，讀者可以參考歷史文檔：完整SIP/SDP媒體協(xié)商概論-SDP協(xié)商模式詳解-會話管理全解。在無invite分叉處理中，初始請求中包含了offer的話，網(wǎng)關(guān)模式的早期媒體流的處理一般不會出現(xiàn)媒體流沿切割問題，它會按照正常的SIP協(xié)商流程來處理。如果出現(xiàn)了呼叫請求分叉的話，早期媒體流的網(wǎng)關(guān)模式環(huán)境中，媒體clipping的問題就可能出現(xiàn)。我們具體舉例說明，在網(wǎng)關(guān)模式的環(huán)境中，網(wǎng)關(guān)支持了多個UAC，UAC可能同時收到針對其不同offer的不同的answer消息，這些消息是在不同的臨時響應(yīng)中，并且來自于不同的UAS服務(wù)器端。這時，在資源有限的前提下，網(wǎng)關(guān)模式面臨帶寬的局限和早期媒體會話選擇的問題。那么現(xiàn)在的問題來了，如果UAC同時收到了來自于不同的UAS服務(wù)器端的早期媒體流，網(wǎng)關(guān)還要對不同用戶呈現(xiàn)不同的早期媒體流數(shù)據(jù)文件，這樣同時對用戶播放不同的媒體文件就會導(dǎo)致用戶端處理非常迷惑。其他的媒體格式例如視頻也同樣會面臨這樣的尷尬問題。另外，如果網(wǎng)關(guān)模式下，一般的UAC對帶寬做了限制，它不可能同時接受所有的早期媒體流，只能同一時間接受一個單個早期媒體會話，而對其他的早期媒體會話進行延后處理，再通過發(fā)送UPDATE請求方式來進行處理。
相比早期媒體流的網(wǎng)關(guān)模式部署方式，應(yīng)用服務(wù)器模式處理提供了比較“聰明”的處理機制。它處理的基本原理是通過多個UAS模塊構(gòu)成，通過不同的UAS來處理不同的UAC早期會話。UAC端則通過early-session 可選標簽標識它是否支持早期媒體會話的分解處理，應(yīng)用服務(wù)器模式則根據(jù)其標簽分解其早期會話，分別對應(yīng)不同的早期會話流程。關(guān)于SIP對早期會話分解類型的處理流程，讀者可以查閱RFC3959做進一步學(xué)習(xí)，這里不再做過多解釋。
針對早期媒體流的處理，一些設(shè)備廠家特別是SBC產(chǎn)品都通過各自比較“聰明”的處理方式和優(yōu)化方案來應(yīng)對請求分叉時的早期媒體流的處理，例如使用P-Early-Media 頭支持的方式（RFC5009）和請求分叉處理的策略選擇方式。在針對請求分叉處理中也采用了針對不同臨時響應(yīng)的選擇策略等，例如：收到的第一個臨時響應(yīng)，收到的第一個RTP流，最后一次收到的SDP和PEM優(yōu)先等不同的處理方式。
5總結(jié)
在本章節(jié)的分享中，筆者首先介紹了針對PSTN到SIP的基本技術(shù)概論，具體解釋了SIP-PSTN中比較核心的網(wǎng)元要素，包括SBC，SIP代理服務(wù)器，服務(wù)查詢定位，然后分別介紹了SIP-PSTN兩個不同方向的呼叫的處理流程。在兩種不同網(wǎng)絡(luò)的呼叫中，筆者補充了部分關(guān)于SIP到PSTN呼叫的錯誤碼映射關(guān)系，幫助讀者清晰了解其對應(yīng)細節(jié)。
除了關(guān)于SIP-PSTN的基本的網(wǎng)絡(luò)框架說明以外，筆者針對早期媒體流的處理方式，以及RFC3261中對早期媒體處理存在的問題進行深入討論，并且進一步通過RFC3960規(guī)范更新支持，對早期媒體流部署方式的網(wǎng)關(guān)模式和應(yīng)用服務(wù)器模式進行了討論，也列舉了某些具體產(chǎn)品中關(guān)于早期媒體流支持的處理方式。希望讀者能夠通過以上討論更加明確SIP-PSTN概念，加深讀者關(guān)于早期媒體流處理的深入理解。
參考資料：
https://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling
http://www.itrcp.com/blog/wp-content/uploads/2013/08/PSTN-Cause-Code-to-SIP-Response-Mapping.pdf
www.dinstar.cn
www.asterisk.org.cn
https://datatracker.ietf.org/doc/html/rfc3960
https://www.ietf.org/rfc/rfc5009.txt
https://datatracker.ietf.org/doc/html/rfc3959
