CUCM Sends BYE "Reason: Q.850; cause=47"

[rphillips3]

Hi,

Our company manufactures a custom SIP endpoint.

We have a customer who is having trouble answering incoming calls from the PSTN over a PRI. When they attempt to answer the call with our device, the endpoint responds to the INVITE from CUCM with an OK which includes a SDP message body. CUCM proceeds to ACK, without a SDP message body, the OK and follows it with a BYE stating reason "Q.850; cause=47" (Resource unavailable, unspecified).

If a call is placed to the same DN internally from a Cisco endpoint, our device has no issue answering the call. After our device responds to the INVITE with an OK, CUCM sends and ACK including a SDP message body and the media session begins.

I'll add that the customer doesn't have any issue dialing out across the PRI from our device.

I haven't had any luck trying to duplicate this issue with our own CUCM system. A key difference between our system and the customer's is the fact that our 2911 gateway only has a POTS interface where as the customer is using a PRI. I don't know for fact whether or not this is the cause of the issue but it's the biggest difference I see between the two systems.

What resource is unavailable or unspecified?

[amoherek]

Hi Ryan,

I've seen the error "Q.850; cause=47" appear when there is a codec mismatch. Can you look at the detailed level logs and see if you find this line, "preCheckCapabilities, caps mismatch!" This would indicate a codec mismatch.

Thanks,

Adrienne

[rphillips3]

Adrienne,

A codec issue has been my suspicion as well. I'm wondering if the incoming call on the PRI is using G.722. The customer said they were able to use a SIP instance of IP Communicator without issue. I've asked them to provide a wireshark trace of this in order to confirm my suspicion of a codec issue, unfortunately I've have yet to receive this. Are we stuck if it ends up being a codec issue? Is there some way to have Call Manager re-encoded the RTP streams to convert between G.722 and G.711 PCMU?

I'm going to have to instruct the customer how to set up the trace on their CM as I don't have access to it. I'm looking at my system now to get a feel for how this mechanism functions. I've pulled a trace from our system, looks like I have "ccm" and "SDL" text files. In which file might I expect to see the "preCheckCapabilities, caps mismatch!" entry?

Are there Trace Filter Settings you'd recommend configuring to ensure we capture the error we're experiencing?

Thanks

[amoherek]

After reviewing the CCM and SDL logs, we determined that there was a codec mismatch between the H.323 Gateway and the SIP endpoint. Without a transcoder device configured on CUCM to handle the codec mismatch, the call fails.

[Dennis Mink]

I confirm, the times I have seen this is when there is a codec mismatch and a possibly lacking an XCODE resource.

[ravichandrann]

we had a similar issue. On the IP Communicator we had to disable the optimize for low bandwidth on Preference-< audio to get it working