Question About CUCM and Transcoders Being Released

[Jay Schulze]

Good Afternoon,

I'll try to keep this short winded but ran into an unusual problem which brought about an unusual answer.

So I was having a problem with dropped calls. I saw this calls were trying to use a transcoder on the gw(hardware). Which wasn't a problem as there was a mismatch when an agent would try to confrence in another agent to the customer by going back through CVP. The customers leg was 729. Put on hold and call back through CVP was 711 since the prompts are 711. Agent making the call is 729. So xcoder gets used. So call goes through CVP returns label for agent. Now it is 729. Try to confrence together call drops.

Reason being that CUCM tries to program the xcoder on the gw for 729-729. GW says nope I can't do 729-729(and why would it?)

038463: *Jul 24 21:09:10.767: sym_xapp_is_transcode_supported: None of the codec type is G711x codec - codec1 11, codec2 11

038464: *Jul 24 21:09:10.767: sym_xapp_check_for_special_act: Unsupported transcode req for sess_type 2, sess_id 33963700, conn_id 67324685,  stream_passthr_id 16777216

038465: *Jul 24 21:09:10.767: sym_xapp_open_receive_chnl: Failed while checking for special action(s) ms_rc 6 - sess_id 33963700, conn_id 67324685, stream_passthr_id 16777216, call_ref 83799046, sess_type 2, profile_id 60

So I had a workaround by making the transcoder profile universal. But I'm now hearing from Cisco that once a transcoder is invoked for that call it will always be there. Seems like bad logic to me from CUCM. The gateway and xcoder recongnize it is trying to do 729-729. Why can't callmanager release the transcoder once the update comes back that the two legs agree on doing 729-729?

Thx

J

[Manish Prasad]

Hi J,

We would love to see CUCM traces for this case , can you please attach it.

[Jay Schulze]

Sure Manish. If you want to take a look. Thanks in advance.

Here is the call ID you want to look for.

587EE743134D11E4BCDE0022915819DC-140630512971928251@170.65.136.15

The agent is 5550320431. You can see them try to conf a call back to cvp. The call leg back to cvp works find it's when they try to join them together @ 10:19:58:411. You see the update go out. These are the errors you see from the gateway not being able to do 729-729 before I made it universal.

StationInit: (0000112) OpenReceiveChannelAck Status=6 (Error: Endpoint failed to open receive channel),

Then you will see the bye immediately following with cause 47 from cucm. I have a workaround in place but my question is why would cucm not drop the xcoder after it sees both legs are 729? I think we all know how transcoding works. Just seems like bad logic to me from the cucm side.

[Manish Prasad]

Hi Jay,

There is feature on CUBE i.e. Mid-call transcoder insert and drop which is avalible from 15.1.2(T).

--------------------------------------------------------------

New Features in Cisco Unified Border Element Enterprise Edition Version 8.5

With Cisco Unified Border Element Release 1.5 (Cisco IOS Software Release 15.1.2T), nomenclature is updated to Cisco Unified Border Element Enterprise Edition 8.5. The new features provided in Cisco Unified Border Element Enterprise Edition Version 8.5 include:

● Voice-class codec support:

- Mid-call codec renegotiation

- Mid-call transcoder insert and drop

From this link.

----------------------------------------------------------------

You can also check page no 76 in attached PDF from Cisco Live session.

Thanks

Manish