Q.850 cause 79 Service or option not implemented, unspecified
The equipment was asked for something it simply does not implement, and could not name which capability. Cause 79 maps to SIP 501 Not Implemented, and the distinction that matters is permanence: where cause 63 says a service is unavailable, cause 79 says the far end has no such capability, so retrying and re-provisioning will not change the answer.
What Q.850 cause 79 Service or option not implemented, unspecified actually means
This closes the not-implemented class, which is the class about what equipment can do rather than what a subscriber is allowed to do or what happens to be free. When it appears, the useful conclusion is about who to talk to: not the provisioning team, because there is nothing to enable, but whoever owns the design of the route or the software on the box. RFC 3398 maps it to 501 Not Implemented, which carries the same finality in SIP and is likewise a statement about capability rather than about this particular call.
This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.
— ITU-T Q.850 section 6.2.7.4.5
The SIP equivalent of Q.850 cause 79
A gateway translating this cause into SIP reports it as SIP 501 Not Implemented. The mapping is defined in RFC 3398 section 7.2.4.1.
What causes Q.850 cause 79 on a business phone system
- A feature request to equipment that never supported itNewer platforms send information older ones were never built to handle. The older element declines rather than guessing, which is the correct behaviour even though it fails the call.
- Different protocol variants either side of an interconnectNational variants and different ISDN or ISUP profiles do not implement the same set of procedures. Calls that need a procedure only one side has will fail consistently in one direction.
- A gateway running software older than the network around itEquipment left on an old release quietly falls behind what the rest of the path assumes. Nothing changed at the gateway, which is why the problem seems to appear from nowhere after a carrier upgrade.
- A vendor default for anything unrecognisedWhere an implementation returns this whenever it does not know what to do, the number is a shrug. Look at what was requested rather than at the code.
How to fix Q.850 cause 79
- Identify the specific feature that triggered itTake a trace and find what was asked for immediately before the refusal. This is the only route to a real answer, because the cause itself deliberately withholds the detail.
- Stop sending the unsupported request on that routeDisabling the feature for calls over that path restores service immediately, at the cost of the feature. It is often the right trade while a longer-term fix is arranged.
- Check software versions at both endsCompare what you are running against what the vendor currently supports and against what the carrier expects. A version gap explains a large share of these refusals.
- Agree the protocol profile with the carrierOn an interconnect, both sides should be working to the same documented variant. Getting that written down prevents a repeat when either side next changes something.
Fixing the underlying problem
This page explains the code. These guides walk through the fix in detail.
Questions about Q.850 cause 79
What is the difference between cause 79 and cause 63?
Can cause 79 be fixed with a configuration change?
Related Q.850 cause values
- Q.850 cause 111Protocol error, unspecified
- Q.850 cause 63Service or option not available, unspecified
- Q.850 cause 65Bearer capability not implemented
Source. Q.850 cause 79 Service or option not implemented, unspecified is defined in ITU-T Q.850 section 6.2.7.4.5 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.