CUCM 8.6.2.21900-5 and H323 Gateway Issues

[Ayodeji Okanlawon]

Guys,

I recently added a new h323 gateway to uor cluster and I observed some very weird issues. During call setup, CUCM never sent any h245 negotiation. All I see is h225 call setup and call progress report, I do not see any h245 TCS, OLC, Master slave determination and as such call fails. I know there is a bug  CSCtq96181 with cucm 8.6 but this is related to unable to add or edit h323 gateway.

Is this another bug

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson       

[Chris Deren]

Are you using fast start by any chance? Can you post your H323 GW configuration screen shot?

Chris

[Ayodeji Okanlawon]

Chris,

No I dont have fast start enabled. Attached is the screen shot. Its just the standard config.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Suresh Subramanian]

Hello,

We are also facing the same issue with CUCM 8.6.2.20000-2. No TCS, MSD and OLC messages.

For the failed call, we see the below error message in the SDI trace.

19:59:49.734 |TranslateAndTransport(181)::waitForSdlRsp_TcpAwaitRespTimer - ERROR: Fail to setup H245 signaling connection!!!|2,100,28,181.1^*^*

And in SDL trace, you can see the same error too.

000237685 |2012/11/21 19:59:49.734 |100 |AppError |||TranslateAndTransport(2,100,21,181)|||H245Log: Process=TranslateAndTransport LogicalChannelNumber=1011 -- TCP ERROR: TcpAwaitRespTimer times out, or received SdlCloseInd from H245Handler, Perform cleanup of H245 Session.

any idea?

Thanks

SS

[Harmit Singh]

Hi Suresh,

Did you try disabling "Wait for Far End H.245 Terminal Capability Set" on the H323 gateway config page, save, apply and reset? Let me know if that helps.

Regards,

Harmit.

[Suresh Subramanian]

yes, tried it with no luck.

[Harmit Singh]

Suresh,

What I can tell you is that the H245 process on the UCM has lost the TCP connectivity with the gateway. Is there a firewall between the two? Are there other H323 gateways talking to the same UCM node that are working fine? How about trying to change the Device Pool on the H323 gateway config page such that the TCP connection is attempted with another node? Did you possibly try that? If that works, I would then restart the CCM service on the problematic node and change the Device Pool config back to the original and test again.

Regards,

Harmit.

[Suresh Subramanian]

Thanks for your response Harmit. From the ccm traces for the failed calls, one thing we noticed was that the H.245 port range was not in the Ephemeral port range (32768 – 61000).

The calls were failing when the H245 port was below TCP 32768.For the working calls, the H245 port was in between

32768 – 61000.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/8_6_1/portlist861.html

”The Ephemeral port range for the system is 32768 – 61000”

Gateway	Unified   CM	1720   / TCP	H.225   signaling services for H.323 gateways and Intercluster Trunk (ICT)
Unified   CM	Gateway

Gateway	Unified   CM	Ephemeral   / TCP	H.225   signaling services on gatekeeper-controlled trunk
Unified   CM	Gateway

Gateway	Unified   CM	Ephemeral   / TCP	H.245   signaling services for establishing voice, video, and data
Unified   CM	Gateway

any idea why it is negotiating out of range?

[Harmit Singh]

Hi Suresh,

Good observation. Could you send me the following:

++     detailed UCM SDI/SDL traces from all nodes in the cluster.

++     Calling party, called party number, timestamp of the call, IP Address and MAC address of IP Phone, IP Address of Gateway, "show network cluster" from Pub CLI, H323 gateway config page screenshot.

From your last note, you mentioned that there are successful calls as well, is that correct? Is the issue intermittent? Is this a new setup or was it working fine before? If it was working fine, what changed? Are there other H323 gateways which are working fine pointing to this UCM cluster? Are both inbound and outbound calls failing? What is the call flow for the good and bad calls? Can you also provide the same outputs requested above for a good call as well?

Any other details regarding the issue would be helpful.

