1、SIP trunk可能很多讀者已經非常熟悉，為了讓一些新人了解trunk的基本概念，我們這里簡單重復介紹一下trunk。SIP中繼簡單來說（當然還有其他類型的連接，例如H323），就是一個對SIP業(yè)務進行接入支持的邏輯連接。和SIP trunk對應的就是傳統(tǒng)的PSTN網絡中trunk，在傳統(tǒng)PSTN網絡中，我們也會使用trunk這個用法。但是，在傳統(tǒng)的PSTN網絡中，我們仍然可以看到至少有一個物理的連接方式，通過物理線路的連接方式從運營商對接到客戶端網絡。在SIP網絡中，我們基本上沒有看到它的物理形態(tài)的連接方式，僅通過虛擬的邏輯連接對接運營商和終端客戶的IP解決方案。根據RFC對trunk的定義是：
以下圖例介紹了傳統(tǒng)E1/T1 trunk接入方式的企業(yè)IPPBX，運營商通過物理的trunk連接到用戶端IPPBX。當然，這里的E1接入方式需要本地部署一個E1接入網關或者語音板卡。
以下圖例介紹了用戶通過網絡使用SIP trunk來實現的SIP接入方式，SIP對接到企業(yè)用戶本地IPPBX。
以下圖例說明了一個比較完整的傳統(tǒng)TDM和SIP混合的接入方式，客戶分別使用了SIP trunk和TDM trunk的方式。
根據目前的發(fā)展來看，SIP trunk 已經可以完全兼容目前市場上絕大部分的應用服務器，這里的Asterisk是一個相對比較籠統(tǒng)的稱呼，事實上，這里包括了很多廠家使用Asterisk平臺開發(fā)的商業(yè)IPPBX，和非常流行的開源項目FreePBX和Issabel 開源項目。
使用SIP trunk和傳統(tǒng)的PSTN網絡相比，SIP trunk 具有以下這些優(yōu)勢：
- 通話成本相對比較低廉。
- 部署方式相對比較靈活。
- 擴容相對比較方便。
- 終端支持的靈活性相對比較大。
- 客戶可以獲得不同落地服務商的號碼資源。
- DID資源豐富，可以支持公司更多分機號碼。
- 如果發(fā)生接入設備故障時，SIP trunk非�？焖偾袚Q到E1/T1中繼。
2、現在我們介紹幾個關于SIP trunk在企業(yè)應用環(huán)境中的典型場景，用戶可以了解更多SIP trunk的場景，例如總部分公司之間的連接，LCR和trunk逃生切換。
以下圖例介紹了一個企業(yè)多地部署的場景（Peer之間的連接），一個跨國公司通過SIP trunk可以實現不同國家之間（美國，日本，中國和越南）的分公司工廠之間的連接，這也是很多企業(yè)客戶經常使用的場景，通過這樣的部署方式，企業(yè)內部通話就可以實現完全免費。當然，除了實現內部免費通話的好處以外，企業(yè)總部可以對分公司的電話系統(tǒng)進行有效地監(jiān)管，方便管理層對公司全局的管理。
為了實現企業(yè)IPPBX多地部署和互通，仍然需要面對很多的技術挑戰(zhàn)，用戶可能需要考慮很多技術因素，產品兼容性的問題，本地支持力度，本地網絡帶寬支持能力等問題。企業(yè)用戶必須根據不同環(huán)境和相關要素進行全面考慮，根據公司需求和本地資源來完成部署。
另外一種場景就是使用LCR實現最低話費呼叫。因為國際業(yè)務的需求，有很多企業(yè)的國際話費成本仍然很高，如果選擇SIP trunk的話，用戶可以使用LCR策略對接運營商所提供的不同國家的線路資源實現最低話費計費方式，用戶通過最佳的線路呼叫。
SIP trunk 還可以提供靈活切換保證企業(yè)IPPBX正常工作。在實際環(huán)境中，企業(yè)IPPBX不能正常工作是完全可能發(fā)生的事情，如果大容量的企業(yè)IPPBX一般都部署一臺從IPPBX來作為一個備份，如果主服務器不能工作的話，另外一臺從服務器可以繼續(xù)工作。公司核心人員的分機可以快速切換到從服務器注冊。當然，這里需要注意幾個方面的因素，運營商是否能夠靈活切換客戶端IP地址，企業(yè)客戶防火墻能夠支持主從服務器IP路由和安全策略，同時IPPBX必須支持數據交互的同步（例如數據庫同步）。我們這里不涉及IPPBX高可靠性解決方案和接入設備的逃生功能。
3、SIP trunk的性能是企業(yè)客戶非常關心的一個話題，因為SIP trunk的性能直接影響了SIP呼叫的QoS或語音通話質量。為了提高SIP trunk的性能或穩(wěn)定性，運營商的網絡帶寬當然是一個最重要的一個指標。目前，大部分國內運營商帶寬已經升級支持了光纖，網絡帶寬足夠，語音質量基本上不會有太大影響。但是仍然有一些地方的運營商在帶寬上存在問題。很多ADSL的客戶可能會出現語音質量差，容易掉線等情況。很多企業(yè)用戶可能不了解運營商的技術細節(jié)，導致語音質量不好，筆者建議用戶和運營商咨詢，獲得帶寬服務的詳細說明。很多時候，因為運營商提供的網絡帶寬的上行和下行的帶寬速度不同，客戶IPPBX呼入呼出使用了不同的帶寬，外部客戶呼入時使用的Download帶寬，而呼出時則使用的Upload 帶寬，導致呼叫的語音質量發(fā)生了很大的變化。
SDSL相對比ADSL好一些，SDSL提供了上下行對稱的帶寬，所以SIP呼叫的呼入呼出帶寬基本上一致，避免了ADSL對SIP trunk支持上的一些缺點。關于ADSL和SDSL的技術細節(jié)，用戶可以在網絡上查找來做進一步研究。除了我們上面提到的帶寬問題，大家也需要注意語音編碼的選擇類型，關于語音編碼的類型和帶寬占用筆者已經在以前的文章中做過很多介紹，這里不再過多論述。在實際部署環(huán)境中，企業(yè)用戶可以根據計算工具，選擇相應的并發(fā)呼叫數量和編碼就可以算出自己所需要的帶寬。
4、在部署SIP trunk是，MPLS（Multi-Protocol Label Switching）也是我們需要說明的技術內容。雖然，MPLS相對距離我們終端客戶比較遠，和我們今天討論的主題不是非常接近，實際上已經在網絡中得到了應用，所以我們今天還是有必要花費一點篇幅簡單對MPLS做一個介紹。MPLS的一種利用在核心網絡中利用標簽引導的方式進行數據傳輸的技術，它可以支持多業(yè)務能力，解決了IP分組的局限性。以下圖例說明了PE（運營商邊界網絡）和CE（終端用戶邊界網絡）在核心網絡中的相互關系。
很多時候，MLPS也可以支持語音和數據混合分離的狀態(tài)，MPLS網絡可以獨立出語音網絡和數據網絡，兩者之間不會互相影響。
以下圖例是思科在融合通信中使用MPLS技術的拓撲實現。
MPLS具有以下優(yōu)勢：
- 節(jié)省了成本，和傳統(tǒng)的Frame Relay或ATM技術相比，MPLS大幅減少了成本。
- 支持QoS的管理，優(yōu)化了對語音和視頻的性能支持。
- MPLS可以支持冗余線路快速切換。
- 更好的性能支持，因為降低了路由器之間的跳轉，性能方面得到了更好保障。
- 在上面的技術中，因為傳統(tǒng)互聯(lián)網的接入方式發(fā)生了很多的變化，DSL，光纖和LTE已經進入了我們的日常生活，但是這些接入方式同時影響著多種企業(yè)網絡業(yè)務。SD-WAN是一種針對WAN進行網絡管理優(yōu)化的技術。一般中文翻譯成軟件定義的廣域網。
- SD-WAN結合了硬件和軟件技術來進行對企業(yè)網絡的優(yōu)化和部署管理，充分發(fā)揮了網絡的作用，使之能夠全部網絡可以提供更加快速高效的網絡環(huán)境來支持不同應用需求環(huán)境。以下圖例說明了傳統(tǒng)WAN環(huán)境和SD-WAN環(huán)境的不同。
在實際應用環(huán)境中，客戶對SD-WAN的要求和運營商所提供的服務如以下圖例：
以下引用的數據說明了SD-WAN技術的市場發(fā)展預測。
Over the next five years, SD-WAN sales will grow at a 69% compound annual growth rate, hitting $8.05 billion in 2021, according to IDC’s Worldwide SD-WAN Forecast, 2017–2021.
因為客戶對大數據，云服務，和移動性的要求，很多公司的網絡平臺需要和第三方平臺對接，很多分公司業(yè)務需要通過總公司的網絡對接到一些服務提供商，這時，就可能導致總公司的網絡承載陡然增加，如果單純使用MPLS已經很難保證網絡的穩(wěn)定性，SD-WAN則可以實現對網絡數據的優(yōu)化和分離，通過SD-WAN實現網絡的穩(wěn)定性，降低了網絡的復雜程度。在以下的圖例中，讀者可以看到，如果公司訂閱了云服務，為了對公司全部網絡進行控制管理，所有分公司的員工如果要使用軟件訂閱服務，必須通過總部的網絡，這樣就會導致總部網絡帶寬需求和穩(wěn)定性受到嚴重影響。
通過SD-WAN的重新部署，分公司網絡可以直接經過互聯(lián)網訪問所訂閱的服務，這樣就可以大大降低網絡的復雜性，同時實現網絡的可控。
但是，讀者要注意，SD-WAN本身僅是針對網絡本身的實現，它本身不是專門針對通信的網絡，所以，它也可能出現數據包丟失，導致客戶端出現其他問題。因為客戶環(huán)境中缺乏對網絡的可見性，所以可能造成客戶排查問題比較困難，也不會像客戶期望的那樣簡單。
5、隨著企業(yè)應用服務能力需求的增加，運營商需要對企業(yè)客戶提供更多的IPPBX功能來滿足用戶的需求。傳統(tǒng)的IPPBX和一般的SIP trunk僅需要一個呼出號碼或者一條PSTN物理連接線路則可以確認IPPBX的身份，而基于SIP trunk的客戶一般都可以獲得除了電話呼叫業(yè)務本身以外，SIP 服務提供商還可以提供短信，在線狀態(tài)等其他的增值業(yè)務，這就需要運營商身份屬性的要求更加明確。確認一個企業(yè)號碼身份必須滿足一下條件：
- 企業(yè)IPPBX的分機需要和呼出設備有關聯(lián)關系，企業(yè)用戶必須有DID號碼。
- 身份信息中可能包括企業(yè)名稱和呼叫方名稱。
- 企業(yè)用戶IPPBX可以接收呼入的DID，并且連接（路由）內部分機。
- 通常運營商通過兩種方式來對企業(yè)用戶呼出的身份進行確認：
- 通過SIP 頭中的From 消息中的caller name和號碼。這個身份消息被作為PSTN呼叫的“private”和“public”身份確認消息。
因為基于SIP網絡的VOIP業(yè)務，仍然需要同時兼顧傳統(tǒng)PSTN的號碼傳遞和確認機制，但是以前的方式不能滿足SIP trunk的業(yè)務需求，現在很多SIP運營商不僅僅提供簡單SIP呼叫業(yè)務，同時增加了很多的增值服務，這些增值服務的身份確認不僅僅需要一個企業(yè)呼叫號碼，同時還要企業(yè)內部分機支持的其他增值服務。因此，RFC標準對P-Asserted Identity進行了規(guī)定來支持運營商對企業(yè)客戶的更多身份確認方式。通過P-Asserted Identity 支持了運營商要求的企業(yè)PBX的呼叫的號碼，并且提供了對運營商提供的其他服務的確認功能，例如，短信，在線狀態(tài)等業(yè)務功能。這種方式也是運營商普遍使用的一種身份確認方式。這里，IPPBX必須重新把From頭的消息映射成一個新的Privancy ID， 這里的name和號碼都發(fā)生了改變。IPPBX必須在SIP 頭中包含Privacy 頭對運營商請求一個privacy消息，IPPBX的SIP頭中必須包含P-Asserted Identity，這樣運營商可以確認這是運營商自己的“私網”用戶。我們的示例中介紹的是運營商和企業(yè)辦公室之間的連接方式，這種方式可能不是運營商一定要要求的，但是如果運營商需要一些加密措施的話，所以這種方式是比較明智的選擇。
根據rfc 3325的規(guī)定，如果終端客戶要轉發(fā)一個消息時，此時轉發(fā)的目的地不在被信任的網絡中，則必須移除已經P-Asserted Identity。這里，如果對端不在可信任的網絡中，對端收到的信息以后則不會看作是一個private的消息。當代理進行轉發(fā)時，它必須決定下一個節(jié)點是否可信。如果是可信的節(jié)點，它不會移除任何自己創(chuàng)建的P-Asserted Identity或來自于可信任節(jié)點的P-Asserted Identity（PAI一般用于兩個Proxy之間的可信任機制，說明UA是通過可信任機制驗證的）。如果是不信任的節(jié)點，則必須檢查Privacy的消息。P-Prefered-Identity（PPI）是終端通知Proxy使用聲明的身份驗證方式來支持可信任機制（一般用于UA到Proxy之間的傳遞）。在P-Asserted Identity 的值中必須包括name-addr/addr-spec，可以是一個值或者兩個值。如果是一個值，則必須是sip，sips或者tel URL。如果是兩個值，一個值必須是sip或者sips URL，另外值必須是tel URL。P-Prefered-Identity也是一樣的要求。
注意，RFC3325 這是針對P-Asserted Identity做了規(guī)定，但是沒有非常明確說明P-Asserted Identity（PAI）和P-Prefered-Identity（PPI）在SIP其他methods中的使用方式和響應方式，RFC5876一個針對RFC3325的拓展協(xié)議，在RFC5876專門對SIP UPDTAE， MESSAGE和PUBLISH做了規(guī)定。事實上，在RFC5876的規(guī)定中也沒有完全說明以上Methods中的P-Asserted Identity用法。讀者如果感興趣的話，可以查閱RFC5876做進一步研究。
以下示例是終端支持了P-Prefered-Identity的消息說明，UA首先發(fā)送INVITE消息，并且攜帶了P-Prefered-Identity，經過第一個Proxy（1），創(chuàng)建了P-Asserted Identity（2），然后經過第一個trusted 節(jié)點，通過這個trusted 節(jié)點到最后一個Untrusted（3），移除P-Asserted Identity消息（4）。
以下消息是終端未帶P-Prefered-Identity的消息說明，因為最后一個節(jié)點是Trusted 節(jié)點，這里的P-Asserted Identity沒有被移除，最后到一個trusted 節(jié)點。
6、企業(yè)IPPBX部署時可能需要涉及呼叫音這個概念。通常情況下，運營商會對企業(yè)客戶端IPPBX發(fā)送SIP響應的消息，企業(yè)IPPBX則根據不同的響應碼生成不同的呼叫音。本地IPPBX可以根據不同的SIP響應碼來生成本地的呼叫音。為了滿足通信行業(yè)標準的呼叫音，IPPBX廠家一般都會根據ITU的標準來生成標準的呼叫音，但是生成什么樣的呼叫音完全有賴于本地IPPBX本身。
7、在部署SIP trunk時，盡管所有廠家都聲稱遵守RFC，但是在實際應用環(huán)境中，因為很多廠家對RFC的解釋不同，或者無法支持更多的RFC標準，這樣可能導致運營商SIP trunk可能不能和廠家的IPPBX完全兼容。這是非常常見的問題。因此，企業(yè)用戶在部署SIP trunk時需要考慮以下幾個方面的問題：
- 關于企業(yè)IPPBX IP地址的問題，運營商可能需要企業(yè)客戶提供IP地址，這里的IP地址可能是企業(yè)客戶的SBC地址，也可能是IPPBX地址，企業(yè)客戶是否有第二個IP地址，是否通過第二個IP地址做逃生處理。
- 確認企業(yè)SBC是否可以支持SIP Digest Authentication，保證驗證消息可以成功接受。
- 企業(yè)客戶終支持的號碼格式（SIP From URL），是完全純位數號碼還是+164的格式。因為號碼格式會影響號碼匹配路由方式，用戶首先需要了解這個號碼格式。
- 企業(yè)客戶終端設備是否需要支持Diversion 頭的轉發(fā)。如果終端沒有支持的話，運營商可能會添加這個轉發(fā)的頭消息。這個頭消息攜帶了源呼叫號碼消息，它可以支持各種拓展的融合通信功能，例如短信，第三方語音郵箱，ACD等功能。更多關于Diversion 支持的內容，讀者查閱RFC5806。
- 是否支持REFER 實現電話轉接或re-INVITE。
- 確認企業(yè)客戶的終端是否真正支持RFC3264中規(guī)定的SDP Offer/Answer模式。
- SIP終端設備是否支持RFC2833，是否支持RFC4733定義的RTP Payload，終端設備是否支持使用G.711，使用帶內傳輸DTMF。
- 終端設備是否具備了支持SBC的能力，包括丟包處理，數據包優(yōu)先級設置，抖動，時延和MoS設置。
- 終端設備是否完全支持呼叫等待中的頭域支持能力支持，例如a=inactive/sendonly/recvonly/sendrecv支持和SDP Offer或Answer中的c=0,0,0,0支持。
- 運營商是否正常編碼打包時長的重新設置，通常情況下，SIP終端支持的G.711的打包時長為默認20 ms，運營商是否可以支持不同的打包時長？
- SIP終端必須支持From 頭，并且結合P-Asserted Identity（PAI）獲得可信任身份， 運營商不支持匿名呼出的號碼。
- 為了支持SDP消息中的183，200 Ok，或者202 的帶內呼叫音，在到達終端客戶之前，終端設備必須能夠馬上關閉任何本地生成的呼叫音或切斷早期媒體流。
- 終端設備是否可以支持使用RTCP-XR（RTP Control Protocol Extended Reports）生成VOIP報告，它可以方便對SIP設備的排查，主要包括的傳輸是：丟包，PLC和信號級等參數。讀者可以查閱RFC3611獲得更多信息。
8、企業(yè)用戶在部署SIP trunk可能會遇到一些問題，筆者羅列了一些主要問題，幫助用戶可以快速排查問題。這些問題大致包括：
- SIP trunk 創(chuàng)建失敗，一般情況下，客戶需要檢查域名，防火墻賬號和密碼設置。
- 403 Forbidden 錯誤，用戶重新檢查密碼。
- 407 Proxy Authentication Required, 企業(yè)IPPBX對運營商的Proxy發(fā)送一個INVITE消息來驗證IPBBX身份。
- 語音質量問題，企業(yè)用戶確保支持足夠的帶寬，通過以上章節(jié)介紹的工具來計算所需帶寬。
- 單通問題，雙方不能聽到對方的聲音，此問題通常是因為防火墻引起的，企業(yè)用戶檢查自己的防火墻。
- trunk 經常掉線的問題，通常情況下，用戶需要重新設置IPPBX的SIP定時器來保證trunk 處于keep live狀態(tài)。企業(yè)用戶可以考慮把定時器設置到小于20 ms。
9、目前市場上已經有很多IPPBX，但是用戶在選擇IPPBX仍然可能會遇到很多兼容性的問題，可能很多廠家對SIP兼容性測試也不夠重視，不夠嚴謹，這樣就可能導致某些IPPBX功能或對SIP終端支持能力不好，還有因為目前很多廠家都是使用開源平臺來開發(fā)的IPPBX，廠家也沒有花費時間在底層做進一步的研究，如果開源的平臺支持了SIP的兼容性參數，則默認廠家的也支持了這些參數。根據SIPit的2014年的測試報告指出（筆者沒有拿到最新的測試報告）：
以上采集的數據基本上涵蓋了目前世界上比較有名的廠家IPPBX和終端產品，對企業(yè)用戶選擇IPPBX有一定的參考作用，企業(yè)用戶可以根據這些數據進一步和IPPBX或終端廠家進行溝通來保證產品的兼容性。
在以上章節(jié)的討論中，筆者首先介紹了SIP trunk的一些背景知識和其優(yōu)勢，也介紹了企業(yè)部署SIP trunk的拓撲圖，在部署時討論了MPLS和SD-WAN在最新技術方面對SIP的支持。在部署SIP trunk時用戶可能面對很多的介紹問題，這些問題需要企業(yè)用戶逐一對照和進一步的研究來保證能夠成功部署SIP turnk。在實際使用過程中，用戶可能會遇到一些常見的問題，筆者也做了簡單分享，用戶可以根據這個思路來做排查工作。最后，筆者根據SIPit的報告羅列出了終端廠家和IPPBX廠家的兼容性測試出現的問題，這樣幫助企業(yè)用戶能夠全面掌握存在的問題，在部署IPPBX前及時和廠家進行溝通。
參考資料：
https://tools.ietf.org/wg/mpls/
https://tools.ietf.org/id/draft-rosenberg-sipping-siptrunk-00.txt
https://yq.aliyun.com/articles/125331
https://www.sdxcentral.com/
https://tools.ietf.org/html/rfc5876
https://tools.ietf.org/html/rfc3325
http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf
https://www.packetizer.com/rfc/rfc3611/
http://www.voiptroubleshooter.com/tools/voiptr_rtcpxr.htm
https://www.sipit.net/SIPit31_summary
關注微信公眾號：asterisk-cn，獲得有價值的行業(yè)分享。訪問開源IPPBX論壇獲得技術幫助：www.issabel.cn/forum
