SIP 501 Not Implemented: what it means and how to fix it

Short answer: SIP 501 Not Implemented means the server does not support the functionality needed to fulfill the request, typically a SIP method it does not recognize. It shows up more often on REFER, UPDATE, INFO or MESSAGE than on INVITE. Check the trace for the method that got the 501 and set the PBX to stop sending it to that trunk.

How Monitor treats SIP 501

The reading depends on what should answer the number, which is the question 2N5 answers when it adds each circuit. These are the rules the product applies today, generated from the same function that judges every test call.

What should answer the number	Reading
A greeting or recorded message (the IVR)	Down
A test tone or echo service	Down
Other: it may ring or be answered	Down

What Monitor records for an IVR: The provider could not complete the call because of a fault on its side (SIP 501).

A call read as Down alerts nobody on its own: it is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident, with each call's SIP code and Q.850 cause as evidence for the carrier. At the default pace, every circuit is tested every 15 minutes.

If the carrier returns SIP 501 when 2N5's calling account registers, before any call, the test is monitoring blind: it is a problem on 2N5's side, it does not count against the circuit and it does not alert the customer.

What does SIP 501 mean in practice?

SIP 501 Not Implemented says the server does not support the functionality needed to fulfill the request. Under RFC 3261, it is the right response when the recipient does not recognize the request method and cannot support it for any user. Proxies forward requests of any method, so a 501 usually comes from the end device, such as the carrier’s SBC or the destination PBX.

In practice, a SIP 501 error rarely blocks the whole call. It tends to break one feature: a transfer that uses REFER, a session refresh with UPDATE, DTMF over INFO or a MESSAGE. The CSeq header in the response shows the refused method, such as CSeq: 102 REFER. Where SIP meets the phone network, RFC 3398 converts a 501 into Q.850 cause 79 and maps causes 29 and 79 back to 501 in the other direction.

Common causes in Brazil

• A call transfer from the phone or the PBX sending REFER to a carrier trunk (Vivo, Claro, Algar, Embratel or another) that does not implement that method.
• UPDATE sent to refresh the session or update call details to equipment that does not support it.
• INFO for DTMF or MESSAGE for text sent by IP phones or softphones to a trunk that does not handle those methods.
• SUBSCRIBE or PUBLISH for presence and busy lamp field (BLF) going to the trunk by mistake instead of staying between extensions.
• A SIP-to-E1 gateway that received Q.850 cause 79 or 29 from the exchange and returned a 501.

How to troubleshoot

1. Open the trace in sngrep and filter for the 501 response. The CSeq header shows which method was refused.
2. Send or capture an OPTIONS to the trunk and read the Allow header in the response: it lists the methods the equipment accepts.
3. In Asterisk, Issabel or FreePBX, turn on pjsip set logger on (or sip set debug on in chan_sip) and repeat the action that failed, such as the transfer, to see which request went out.
4. Run pjsip show endpoint <trunk> and review the options that generate extra methods, such as the DTMF mode and session timers.
5. In 3CX, turn on verbose logging and check the Activity Log for the request that got the 501.
6. If the 501 came in response to the INVITE, look in the SDP or the Require and Supported headers for an extension the destination does not implement.

What to send your carrier

• The exact date and time with the time zone, for example 2026-10-07 14:32:10 -03:00.
• The calling number (A), the called number (B) and the Call-ID.
• The full SIP/2.0 501 Not Implemented line and the CSeq header with the refused method.
• Which feature failed for the user (transfer, DTMF, the whole call).
• The pcap file of the capture, if you have one.

Frequently asked questions

What is the difference between SIP 501 and SIP 405?

501 Not Implemented says the server does not recognize the method and does not support it for any user. 405 Method Not Allowed says the server recognizes the method, but it is not allowed for that resource. In both cases, the Allow header in the response, or in a reply to OPTIONS, shows which methods the equipment accepts.

Does a 501 in reply to OPTIONS take the trunk down?

Usually not. OPTIONS is used as a keepalive for the trunk, and any response shows the equipment on the other side is up. What matters for calls is the response to INVITE. Still, check whether your PBX or SBC treats a 501 to OPTIONS as a failure, because that depends on the configuration.

Does a real test call catch this error?

Yes, when it comes in response to the INVITE. A real test call receives the final SIP response the network returns. When the result counts as a failure, the call is retried before any alert goes out, and the alert is sent by email and SMS.