[cisco-voip] Incoming H323 Calls Fail to Connect

[Go0se]

What do your configs look like on the h323 gateways?

 

-Go0se

 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Keith Allan
Sent: Sunday, May 17, 2009 3:45 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Incoming H323 Calls Fail to Connect
Importance: Low

 

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
<http://www.mailcontroller.altohiway.com/> .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090518/6110393b/attachment.html>