Q.850 cause 111 Protocol error, unspecified

What Q.850 cause 111 means

The signalling itself was wrong in a way the equipment could not classify. As the protocol-error catch-all, cause 111 points at the messages rather than at capacity, permissions or routing. In practice something between the two ends is usually altering, truncating or mis-sequencing signalling, and an ALG or a mismatched protocol profile is the first place to look. It maps to SIP 500.

Protocol error class
Sent by Any element that could not process the signalling it received
Occasional

What Q.850 cause 111 Protocol error, unspecified actually means

A protocol error means a message was structurally or logically invalid: a mandatory element missing, a value that cannot be parsed, or a message arriving at a point in the call where it makes no sense. The unspecified variant is used when none of the more precise protocol causes fits, which tells you the receiving equipment recognised the message as wrong without being able to say how. It is worth holding it apart from its neighbours: cause 102 means nothing arrived at all, cause 103 means something unknown arrived and was tolerated, and cause 111 means something arrived and was rejected as invalid. RFC 3398 maps it to 500 Server Internal Error.

This cause is used to report a protocol error event only when no other cause in the protocol error class applies.
— ITU-T Q.850 section 6.2.7.6.10

The SIP equivalent of Q.850 cause 111

A gateway translating this cause into SIP reports it as SIP 500 Server Internal Error. The mapping is defined in RFC 3398 section 7.2.4.1.

What causes Q.850 cause 111 on a business phone system

SIP ALG rewriting headers badlyRouters that try to help by editing SIP messages regularly produce inconsistent or malformed results, particularly with multiple concurrent calls. This is the leading explanation on small-business connections and is quick to rule in or out.
Malformed messages from a device or an old firmware releaseA handset, adaptor or PBX with a signalling bug can emit messages that are subtly out of specification. They may work with one carrier and fail with another, depending on how strictly each validates.
Messages arriving out of sequence after a failoverWhen a call moves between nodes, state can be lost and later messages then refer to something the new node knows nothing about. The result is a valid message received at an invalid moment.
Large messages fragmented over UDPSIP messages carrying long headers or extensive media descriptions can exceed the path MTU and fragment. If fragments are lost or blocked, what arrives is incomplete and rejected as an error.
A protocol variant mismatch on an interconnectTwo networks following different profiles can each send something the other considers invalid. This produces failures that are consistent by route rather than by time or by load.

How to fix Q.850 cause 111

Disable SIP ALG and retest before anything elseIt is the cheapest test available and it resolves a substantial share of these cases. Restart the router afterwards and repeat the failing scenario rather than assuming the change took effect.
Capture the signalling and read the rejected messageUnlike most causes, this one is directly observable: the invalid message is there in the trace. Find the last message before the failure and compare it against a successful call.
Test over TCP where fragmentation is plausibleIf messages are large, switching the trunk to TCP removes UDP fragmentation as a variable. Confirm the carrier supports it before making the change.
Update firmware on the device that generated the bad messageOnce the trace identifies the source, check the release notes for signalling fixes. This is the point at which an upgrade is justified, rather than as a speculative first move.
Agree the profile with the carrier on an interconnectWhere two networks meet, both should be working to the same documented set of headers and procedures. Discrepancies here are best settled in writing so they survive the next change at either end.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about Q.850 cause 111

What is the difference between cause 111 and cause 102?

Cause 102 means a reply never arrived and a timer eventually gave up waiting. Cause 111 means something did arrive and the receiving equipment judged it invalid, which is a much more tractable problem because the offending message is visible in a trace.

Can SIP ALG really cause protocol errors?

Yes, and it is one of the most common causes on UK small-business routers. The feature attempts to rewrite addresses inside SIP messages and frequently produces inconsistent results, which is why most providers recommend turning it off.

Is cause 111 my equipment or the carrier's?

A packet capture answers this definitively, which is worth the effort before escalating. Whoever generated the message that was rejected owns the problem, and the trace shows that without ambiguity.

Related Q.850 cause values

Source. Q.850 cause 111 Protocol error, unspecified is defined in ITU-T Q.850 section 6.2.7.6.10 and registered in the ITU-T Recommendation Q.850 (10/2018). The causes and fixes above are drawn from our own experience supporting UK business phone systems.

All Call hangup causes (Q.850) codes