Which IP is me?
A couple of days ago, I received one of the strange calls you just get after instructing for a while. A Marine who I had taught a CallManager Express (CME) course to was having a peculiar problem. He called and asked if I minded helping him out. A simplified version of his topology looks like this:
The phone on the left is registered to the CME router, and the phone on the right is registered to the CallManager on the right. The problem was that the phone on the right could call the phone on the left (including 2 way audio), but when the phone on the left tried to call the phone on the right, it would get a fast busy.
I’ve seen this problem a thousand times and was fully ready to have this solved in 2 minutes over the phone. After having the Marine go into the InterCluster Trunk (ICT), I had him check the Calling Search Space (CSS) and it was blank. He told me they had not implemented any partitions or CSS, but of course we verified to be sure and just as the Marine reported there were none implemented. This just started to get interesting. I had him hop onto the command line to verify his dial-peers. You can easily get there with “show run | include dial-peer”. The Marine had the cutsheet that was handed out at the CME class and had the dial-peers configured perfectly.
Next, I had him hop on the CallManager and pull up the Route Plan Report. Every once in a while I will see some just crazy stuff here. **side note** If you could like to completely FUBAR a CallManager, create an ICT for yourself and use a Route Pattern for your phones (this is something I always check for on a newly configured CallManager). After ensuring the ICT was tied to the correct Route Group, List and Pattern I was confident the dial-plan was good.
I told the Marine I had one more idea and if this didn’t work, I would come down. I had the Marine check the regions and locations to see if there was something strange in there. Turned out the CallManager was set to use G.729 (which matches the CME default) and the location bandwidth was sufficient for the number of calls they were expecting. True to my word, I told the Marine I would head down to where he was at when I finished a couple of things at the shop.
When I arrived at their site I was able to get the full equipment string and started by checking the standard IP trouble-shooting steps ensuring everything was routing properly, there weren’t any strange ACLs, etc. After being satisfied the IP side of things were good, it was time to ensure the dial-plan was working the way I expected. I hopped on the router and started a “debug voice dialpeer”. The intent behind this was to ensure the digits dialed on the phone were matching the dial-peer that I was expecting. Sure enough after running the debug, the dial-peers were now verified correct.
At this point, it was time to go back to the very basics. I double-checked the IP address from the dial-peer was the IP address of the CallManager, and made sure the IP address for the ICT was the IP address of the CME router. The only notable item was the Marine (as I suggested in the class) was using a loopback interface for his CME service (and consequently at the target of his ICT). I’ve had a problem with loopbacks before when configuring SIP trunks. I was down to my last couple of ideas on how to fix this, so I figured this was the time for a long shot. I had the Marine change the target IP address of his ICT on the CallManager from the loopback of the CME router to the tunnel interface on the CME router (depicted as 192.168.1.1 on the diagram above). Sure enough, phones started ringing both ways. The Marine was excited it was finally working, but I was still uncomfortable. The reason you use loopbacks is so that in the event an interface goes down the IP telephony will continue to work. Even though the tunnel is a logical interface, the actual topology was a lot more complicated and they needed to be able to use the loopback.
About 5 minutes worth of google engineering on my cell phone with 1 bar I was able to find a command that seemed to fit the bill. I hopped on the router and made my way to the loopback interface and added the following commands: “h323-gateway voip interface” and “h323-gateway voip bind srcaddr <loopback IP address>”. After adding those commands, I had the Marine change the ICT back to the CME router’s loopback IP and the phones were still working. Success!
The reason the calls from the CME router’s phones were failing were because the router was encapsulating the signaling packets with a source address of the interface closest to the CallManager (the tunnel interface). When those packets arrived at the CallManager, it did not have an ICT that matched that source address, so it blocked the calls thinking they were unauthorized. By forcing the router to encapsulate the packets using its loopback IP, the calls then matched the configured ICT on the CallManager and phones started ringing (both ways).