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.
Senior Applications Analyst
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.....
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.
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: com.cisco.cti.protocol.CallAnswerResponse
received Event: com.cisco.cti.protocol.CallStateChangedEvent
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
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:
CTIERR_REDIRECT_CALL_UNKNOWN_DESTINATION=0x8ccc0034::Attempt to redirect
to an unknown
Let us know,