Read 421 as a missing capability advertisement
RFC 3261 defines 421 Extension Required when a user-agent server needs a particular extension to process a request but that option tag is absent from the request's Supported header. The response must list the needed extensions in Require. Preserve the request method and Request-URI, Call-ID, CSeq, top Via branch, Supported values, response source, Require values and timestamp on the exact signaling leg.
A 421 is not a generic missing SIP header, codec, SDP attribute or application feature. It identifies an extension capability the responder says is essential for this request. The specification advises servers to use baseline SIP when useful service remains possible and not to send 421 unless the extension is genuinely required.
Keep Supported advertisement and Require demand distinct
Supported advertises extensions the requester understands. Require in the 421 response identifies the extension the user-agent server says it needs. Compare each required token with the request's actual Supported list and the current IANA registry; do not infer either list from a product label or from another signaling leg.
The responding element matters. RFC 3261 describes 421 as a user-agent-server decision, while Proxy-Require and 420 can identify different extension-processing boundaries. A back-to-back user agent can terminate one request and create another, so a downstream 421 does not prove the upstream client omitted the same advertisement.
Treat the named option tag as the correction boundary
Establish what the required extension changes, whether the requester actually implements it and whether the request can be regenerated with a truthful Supported advertisement. Do not merely inject a token: capability signaling without the behavior can move the failure into the extension exchange and conceal the original evidence. Option tags used by these compatibility mechanisms belong to standards-track extensions.
If Require is absent, names a token already present in Supported or uses an unregistered vendor token, retain that discrepancy as interoperability evidence. Escalate it with the exact messages rather than globally advertising every extension.
Separate 421 from nearby extension and session failures
A 420 response means the request required an extension the responder did not understand; 421 means the server requires an extension the client did not advertise. A 415 response concerns message-body format or handling, while 488 concerns session acceptability. These statuses can appear around one call but identify different owners and correction boundaries.
For 100rel, the IANA registry and RFC 3262 bind the option tag to reliable provisional responses and PRACK. It is not a codec, RTP, early-media-content or final-response switch. Use the Asterisk PJSIP 421 investigation to preserve the endpoint policy, Supported and Require fields, RSeq, RAck and PRACK evidence separately.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: applying extensions ↗
- IETF RFC 3261: 421 Extension Required ↗
- IETF RFC 3262: reliability of provisional responses ↗
- IANA SIP option-tag registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.