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