Contact terminated on Accept Step

Unanswered Question
Jun 23rd, 2008
User Badges:

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



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Chris Deren Mon, 06/23/2008 - 19:26
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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


rkrishnan7 Mon, 06/23/2008 - 21:01
User Badges:

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.


Chris Deren Tue, 06/24/2008 - 04:16
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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

koziollz1 Wed, 06/22/2016 - 06:29
User Badges:

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

Chris Deren Wed, 06/22/2016 - 06:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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

Tony Knight Thu, 10/01/2009 - 16:44
User Badges:

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?

Abdulbaseer Mohammed Thu, 10/01/2009 - 22:29
User Badges:
  • Silver, 250 points or more

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.

Ryan LaFountain Sat, 10/03/2009 - 07:09
User Badges:
  • 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:


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

Tony Knight Sun, 10/04/2009 - 14:49
User Badges:

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

Actions

This Discussion