Q.850 cause 127 (Interworking, unspecified): what it means

Short answer: Q.850 cause 127 (Interworking, unspecified) means the call passed through an interconnection with a network that does not provide causes for its actions, so the exact reason is unknown. It does not point to a specific defect. It is common on gateways between SIP, ISDN and R2 signaling. Find out on which leg the call failed and which response came from there.

How Monitor treats cause 127

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

Q.850 cause 127, Interworking, unspecified, means there was interworking with a network that does not provide causes for the actions it takes, so the exact cause of the message is not known. It is the only cause in the interworking class in Q.850. Under RFC 3398 (section 7.2.4.1), cause 127 becomes SIP 500 Server Internal Error. In the other direction, several SIP responses with no telephony equivalent map back to 127: 413, 414, 416, 420, 421, 423, 505 and 513. In other words, problems with SIP extensions (the Require header), message size or version can reach the telephone network as 127. The cause appears in the ISUP REL, in a Reason: Q.850;cause=127 (RFC 6432) and, in Asterisk, in ${HANGUPCAUSE}, as well as the CDR’s hangupcause field when it is recorded.

When it appears

• A call that crosses a leg with R2 MFC signaling, still common on E1 in Brazil, which does not carry Q.850 causes.
• A gateway that receives SIP 420 Bad Extension or 421 Extension Required because of Require: 100rel or Require: timer.
• A SIP message that is too large, answered with 513 Message Too Large.
• A Request-URI that is too long (414) or an unsupported URI scheme (416).
• Equipment from different vendors in sequence, each one translating the previous one’s cause.

How to diagnose it

1. Follow the call leg by leg in sngrep or in the pcap and find the first error response.
2. If the first response is 420 or 421, check the INVITE’s Require and Supported headers; in PJSIP, test with 100rel and timers turned off on the endpoint.
3. If it is 513, reduce the size of the INVITE (fewer codecs or headers) or use TCP.
4. On an E1 with R2, check on the gateway which B signal the destination returned and how the gateway translated it.
5. In 3CX, the Activity Log with Verbose logging shows the trunk’s exact response before translation.
6. Ask whoever is responsible for each gateway for the cause or response it received before generating the 127.

What to send the carrier

• Date, time and time zone of the attempts.
• The A and B numbers.
• The Call-ID, the SIP/2.0 500 Server Internal Error line and the Reason with cause=127.
• The full INVITE, with Require, Supported and the message size.
• An explicit request for the original response or signal on the leg where the carrier did the interconnection.

Frequently asked questions

Does cause 127 mean the carrier has an internal error?

Not necessarily. Under RFC 3398, cause 127 becomes SIP 500 Server Internal Error, which looks like an internal failure, but the cause only says the call passed through a network that did not report the reason. The real error can be on any leg, including a rejected SIP extension or a message that is too large.

Why do I see cause 127 on E1 trunks with R2?

Because R2 MFC signaling does not carry Q.850 causes: it uses B signals, such as subscriber free, busy or congestion. The gateway that connects R2 to ISDN or SIP has to translate those signals, and when there is no clear translation, or when the destination simply releases the call, it may use cause 127.