Regards,

Harmit.

[Suresh Subramanian]

Harmit,  The failure rate for the external outbound calls is 1 off 6

Yes,it is new cucm cluster  version 8.6.2.20000-2 and it is behind firewalls.we integrate the existing H.323 GW to it.

Call Flow: IP phone----CUCM----(firewall)-------H.323 gateway-----E1-PRI-----PSTN.

In the firewall we have opened TCP/UDP 32768-65535. for the working calls, the H245 port is within the range (32768-65535).

The issur was observed when the incoming 'Call Proceeding' message from h.323 gateway negotiated the h245 info as below.

        h245Address ipAddress :

          {

            ip '0AEA1D34'H,

            port 30023

          },

>> we saw the same h245 info in Call Alerting message too

>> for all the working calls, the h245 port was with the ephemeral range.

>> however when the calls were initiated from our existing CUCM 6.1.5, the calls were successfull through the same h.323 gateway as there is no firewall in between cucm and gw.

>> I suspect the firewall as the cause of this issue. I'm sure the calls will work if we open the port below the Ephemeral range.

>> My question is why the h.323 gw negotiates the h245 info with out of range ports?

>> is there a way to to instruct the h323 gw to negotiate the h245 info with particular port range?

>> for ease of troubleshooting i registered the phone and gw in the same ccm grp. Attached are the SDI and SDL traces from the primary node of that ccm grp.

>> at the time:19:59:49.734, you can see the error messages in both SDI and SDL traces.

Thanks

Suresh

[Ayodeji Okanlawon]

I have seen another cisco documentation that says the TCP port used by h323 h245 is 11000 - 65535. So on your firewall I will just open this port range..

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Suresh Subramanian]

We are using slow start.is it possible to enable H245 tunneling with slow start?

it is 3845 gateway with IOS: 15.1.4M5.

I dont find the way to enable the tunneling in voice service voip and voice class h323.

is there any hidden and supported command to enable tunneling for slow start?

[Harmit Singh]

Hi Suresh,

Thank you for the details. In order to enable / disable H245 tunneling on the gateway, you need to do the following:

voice service voip

h323

h245 tunnel disable

Tunneling should be enabled by default. If you wish to enable it, the command is "no h245 tunnel disable". These are hidden commands. I reviewed the traces and yes, it appears the far end (H323 gateway) is sending:

h245Address ipAddress :

          {

            ip '0AEA1D34'H,

            port 18058

          },

This does not look correct to me either. It would be a good idea to capture the following debugs from the gateway:

debug h225 asn1

debug h245 asn1

debug h245 events

debug cch323 h245

debug isdn q931

Please capture 2 seperate debugs, one with a good call and the other with a bad call. I'm also suspecting the firewalls at this time.

Regards,

Harmit.

[Ayodeji Okanlawon]

Harmit,

That port is normal for h323 h245 signalling...The port range used by h323 h245 signalling is this 11000 - 65535.

For my case, CUCM does not even send any h245 signalling. Its not a question of it been dropped by the firewall. I dont even see it originating from the CUCM. I disabled wait for far end TCS and reset the gateway, yet the result was the same. I switched to sip instead because I was getting no where witht he h323...

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Harmit Singh]

I agree with you on that. However, that should only apply to IOS i.e. IOS ideally does not have a limitation on the port range for H.245 like UCM does, as long as the port GW is opening doesnt fall in the registered port ranges.

Whereas, UCM 8.6 has an ephemeral TCP range from 32768 - 61000 in align with linux operating system range:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/8_6_1/portlist861.html

For your issue, sounds like a TCP issue again where you dont see any H245 signaling. The H245 signaling will not begin unless a TCP connection is established. Did you check to make sure that happened for the H245 signaling to commence? Packet captures from both ends would help to quite an extent in figuring this out. Also, you could always try pointing the H323 gateway to another UCM node to see if it's a node specific TCP issue.

HTH.

Regards,

Harmit.