Q.850 cause 102 Recovery on timer expiry

What Q.850 cause 102 means

A timer ran out waiting for a reply that never came, so the equipment cleared the call to recover. Cause 102 does not say what went wrong; it says the conversation stopped part-way through. In UK business networks the usual culprit is signalling blocked or altered in one direction by a firewall, a SIP ALG or an SBC. It maps to SIP 504 Gateway Timeout.

Protocol error class
Sent by Whichever element was waiting, often the originating gateway or PBX
Occasional

What Q.850 cause 102 Recovery on timer expiry actually means

The timer is the recovery mechanism, not the fault. Something upstream or downstream failed silently, and rather than leave a call half-established forever, the equipment applied a timeout and tore it down. That is why this cause is more informative about timing than about the problem: the elapsed time before the failure usually identifies which timer fired, and the timer identifies which stage of the call was waiting. RFC 3398 maps it to 504 Gateway Timeout, which conveys the same idea of a reply that never arrived.

This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures.
— ITU-T Q.850 section 6.2.7.6.7

The SIP equivalent of Q.850 cause 102

A gateway translating this cause into SIP reports it as SIP 504 Server Time-out. The mapping is defined in RFC 3398 section 7.2.4.1.

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

A firewall or NAT entry expiring mid-callRouters age out idle UDP sessions, often well before a long call ends. Once the entry disappears, replies from the carrier have nowhere to go and the next timer to expire clears the call.
SIP ALG rewriting messages so replies never matchAn application layer gateway that edits SIP headers can leave the two ends unable to associate a reply with its request. Each side waits for the other, and one of them times out first.
Signalling that only travels in one directionAsymmetric routing, a one-sided firewall rule or a misconfigured route can let requests out while blocking responses back. Calls fail at a suspiciously consistent point because the timeout is the only thing ending them.
A far-end device that stopped respondingA PBX that reboots, crashes or loses its route mid-call goes silent rather than sending an error. The timeout is your equipment coping with the silence.
Session timers not being refreshedWhere both ends agree to periodically re-confirm a call, a missed refresh ends it even though audio was flowing. Calls that die at a round figure such as thirty minutes point strongly at this.

How to fix Q.850 cause 102

Note whether failures happen at a consistent elapsed timeThis is the single most useful observation available. A tight cluster at around thirty seconds points at a setup timer, while a cluster at a round number of minutes points at a session timer or a NAT entry ageing out.
Turn off SIP ALG on the router and retestIt is enabled by default on much consumer and small-business equipment and it causes more problems than it solves on a properly configured trunk. Reboot after disabling it, since some routers keep the old behaviour until they restart.
Extend UDP timeouts and confirm keep-alives are workingSet the firewall UDP timeout comfortably longer than your registration interval, and check the PBX is actually sending keep-alives. Both need to be right; either alone can still let the entry lapse.
Capture traffic on both sides of the firewallTwo simultaneous captures show whether the missing message left your network or never arrived. This is the step that settles arguments about whose fault it is, and it usually takes one reproduction.
Compare session timer settings with the carrierA mismatch in the agreed refresh interval, or a disagreement about who refreshes, produces exactly this pattern. Ask the carrier what they expect rather than adjusting values speculatively.

Fixing the underlying problem

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

Questions about Q.850 cause 102

Do calls that always drop at the same length mean cause 102?

They very often do, because a consistent duration is the signature of a timer rather than of a network fault. Record the duration to the second on several examples, since the figure itself narrows down which timer and therefore which device to examine.

Is cause 102 caused by a poor internet connection?

Not usually in the way people expect. Severe packet loss can produce it, but a firewall, NAT timeout or ALG blocking one direction of signalling is a far more common explanation, and those can happen on a connection that tests perfectly.

Which timer expired?

The cause does not say, so the elapsed time is your evidence. Call setup timers typically fire within the first minute, while session refresh and NAT ageing problems fire after several minutes of an otherwise normal call.

Related Q.850 cause values

Source. Q.850 cause 102 Recovery on timer expiry is defined in ITU-T Q.850 section 6.2.7.6.7 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