Q.850 cause 102 (Recovery on timer expiry): what it means

Short answer: Q.850 cause 102 (Recovery on timer expiry) means an error recovery procedure started because a protocol timer expired: some expected message did not arrive in time. On SIP trunks it is usually an unanswered INVITE, caused by a firewall, NAT, SIP ALG or a UDP packet that is too large. Follow the signaling and see where it stops.

How Monitor treats cause 102

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. On the English screens, cause 102 reads: a protocol timer expired.

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

Q.850 cause 102, Recovery on timer expiry, means a procedure was started by the expiry of a timer, as part of the error handling procedures. In other words, a device waited for a message that never came and gave up. It belongs to the protocol error class. Under RFC 3398 (section 7.2.4.1), cause 102 becomes SIP 504 Server Time-out (the RFC writes “504 Gateway timeout”); in the other direction, SIP 408 Request Timeout and 504 map back to 102. In SIP, the typical timer is the INVITE’s Timer B, at 64 times T1, or 32 seconds with the default T1 of 500 ms (RFC 3261). The cause arrives in the ISUP REL and in a Reason: Q.850;cause=102. In Asterisk, ${HANGUPCAUSE} is set to 102, and the CDR shows hangupcause 102 when it records the field.

When it appears

• A firewall blocking the carrier’s response or the outbound INVITE itself.
• NAT with no mapping for the SIP port, or the router’s SIP ALG altering the messages.
• An INVITE with an SDP that is too large (many codecs), which exceeds the MTU, gets fragmented over UDP, and loses a fragment.
• The trunk’s DNS resolving to an old carrier IP address.
• An intermediate SIP server that does not respond and does not even send 100 Trying.

How to diagnose it

1. In sngrep, see whether the INVITE was retransmitted several times with no response: that confirms nothing came back.
2. Capture on the external interface with tcpdump -i any -s 0 -w call.pcap port 5060 to find out whether the INVITE left and whether any response arrived.
3. Disable the router’s SIP ALG and check the NAT and firewall rules for the carrier’s IP addresses.
4. If the INVITE is larger than about 1,300 bytes, reduce the codecs offered or use TCP on the trunk.
5. Check the DNS for the trunk’s domain and the IP address the INVITE is actually going to.
6. In 3CX, the Activity Log with Verbose logging shows whether the trunk received any response before the timeout.

What to send the carrier

• Date, time and time zone of the attempts.
• The A and B numbers.
• The Call-ID and what you received: no response, SIP/2.0 408 Request Timeout or 504, with the Reason.
• The source public IP address and the destination IP address the INVITE was sent to.
• The pcap showing the INVITE retransmissions.

Frequently asked questions

Why does the call take about 32 seconds before failing with cause 102?

Because a SIP INVITE over UDP is retransmitted until Timer B expires, and Timer B is 64 times T1. With the default T1 of 500 ms, that comes to 32 seconds. If no final response arrives within that interval, the transaction fails, and the gateway reports cause 102 to the telephony side.

Does a real test call help with timeout failures?

Yes, because it follows the same signaling path as an ordinary call and gets the final SIP response, or the lack of one. A failure is retried before it becomes an alert, which avoids an alarm over a single lost packet, and the alert goes out by email and SMS.