06-23-2008 04:20 PM - edited 03-14-2019 02:26 AM
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.
Thanks
Ram Radhakrishnan
Senior Applications Analyst
Sentinel Technologies
06-23-2008 07:26 PM
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!
Chris
06-23-2008 09:01 PM
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.
06-24-2008 04:16 AM
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.
Chris
06-22-2016 06:29 AM
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.....
THANKS AGAIN!!!
06-22-2016 06:34 AM
You're welcome and thank you for nice rating :-)
10-01-2009 04:44 PM
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?
10-01-2009 10:29 PM
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.
10-03-2009 07:09 AM
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:
sending: com.cisco.cti.protocol.CallAnswerRequest
...
received Response: com.cisco.cti.protocol.CallAnswerResponse
...
received Event: com.cisco.cti.protocol.CallStateChangedEvent
...
CallStateChanged [
state=DISCONNECTED cause=RESOURCESNAVAIL
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
configured
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
destination
Let us know,
Ryan
10-04-2009 02:49 PM
Thanks, I re-defined all the parameters taking careful notice as to what was configured and it worked fine.
05-06-2019 03:17 PM
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.
11-13-2019 07:16 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide