- 不能注冊或呼叫到SIP服務(wù)器端
- 30秒掛斷呼叫的黃金法則
- 咬線(xiàn)或摘機狀態(tài)
- 單通或無(wú)語(yǔ)音
- 收到400 bad request
- 收到413，513 Request Entity Too Large或Message Too Large消息
- 收到408， 480或者487 消息
- 483 - Too Many Hops
- 488 – Not Acceptable Here
- 語(yǔ)音質(zhì)量和思科語(yǔ)音文件示例分享
這里，讀者一定要注意，我們這里僅討論關(guān)于SIP環(huán)境中的常見(jiàn)問(wèn)題，可能涉及網(wǎng)絡(luò )環(huán)境或者硬件終端的問(wèn)題，因為很多廠(chǎng)家和SIP服務(wù)器的配置不同，可能存在一定的差異，所以用戶(hù)在我們的方法中特別需要根據廠(chǎng)家的不同，增加一些專(zhuān)門(mén)針對每個(gè)廠(chǎng)家或者SIP服務(wù)器的排查方式。我們僅討論一般情況下的排查方式。
1、在一般的SIP 環(huán)境中，通常來(lái)說(shuō)，SIP 終端需要注冊到SIP服務(wù)器端來(lái)實(shí)現認證，服務(wù)器端獲得SIP終端的位置，然后才能進(jìn)行正常的呼叫流程。注冊問(wèn)題可能有以下幾種呈現方式：
- 不能注冊，完全沒(méi)有和SIP服務(wù)器連接。如果終端發(fā)送注冊消息給服務(wù)器端時(shí)，雙方完全可能完全沒(méi)有實(shí)現通訊。用戶(hù)需要在服務(wù)器端通過(guò)日志排查方式，檢查SIP終端是否有注冊消息進(jìn)入到服務(wù)器端，或者SIP終端通過(guò)網(wǎng)絡(luò )工具對服務(wù)器端進(jìn)行排查，例如使用Ping 命令。如果連Ping命令都檢測不到服務(wù)器地址，基本上可以斷定SIP終端根本沒(méi)有和服務(wù)器端連接。關(guān)于服務(wù)器端排查方式很多，最典型的就是使用的Asterisk，FreeSWITCH，OpenSIPS或者Kamailio等開(kāi)源的軟交換平臺。每個(gè)平臺都有各自的排查命令，用戶(hù)可以參考官方手冊來(lái)判斷。當然，用戶(hù)也可以使用linux排查工具對5060端口抓包排查（例如，sngrep）。本人非常推薦這個(gè)工具，非常好用，可以實(shí)時(shí)檢查SIP消息。
- SIP終端發(fā)出了注冊消息，但是SIP服務(wù)器端沒(méi)有返回的消息。如果SIP終端對SIP服務(wù)器端發(fā)送了注冊消息，但是服務(wù)器端沒(méi)有返回響應消息，則可能是服務(wù)器端的問(wèn)題。用戶(hù)需要排查服務(wù)器端為什么沒(méi)有返回消息，或者在返回路徑上的節點(diǎn)是否出現了問(wèn)題。
- 客戶(hù)端收到錯誤消息，收到太多401/407 Unauthorized。SIP終端在注冊時(shí)，如果用戶(hù)的安全設置出現了錯誤，可能導致服務(wù)器端發(fā)送多個(gè) 401 錯誤。服務(wù)器端第一次發(fā)送到是正常的401驗證信息，如果連續多次發(fā)送401/407 錯誤的話(huà)，可能是SIP終端輸入了錯誤的用戶(hù)賬號信息，SIP終端側需要配合服務(wù)器端進(jìn)行排查，也可能服務(wù)器端的SIP賬號消息保存錯誤，或者沒(méi)有重新加載服務(wù)器相應模塊，用戶(hù)最好通過(guò)服務(wù)器端的CLI命令來(lái)檢查內存中的SIP終端的真實(shí)數據信息。
- 客戶(hù)端收到403 Forbidden 消息。如果用戶(hù)帳戶(hù)信息沒(méi)有問(wèn)題的話(huà)，SIP終端可能沒(méi)有輸入正確的From domain或者R-URI。有時(shí)，服務(wù)器端禁止同時(shí)注冊幾個(gè)SIP終端賬號，或者注冊過(guò)于頻繁，服務(wù)器端可能過(guò)濾了此地址。需要用戶(hù)配合服務(wù)器端地址進(jìn)行進(jìn)一步檢查。這里，筆者僅討論注冊階段出現的403 問(wèn)題，當然也可能是系統防火墻或者其他的配置禁止了注冊消息。如果是呼叫時(shí)出現403的話(huà)，則可能是另外的原因，例如可能欠費，可能呼叫了服務(wù)器端禁止的號碼碼位等其他因素。
2、我們經(jīng)常會(huì )遇到客戶(hù)抱怨這樣的問(wèn)題，電話(huà)通話(huà)時(shí)，在大概30秒左右就斷線(xiàn)。這樣的問(wèn)題最主要的原因是SIP終端沒(méi)有收到ACK消息。SIP終端發(fā)送了 200 OK以后就開(kāi)始了媒體的創(chuàng )建，RTP語(yǔ)音流開(kāi)始啟動(dòng)，事實(shí)上，SIP終端可能還沒(méi)有收到ACK消息，因此在30秒左右，沒(méi)有收到消息的一方就發(fā)送了一個(gè)BYE消息。那么，為什么我們沒(méi)有收到ACK消息呢？
具體的場(chǎng)景如下兩種示例，返回時(shí)因為NAT問(wèn)題導致ACK沒(méi)有辦法返回到相應的終端：
在很多應用場(chǎng)景中，用戶(hù)可能遇到更為復雜的NAT環(huán)境，如果其中一個(gè)代理出現了NAT處理無(wú)效的結果，就可能導致整個(gè)SIP信令路徑出現ACK丟失的問(wèn)題。
一般情況下，缺少ACK消息的原因主要來(lái)自于以下幾個(gè)方面：
- Contact header 錯誤
- 客戶(hù)端沒(méi)有支持router header
- 網(wǎng)關(guān)在NAT后
- Contact header 的地址在NAT后
以上幾種情況都需要用戶(hù)排查網(wǎng)絡(luò )環(huán)境和NAT設置。因為NAT問(wèn)題，ACK返回的路徑地址發(fā)生了改變，所以SIP終端沒(méi)有收到ACK消息。
一些廠(chǎng)家的設備或者媒體服務(wù)器也有類(lèi)似的設置，例如Lync 服務(wù)器，它支持了RTCP 呼叫活動(dòng)檢測功能，如果超過(guò)30秒的檢測周期沒(méi)有收到RTCP數據包，則會(huì )掛機。在開(kāi)源Asterisk平臺上，RTP的默認設置時(shí)間為30秒，一些SIP運營(yíng)商可能會(huì )忽略UPDTAE消息，在SIP的設置中可以對其進(jìn)行設置調整disallowed_methods=UPDATE 或SIP的會(huì )話(huà)定時(shí)器設置。
3、SIP終端不能掛機或者處于摘機狀態(tài)是第三個(gè)經(jīng)常遇到的問(wèn)題。在SIP終端中的表現形式為終端沒(méi)有發(fā)送BYE消息或者發(fā)送了錯誤的BYE消息內容。
沒(méi)有發(fā)送BYE的狀態(tài)：
其原因主要表現在：
- 沒(méi)有發(fā)送BYE消息
- 發(fā)送到BYE消息攜帶了錯誤的to-tag
- 發(fā)送了格式不規范的BYE消息，例如格式錯誤，sequences錯誤或者時(shí)間戳錯誤。
- 發(fā)送的BYE消息中攜帶的是錯誤的路由信息
對于出現的這些問(wèn)題，用戶(hù)需要根據SIP消息來(lái)進(jìn)行排查，對比哪些路徑節點(diǎn)出現了問(wèn)題。當然，這些問(wèn)題帶來(lái)的結果大家可能都非常清楚。首先，計費的準確性出現了問(wèn)題，用戶(hù)的計費不能完整準確地監控。另外，如果媒體服務(wù)器對呼叫有限制的話(huà)，因為其中一個(gè)SIP終端沒(méi)有真正掛機，其他用戶(hù)可能不能呼出的問(wèn)題。如果是一臺模擬網(wǎng)關(guān)的話(huà)，可能出現FXO或者FXS不能正常工作的問(wèn)題。
出現以上這些問(wèn)題，讀者還是要從終端的配置來(lái)解決問(wèn)題，是否出現了終端的配置問(wèn)題，終端的質(zhì)量問(wèn)題。如果是FXO或者FXS的話(huà)，是否出現了制式不匹配的問(wèn)題導致咬線(xiàn)或者摘機的問(wèn)題。
從服務(wù)器端處理的話(huà)，可以通過(guò)兩種辦法來(lái)通過(guò)服務(wù)器端對其進(jìn)行強制掛機處理。這四種服務(wù)器端的檢測方式是：
- 開(kāi)啟RTP超時(shí)檢測來(lái)檢測終端的RTP流是否仍然活動(dòng)
- 開(kāi)啟SIP的KeepAlive 檢測SIP 會(huì )話(huà)狀態(tài)
- 使用Proxy中的dialog中的OPTION來(lái)檢測SIP終端響應狀態(tài)，SIP終端發(fā)送 200 OK到proxy來(lái)檢測終端的狀態(tài)。
- 使用SIP session timer 定時(shí)器來(lái)進(jìn)行周期檢測，SIP終端一直在周期內刷新自己的狀態(tài)。如果SIP終端來(lái)定時(shí)器的時(shí)間范圍內，則表示終端參與活動(dòng)狀態(tài)；否則，則對其發(fā)送BYE消息，強行掛機。
關(guān)于session timer的規范，大家可以參考rfc4028，具體的定義方式如下：
完整的SIP sesison timer 流程圖如下：
但是，因為很多SIP網(wǎng)絡(luò )環(huán)境中介入了SBC或者其他的網(wǎng)絡(luò )設備，很多情況下，有時(shí)定時(shí)器時(shí)間設置過(guò)短，SBC作為UAC或者UAS，或者proxy不刷新都可能出現上述問(wèn)題。所以，會(huì )話(huà)的定時(shí)器的管理需要特別小心。
4、在SIP 語(yǔ)音呼叫中，一些用戶(hù)也經(jīng)常遇到單通的問(wèn)題，簡(jiǎn)單來(lái)說(shuō)，就是雙方呼叫時(shí)，只能聽(tīng)到一方的語(yǔ)音。單通問(wèn)題的主要原因來(lái)自于以下幾個(gè)方面：
- INVITE和200 OK中的SDP的地址不通。用戶(hù)可以通過(guò)sngrep工具來(lái)檢查SDP的地址是否可以ping 通。如果INVITE中的地址不能和200 OK中的SDP地址不能連通的話(huà)，可能導致單通的問(wèn)題，有時(shí)也存在NAT問(wèn)題，需要用戶(hù)針對性地進(jìn)行排查。
- 網(wǎng)絡(luò )防火墻過(guò)濾了UDP端口。如果以上兩個(gè)地址相通的話(huà)，也有可能是網(wǎng)絡(luò )的防火墻過(guò)濾了RTP端口。用戶(hù)必須開(kāi)啟路由器的端口轉發(fā)策略，媒體服務(wù)器的端口范圍不同，可能rtp的端口設置不同。一般的例如Asterisk或者FreeSWITCH都是10000-20000的端口范圍，也有一些服務(wù)器端口從其他的數值開(kāi)始計算。
- ALG 網(wǎng)關(guān)設置問(wèn)題。ALG網(wǎng)關(guān)有時(shí)可以解決NAT問(wèn)題，但是也同樣會(huì )帶來(lái)其他的問(wèn)題。ALG可以設置其他的SIP 服務(wù)器端口。有時(shí)用戶(hù)可以關(guān)閉路由器上的ALG選項解決單通問(wèn)題。
5、有時(shí)，SIP終端可能收到400 Bad Request的消息。通常情況下，這是因為消息體中攜帶了非法的參數或者SIP服務(wù)器或者代理不能正確解析消息體格式，有可能在消息體中攜帶了重復的參數設置或者其他非法字符。在以下的示例中，出現了兩個(gè)重復的mkp參數設置，顯然，SIP proxy 不可能解析這個(gè)格式。另外，在最后一個(gè)header中，因為解析失敗的原因，可能丟失了To以后的最后Contact 頭域值。
還有很多其他的配置也可能導致400 Bad Request，例如Content-Length長(cháng)度的問(wèn)題，NAT地址的無(wú)效的host問(wèn)題等問(wèn)題。讀者一定要特別注意，對于Content-Length或者其他的語(yǔ)法格式的規范。具體的規范用戶(hù)可以參考rfc4475。在rfc4475中有如下定義：
- When sent over UDP （as this message ostensibly was）, the receiving
- element should respond with a 400 Bad Request error.
- 用戶(hù)在SIP的消息體中，可以看到關(guān)于Content-Length的數值，然后通過(guò)實(shí)際計算，獲得真正的Content-Length數值。以下的示例說(shuō)明了一個(gè)簡(jiǎn)單的400 Bad Request。這里，因為Content-Length數值不符導致的400 Bad Request錯誤。
- 用戶(hù)可以使用計算工具來(lái)計算實(shí)際的Content-Length的值，然后根據SIP中的Content-Length判斷是否是相等，在以上圖例中，Content-Length是10000，實(shí)際數值為145。通常情況下，用戶(hù)如果懷疑Content-Length的問(wèn)題，系統出現了400 Bad Request就是因為兩個(gè)值不相等導致。
6、"513 Message Too Large" 是用戶(hù)經(jīng)常遇到的一個(gè)問(wèn)題，通常情況下，顯示的消息是413 - Entity too large 或513 Message too big等類(lèi)似的錯誤。錯誤示例如下：
- U 192.168.1.109:5060 -> 192.168.1.1:5060
- SIP/2.0 513 Message too big.Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch=
- z9hG4bKcf61.2d407ae2.0.
- Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch=
- z9hG4bKcf61.1d407ae2.0.
- Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch=
- z9hG4bKcf61.0d407ae2.0.
- Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch=
- z9hG4bKcf61.fc407ae2.0.
- Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123
- ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296.
- To: "100"
- From: "100"
- Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk
導致 413 或者513 錯誤主要來(lái)自于以下幾個(gè)方面的因素：
- UDP包的限制是1500 bytes
- Proxy路由路徑中添加了太多的VIA header
- 路由路徑中添加Record-Route headers
- 終端配置了太多的編碼選項支持
針對以上這些因素和具體的原因，用戶(hù)可以根據以下幾個(gè)方面的策略來(lái)排查問(wèn)題：
- 盡量減少太多的proxy路由，大家知道，每經(jīng)過(guò)一個(gè)proxy路由就會(huì )增加相應的頭值，最后可能出現數據包太大的問(wèn)題，UDP拒絕通過(guò)。
- 盡量減少終端的編碼選項支持，我們建議用戶(hù)使用1-3種常用的編碼即可。
- 排查一些SIP 服務(wù)器可能增加額外的自有的頭包。一些商業(yè)的解決方案可能有自有的非標準的頭包，如果沒(méi)有必要的話(huà)，可以關(guān)閉這些選項設置。
- 使用拓撲隱藏方式或者B2BUA減少路由的其他開(kāi)銷(xiāo)。這種方式僅產(chǎn)生新的請求，不會(huì )增加Via header頭域值和record header。
- 盡量不要使用BLF, 因為BLF會(huì )不斷發(fā)送新的消息，數據包會(huì )增加。
7、一些用戶(hù)可能會(huì )遇到408， 480 或者487的消息。通常情況下，這三個(gè)錯誤消息和SIP的定時(shí)器相關(guān)，可能服務(wù)器端或者用戶(hù)端的定時(shí)器設置相關(guān)。很多SIP服務(wù)器在收到臨時(shí)響應消息前，有一個(gè)5秒鐘的時(shí)間限定。如果超時(shí)的話(huà)，就會(huì )返回408 消息。實(shí)際上，SIP 服務(wù)器端和SIP 用戶(hù)端都有各自的呼叫等待超時(shí)設置。在實(shí)際的環(huán)境中，用戶(hù)出現錯誤碼時(shí)，問(wèn)題可能來(lái)自于SIP終端設置或者SIP服務(wù)器端的超時(shí)設置。
在一個(gè)呼叫創(chuàng )建以后，SIP終端開(kāi)始振鈴，如果SIP服務(wù)器端的超時(shí)設置首先被觸發(fā)，服務(wù)器端就會(huì )返回一個(gè)408 timeout 消息。如果是SIP終端的超時(shí)設置被首先觸發(fā)的話(huà)，客戶(hù)端會(huì )發(fā)送一個(gè)480 消息。每次觸發(fā)超時(shí)以后，對端都會(huì )發(fā)送一個(gè)Cancel, 這里的Cancel 和INVITE是兩個(gè)分別不同的事務(wù)， 他們執行各自的流程。如果SIP 用戶(hù)端在一定的超時(shí)設置時(shí)間內沒(méi)有人接聽(tīng)呼叫，就會(huì )返回一個(gè)487 消息。讀者可以參考以下示例來(lái)進(jìn)一步了解487（cause 487 request terminated）的使用場(chǎng)景。這里的OK響應的是Cancel。487響應的是INVITE。
有時(shí)也可能是SIP終端本地設置的問(wèn)題，設置錯誤，也可能導致408 超時(shí)錯誤。如果SIP終端收到了408 超時(shí)消息，這表示SIP終端嘗試連接的SIP服務(wù)器沒(méi)有任何回復消息。SIP終端需要檢查本地的網(wǎng)絡(luò )設置（STUN或者TURN）或者NAT設置。
8、“483 too many hops”也是SIP 新用戶(hù)經(jīng)常遇到的問(wèn)題。一般情況下，如果用戶(hù)配置了服務(wù)器，錯誤配置domain或不清楚domain。有時(shí)，如果運營(yíng)商的MAX-Forwards支持的設置比較小的時(shí)候（默認是70），SIP終端也會(huì )出現這個(gè)錯誤。服務(wù)器端會(huì )返回原來(lái)的地址，這樣就會(huì )導致一個(gè)SIP 地址形成一個(gè)自己的回環(huán)網(wǎng)絡(luò )。大家知道，在SIP header中的MAX-Forwards 每經(jīng)過(guò)一個(gè)跳，這個(gè)數值就會(huì )遞減1，最后，Max-Forwards 減少到0。因此，服務(wù)器端響應一個(gè)483消息。
一些SIP 解決方案的廠(chǎng)家也支持了Loop Detection 功能，它可以支持detect 模式，超時(shí)設置和閥值，如果用戶(hù)遇到類(lèi)似的設備的話(huà)，可以開(kāi)啟這些參數做進(jìn)一步的優(yōu)化措施。
9、除了以上這些問(wèn)題以外，還有一些問(wèn)題是用戶(hù)根本沒(méi)有意識到的，這些問(wèn)題也相對比較專(zhuān)業(yè)，因此，用戶(hù)很難找一下子到真正的解決方案。這些問(wèn)題中，“488 Not Acceptable here" 就是一個(gè)比較特殊的問(wèn)題。用戶(hù)不清楚如何解決這些問(wèn)題。 因為這個(gè)問(wèn)題可能涉及到了SIP服務(wù)器端的配置。一般情況下，如果SIP 終端出現這個(gè)問(wèn)題的話(huà)，都是因為編碼不支持導致的。如果不同的SIP終端使用了不同的語(yǔ)音編碼的話(huà)，需要SIP媒體服務(wù)器進(jìn)行編碼協(xié)商，如果雙方的編碼統一了，才能進(jìn)行正常的呼叫。很多情況下，用戶(hù)設置的編碼有很大差異，如果媒體服務(wù)器編碼協(xié)商失敗的話(huà)，就會(huì )返回488的錯誤。
關(guān)于服務(wù)器端編碼支持能力，用戶(hù)可以和維護人員聯(lián)系，檢查是否支持SIP終端設置的編碼，如果不支持的話(huà)，需要關(guān)閉編碼選項。很多情況下，特別是用戶(hù)使用Asterisk或FreeSWITCH，為了節省網(wǎng)絡(luò )帶寬的開(kāi)銷(xiāo)，很多SIP trunk 或者IMS使用了G.729。但是，很多Asterisk和FreeSWITCH 如果沒(méi)有默認配置G.729的模塊的話(huà)， 或者沒(méi)有編碼轉換的能力，那么服務(wù)器端結合出現編碼協(xié)商失敗的問(wèn)題，最后返回488 響應消息。關(guān)于A(yíng)sterisk或者FreeSWITCH 如何支持G.729 編碼的問(wèn)題，讀者可以參考筆者微信號的歷史文檔。這里不再做過(guò)多討論。
有時(shí)，在以前的FreeSWITCH平臺上，488 協(xié)商問(wèn)題也可能出現在一些傳真的檢測功能上。如果傳真協(xié)商出現問(wèn)題，也可能導致488 響應的錯誤消息。
10、經(jīng)常聽(tīng)到客戶(hù)的投訴說(shuō)語(yǔ)音質(zhì)量不好。在VOIP環(huán)境中，很多因素影響語(yǔ)音質(zhì)量。筆者在前面的討論中討論了關(guān)于MOS的評測等技術(shù)手段。這里不再累述。
除了以上鏈接中提到的三種問(wèn)題以外，我們這里簡(jiǎn)單說(shuō)明一下語(yǔ)音回聲的三個(gè)黃金法則：
- 回聲總是在聽(tīng)到回聲的對端產(chǎn)生
- 回聲的問(wèn)題大部分是有PSTN的接入設備導致，所以盡量使用帶回聲的處理接入設備，杜絕回聲的產(chǎn)生
- 如果遇到回聲，不使用帶揚聲器的終端測試，使用耳麥軟電話(huà)測試。
- 一般來(lái)說(shuō)，回聲是從終端或者接入設備傳入，因此必須從接入或者終端方解決回聲問(wèn)題。
- 很多客戶(hù)也不清楚語(yǔ)音問(wèn)題的真實(shí)的感受，用戶(hù)可以聽(tīng)筆者的語(yǔ)音文件示例，感受各種語(yǔ)音問(wèn)題。筆者提供了一個(gè)講話(huà)人自己的回聲示例：
當然，語(yǔ)音質(zhì)量的問(wèn)題僅是一個(gè)比較寬泛的說(shuō)法，其概念本身不具有規范和專(zhuān)業(yè)性。思科技術(shù)網(wǎng)站對各種語(yǔ)音問(wèn)題的原因做了大量的研究，也提供了對各種語(yǔ)音問(wèn)題的排查方式和產(chǎn)生原因。讀者可以參考思科的技術(shù)文檔。
根據思科對語(yǔ)音問(wèn)題的定義，思科定義為：噪音和語(yǔ)音失真。噪音類(lèi)別包括以下幾個(gè)類(lèi)別：
- Absolute Silence
- Clicking
- Crackling
- Crosstalk
- Hissing
- Hum
- Popping
- Motor Sound
- Screeching
- Static
以上這些類(lèi)別有不同的文件示例，因為微信不能插入多個(gè)語(yǔ)音文件，用戶(hù)可以到思科網(wǎng)站查詢(xún)。語(yǔ)音失真又進(jìn)一步定義了多種語(yǔ)音失真的子類(lèi)別，他們分別為：
- 回聲語(yǔ)音
- 混亂語(yǔ)音
- 音量失真
11、在本章節的討論中，筆者重點(diǎn)對SIP 呼叫中存在的十大常見(jiàn)的經(jīng)典問(wèn)題做了比較詳細的介紹，同時(shí)針對每個(gè)SIP 響應錯誤的原因也做了深入的分析。每個(gè)SIP消息的生成都和終端的配置，服務(wù)器的支持能力，網(wǎng)絡(luò )環(huán)境有著(zhù)非常緊密的聯(lián)系。用戶(hù)需要借助排查工具，然后根據筆者的建議來(lái)進(jìn)行排查。當然，筆者的建議僅是一個(gè)思路而已，具體的問(wèn)題可能和其他的因素相關(guān)。所以，讀者一定要根據技術(shù)文檔結合實(shí)際情況來(lái)排查問(wèn)題。
在最后的章節中，筆者特別建議用戶(hù)查看思科的語(yǔ)音示例文件和其解決辦法，這是比較權威的語(yǔ)音排查方式，也相對應該說(shuō)VOIP領(lǐng)域最完整的語(yǔ)音示例，強烈建議讀者參考學(xué)習。
另外，筆者這里列出的問(wèn)題也不能非常完整歸納所有的SIP方面的問(wèn)題，也不能完全保證解決所有所列出的問(wèn)題，需要讀者根據實(shí)際呼叫來(lái)動(dòng)手解決。這里，筆者的目的僅是一個(gè)學(xué)習分享。有錯誤之處，望諒解！
參考資料：
https://github.com/irontec/sngrep/wiki
http://www1.coe.neu.edu/~eeichen/spring_2015/class_notes/b_jan_20/RTP_new.pdf
http://www.helpmedial.com/docs/Advanced-Router-SIP-ALG-Troubleshooting.pdf
https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/
https://tools.ietf.org/html/rfc4028
https://tools.ietf.org/html/rfc4475#section-3.1.2.2
http://www.charactercountonline.com/
https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/rsip_reftimesumm.html
https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/30141-symptoms.html
關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
