目錄

簡介

必要條件

需求

採用元件

網路拓撲

問題

驗證

解決方案

軟體媒體終端點(MTP)

媒體週轉

媒體防長號

啟用CUBE以在協商的媒體IP/埠中傳送STUN資料包

簡介

本檔案介紹如何對思科整合邊界元件(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。

1. 注意：硬體MTP無法傳送虛擬RTP流。 確保與中繼關聯的MRGL僅呼叫軟體MTP。軟體MTP只能橋接G711呼叫，確保端到端呼叫流程必須使用G711才能使此解決方法正常工作。

下一張圖顯示虛擬RTP負載在Wireshark中的顯示方式：

媒體週轉

藉助媒體繞流，信令資料包在CUBE上終止和發起，但媒體資料包繞過CUBE，並在終端之間直接流動。

voice service voip

media flow-around

使用媒體繞流進行呼叫

注意：這可能會影響CUBE功能，因為它無法終止任何呼叫的媒體。RTP會繞過CUBE並在端點之間直接流動。在這種情況下，它直接在ITSP之間流動。

如果在全域性配置下配置了介質繞流，則介質繞流的撥號對等配置模式不會生效。

組態

1. 在全域性配置下配置介質繞流。

2. 建立具有媒體直通功能的語音級媒體。

3. 將語音級介質應用到所有預期使用介質流經的撥號對等體上。

4. 沒有此配置的撥號對等體將歸入介質繞流，因為它是全域性配置的。

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或兩者的撥號對等體上完成。