Showing results for 
Search instead for 
Did you mean: 

Contact terminated on Accept Step

Hi All,

I wonder if anyone has run across this:

New Install, CCM 6.x, CRS 5.x

I am trying to test basic CRS functionality by using a simple script similar to the ICD.aef supplied by Cisco.

Dialling the Route Point results in a fast busy.

To verify that the call is in fact reaching CRS, I set up a reactive debug session. The script fails as soon as it hits the Accept step with the following error:

Contact id:xx, channel id:y,

Contact is in Terminated/Connected State.

where x and y are numbers that may change with each new attempt.

The CRS engine is in full service.

Ideas, anyone ? Any help would be greatly appreciated.


Ram Radhakrishnan

Senior Applications Analyst

Sentinel Technologies

Hall of Fame Master

This sounds like a codec mismatch, CRS cannot do native transcoding, if you installed it as G711 make sure you send G711 calls to or use transcoders.

If this is not the issue, look into the MIVR logs for more clues.

HTH, please rate all useful posts!



Thank you very much for the tip, I'll check again, but both CCM and CRS are at G711. Would I see something related to codecs in the MIVR logs ?

In the past when I have seen Codec mix ups cause the prompts to be simply not played; I have not observed an exception or error when executing teh "Accept" step.


The MIVR logs will not explicitely say that, but they will give you enough details to figure out the issue.

The codec mismatch would cause the accept step to fail. If you are calling in from IP communicator make sure that it is not set to optimize bandwidth.



I know this thread is ancient but THANK YOU!!!!

I was running into this on a new CSR 11 deployment on all my scripts and was losing my hair over it. Tripled checked everything was set to G711, even though my whole environment is G711! Opened a TAC case after a couple days, and while the engineer was reviewing my systems was going through google search results and found this!!!

What a crazy "bug" for CIPC with that setting. I do not understand why the applications/software side setting would cause this when everything region, device pool, device, etc is set to G711.....



You're welcome and thank you for nice rating :-)


did you ever get an answer to your question as I am experiencing the same on CCM 7 and CCX 7? If so, what was the resolution? If not, has anyone got any ideas?


Is your script in fact failing on accept step or the next one?

Did you try with any script it consistently fails on accept?

Fast busy etc sounds like some mis match in partitions/ CSS etc however if the call is made through to CRS script then ignore this.

may be include you script here.

Cisco Employee

Hi Ram,

As others have suggested, this sounds like codec negotiation or something similar. When the contact hits the accept step, the CTI Port will do media negotiation with CUCM and the calling device. If this fails, it may result in slow busy or fast busy.

If you take a look at the MIVR logs you may see something similar to:

CallCtlConnFailed, Inbound call, callctl cause:107

If you pull the JTAPI logs you may see a sequence similar to this:



received Response:


received Event:


CallStateChanged [


This usually means CUCM is trying to invoke a transcoder. Look at the Detailed CUCM traces for this timeframe and look at the bearer capabilities:

capA - 3, 86 g711Alaw56k, g729b, capB - 2, 4 g711alaw64k, g711ulaw64k

As you can see UCCX is advertising g711alaw64k and g711ulaw64k (capB) at the standard bit rates, but the calling device is advertising 56k.

CUCM attempts to invoke a transcoder for this call to transcode the rates, but none is configured:

CCM|MediaResourceManager::sendAllocationResourceErr - ERROR - no

transcoder device


So the call fails.

If none of this checks out, then take a look at the CSS/Partitions. The calling device CSS must contain the partitions of the CTI Ports. The partition and CSS of the CTI Route Point do not matter. You may see the following in the MIVR logs after UCCX selects a CTI Port and tells CUCM to redirect to that port:


to an unknown


Let us know,



Thanks, I re-defined all the parameters taking careful notice as to what was configured and it worked fine.


is this a new installation? I'm wondering also if when you send the call to the trigger, if your agent switches from Ready to state to Reserve state to indicate that the call was sent to the phone?  if not, this is not the issue I have seen and resolved.


Hello everyone.

In the case of codec mismatch, you can check it by calling to UCCX trigger Directory Number from your agent number. If it will answer correctly, then check codec settings on CUCM. You can set up exact G.711 for Device Pools to both directions here: System - Region Information - Region.


Have a great day.


Content for Community-Ad