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