Q.850 cause 65 (Bearer capability not implemented): what it means

Short answer: Q.850 cause 65 (Bearer capability not implemented) means the equipment that cleared the call does not support the requested bearer capability, such as a data call or a media format. On SIP trunks, it is almost always a missing common codec or T.38 fax not being accepted. Compare the SDP in the INVITE with what the carrier accepts.

How Monitor treats cause 65

When the carrier gives the Q.850 cause in the Reason header of the SIP response, Monitor keeps it beside the SIP code on every test call, and it appears in the incident's evidence, ready for the ticket with the carrier.

Like any failure, a test call read as Down is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident.

What does cause 65 mean in practice?

Q.850 cause 65, Bearer capability not implemented, means the equipment sending the cause does not implement the requested bearer capability. In TDM telephony, the bearer says whether the call is speech, 3.1 kHz audio or unrestricted digital data. In SIP, that role falls to the media description in the SDP. Under RFC 3398 (section 7.2.4.1), cause 65 becomes SIP 488 Not Acceptable Here. In the other direction, a 488 or a 606 Not Acceptable whose Warning is about bearer capability maps back to 65; without that Warning, the default is 31. The cause appears in the ISUP REL, the ISDN DISCONNECT and a Reason: Q.850;cause=65. In Asterisk, ${HANGUPCAUSE} is set to 65, and the CDR shows hangupcause 65 when it records the field.

When it appears

• No codec in common: the PBX offers only G.729 and the carrier accepts only G.711 A-law (PCMA), the standard in Brazil.
• A re-INVITE for T.38 fax on a trunk that does not accept T.38.
• An ISDN data call (64 kbit/s unrestricted) sent to a voice-only destination.
• Video or other media offered on an audio-only trunk, without a compatible audio line.
• An older gateway that does not implement the requested bearer format.

How to diagnose it

1. In sngrep, open the INVITE and look at the m=audio and a=rtpmap lines in the SDP.
2. Read the 488’s Warning: codes 304 (Media type not available) and 305 (Incompatible media format) point to the media.
3. In Asterisk, check the endpoint’s allow and disallow with pjsip show endpoint trunk-name and make sure alaw is on the list.
4. In 3CX, check the codec order configured on the trunk and compare it with the carrier’s list.
5. For fax, test with T.38 turned off (G.711 passthrough) or confirm with the carrier whether T.38 is supported.
6. On an ISDN E1, pri set debug on span 1 shows the Bearer Capability sent in the SETUP.

What to send the carrier

• Date, time and time zone of the attempts.
• The A and B numbers and the type of call (voice, fax, data).
• The Call-ID, the SIP/2.0 488 Not Acceptable Here line, the Warning and the Reason.
• The full SDP of the rejected INVITE or re-INVITE.
• An explicit request for the codec list and for T.38 support on the trunk.

Frequently asked questions

Is cause 65 the same as SIP 488?

Almost. Under RFC 3398, cause 65 becomes SIP 488 Not Acceptable Here, but a 488 only maps back to cause 65 when the Warning is about bearer capability; without that, it becomes cause 31. So a 488 can reach the telephone network as 65 or as 31, depending on what the rejecting equipment wrote in the Warning.

Why does fax fail with cause 65 while voice works?

Because fax usually switches media mid-call, with a re-INVITE asking for T.38. If the trunk or gateway on the other side does not accept T.38, it rejects the new media, and the cause can be 65. Voice in G.711 keeps working because it uses a format both sides accept.