12-02-2014 07:25 AM
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!
01-10-2015 11:59 AM
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.
06-14-2016 12:45 PM
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
01-17-2018 11:00 AM - edited 01-17-2018 11:03 AM
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.
01-22-2018 05:13 AM
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
01-22-2018 10:25 PM
There could be two reasons..
One is Codec negotiation
Another one is bandwidth issue.... try changing the bandwidth level in Region
01-23-2018 01:13 AM
01-23-2018 05:36 AM
How about your regions and audio codec preference list?
01-23-2018 06:38 AM
05-14-2019 03:50 PM
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.
11-04-2018 01:21 AM
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
11-06-2018 04:31 PM
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
02-04-2020 01:59 PM
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.
09-24-2024 10:52 AM
Carrier using TLS and you are not thats what code 65 mean, enable TLS on your dial peer on gateway
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide