cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
29021
Views
21
Helpful
13
Replies

Cisco CUBE Reason: Q.850;cause=65

jgraham01
Level 1
Level 1

Hello!

 

We have a client who uses cisco cube and cucm, the client is currently having issues calling out to certain numbers, the calling party hears a ring or two and then the call disconnects.  The message flows show a very quick bye coming from the client side with a reason: Q.850;cause=65.  The BYE occurs immediatelly after the client sends the ACK to our 200OK w/ SDP.

 

Max-Forwards: 70

Timestamp: 1417530556

CSeq: 102 BYE

Reason: Q.850;cause=65

P-RTP-Stat: PS=94,OS=1880,PR=107,OR=2140,PL=0,JI=0,LA=0,DU=0

Content-Length: 0

 

This is only occuring to specific term numbers, has anyone run into this, know how to resolve, or what we can suggest to the client as we believe the client will need to modify something on their end to resolve the issue...

 

Thanks!

13 Replies 13

Cause 65: bearer capability not implemented.

 

Probably there is a codec negotiation issue.

As workaround you can try to force only one codec, e.g. G.711u.

Please add a SIP trace.

 

Regards.

dianareyes
Level 1
Level 1

Greetings! 

I am running into the same exact issue and came across your post.  

Did you ever find a fix for your reported issue?  

Any suggestions or guidance will be greatly appreciated!

Thank you,

Diana

I realize this is an older post but I am finding more and more of these sit unanswered yet at the top of the results from a Google search.  I have run into this issue many times and thought I would take the time to provide some feedback here.

 __________________________________________________

 

Often times this is an issue only to certain numbers due to equipment downstream in the carrier network.  This is often the case with 911 calls and the speed at which the call is delivered and answered.  Often you can resolve this by enabling Early Offer so you have a codec at the ready when the call is delivered and connected.  Depending on your CCM/CME setup there are several places you may choose to enable early offer. 

 

You can enable it on the dial peer

    dial-peer voice 400 voip

      voice-class sip early-offer forced

 

You can enable it on CCM in the Device>>Device Settings>>SIP Profile menu item.  On that screen you can search for "offer" and set it there.  

 

I hope this basic answer helps someone who stumbles across this Google result.  If it does please rate this answer. 

 

Our customer has a similar issue as the original problem but only for Jabber for Windows users.

 

Customer does not have CUBE however, network is CUCM direct to BT SIP solution via SIP trunk.

 

When calling certain numbers, caller hears two ringtones and then call is ended on answer.

 

Early Offer has been enabled with no change to fault, as has Disable Early Media on 180 and send PRACK for all 1XX messages.

If we enable MTP required on Jabber profile, calls are fine but we shouldn't need to enable MTP for this.

has anyone else experienced this and found a working solution without using CUBE.

 

Thanks

Doug

There could be two reasons..

 

One is Codec negotiation 

Another one is bandwidth issue.... try changing the bandwidth level in Region 

Hi Saravana,
It does look like a Codec mismatch but the BT SIP platform is locked down to G.711 only and transcodes anything else and the client side only uses G.711 too.
Bandwidth is also not an issue, utilisation is running at less than 50%.
Thanks
Doug

How about your regions and audio codec preference list? 

Hi Nathan,
The regions are all set to support G.711 and although the codec preference list has a few in it, G.711 is at the top.
Doug

voice-class sip early-offer forced

 

 

Ths command was useful for me.  I am using CUBE to Call  Centric SIP Provider.

 

Calls to cellular were dropped.

I entered this command at the Dial Peer to Call Centric and now calls are established normally.

 

Thanks.

 

darin.marais
Level 4
Level 4

I think the issue could be due to a Cisco bug.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvk66880

I faced the same issue at some point.

Good idea to upgrade the IOS on the cube device if its a isr44xx

thanks for your help everyone.  Codec mismatch ended up resolving my issue. I added the line below to the dial-peer.

 

dial-peer voice 6600 voip
 codec g711ulaw

Todd Hebert
Level 5
Level 5

I had this issue today on a new 4321 configured as a SIP gateway with a T1 PRI connected.  In my case, inbound calls worked fine, but outbound calls were failing fast busy immediately.  I forgot to put the voice-class codec group with g711ulaw on my inbound dial-peer from CUCM.  Once I told the router which codec to use outbound calls worked fine.  Debugging ccsip media on the router told me the answer.  The router wanted g729br8 which isn't even in CUCM I don't think, definitely was not in my audio codec preference list assigned to the region.  So CUCM was offering every CODEC under the sun in the SIP INVITE, except that one, and the 4321 only wanted that one for some odd reason.  I'm sure TAC would has some grand explanation why Cisco products don't natively talk to each other.

Carrier using TLS and you are not thats what code 65 mean, enable TLS on your dial peer on gateway