Q.850 cause 30 Response to STATUS ENQUIRY

• Normal class
• Sent by The switch answering a STATUS ENQUIRY, inside a STATUS message
• Rare

What Q.850 cause 30 Response to STATUS ENQUIRY actually means

Signalling protocols include a way for one end to ask the other what state a particular call is in. The reply is a STATUS message, and this cause value is attached purely to explain why that message was sent: because somebody asked. It carries no judgement about the call, reports no problem and terminates nothing. RFC 3398 publishes no SIP equivalent, which makes sense given it is not a call outcome. If your fault-finding tool has surfaced this as a hangup reason, the tool is misreading a trace.

This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message.

— ITU-T Q.850 section 6.2.7.1.24

The SIP equivalent of Q.850 cause 30

RFC 3398 publishes no recommended SIP status for this cause. It maps a subset of cause values only, and states that a cause outside that subset should default to 500 Server Internal Error. Seeing this cause reach a SIP leg unchanged usually means something in the path passed it through without translating it.

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

• Routine state auditing between two switchesSome equipment polls the state of long-running calls as a matter of course. The enquiry and the reply are entirely normal traffic and appear steadily in any detailed capture.
• One side has lost track of a callAfter a brief interruption, an exchange may be unsure whether a call is still up and will ask. The reply is normal; what is worth noting is that something prompted the question.
• Recovery after a data link glitchWhen layer 2 on an ISDN circuit drops and recovers, both ends resynchronise their view of active calls. A burst of enquiries and replies immediately after a link event is expected behaviour.
• A debug capture showing normal internalsTurn on full protocol tracing and you will see a great deal of machinery that never surfaces in day-to-day logs. Finding this cause in a capture usually means you are looking deeper than you need to.

How to fix Q.850 cause 30

1. Do not treat it as a faultThere is nothing to repair in the cause itself. If a monitoring tool is alerting on it, adjust the tool rather than the phone system.
2. Look at what prompted the enquiryThe interesting question is why one side needed to ask. Check the trace immediately before it for a link failure, a timer expiry or a message that went unanswered.
3. Compare the reported call state with realityIf the STATUS reply describes a call state the other end does not recognise, the two systems have diverged. That mismatch is a genuine fault and usually shows up as stuck channels.
4. Check layer 1 and layer 2 if enquiries are frequentPersistent state auditing on an ISDN circuit points at an unstable link. Look at error counters and physical connections rather than at call handling configuration.
5. Question why Q.931 signalling is present at allOn an estate that is supposed to be fully SIP, this cause is evidence of surviving TDM somewhere. Find the gateway or circuit responsible and factor it into your switch-off planning.

Questions about Q.850 cause 30

Related Q.850 cause values

• Q.850 cause 16Normal call clearing
• Q.850 cause 31Normal, unspecified
• Q.850 cause 6Channel unacceptable

Source. Q.850 cause 30 Response to STATUS ENQUIRY is defined in ITU-T Q.850 section 6.2.7.1.24 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