unexpected RTP connection addresses

[neilhunter45355]

I have a situation in which there are two sites running CME - both have 'phones on their 'local' networks (let's say 10.10.1.2 at one site and 10.20.1.2 at the other), and the 'phone network at one site is also visible from the other, so, e.g. I can sit on a test computer at one site and ping the IP address of the other site's phone.  There are multiple routes for traffic between the sites, using different physical interfaces from the routers.  When a call from one site to the other is in progress, 'show voip rtp connections' at a site shows one connection from the IP address of a phone, which I'd expect, but the other RTP conection is between addresses which are specific to one of these physical interfaces (and these are addresses which CME knows nothing about!)  The net effect is that if that particular interface goes down, one side of the call stays connected and the other side doesn't - it goes silent. 

What's going on here?  What I want to happen is that the call survives rerouting - which one side does - and what I'd expect to see is that the RTP conections are between phones, not addresses on physical interfaces.  (I tried 'voice service voip / media flow-around' but that didn't have any effect).

[Scott Leport]

Hi,

It sounds like you need to bind the signalling and media to a specific interface. This issue can occur when there are multiple interfaces on a router.

You can bind globally or on a dial-peer or voice tenant level. Best to bind at the dial-peer level IMO.

So for example if you are expecting the signalling and RTP to arrive on a specific interface (say Gi0/0/0), you can apply them to your dial-peers, e.g.

Site A

dial-peer voice 1001 voip

description ***To Site B***

voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0

Site B

dial-peer voice 1001 voip

description ***To Site A***

voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0

[neilhunter45355]

Thanks for the response.  I probably wasn't clear that this is what I *dont* want but is happening anyway.  I haven't configured any bindings.  If the preferred (lowest-cost) route is unavailable when the call is placed it uses another one (which is correct).  Whichever route gets used, the RTP stream, in one direction at least, seems to be associated with a particular physical interface on the route, not the endpoint, so when the route down that interface is broken the call is not sustained.  In the other direction the RTP traffic takes an alternative route.  Strangely (because both sites have the same CME configuration apart from the obvious differences like dial peers) this only happens in one direction.

[Scott Leport]

Hi Neil,

Based on the links below, the CME is using flow-through and is working as expected when making a call between different sites. Media flow-around would only work in the circumstances described on page 165-166 of the CME admin guide:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/manual/cmeadm.pdf

Also from this link

Flow of an RTP stream:

"For video streams between two local SCCP endpoints, the Real-Time Transport Protocol (RTP) stream is in flow-around mode. For video streams between SCCP and H.323 endpoints or two SCCP endpoints on different Cisco Unified CME routers, the RTP stream is in flow-through mode."

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/admin/configuration/manual/cmeadm/cmevideo.html#reference_52780E205B3C4529B09158D32295F53B

As for the issue itself, it would sound like an IP routing issue when the traffic fails over to the alternate path. Perhaps verifying Firewall rules or ACLs on any upstream devices in between your two sites on the alternate paths.

[neilhunter45355]

Hi Scott.  Thanks for the pointer.  Both phones are SIP, incidentally.  This is a closed system, and nothing en route [on any of the possible routes!] is imposing access control, NAT, or a firewall, so whatever the problem is, it's something under my control, i.e. in the configuration of the routers.  I'm convinced that the routing would all work if the RTP streams were between the terminal nodes, and so I need to persuade the system to use flow-around mode, which it seems it isn't doing at the moment.  All the prerequisites seem to be met - it's a SIP trunk call, IPv4.   Is there a way of examining the status of the call to see whether it's in flow-around or flow-through mode so I can confirm?  (Since only one leg is affected, I'm guessing that only one of the sites is in flow-through).  I'm also going to attempt to find out if one of the phones is somehow using the 'wrong' codec on the call and therefore invoking transcoding - is it possible to find this out by interrogating the router or do I have to look inside the device itself?

[Scott Leport]

Hi Neil,

"show sip calls" will verify both what media mode is being used and the codec negotiated.

"show call active voice" and the media setting value will also show if a call is in flow-through or flow-around mode.

Alternatively a "show call active voice brief" gives you a brief output of the command above and is also a quick way of verifying which codec is in use on the call. 

To find out if it's even attempting flow-around, you may need to issue the "debug ccsip all". I'd issue that debug with care and don't do it in production hours if you have high call volumes between those sites. 

[neilhunter45355]

Helpful - thanks.  It's definitely working in flow-through mode at both sites despite my commands to the contrary.  Everything using the same codec, so not a transcoding issue.  I'm going to set this up on a test rig with all the extraeneous config stripped out so I can post a 'show run'.

[Scott Leport]

Hi Neil,

That's the outcome I was expecting. It would only use flow-around if the two handsets were registered to the same CME, otherwise flow-through is used.

I think what @TONY SMITH has suggested below is the right thing to do here because a loopback interface will always remain up (as long as the router is operational) and won't be affected by any interruption to the physical interfaces.

It means a small design change to your network as you'll need to configure additional IP addressing and include that in routing or possibly take the IP address off one of your physical interfaces and bind it to the loopback with the ip unnumbered command.

[TONY SMITH]

These "unexpected RTP connection addresses", are they physical interfaces on the CME?   I'm having a little difficulty visualising exactly what you mean, but for example if you have two alternate routes, which use different interfaces on the CME, then one option might be to create a Loopback interface on the CME and use that to bind all your media and signalling.  This Loopback address will then be reachable via any available route, independent of the physical path taken.  Remember to include the Loopback address or subnet into your routing.

[neilhunter45355]

Tony, thanks for the response.  The CME here is a 4400 series ISR with multiple WAN interfaces (and some SIP 'phones directly connected to a LANswitch NIM).  The 'unexpected addresses' are the IP addresses of the interfaces at both ends of one the WAN connection.  I'll try out the loopback address idea on a test setup and let you know how I get on.

[neilhunter45355 · Accepted solution]

Yes, that has got it working, thanks.  All I needed to do (in this case) was to "bind media source-add <a loopback address>" - calls now survive interruptions in either path, though with a hiccup until ospf establishes the working route.