[cisco-voip] Incoming H323 Calls Fail to Connect

[Ryan Ratliff]

I think you are right on with packet captures.  Are you seeing any  
H225 traffic from CUCM to the gateway at all?  Typically in order for  
the caller to even hear ringback you need to get a Call Proceeding  
and Alerting message from CUCM to the gateway.  If you are seeing  
those but no Connect then that's very odd and you may need to look at  
CCM traces as well as the packet capture.

-Ryan

On May 17, 2009, at 4:45 AM, Keith Allan wrote:

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.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip