Hold causes calls to disconnect

[nick anderson]

Hello,

I have a UCM 6.1 cluster with several h323 gateways. I am having a problem with the Hold/Transfer features on one gateway.  The gateway is a 2851 running 12.4(24)T with one NI2 PRI.  The gateway and phones are on the same local VLAN, and the CM server is across a router on a different network.

Station-Station calls work fine.  When a call is placed on hold, the MOH is delivered and the call can be retreived.

Calls coming in through the gateway are able to complete.  Unity is able to deliver prompts and record.  However, placing the call on hold causes it to be immediately dropped.  A Q931 debug on the gateway reports a "Temporary Failure", but otherwise I get no errors reported.

I'll be glad to post any other traces that would help...I was not sure what router debugs would be helpful, or which log files would be most relevant.

Any direction at all would be great.

[Aaron Harrison]

Odd. During those 4 seconds before the fail, do you hear audio?

It might be worth us tidying things up a bit to see if it makes it happier... apply this:

voice class codec 1

codec preference 1 g729abr8

codec preference 2 g729ar8

codec preference 3 g711alaw

codec preference 4 g711ulaw

!

!

!

voice class h323 1

h225 timeout tcp establish 3

First one allows it to select a codec from the list, effectively CCM will then decide what is used.

Second class basically is unrelated to this problem, but if your primary CCM goes offline you can get long timeouts before the call is routed to the next CCM.

Next, set your DP 100 to be the incoming VoIP peer (so you aren't matching the default dial-peer), and disable voice activity detection (not used with CCM) and set the above classes on it:

Dial-peer voice 100

Incoming called-number .

No vad

Voice class codec 1

Voice class h323 1

Apply the last three commands (no vad and the classes) to your other VoIP dial peers.

And try again...

Regards

Aaron

[nick anderson]

I am hearing audio now for the 4 seconds before the call drops. We were talking before about it having trouble setting up the h.245, and that gave me a thought... 4 seconds is default OLC timeout for h245 (Open Logical Channel).  If I increase the OLC timeout to 30 seconds, I hear 30 seconds of music before the call drops.

I made the Dial-Peer changes you listed, but they had no effect on the issue.

Message was edited by: nick anderson

[Aaron Harrison]

Hmmm... the plot thickens... set that timer to 24 hours, and yer done

It's 'Open Logical Channel', according to google... so I guess it must be expecting to open a two way channel, and when it doesn't happen it assumes an error and fails?

Do you mcast or ucast your MoH?

If mcast you should have 'ccm-manager music-on-hold' configured.. maybe configure that anyways (getting desperate here)...

What version is your IOS?

Aaron

[nick anderson]

MOH is all ucast. The exact IOS version is: "(C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)"

Looking at a packet capture and filtering on h245:

For the original call I see:

...

GW -> CM OpenLogicalChannel (G711u)

CM -> GW OpenLogicalChannel (G711u)

GW -> CM OpenLogicalChannelAck

CM -> GW  OpenLogicalChannelAck

...

For the Hold operation I see:

...

GW -> CM OpenLogicalChannel (G729)

CM -> GW  OpenLogicalChannel (G729)

GW -> CM OpenLogicalChannelAck

GW -> CM CloseLogicalChannel

end

Should the gateway be trying to open a media stream?  (Basically, is the OLC the issue or is an Ack getting lost...)  If the gateway is expecting that Ack to come back from CM, then it makes sense that it would drop the connection after the OLC timeout. I dont have access to trace a working gateway...

[Aaron Harrison]

Hmm... good question.

GW sends an ACK to CCM, as it has opened a channel (to receive the MoH)

GW then closes it (presumably after your OLC timeout though there are no times in your post).

CM won't ACK the request to open a channel, as at that point the conversation is one-way (i.e. from MoH server to GW, and MoH server isn't interested in listing)

Can you post up the capture? I have a gateway here I can set to 323...

[nick anderson]

Time probably would have been good info to include... hehe

Capture is attached:

[Aaron Harrison]

I see what you mean - CCM doesn't return the ACK... in my capture it returns an ACK with empty IPs etc.

What ver of CCM are you running?

[nick anderson]

Version 6.1.3.2000-1

[Aaron Harrison]

Have you got detailed debugging on and H225/H245 checked on the CallManager?

Might be worth pulling the logs, try to see why CCM doesn't send the ACK.

Aaron

[nick anderson]

I'm embarrased to admit, but I'm not really sure how to check the debug level, or which logs to pull.

Sent from Nick Anderson's Blackberry.

[Aaron Harrison]

Hi

No problem.

Log into CCMAdmin.

Go to the navigation drop down on the top right, select CCM Serviceability then hit go

Go to trace settings in one of the menus.

Select a server, then the CM Services, then CallManager service.

Check the boxes for H245/h225 and set the level to 'detailed'.

To retrieve the logs, download RTMT from the Applications/plugins page on ccmadmin. Run that, login as ccmadministrator (or whatever your ccmadmin user is), and go to trace/log central, the 'Collect Files', and follow your nose from there.

At this point I suspect one of two things:

1) CCM is trying to set up a transcoder or something, and is not responding with an ACK because it's doing something

2) You are hitting a bug..

I would suggest temporarily putting the gateway into a DP/region that allows G711 to rule out option 1). If you get the same problem/packet cap info (i.e. no ACK to the GW's OLC) then you might want to raise a TAC case.

Aaron

[nick anderson]

Wow... That is a difficult log to read.  What I do see though, is that every OLC and OLCack message appears with its pair...Call Manager seems to be sending the message. After the length of the 245 OLC timer, I can see the following message:

04/01/2010 13:43:38.869 CCM|TranslateAndTransport(32291)::wait_SdlCloseInd - ERROR: H245 signaling connection aborted!!!|<:HQCCMCLUSTER><:10.192.36.11><:2><:10.26.16.2><:><:ERROR><:0001>

I'll have to look at some other network logs and see why the packet is not reaching the Gateway.

[Aaron Harrison]

Hi

Do the timestamps add up when you compare with the client? i.e. is there an ACK, but lots later?

You can do a capture on the CCM at the same time:

Utils network capture count 1000000 size all file h245

Then allow it to capture the traffic and CTRL+C out, followed by collecting the packet cap file via 'collect files' in RTMT... do a gateway-side capture at the same time, and compare the two.

What seems really unlikely is that the ACKs only are lost, consistently... you know?

Aaron

[Aaron Harrison]

OK - I'll show you mine if you show me yours :-)

Attached is a cap from my lab.

Hosts are:

192.168.0.10 -GW

192.168.0.201 -IP Phone

192.168.0.71 - CUCM (7.0)

Sequence is :

Call inbound from GW, phone offhook in packet 27

Phone hits hold in packet 80

Phone unholds in packet 541

Phone hangs up in packet 687

All goes well...

[Cesar Ortega]

Hello everybody,

I had exactly the same issue this week. Solution was activate MTP on Gateway configuration section in the Call Manager (Devices > Gateway > "Check" Media Termination Point)

After I do "Save" and "Apply Config" and done!

Please also pay attention to this document during troubleshooting: http://www.cisco.com/warp/public/788/AVVID/ios-moh-resource.pdf

Regards,

Alejandro