SIP response codes reference for wholesale VoIP

Every failed call in a wholesale network leaves a three-digit footprint: the SIP final response that ended it. Lesson 9 showed how to work the handful of codes you meet every day. This lesson is the reference you keep open next to the CDR screen: what each class of response means, the codes that matter in carrier traffic, how they map to telephone-network cause values, and — most important — whether the switch should try another vendor or stop.

How to read a response code

The first digit gives the class. The other two narrow it down. A device that receives a code it does not recognise is supposed to treat it like the x00 of the same class, so an unknown 499 behaves like 400.

Provisional responses (1xx)

• 100 Trying – the next hop received the INVITE. It stops retransmissions but says nothing about the far end. If you only ever get 100 and then silence, the problem is further down the chain.
• 180 Ringing – the called phone is alerting. Your switch usually plays its own ringback tone to the caller.
• 183 Session Progress – carries SDP so the caller can hear early media: real ringback, an announcement, or a recorded message. Many routes send 183 instead of 180. A long early-media phase followed by a 200 OK with no ringing is one of the signatures of false answer supervision.

The 4xx codes that matter

The 5xx and 6xx codes

SIP codes and Q.850 cause values

Calls that leave the IP world and enter a mobile or fixed network are cleared with a numeric cause value (from the ITU-T Q.850 list). Gateways translate between the two, and many vendors add the original cause in a Reason header, for example Reason: Q.850;cause=17. That header is often more honest than the SIP code itself.

Exact mappings differ between vendors. Learn each partner’s habits and write them down.

Fail over or stop? A decision guide

Every failure code is a routing decision. Retry the wrong ones and you add seconds of post-dial delay, pay for useless attempts and annoy subscribers who are simply busy. Retry too few and you lose calls a second vendor could have completed.

Practical rules most carriers end up with:

1. Never fail over on 486, 487 or 6xx. The answer would be the same on any route.
2. Usually stop on 404, 410 and 484. The number is wrong. Exception: if one vendor returns 404 for a range that others complete, that vendor simply lacks the route — fail over and ticket them.
3. Fail over on 5xx. These describe the vendor, not the subscriber.
4. Treat 480 and 403 per vendor. Some vendors use them honestly, others to mean “no capacity”. Decide based on evidence from your CDRs.
5. Cap the attempts. Two or three vendors per call and an overall time budget (for example 15–20 seconds) keep PDD under control.
6. Return a clean code to the customer. If every vendor failed, pass back the most meaningful code (often the last one, or a 503) rather than a confusing internal one.

Reading codes as a pattern

A single code tells you about one call; the mix tells you about a route. A short report of final codes per vendor and destination for the last hour often finds problems before KPIs move. For example, with invented numbers:

Vendor X → Country Z mobile, last 60 min, 1,200 attempts
  200 OK ............ 492  (41%)
  486 Busy .......... 118  (10%)
  487 Cancelled ..... 230  (19%)
  480 Unavailable ...  96  ( 8%)
  503 Unavailable ... 264  (22%)   ← normally under 2%

Busy and cancelled shares look normal for mobiles; the 503 share is not. That points to a capacity limit or a fault at Vendor X, not to the destination.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.