Hold causes calls to disconnect

Unanswered Question
Mar 25th, 2010

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Aaron Harrison Fri, 03/26/2010 - 02:14

Hi

Try:

Debug cch323

A quick stab in the dark would suggest it might be a problem with MoH being played to the GW.

Regards

Aaron

nick anderson Fri, 03/26/2010 - 12:09

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

I have attached a debug for 1 test call. I included the q931 and cch323 all.  I see the following message near the disconnect: "Timer [CCH323_H245_UCHAN_TIMER] expired".

Attachment: 
Jaime Valencia Fri, 03/26/2010 - 06:45

Look in the app log for any MTP errors.

The usual cause for this is that the H323 lacks the MTP required, or if configured it cannot allocate the MTP

There was some documentation that explained this but i cannot find it right now.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

nick anderson Fri, 03/26/2010 - 13:45

Is 'Application  Logs -> CiscoSysLog' the log file you meant?  If so, there are no MTP  messages in the log on either the Publisher or Subscriber.

I have tried using an MTP on the Gateway and on Call Manager in the Media Resource Group.  It did not affect the issue.

j.sillers Fri, 03/26/2010 - 22:25

Can you post the router config?  Also, do you hear Hold music if the Vmail AA puts you on hold for a transfer?  That would come from the media defined for the VoiceMail ports but still back to the GW.  This would eliminate the GWs ability to pass on G711 hold music.  Also, can you set up a phone to not play the music?  If so, does the call still drop?

allan.thomas Sat, 03/27/2010 - 03:57

Hi Nick,

Firstly I would verify whether placing a call on hold which excludes any MoH resource exhibits the same symptoms as Aaron had mentioned.  In this scenario I would expect Tone-On-Hold, and for the call to be successfully resumed.  Incidentally are you running multicast or unicast on your MoH server?, also check that you have ccm-manager music-on-hold configured on your gateway.

Rgds

Allan.

nick anderson Tue, 03/30/2010 - 07:55

All of my MOH sources are unicast.

As I posted above,  removing the Gateway's access to any MOH source allows the call to be  placed on hold and resumed. Based on wireshark (and my region settings) MOH is coming in as G.729.  I am not familiar with the commands for  ccm-manager music-on-hold.  Do you know where that is documented?

Router config is attached.

Attachment: 
j.sillers Mon, 02/21/2011 - 09:32

Is the trancoding resource registered ?  I see you have it defined but I generally add the following to the CCM Group:

sccp ccm   group 1      

associate ccm 1 priority 1      

associate ccm 2 priority 2      

associate ccm 3 priority 3      

associate profile 20 register MTP_SiteName_GW1      

associate profile 10 register CFB_SiteName_GW1 

those are my MTPs and Conf resources pre-defined in my UCM config.  They would contain the local router resources.

Also, under your DSPFARM PROFILE you could try adding "g729r8" and "g729br8" to cover all your G.729 bases

Finally,  to add MOH to the ccm-manager fallback section of the config for MoH in SRST mode

moh       

(please rate if this was useful or if I was way off base)

Aaron Harrison Fri, 03/26/2010 - 12:25

Hi

So... looks to me like it's having trouble setting up the media (h245 being responsible for media neg etc).

I see G729 being used; if you are running a default MoH config then it only supports G711 (G729 sounds bad for music) so it will try to invoke a transcoder. Do you have any transcoders?

A quick test might be to go into Service Parameters for the IP Voice Media Streaming service, and enable the parameter that allows G729 streaming. If it then holds OK, you at least know where the problem lies (roughly).

Regards

Aaron

nick anderson Fri, 03/26/2010 - 12:47

I have a transcoder registered, and in that phone's Media Resource Group (config below).  I checked the Service Parameters for both CM servers, and all 4 codecs were already enabled.

It seems like it should have everything it needs =(

sccp local GigabitEthernet0/0
sccp ccm 10.192.36.10 identifier 2 priority 2 version 6.0
sccp ccm 10.192.36.11 identifier 1 priority 1 version 6.0
sccp
!
sccp ccm group 1
bind interface GigabitEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register DFW-2851-tnc
!
dspfarm profile 1 transcode 
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application SCCP

!

Aaron Harrison Sat, 03/27/2010 - 02:47

Hi

So... you have an MRGL on the phone hmmm?

The way this works is that the system will play out the MOH source assigned to the phone. The system will do this using the resources applied in the MRGL assigned to the gateway.

The phone could be the other side of the world, so there's no point using a transcoder or music source from there.

What devices do you have on this site that require a transcoder based locally? If all you have on this site are gateways and phones, you can almost guarantee you don't need one on this gateway (you need a transcoder only where a stream must be switched between codecs due to one end not supporting the codec in use on the WAN, and the transcoder should be collocated with the device that doesn't support the WAN codec - commonly this includes any flavor of Unity not enabled for G729, UCCX running G711, ARC, etc.).

I would do one of these two things:

1) Temporarily shut off MoH to prove that hold then works (by stopping the MoH part of the IP VMS service, not the whole thing)

2) Or ensure that all your MoH's are in MRGs, and remove any MoH MRGs from the gateway.

That it is failing to set up H245 suggests a media problem to me, and if there were no MoH there is just a local tone generated...

Regards

Aaron

nick anderson Tue, 03/30/2010 - 07:50

You were right on about the MOH...  I took the MOH source out of the Gateway's MRGL (I had only done that for the phone before...), so that the Gateway had no access to any MOH sources. I was then able to place a call on hold and resume it normally.

Now I dont understand why I can't get MOH to the gateway though...  The MOH source can play to the phones successfully.  When I do a Wireshark trace on the gateway I see 4 seconds of RTP for a G.729 stream after hold is pressed, but then the call is connected and the stream is stopped.  At least I know where to focus now.

The only devices on-site are the 1 gateway and several phones.  Based on my Region relationships in call manager, everything should be coming to me via G.729.  I defined the local transcoder as a troubleshooting test.  If I dont need it, I can remove it from the config.

nick anderson Wed, 03/31/2010 - 08:26

I added a MOH souce back to the MRGL that both devices are in.

When I leave MTP unchecked on the gateway, I get 4 seconds of RTP, then the call drops (as before).

When I check MTP I get Beep Tones instead of music, but the call is retreivable (same behavior I had when there were no MOH sources in the MRGL).

Aaron Harrison Wed, 03/31/2010 - 08:51

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 Wed, 03/31/2010 - 12:11

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 Wed, 03/31/2010 - 12:46

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 Wed, 03/31/2010 - 14:11

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 Thu, 04/01/2010 - 05:52

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...

Aaron Harrison Thu, 04/01/2010 - 08:37

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?

Aaron Harrison Thu, 04/01/2010 - 08:59

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 Thu, 04/01/2010 - 10:07

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 Thu, 04/01/2010 - 10:15

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 Thu, 04/01/2010 - 15:34

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!!!|

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

Aaron Harrison Thu, 04/01/2010 - 15:49

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 Thu, 04/01/2010 - 08:18

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 Thu, 08/16/2012 - 01:04

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     

Actions

This Discussion