[cisco-voip] Incoming H323 Calls Fail to Connect

[Keith Allan]

We have a customer running CUMC V4 with a remote site across a private
leased line.  At the remote site we have IP phones and two H323 voice
gateways. Users at the remote site can make internal local calls and
calls across the WAN. They can make and receive calls through both the
H323 gateways in the remote site.

 

The customer now has a 20Mb Metro-Ethernet MPLS circuit between the two
sites and has re-routed the traffic between the two sites from the
private leased line to the MPLS circuit.

 

Following this change, the users at the remote site can still make
internal local calls and calls across the WAN.  They can make outgoing
calls through either of the two H323 voice gateways at the remote site.

 

The problem is with incoming calls through either of the voice gateways
at the remote site.  When either of the two remote H323 gateways
receives an incoming call, it rings the extension but when the user
takes the phone off-hook, the calling party still hears ringing and the
called party hears nothing. If the called party places the phone back
on-hook, it starts ringing again.  If the calling party continues to
wait, the call goes to voicemail.

 

Debugging the H225/245 on the gateway, we see the H225 signalling
traffic to the CUCM when the call comes in but when the phone is taken
off-hook to answer the call, there is no H225/245 traffic back from the
CUCM to complete the e call.

 

If we re-route traffic back across the leased line, it all works fine.

 

All routing has been thoroughly checked and none of the H323 source bind
addresses have been changed.  Our next step is to take sniffer traces
from each end of the link to analyse the H323.

 

The only time I have seen something similar was when a firewall in the
MPLS cloud decided the H225 traffic was a DOS attack and closed the
session but we are assured there are no firewalls in the network.

 

Has anyone seen anything similar or have any ideas what may be causing
the problem.



This message has been scanned by MailController - www.MailController.altohiway.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090517/d2dba1dc/attachment.html>