Recently, I was troubleshooting a very interesting problem that involved a Cisco Call Manager, VG200 gateway with FXS ports and running MGCP, and several 7960 IP phones. The problem was that I could easily establish calls from my analog phones on my gateway to my IP phones and vice versa, but my audio was only one-way. I could speak into the analog phone and hear myself on my IP phone, but not the other way around. Curiously, DTMF signaling was working, because when I pressed buttons on my IP phone, it beeped in my ear on the analog phone.
During the course of troubleshooting, I realized early on that I was sending RTP traffic from the gateway (obviously) but not receiving any from the phone. And clearly, MGCP was working fine with the Call Manager and I could ping everything on the network.
If you've had much real-world experience with routing and switching, you probably learned long ago to use loopback addresses on your routers for such things as your OSPF and BGP router-id and for tunnel endpoints, etc. This is a "best-practice" habit that will save you a lot of grief because lots of IOS software processes need an IP address to source their traffic from, and usually choose the highest address, unless there is a loopback, in which case, they choose the highest loopback address.
Anyways, to make a long story short, I issued the poorly documented "show rtpspi call" command on my voice gateway:
r7vg200#show rtpspi call
RTP Service Provider info:
No. CallId dstCallId Mode LocalRTP RmtRTP LocalIP RemoteIP
1 14 13 Snd-Rcv 16384 27376 0x7070707 0xC0A801DC
and was quite surprised to see my RTP traffic coming from my loopback address, instead of the FastEthernet interface address. Shortly afterwards, I remembered that my loopback, in this case 7.7.7.7, was just a dummy address I had configured but because VG200s aren't routers, and can't run real routing protocols, the loopback address was not globally reachable in my network. Thus, my IP phones had no route to send their RTP traffic to!
To verify this was actually the problem, I deleted the loopback interface and ran the command again. Sure enough, this time, it showed the FastEthernet interface address of 192.168.2.7.
r7vg200#show rtpspi call
RTP Service Provider info:
No. CallId dstCallId Mode LocalRTP RmtRTP LocalIP RemoteIP
1 16 15 Snd-Rcv 16384 31248 0xC0A80207 0xC0A801DC
I tried a call and magically, had two-way audio. I then re-added the loopback and fixed my routing and tried another call successfully.
The moral of this story is: watch out for loopbacks on voice gateways. If you use them, make sure any VOIP endpoints in your network have a route to the loopback address, not just the physical interfaces of the gateway.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
