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

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?

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

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

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.

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

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