Bind 501 to one request and responder
SIP 501 means the server does not support the functionality required to fulfil that request. Preserve the method, Request-URI, Call-ID, CSeq, top Via branch, Route set, source and destination, then identify the system that emitted the final response. A PBX or B2BUA can receive one method on a leg and create a different transaction on another, so a phone displaying 501 does not prove the phone system generated it.
Keep INVITE, REFER, MESSAGE, INFO, PUBLISH and other methods separate. The code identifies an unsupported function at that responder for that request; it does not by itself establish a product-wide outage, missing codec, bad credentials or network failure.
Distinguish 501 from 405 and 420
RFC 3261 uses 405 when a server understands the method but does not allow it for the resource named by the Request-URI; that response includes an Allow header listing valid methods. A 501 instead reports that the server lacks the functionality needed to fulfil the request. Preserve any Allow header, but do not invent one when the responder did not send it.
An unsupported option tag required by a Require header is a 420 Bad Extension condition and can identify tags in Unsupported. That is different from an unknown request method. Do not remove every Require value, replace the method or disable a SIP feature until the captured response and the governing extension specification establish the incompatible item.
Treat method support as hop-specific
A proxy that does not recognize a method can reject it even when both end systems support the associated feature. Conversely, a proxy can forward an unknown method while the target user agent returns 501. Identify every signaling hop and compare the rejecting component's current method support rather than assuming an end-to-end capability from one product label.
RFC 4475 includes unknown-method test cases and notes that 501 is the preferred future-compatible response. A deliberately unusual test method belongs in an isolated interoperability lab; do not send arbitrary methods through production trunks as a discovery technique.
Preserve the method's own state machine
A failed REFER, MESSAGE or subscription-related request can affect a feature without ending an established INVITE dialog. The extension that defines the method governs any retry, fallback, implicit subscription or dialog impact. Do not automatically resend the request as INVITE, INFO or another method merely because it traverses the same dialog.
Capture the transaction immediately before and after 501 and record what the application was trying to accomplish. A user report such as transfer failed, message failed or presence stopped is the symptom; the specific request and responder locate the unsupported function.
Use Asterisk evidence without losing the wire code
For Asterisk PJSIP, capture a narrow reproduction with protocol logging, then correlate Call-ID, CSeq, timestamp and PJSIP channel with the loaded endpoint and relevant application or module. Disable protocol logging afterward and protect credentials, identities and bodies. Use the focused Asterisk investigation for the full evidence path.
Asterisk's published hangup mappings group many otherwise unlisted 5xx responses into a coarse switching-congestion cause. Preserve the original 501 before consulting per-channel causes or Dial results; a translated cause cannot reconstruct the exact method, responder or response code.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: 405 and 501 response semantics ↗
- IETF RFC 4475: unknown-method SIP torture tests ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk hangup cause mappings ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.