Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

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.

Thanks

Ram Radhakrishnan

Senior Applications Analyst

Sentinel Technologies

9 REPLIES
Hall of Fame Super Silver

Re: Contact terminated on Accept Step

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

New Member

Re: Contact terminated on Accept Step

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.

Hall of Fame Super Silver

Re: Contact terminated on 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.

Chris

New Member

I know this thread is ancient

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

Hall of Fame Super Silver

You're welcome and thank you

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

New Member

Re: Contact terminated on Accept Step

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?

Re: Contact terminated on Accept Step

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

Re: Contact terminated on Accept Step

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

New Member

Re: Contact terminated on Accept Step

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

2118
Views
5
Helpful
9
Replies
CreatePlease to create content