Introduction
The document explains a common scenario when the call coming from an Internet Telephony Service Provider (ITSP) is forwarded or transferred back to the ITSP resulting in no way audio. Regular calls to PSTN from IP phones work fine.
Prerequisites
Cisco recommends that you have knowledge of these topics:
- Session Initiation Protocol (SIP)
- How to configure and use Cisco Unified Border Element (CUBE)
- Media flow-through and flow-around
Components Used
The information in this document is based on these hardware and software versions
- Cisco Unified Communications Manager (CUCM) - 11.5.1.10000-5
- CUBE- 15.5(3)S5
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Network Topology
Problem
As per SIP RFC 3264, the media socket negotiations between the SIP User Agent Client (UAC) and SIP User Agent Server (UAS) happen through Session Description Protocol (SDP) in Offer/Answer model. This is followed by every VoIP product manufacturer.
Few ITSPs do not consider the IP Address and port information in the SDP because of their firewall implementation. Therefore, the socket has to be initiated by the far end (in our case, CUBE). This ITSP requires the far end to send some Real-Time Transport Protocol (RTP) packets towards it. Once these packets are received, the ITSP will start transmitting packets to the source IP of the packets it receives.
In a call between an IP phone and the ITSP, which does not feature the hair-pin, this problem does not occur. This is because the IP phone sends dummy RTP packets after opening the required ports, therefore avoiding the problem altogether.
Since the call is coming from Provider and sent back to Provider , So both the call initiator and the call receiver won’t send any streams unless it receives a stream from someone in the path of the call. This is where we get stuck in a deadlock situation.
Verify
The “sh voip rtp connections” output will show the RTP connection getting established successfully
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
The “sh call active voice brief” output will show the Rx/Tx counters of all the 4 call legs from the perspective of CUBE as 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
Note: In case of Routers Running IOS-XE , make sure that you enable the following to check the Rx/Tx counters.
voice service voip media bulk-stats
This is not recommended to enable in a high call volume . Enable it when the CPU percentage is less than 30 %.
Solution
There are multiple solutions to the above problem.
Software Media Termination Point (MTP)
This is the preferred method to overcome the problem. CUCM software MTPs are capable of sending dummy RTP packets. In a hairpinned call, the software MTP will supply dummy RTP packets to the both the call initiator and the call receiver. Therefore, the ITSP will receive these packets and reply with RTP to the software MTP.
Make sure that 'MTP Required' checkbox is checked on the Device > SIP trunk page and the Media Resource Group List (MRGL) of that trunk contains atleast one software MTP.
Note:
1.Hardware MTPs cannot send dummy RTP streams. Make sure that the MRGL associated with the trunk can invoke software MTPs only.
2.Software MTP can only bridge G711 calls, so the end to end call flow must be G711 for this workaround to work
This is how Dummy RTP payload will look in wireshark:
Media Flow Around
With media flow around, The CUBE will not terminate the media . The media will be terminated end to end (the Provider will bridge the media internally)
voice service voip media flow-around
Call with Media flow-around
Note:
This can be impacting as CUBE won’t terminate media for any calls. RTP bypasses the CUBE and flows directly between the endpoints. In this case, it will flow directly between the provider.
Dial-peer configuration mode of media flow-through doesn’t take effect if you have media flow-around configured under global configuration (CSCsl67833 )
Steps to configure:
1.Configure media flow-around under global configuration
2. Create a voice class media with media flow-through in it.
3. Apply these Voice-class media on all the dial-peers in which Media flow through is expected to be used.
4. The dial-peers which don't have this configuration will fall to media flow-around automatically as it is configured globally.
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
Media Anti-Trombone
This feature functions in a similar manner as Media Flow Around, however, is less impacting. First, it looks for looped or hairpinned calls. If a hairpinned call is found, this feature triggers another round of media negotiation for the identified call. At the end of this negotiation, the CUBE will no longer be part of the media path.
Both parties (CUBE and ITSP) need to support the anti-tromboning feature in order for this to work.
voice service voip media anti-trombone
Call with Media anti-trombone
Note:- Check the restrictions before configuring Media anti-trombone
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/media-path.html