Read 420 as a required-extension rejection
RFC 3261 defines 420 Bad Extension when a server does not understand a protocol extension named in a Require or Proxy-Require header. The response must list the unsupported option tags in an Unsupported header. Preserve the request method and Request-URI, Call-ID, CSeq, top Via branch, Require and Proxy-Require values, response source, Unsupported values and timestamp on the exact signaling leg.
A 420 is not a generic indication that a SIP header, URI, route, codec or SDP attribute is wrong. An unknown ordinary header is normally ignored under the base specification; the rejection is tied to extension requirements that the relevant server or proxy cannot satisfy.
Keep Require, Supported and Proxy-Require distinct
Supported advertises extensions the sender understands. Require says the receiving user agent must understand listed option tags to process that request, while Proxy-Require applies the requirement to proxies on the path. RFC 3261 restricts these option tags to standards-track extensions. Capture all three fields rather than inferring the requirement from a feature label.
The responding element matters. A user-agent server rejecting Require and a proxy rejecting Proxy-Require establish different ownership. A PBX acting as a back-to-back user agent can terminate one leg and create another, so a downstream 420 and the response delivered upstream need not share headers or identity fields end to end.
Interpret Unsupported as the correction boundary
Compare every Unsupported token with the request's Require and Proxy-Require values and the current IANA registry. A missing, transformed or vendor-defined token is a configuration or interoperability clue, not permission to remove every requirement. The named extension may protect semantics that the application actually needs.
RFC 3261 allows a client receiving 420 to retry without extensions named in Unsupported, but only when the request can still be processed correctly without them. Preserve whether the user agent retried, the resulting request and the next response. Do not suppress the requirement at an unrelated intermediary or globally strip Require headers to make one call proceed.
Separate 420 from nearby failures
A 421 response means the server requires an extension the client did not advertise; 420 means the request required an extension the responder did not understand. A 415 response concerns message-body format or handling, while 488 concerns session acceptability. These statuses can appear around the same call but identify different negotiation boundaries.
For the common 100rel option tag, inspect reliable provisional response behavior and PRACK separately from final call acceptance and media. IANA defines 100rel as provisional-response reliability, not as a codec, RTP or general early-media switch. Use the Asterisk PJSIP 420 investigation for endpoint-specific evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: Supported, Require and Proxy-Require processing ↗
- IETF RFC 3261: 420 Bad Extension ↗
- IANA SIP option-tag registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.