SIP 500 Server Internal Error: what it means and how to fix it
Short answer: SIP 500 Server Internal Error means a server on the route hit an unexpected condition and could not process the request. Common causes are a software fault in the PBX, the SBC or the carrier, or a 503 from a downstream server that a proxy turned into a 500. Find out who generated the response before you open a ticket.
| Code | 500 |
|---|---|
| Official name | Server Internal Error |
| Class | 5xx: server failure |
| Defined in | RFC 3261 |
| Q.850 causes that usually come with it | 111 (Protocol error, unspecified), 127 (Interworking, unspecified), 41 (Temporary failure) |
How Monitor treats SIP 500
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: an internal fault at the provider (SIP 500).
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 500 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 500 mean in practice?
SIP 500 Server Internal Error is the generic 5xx response: the server ran into an unexpected condition that kept it from fulfilling the request. RFC 3261 allows it to carry Retry-After, and the client may try again after a few seconds. The code does not say what failed, only that the failure happened on the side of the server that responded.
One detail matters for troubleshooting: under RFC 3261, a proxy that receives only a SIP 503 from a downstream server should not pass it along, and should generate a 500 instead. So a SIP 500 error can hide an outage further down the route. Where SIP meets the phone network, RFC 3398 converts Q.850 cause 127 (Interworking, unspecified), cause 111 and any unmapped cause into a 500.
Common causes in Brazil
- A software fault in the PBX (Asterisk, Issabel, FreePBX, 3CX) after a version or module upgrade.
- An internal dependency down in the PBX or the carrier’s platform, such as a database or a routing service.
- A proxy or SBC that received a 503 from the next server and turned it into a 500.
- A SIP-to-E1 gateway that received a Q.850 cause with no mapping from the exchange, such as 111 or 127, and returned a 500.
- The carrier’s SBC (Vivo, Claro, Algar, Embratel or another) failing intermittently during maintenance or a restart.
How to troubleshoot
- Capture the call with
sngrepand identify who generated the 500 from the Via, Server and User-Agent headers. - In Asterisk, Issabel or FreePBX, turn on
pjsip set logger on(orsip set debug onin chan_sip) and look for the Reason header, such asReason: Q.850;cause=127, and any Retry-After. - If the 500 came from your PBX, read the full Asterisk log for the same time window, looking for module or database errors.
- Run
pjsip show registrationsandcore show channelsto rule out a downed trunk or an overloaded PBX. - In 3CX, turn on verbose logging and check the Activity Log for the step that failed.
- Place the call a few times. A 500 on every call points to configuration or software; an intermittent 500 points to overload or a failure further along.
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 500 Server Internal Errorline and the Server, Reason and Retry-After headers, if present. - How many attempts failed and whether the failure is constant or intermittent.
- The pcap file of the capture, if you have one.
Frequently asked questions
Does a SIP 500 always come from the carrier?
No. Any server on the route can generate a 500: your PBX, an SBC on your network, the carrier's SBC or equipment further along. Before you open a ticket, capture the response and check the Via, Server and User-Agent headers. If the 500 originated in your PBX, the problem is local.
Which Q.850 cause goes with a SIP 500?
Under RFC 3398, a gateway converts a SIP 500 into Q.850 cause 41 (Temporary failure). In the other direction, cause 111 (Protocol error, unspecified), cause 127 (Interworking, unspecified) and any cause without its own mapping become a 500. A `Reason: Q.850;cause=127` header points to a failure in the conversion between networks.
Does a real test call catch this error?
Yes. A real test call receives the final SIP response the network returns, including a 500. 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.