Q.850 cause 88 (Incompatible destination): what it means

Short answer: Q.850 cause 88 (Incompatible destination) means the destination received a call request with compatibility attributes it cannot handle, such as the terminal type or the data rate. It is common when voice, fax and data get mixed up. Check the type of call sent, the bearer requested, and what kind of terminal is connected to the number.

How Monitor treats cause 88

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 88 mean in practice?

Q.850 cause 88, Incompatible destination, means the destination equipment received a call request with low layer compatibility, high layer compatibility or other attributes, such as the data rate, that it cannot accommodate. Unlike cause 65, which is about a bearer that is not implemented, 88 points to a mismatch between what the call asks for and the type of terminal at the destination. It belongs to the Q.850 invalid message class. Under RFC 3398 (section 7.2.4.1), cause 88 becomes SIP 503 Service Unavailable, so on the SIP side it gets mixed up with capacity failures. It arrives in the ISUP REL, the ISDN DISCONNECT and a Reason: Q.850;cause=88 (RFC 6432). In Asterisk, ${HANGUPCAUSE} is set to 88, and the CDR shows hangupcause 88 when it records the field.

When it appears

• An ISDN data call (64 kbit/s unrestricted) to an analog phone or a voice-only destination.
• A voice call to a line configured for fax or data only.
• An ISDN gateway that passes on a high layer compatibility (HLC) the destination terminal does not accept.
• Older ISDN terminals with a specific configuration, such as group 4 fax or a videophone.
• SIP-ISDN gateways that build the SETUP with a different bearer from the one the destination expects.

How to diagnose it

1. On an ISDN E1, turn on pri set debug on span 1 and read the Bearer Capability, Low Layer Compatibility and High Layer Compatibility fields in the SETUP.
2. Confirm with the number’s owner what type of terminal is connected to it.
3. On the SIP-ISDN gateway, check how it fills in the bearer: many have an option to force speech or 3.1 kHz audio.
4. In Asterisk with DAHDI, the TRANSFERCAPABILITY channel variable sets the bearer for outbound calls; confirm the value in use.
5. In sngrep, see whether the 503 came with Reason: Q.850;cause=88, to tell it apart from a 503 caused by a lack of capacity.

What to send the carrier

• Date, time and time zone of the attempts.
• The A and B numbers and the intended type of call (voice, fax, data).
• The Call-ID, the SIP/2.0 503 Service Unavailable response and the Reason with cause=88.
• The trace of the SETUP with the Bearer Capability, if the call goes out over an ISDN E1.
• A request to confirm the type of terminal provisioned on the destination number.

Frequently asked questions

Why does cause 88 become SIP 503 and not 488?

Because that is what the RFC 3398 table defines: cause 88 becomes SIP 503 Service Unavailable, while cause 65 becomes 488. In practice, this makes a compatibility problem look like a capacity problem on the SIP side. Only the Reason header with cause=88, or the TDM trace, shows the real reason.

Does cause 88 appear on pure SIP trunks?

Rarely. It originates in networks with ISDN or ISUP signaling, where the call carries compatibility attributes. On a SIP trunk, you usually see it when the call crosses a gateway into the TDM network and the destination there rejects the attributes. If the path is SIP end to end, the usual result is a 488 with a Warning.