SIP 600 Busy Everywhere: what it means and how to fix it

Short answer: SIP 600 Busy Everywhere means the destination was reached, is busy, and knows no other endpoint would accept the call right now. It is a 6xx global failure, so the proxy stops trying other routes. On a trunk, it can mean the concurrent channels are used up. Check who generated the response and the channel limit on the route.

How Monitor treats SIP 600

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	Up

For "Other": With "Count busy as reachable" unticked: Down.

What Monitor records for an IVR: The line was busy: the phone is on another call, but this circuit is supposed to answer every call by itself (SIP 600).

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 600 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 600 mean in practice?

SIP 600 Busy Everywhere is a 6xx response, the global failure class. According to RFC 3261, the destination’s system was contacted successfully, but the destination is busy and does not wish to take the call right now. The destination should only send this response when it knows no other endpoint could accept the call; it may carry Retry-After with a better time to try.

The practical consequence is that a proxy that receives a 600 cancels its pending attempts and does not look for other routes. That is what sets it apart from SIP 486, which says “busy here” and leaves other routes open. On trunks, a 600 can also mean the concurrent channels are used up, when the carrier’s or the company’s SBC is configured to respond that way. A SIP 600 error is less common than a 486, which is why it is worth identifying the equipment that generated it.

Common causes in Brazil

• Concurrent channels used up on an SBC configured to respond 600 instead of 486, to keep the PBX from trying other routes.
• The concurrent-call limit per SIP account reached on a carrier trunk (Vivo, Claro, Algar, Embratel or another).
• A hosted contact-center platform or IVR that responds 600 when every seat is in use.
• A ring group with every extension busy, when the destination system decides none of them can answer.
• Intermediate equipment that turns a busy signal from another network into a 600 instead of passing the 486 along.

How to troubleshoot

1. Capture the call with sngrep and see who generated the 600 from the Via, Server and User-Agent headers in the response.
2. In Asterisk, Issabel or FreePBX, turn on pjsip set logger on (or sip set debug on in chan_sip) and look for Reason: Q.850;cause=17 and any Retry-After.
3. Run core show channels at the time of the failure to count the active calls and compare them with the route’s channel limit.
4. Check the log for whether the PBX tried another route after the response. If the overflow route was never used, the 600 may be why.
5. In 3CX, turn on verbose logging and check the Activity Log for the trunk that returned the 600.
6. Place the call through another trunk or from a mobile phone. If it completes, the problem is the route’s capacity, not the destination.

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) and the called number (B), in the format sent in the INVITE.
• The Call-ID and the full response line, such as SIP/2.0 600 Busy Everywhere.
• The Reason and Retry-After headers, if present.
• How many attempts failed, over what time window, and how many calls were active on the trunk.
• The pcap file of the capture, if you have one.

Frequently asked questions

Is a SIP 600 more serious than a 486?

Not necessarily. Both say the destination is busy. The difference is scope: a 486 applies only to that endpoint, while a 600 warns that no other endpoint will accept, so the proxy should not try other routes. If your PBX has an overflow route, a 600 can keep it from being used.

Which Q.850 cause goes with a SIP 600?

Under RFC 3398, a gateway that converts a SIP 600 for the phone network uses Q.850 cause 17 (User busy). In the other direction, cause 17 becomes a 486, not a 600. So a 600 that reaches your PBX was almost always generated by SIP equipment, not translated from a telephone exchange.

Does a real test call catch this code?

Yes. A real test call receives the final SIP response the network returns, including a 600. 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.