<p id="l1pda"></p>
<track id="l1pda"></track>
      1. 您當前的位置是:  首頁 > 新聞 > 文章精選 >
         首頁 > 新聞 > 文章精選 >

        SIP語音環境中十大經典問題及解決辦法

        2018-12-28 09:37:18   作者:james.zhu   來源:CTI論壇   評論:0  點擊:


          在VOIP的環境中,特別是基于SIP通信的環境中,我們經常會遇到一些非常常見的問題,例如,單通,30秒就斷線,注冊問題,回聲等。這些問題事實上都有非常直接的排查方式和解決辦法,用戶可以按照一定的排查方式,工具非常高效地解決這些問題。但是,因為讀者技術水平參差不齊,網絡上的很多技術也不完整。筆者今天系統歸納了這些問題。根據一些用戶的使用環境和用戶經常遇到一些問題,我們列舉了以下十個在SIP呼叫中經常遇到的問題,并且給出了相應的排查方式,用戶可以按照這些方法來解決SIP通話中的這些問題。這十個經典的問題包括:
        1. 不能注冊或呼叫到SIP服務器端
        2. 30秒掛斷呼叫的黃金法則
        3. 咬線或摘機狀態
        4. 單通或無語音
        5. 收到400 bad request
        6. 收到413,513 Request Entity Too Large或Message Too Large消息
        7. 收到408, 480或者487 消息
        8. 483 - Too Many Hops
        9. 488 – Not Acceptable Here
        10. 語音質量和思科語音文件示例分享
          這里,讀者一定要注意,我們這里僅討論關于SIP環境中的常見問題,可能涉及網絡環境或者硬件終端的問題,因為很多廠家和SIP服務器的配置不同,可能存在一定的差異,所以用戶在我們的方法中特別需要根據廠家的不同,增加一些專門針對每個廠家或者SIP服務器的排查方式。我們僅討論一般情況下的排查方式。
          1、在一般的SIP 環境中,通常來說,SIP 終端需要注冊到SIP服務器端來實現認證,服務器端獲得SIP終端的位置,然后才能進行正常的呼叫流程。注冊問題可能有以下幾種呈現方式:
        • 不能注冊,完全沒有和SIP服務器連接。如果終端發送注冊消息給服務器端時,雙方完全可能完全沒有實現通訊。用戶需要在服務器端通過日志排查方式,檢查SIP終端是否有注冊消息進入到服務器端,或者SIP終端通過網絡工具對服務器端進行排查,例如使用Ping 命令。如果連Ping命令都檢測不到服務器地址,基本上可以斷定SIP終端根本沒有和服務器端連接。關于服務器端排查方式很多,最典型的就是使用的Asterisk,FreeSWITCH,OpenSIPS或者Kamailio等開源的軟交換平臺。每個平臺都有各自的排查命令,用戶可以參考官方手冊來判斷。當然,用戶也可以使用linux排查工具對5060端口抓包排查(例如,sngrep)。本人非常推薦這個工具,非常好用,可以實時檢查SIP消息。




        • SIP終端發出了注冊消息,但是SIP服務器端沒有返回的消息。如果SIP終端對SIP服務器端發送了注冊消息,但是服務器端沒有返回響應消息,則可能是服務器端的問題。用戶需要排查服務器端為什么沒有返回消息,或者在返回路徑上的節點是否出現了問題。
        • 客戶端收到錯誤消息,收到太多401/407 Unauthorized。SIP終端在注冊時,如果用戶的安全設置出現了錯誤,可能導致服務器端發送多個 401 錯誤。服務器端第一次發送到是正常的401驗證信息,如果連續多次發送401/407 錯誤的話,可能是SIP終端輸入了錯誤的用戶賬號信息,SIP終端側需要配合服務器端進行排查,也可能服務器端的SIP賬號消息保存錯誤,或者沒有重新加載服務器相應模塊,用戶最好通過服務器端的CLI命令來檢查內存中的SIP終端的真實數據信息。
        • 客戶端收到403 Forbidden 消息。如果用戶帳戶信息沒有問題的話,SIP終端可能沒有輸入正確的From domain或者R-URI。有時,服務器端禁止同時注冊幾個SIP終端賬號,或者注冊過于頻繁,服務器端可能過濾了此地址。需要用戶配合服務器端地址進行進一步檢查。這里,筆者僅討論注冊階段出現的403 問題,當然也可能是系統防火墻或者其他的配置禁止了注冊消息。如果是呼叫時出現403的話,則可能是另外的原因,例如可能欠費,可能呼叫了服務器端禁止的號碼碼位等其他因素。
          2、我們經常會遇到客戶抱怨這樣的問題,電話通話時,在大概30秒左右就斷線。這樣的問題最主要的原因是SIP終端沒有收到ACK消息。SIP終端發送了 200 OK以后就開始了媒體的創建,RTP語音流開始啟動,事實上,SIP終端可能還沒有收到ACK消息,因此在30秒左右,沒有收到消息的一方就發送了一個BYE消息。那么,為什么我們沒有收到ACK消息呢?
          具體的場景如下兩種示例,返回時因為NAT問題導致ACK沒有辦法返回到相應的終端:

          在很多應用場景中,用戶可能遇到更為復雜的NAT環境,如果其中一個代理出現了NAT處理無效的結果,就可能導致整個SIP信令路徑出現ACK丟失的問題。
          一般情況下,缺少ACK消息的原因主要來自于以下幾個方面:
        • Contact header 錯誤
        • 客戶端沒有支持router header
        • 網關在NAT后
        • Contact header 的地址在NAT后
          以上幾種情況都需要用戶排查網絡環境和NAT設置。因為NAT問題,ACK返回的路徑地址發生了改變,所以SIP終端沒有收到ACK消息。
          一些廠家的設備或者媒體服務器也有類似的設置,例如Lync 服務器,它支持了RTCP 呼叫活動檢測功能,如果超過30秒的檢測周期沒有收到RTCP數據包,則會掛機。在開源Asterisk平臺上,RTP的默認設置時間為30秒,一些SIP運營商可能會忽略UPDTAE消息,在SIP的設置中可以對其進行設置調整disallowed_methods=UPDATE 或SIP的會話定時器設置。
          3、SIP終端不能掛機或者處于摘機狀態是第三個經常遇到的問題。在SIP終端中的表現形式為終端沒有發送BYE消息或者發送了錯誤的BYE消息內容。
          沒有發送BYE的狀態:
          其原因主要表現在:
        • 沒有發送BYE消息
        • 發送到BYE消息攜帶了錯誤的to-tag
        • 發送了格式不規范的BYE消息,例如格式錯誤,sequences錯誤或者時間戳錯誤。
        • 發送的BYE消息中攜帶的是錯誤的路由信息
          對于出現的這些問題,用戶需要根據SIP消息來進行排查,對比哪些路徑節點出現了問題。當然,這些問題帶來的結果大家可能都非常清楚。首先,計費的準確性出現了問題,用戶的計費不能完整準確地監控。另外,如果媒體服務器對呼叫有限制的話,因為其中一個SIP終端沒有真正掛機,其他用戶可能不能呼出的問題。如果是一臺模擬網關的話,可能出現FXO或者FXS不能正常工作的問題。
          出現以上這些問題,讀者還是要從終端的配置來解決問題,是否出現了終端的配置問題,終端的質量問題。如果是FXO或者FXS的話,是否出現了制式不匹配的問題導致咬線或者摘機的問題。
          從服務器端處理的話,可以通過兩種辦法來通過服務器端對其進行強制掛機處理。這四種服務器端的檢測方式是:
        • 開啟RTP超時檢測來檢測終端的RTP流是否仍然活動
        • 開啟SIP的KeepAlive 檢測SIP 會話狀態
        • 使用Proxy中的dialog中的OPTION來檢測SIP終端響應狀態,SIP終端發送 200 OK到proxy來檢測終端的狀態。
        • 使用SIP session timer 定時器來進行周期檢測,SIP終端一直在周期內刷新自己的狀態。如果SIP終端來定時器的時間范圍內,則表示終端參與活動狀態;否則,則對其發送BYE消息,強行掛機。
          關于session timer的規范,大家可以參考rfc4028,具體的定義方式如下:
          完整的SIP sesison timer 流程圖如下:
          但是,因為很多SIP網絡環境中介入了SBC或者其他的網絡設備,很多情況下,有時定時器時間設置過短,SBC作為UAC或者UAS,或者proxy不刷新都可能出現上述問題。所以,會話的定時器的管理需要特別小心。
          4、在SIP 語音呼叫中,一些用戶也經常遇到單通的問題,簡單來說,就是雙方呼叫時,只能聽到一方的語音。單通問題的主要原因來自于以下幾個方面:
        • INVITE和200 OK中的SDP的地址不通。用戶可以通過sngrep工具來檢查SDP的地址是否可以ping 通。如果INVITE中的地址不能和200 OK中的SDP地址不能連通的話,可能導致單通的問題,有時也存在NAT問題,需要用戶針對性地進行排查。
        • 網絡防火墻過濾了UDP端口。如果以上兩個地址相通的話,也有可能是網絡的防火墻過濾了RTP端口。用戶必須開啟路由器的端口轉發策略,媒體服務器的端口范圍不同,可能rtp的端口設置不同。一般的例如Asterisk或者FreeSWITCH都是10000-20000的端口范圍,也有一些服務器端口從其他的數值開始計算。
        • ALG 網關設置問題。ALG網關有時可以解決NAT問題,但是也同樣會帶來其他的問題。ALG可以設置其他的SIP 服務器端口。有時用戶可以關閉路由器上的ALG選項解決單通問題。
          5、有時,SIP終端可能收到400 Bad Request的消息。通常情況下,這是因為消息體中攜帶了非法的參數或者SIP服務器或者代理不能正確解析消息體格式,有可能在消息體中攜帶了重復的參數設置或者其他非法字符。在以下的示例中,出現了兩個重復的mkp參數設置,顯然,SIP proxy 不可能解析這個格式。另外,在最后一個header中,因為解析失敗的原因,可能丟失了To以后的最后Contact 頭域值。
          還有很多其他的配置也可能導致400 Bad Request,例如Content-Length長度的問題,NAT地址的無效的host問題等問題。讀者一定要特別注意,對于Content-Length或者其他的語法格式的規范。具體的規范用戶可以參考rfc4475。在rfc4475中有如下定義:
        • When sent over UDP (as this message ostensibly was), the receiving
        • element should respond with a 400 Bad Request error.
        • 用戶在SIP的消息體中,可以看到關于Content-Length的數值,然后通過實際計算,獲得真正的Content-Length數值。以下的示例說明了一個簡單的400 Bad Request。這里,因為Content-Length數值不符導致的400 Bad Request錯誤。
        • 用戶可以使用計算工具來計算實際的Content-Length的值,然后根據SIP中的Content-Length判斷是否是相等,在以上圖例中,Content-Length是10000,實際數值為145。通常情況下,用戶如果懷疑Content-Length的問題,系統出現了400 Bad Request就是因為兩個值不相等導致。
          6、"513 Message Too Large" 是用戶經常遇到的一個問題,通常情況下,顯示的消息是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";tag=329cfeaa6ded039da25ff8cbb8668bd2.3724.
        • From: "100";tag=6c4a5976.
        • Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk
          導致 413 或者513 錯誤主要來自于以下幾個方面的因素:
        • UDP包的限制是1500 bytes
        • Proxy路由路徑中添加了太多的VIA header
        • 路由路徑中添加Record-Route headers
        • 終端配置了太多的編碼選項支持
          針對以上這些因素和具體的原因,用戶可以根據以下幾個方面的策略來排查問題:
        • 盡量減少太多的proxy路由,大家知道,每經過一個proxy路由就會增加相應的頭值,最后可能出現數據包太大的問題,UDP拒絕通過。
        • 盡量減少終端的編碼選項支持,我們建議用戶使用1-3種常用的編碼即可。
        • 排查一些SIP 服務器可能增加額外的自有的頭包。一些商業的解決方案可能有自有的非標準的頭包,如果沒有必要的話,可以關閉這些選項設置。
        • 使用拓撲隱藏方式或者B2BUA減少路由的其他開銷。這種方式僅產生新的請求,不會增加Via header頭域值和record header。
        • 盡量不要使用BLF, 因為BLF會不斷發送新的消息,數據包會增加。
          7、一些用戶可能會遇到408, 480 或者487的消息。通常情況下,這三個錯誤消息和SIP的定時器相關,可能服務器端或者用戶端的定時器設置相關。很多SIP服務器在收到臨時響應消息前,有一個5秒鐘的時間限定。如果超時的話,就會返回408 消息。實際上,SIP 服務器端和SIP 用戶端都有各自的呼叫等待超時設置。在實際的環境中,用戶出現錯誤碼時,問題可能來自于SIP終端設置或者SIP服務器端的超時設置。
          在一個呼叫創建以后,SIP終端開始振鈴,如果SIP服務器端的超時設置首先被觸發,服務器端就會返回一個408 timeout 消息。如果是SIP終端的超時設置被首先觸發的話,客戶端會發送一個480 消息。每次觸發超時以后,對端都會發送一個Cancel, 這里的Cancel 和INVITE是兩個分別不同的事務, 他們執行各自的流程。如果SIP 用戶端在一定的超時設置時間內沒有人接聽呼叫,就會返回一個487 消息。讀者可以參考以下示例來進一步了解487(cause 487 request terminated)的使用場景。這里的OK響應的是Cancel。487響應的是INVITE。
          有時也可能是SIP終端本地設置的問題,設置錯誤,也可能導致408 超時錯誤。如果SIP終端收到了408 超時消息,這表示SIP終端嘗試連接的SIP服務器沒有任何回復消息。SIP終端需要檢查本地的網絡設置(STUN或者TURN)或者NAT設置。
          8、“483 too many hops”也是SIP 新用戶經常遇到的問題。一般情況下,如果用戶配置了服務器,錯誤配置domain或不清楚domain。有時,如果運營商的MAX-Forwards支持的設置比較小的時候(默認是70),SIP終端也會出現這個錯誤。服務器端會返回原來的地址,這樣就會導致一個SIP 地址形成一個自己的回環網絡。大家知道,在SIP header中的MAX-Forwards 每經過一個跳,這個數值就會遞減1,最后,Max-Forwards 減少到0。因此,服務器端響應一個483消息。
          一些SIP 解決方案的廠家也支持了Loop Detection 功能,它可以支持detect 模式,超時設置和閥值,如果用戶遇到類似的設備的話,可以開啟這些參數做進一步的優化措施。
          9、除了以上這些問題以外,還有一些問題是用戶根本沒有意識到的,這些問題也相對比較專業,因此,用戶很難找一下子到真正的解決方案。這些問題中,“488 Not Acceptable here" 就是一個比較特殊的問題。用戶不清楚如何解決這些問題。 因為這個問題可能涉及到了SIP服務器端的配置。一般情況下,如果SIP 終端出現這個問題的話,都是因為編碼不支持導致的。如果不同的SIP終端使用了不同的語音編碼的話,需要SIP媒體服務器進行編碼協商,如果雙方的編碼統一了,才能進行正常的呼叫。很多情況下,用戶設置的編碼有很大差異,如果媒體服務器編碼協商失敗的話,就會返回488的錯誤。
          關于服務器端編碼支持能力,用戶可以和維護人員聯系,檢查是否支持SIP終端設置的編碼,如果不支持的話,需要關閉編碼選項。很多情況下,特別是用戶使用Asterisk或FreeSWITCH,為了節省網絡帶寬的開銷,很多SIP trunk 或者IMS使用了G.729。但是,很多Asterisk和FreeSWITCH 如果沒有默認配置G.729的模塊的話, 或者沒有編碼轉換的能力,那么服務器端結合出現編碼協商失敗的問題,最后返回488 響應消息。關于Asterisk或者FreeSWITCH 如何支持G.729 編碼的問題,讀者可以參考筆者微信號的歷史文檔。這里不再做過多討論。
          有時,在以前的FreeSWITCH平臺上,488 協商問題也可能出現在一些傳真的檢測功能上。如果傳真協商出現問題,也可能導致488 響應的錯誤消息。
          10、經常聽到客戶的投訴說語音質量不好。在VOIP環境中,很多因素影響語音質量。筆者在前面的討論中討論了關于MOS的評測等技術手段。這里不再累述。
          除了以上鏈接中提到的三種問題以外,我們這里簡單說明一下語音回聲的三個黃金法則:
        • 回聲總是在聽到回聲的對端產生
        • 回聲的問題大部分是有PSTN的接入設備導致,所以盡量使用帶回聲的處理接入設備,杜絕回聲的產生
        • 如果遇到回聲,不使用帶揚聲器的終端測試,使用耳麥軟電話測試。
        • 一般來說,回聲是從終端或者接入設備傳入,因此必須從接入或者終端方解決回聲問題。
        • 很多客戶也不清楚語音問題的真實的感受,用戶可以聽筆者的語音文件示例,感受各種語音問題。筆者提供了一個講話人自己的回聲示例:
          當然,語音質量的問題僅是一個比較寬泛的說法,其概念本身不具有規范和專業性。思科技術網站對各種語音問題的原因做了大量的研究,也提供了對各種語音問題的排查方式和產生原因。讀者可以參考思科的技術文檔。


          根據思科對語音問題的定義,思科定義為:噪音和語音失真。噪音類別包括以下幾個類別:
        • Absolute Silence
        • Clicking
        • Crackling
        • Crosstalk
        • Hissing
        • Hum
        • Popping
        • Motor Sound
        • Screeching
        • Static
          以上這些類別有不同的文件示例,因為微信不能插入多個語音文件,用戶可以到思科網站查詢。語音失真又進一步定義了多種語音失真的子類別,他們分別為:
        • 回聲語音
        • 混亂語音
        • 音量失真
          11、在本章節的討論中,筆者重點對SIP 呼叫中存在的十大常見的經典問題做了比較詳細的介紹,同時針對每個SIP 響應錯誤的原因也做了深入的分析。每個SIP消息的生成都和終端的配置,服務器的支持能力,網絡環境有著非常緊密的聯系。用戶需要借助排查工具,然后根據筆者的建議來進行排查。當然,筆者的建議僅是一個思路而已,具體的問題可能和其他的因素相關。所以,讀者一定要根據技術文檔結合實際情況來排查問題。
          在最后的章節中,筆者特別建議用戶查看思科的語音示例文件和其解決辦法,這是比較權威的語音排查方式,也相對應該說VOIP領域最完整的語音示例,強烈建議讀者參考學習。
          另外,筆者這里列出的問題也不能非常完整歸納所有的SIP方面的問題,也不能完全保證解決所有所列出的問題,需要讀者根據實際呼叫來動手解決。這里,筆者的目的僅是一個學習分享。有錯誤之處,望諒解!
          參考資料:
          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


          關注微信公眾號:asterisk-cn,獲得有價值的Asterisk行業分享
          Asterisk freepbx 中文官方論壇:http://bbs.freepbx.cn/forum.php
          Asterisk freepbx技術文檔: www.freepbx.org.cn
          融合通信商業解決方案,協同解決方案首選產品:www.hiastar.com
          Asterisk/FreePBX中國合作伙伴,官方qq技術分享群(3000千人):589995817
        【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

        專題

        CTI論壇會員企業

        欧美性爱欧美
        <p id="l1pda"></p>
        <track id="l1pda"></track>