I have a VoIP gateway (AS5300) which is connected to my CM via VLAN 98. Both the VoIP gateway and the CM is in VLAN 98. Currently, I have a gateway entry in CM for routing all the VoIP to PSTN. Right now, the gateway IP address is pointing to the FE port of the AS 5300 which is in the same VLAN 98 as CM. However, when I changed the gateway IP address pointing to the loopback interface of AS 5300 (different from VLAN 98), when I use a public phone to call an IP phone, I only hear ringing but the IP phone actually does not ring. Also, when I ring to any other remote VoIP site, the same symptom happens. When I change back to the original setting, everything is fine. Any idea ?
Check your codecs. The result you describe sounds a lot like a codec missmatch. The codec is specified in the dial-peer and is G.729a by default. Your region in CM might be running G.711 to the gateway and the gateway trying to run G.729a back.
Hmmm....if you say that this is codec mismatch issue, then how come, when I just point back to the old gateway Ip address which is in the same VLAN subnet as CM, I didn't change any codec configuration and things just started to work. I feel like like this is a call routing issue. But don't know how to trouble-shoot. By the way, thanks for your great reply. Any more idea ?
try under loopback interface command prompt the command "h323-gateway voip bind srcaddr a.b.c.d" where a.b.c.d is the Loopback_IP_address.
Also try resseting the gateway at CM after you make changes. And when you make a call, with "deb ccapi inout" see if the call matches the outgoing voip dial peer to the CM.
Thank you very much ! I don't think I have the luxury to verify the command to see if that will solve my problem as it is just not available on my router's IOS.
By the way, I have another problem here. I think they should be related. I have 8 sites (VoIP) sites connected via a WAN to my CCM. As you know that on CCM, you need to configure route pattern and gateway (I am using H323). Initially, all the H323 gateway IP address on CCM are pointing to the remote end site router serial interface (primary link). However, if the primary link is down, even when the ISDN back-up is kicked up, the H323 gateway is down as the primary serial interface is still down. Hence, ideally, I should have all the H323 gateway IP address on CCM to be pointing to the remote end site loopback interface. So, I did this. Then, when come to specifying the route pattern, I use the loopback0 interface IP address as the new H323 gateway IP address (as configured on CCM).
The problem after doing the above configuration change, I found that all the remote end site cannot make outgoing call but can receive incoming call for both type of on-net and off-net VoIP calls. In addition to that, the remote end user can also make VoIP calls to phones connected to the FXS POTs on the same router.
Then, I found the work-around. When I created an extra (dummy) H323 gateway entry that points to the old serial interface, but the route pattern's H323 gateway is still pointing to the remote end router's looopback0, this problem is gone. All the VoIP can make outgoing and incoming calls for both type of on-net and off-net calls.
Why is this happening ? Is it because the H323 gateway IP address used by the remote end router is different from the one used by CCM. Please help ?
Are you using the following command:
h323-gateway voip bind srcaddr x.x.x.x
This command will sets the source IP address to be used for this gateway. The ip-address argument specifies the IP address to be used for outgoing H.323 traffic, which includes H.225, H.245, and RAS messages. Typically, this is the IP address assigned to the Ethernet interface. In your case use that command under the loopback interface.
All my remote VoIP router is running IOS version : c2600-is-mz.121-8.bin. Hence, I could not use that command h323-gateway voip bind srcaddr x.x.x.x. I had talked to my local vendor, this problem should not happen. A bug is suspected. Currently, my Call Manager is running the version of 3.1(1). So, what I have done is that is to get a TAC case opened to see if there is a way to resolve the bug. If not, may need to upgrade the IOS...What do you think ?
You can use that command under a main interface and it is not available under a sub interface (ie: vlan interface). I would like to know why? Which i do not know the answer. This command should be present in the ios you are using. You can also use that command on a loopback interface.
Thanks ! Pal ! For all these exciting exchange. Hey ! If you were interested, why don't you write an email to me via firstname.lastname@example.org. I am from Malaysia...Where are you from ?