排除CUBE上的发夹呼叫的单向音频问题

简介

本文档介绍如何解决思科统一边界要素(CUBE)上的发夹呼叫的单向音频问题。

先决条件

要求

Cisco 建议您了解以下主题：

• 会话初始协议 (SIP)
• 如何配置和使用CUBE
• 介质直通和绕流

使用的组件

本文档中的信息基于下列硬件和软件版本：

• 思科统一通信管理器(CUCM)- 11.5.1.10000-5
• CUBE - 15.5(3)S5

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

网络拓扑

问题

发夹呼叫是来自Internet电话服务提供商(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

使用媒体防长号呼叫

注：请在配置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

ITSP中**入站拨号对等体的说**

voice-class stun-usage 1

这可以在用于从ITSP接收呼叫的拨号对等体或用于将呼叫发送到ITSP的拨号对等体或两者上完成。