簡介
本檔案介紹如何對思科整合邊界元件(CUBE)上的髮夾呼叫進行單向音訊問題疑難排解。
必要條件
需求
思科建議您瞭解以下主題:
- 作業階段啟始通訊協定(SIP)
- 如何配置和使用CUBE
- 介質流經和繞流
採用元件
本檔案中的資訊是根據以下硬體和軟體版本:
- 思科整合通訊管理員(CUCM)- 11.5.1.10000-5
- CUBE - 15.5(3)S5
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
網路拓撲
問題
髮夾式呼叫是來自網際網路電話服務提供商(ITSP)的傳入呼叫,已轉發或轉接回ITSP,這會導致無聲音訊,從IP電話到ITSP的常規呼叫工作正常。
根據SIP RFC 3264,SIP使用者代理客戶端(UAC)和SIP使用者代理伺服器(UAS)之間的媒體套接字協商通過提供/應答模型中的會話描述協定(SDP)進行,然後是每個語音IP(VoIP)產品製造商。
有些ITSP由於實施了防火牆,所以不考慮SDP中的IP地址和埠資訊,因此,套接字必須在遠端啟動(在本例中為CUBE)。ITSP要求遠端向其傳送一些即時傳輸通訊協定(RTP)封包,一旦ITSP收到RTP封包,它就會將封包傳送到所接收封包的來源IP。
在IP電話與ITSP之間的呼叫中(該呼叫不帶有髮夾功能),不會出現此問題,這是因為IP電話在開啟所需埠後傳送虛假RTP資料包。
當呼叫來自ITSP並傳送回它們時,呼叫發起方和呼叫接收方不傳送任何流,除非它們從呼叫路徑中的某個人接收流,否則出現死鎖情況。
驗證
若要驗證連線是否成功建立,請運行以下命令:show voip rtp connections。
Max Ports Available: 19999, Ports Reserved: 101, Ports in Use: 4
Port range not configured, Min: 8000, Max: 48199
Ports Ports Ports
Media-Address Range Available Reserved In-use
Default Address-Range 19999 101 4
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 21 22 16424 16568 10.106.36.169 10.106.108.72
2 22 21 16426 24602 10.106.36.169 10.106.123.29
3 23 24 16428 24600 10.106.36.169 10.106.123.29
4 24 23 16430 16570 10.106.36.169 10.106.108.72
Found 4 active RTP connections
運行命令show call active voice brief,以便從CUBE的角度,將所有4個呼叫段的Rx/Tx計數器顯示為0/0。
Total call-legs: 4
35E9 : 21 7441740ms.1 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Answer 5655 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.108.72:16568 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
35E9 : 22 7441740ms.2 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Originate 7961 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.123.29:24602 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
0 : 23 7441780ms.1 (*13:00:22.897 UTC Sat May 20 2017) +4020 pid:124 Answer 5655 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.123.29:24600 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
0 : 24 7441780ms.2 (*13:00:22.897 UTC Sat May 20 2017) +4010 pid:124 Originate 7961 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.108.72:16570 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
註:如果路由器使用IOS-XE,請運行以下命令以驗證Rx/Tx計數器:
voice service voip
media bulk-stats
建議不要在呼叫卷高時運行此命令,請確保在CPU小於30%時運行此命令。
解決方案
軟體媒體終端點(MTP)
這是克服此問題的首選方法。CUCM軟體MTP能夠傳送虛擬RTP資料包。在髮夾式呼叫中,軟體MTP向呼叫發起方和呼叫接收方兩者提供虛構RTP分組,因此,ITSP接收這些分組並用RTP回覆軟體MTP。
確保在Trunk Configuration頁面上選中Media Termination Point Required覈取方塊。導覽至Device > SIP trunk,然後選擇該中繼的Media Resource Group List(MRGL),驗證它是否至少包含一個軟體MTP。
- 注意:硬體MTP無法傳送虛擬RTP流。 確保與中繼關聯的MRGL僅呼叫軟體MTP。軟體MTP只能橋接G711呼叫,確保端到端呼叫流程必須使用G711才能使此解決方法正常工作。
下一張圖顯示虛擬RTP負載在Wireshark中的顯示方式:
媒體週轉
藉助媒體繞流,信令資料包在CUBE上終止和發起,但媒體資料包繞過CUBE,並在終端之間直接流動。
voice service voip
media flow-around
使用媒體繞流進行呼叫
注意:這可能會影響CUBE功能,因為它無法終止任何呼叫的媒體。RTP會繞過CUBE並在端點之間直接流動。在這種情況下,它直接在ITSP之間流動。
如果在全域性配置下配置了介質繞流,則介質繞流的撥號對等配置模式不會生效。
組態
- 在全域性配置下配置介質繞流。
- 建立具有媒體直通功能的語音級媒體。
- 將語音級介質應用到所有預期使用介質流經的撥號對等體上。
- 沒有此配置的撥號對等體將歸入介質繞流,因為它是全域性配置的。
Voice service voip
media flow-around
voice-class media 10
media flow-through
dial-peer voice 1 voip
Description ** Inbound dial-peer **
voice class media 10
dial-peer voice 2 voip
Description ** Outbound dial-peer **
voice class media 10
媒體防長號
此功能的工作方式與介質繞流類似,但影響較小。首先,它會查詢環回或髮夾呼叫,如果找到髮夾呼叫,則此功能會觸發已識別呼叫的另一輪媒體協商。在此協商結束時,CUBE不再是媒體路徑的一部分。
雙方(CUBE和ITSP)都需要支援防長號功能,以便其正常工作。
voice service voip
media anti-trombone
使用媒體防長號呼叫
注意:在http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/media-path.html上配置媒體防長號之前,先驗證限制
啟用CUBE以在協商的媒體IP/埠中傳送STUN資料包
啟用CUBE以通過協商的媒體路徑傳送本地生成的STUN請求/資料包(這些stun資料包為具有相同媒體IP/埠號的UDP資料包),如果這些裝置沒有驗證實際應用程式資料,則媒體路徑中的裝置可以在驗證IP/埠/傳輸協定之後獲得這些stun資料包之後清除路徑:
語音服務voip
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
voice class stun-usage 1
stun usage firewall-traversal flow data
dial-peer voice 2000 voip
來自**的入站撥號對等體的說**
voice-class stun-usage 1
這可以在用於從ITSP接收呼叫的撥號對等體或用於將呼叫傳送到ITSP或兩者的撥號對等體上完成。