VoxMost NOC tickets fall into a small number of categories: calls that fail, calls with missing or one-way audio, and calls that connect with poor quality. This lesson gives you a structured way to troubleshoot each one, explains the SIP response codes you will see most often, and shows how to work through a codec mismatch. Addresses and names are examples only.
A troubleshooting method that works
- Get specifics. Ask for example calls: time with timezone, dialled number (can be partly masked), caller ID used, and what the user experienced.
- Find the calls in the CDRs. Which customer gateway, which vendor gateway, what end reason or response code, how long?
- Check scope. One customer or all? One destination or many? One vendor or every vendor? Scope often reveals the cause faster than any trace.
- Look at signalling. Capture or retrieve the SIP trace for an example call.
- Look at media if the problem is audio: are RTP packets flowing in both directions, to the right addresses?
- Fix, re-test and document. Keep notes so the next person can solve a similar ticket faster.
SIP response codes you will see often
| Code | Meaning | Typical causes in wholesale |
|---|---|---|
| 403 Forbidden | Request refused | Source IP not whitelisted, account blocked or out of balance, destination not allowed |
| 404 Not Found | Number does not exist / no route | Invalid number, wrong number format or tech prefix, no route for prefix |
| 480 Temporarily Unavailable | Callee not reachable now | Phone off or out of coverage; sometimes used by vendors for “no capacity” |
| 486 Busy Here | Callee busy | Genuine busy subscriber — normally should not be retried on another route |
| 487 Request Terminated | Call cancelled | Caller hung up before answer (CANCEL) |
| 488 Not Acceptable Here | Media not acceptable | No common codec, unsupported SDP |
| 500 Server Internal Error | Server failure | Fault on the remote platform |
| 503 Service Unavailable | Server cannot handle the call | Vendor overloaded, capacity limit reached, route down; candidate for failover |
Vendors do not always use codes exactly as the standards intend, so learn the habits of each partner and build your failover rules accordingly.
Working a 403
If a customer reports 403 on every call, check in this order: is their source IP the one configured on the mapping gateway; is the account active with balance or credit; have they reached a concurrent-call limit; is the dialled prefix in their rate group? If only some destinations fail, a missing rate or a blocked destination is more likely.
Working a 404
Compare the number the customer sent with what you sent to the vendor. A tech prefix not stripped, a missing country code, or an extra leading zero are the usual suspects. If the format is right, ask the vendor whether they have a route for that range.
Working 480 and 503 bursts
A sudden wave of 480 or 503 from one vendor usually means a capacity or network problem on their side. Confirm the scope, fail over traffic if you can, and open a ticket with example Call-IDs and times.
No audio and one-way audio
Signalling can succeed perfectly while audio fails, because RTP travels separately from SIP. The most common cause is NAT or firewall configuration.
Checklist
- Check the
c=line in the SDP from each side. A private address (10.x, 172.16–31.x, 192.168.x) from a device on the internet is a red flag. - Enable NAT handling on the switch for that gateway (send media back to the source address of received packets), or relay media through the switch.
- Ask the customer to configure their device’s external address, and to disable SIP “helpers” (SIP ALG) on their router, which often rewrite packets incorrectly.
- Make sure firewalls allow the RTP port range in both directions.
- If audio stops after a fixed time (for example around 30 seconds), check for missing ACKs or session timers — often also NAT-related.
Codec mismatch
When the two sides share no codec, the call fails with 488, or sometimes connects without audio if a device ignores the negotiation. To troubleshoot:
- Read the codec list (
m=line andrtpmapentries) in the INVITE’s SDP. - Read what the vendor answered, or what error it returned.
- Compare with the codecs configured on the mapping and routing gateways.
- Fix by allowing a common codec on both legs, or enable transcoding on the switch if capacity allows.
Also check the DTMF method (RFC 2833/4733 telephone-events versus in-band). A mismatch there causes IVR menus to ignore key presses even though voice works.
Poor quality on connected calls
- Check packet loss, jitter and MOS per route (see Lesson 6). If only one vendor is affected, it is probably their path.
- Check your own server: CPU, network interface errors and bandwidth at the time of the complaint.
- Listen to a recording to describe the problem accurately: choppy, robotic, echo, low volume.
- Compare busy-hour and quiet-hour quality; congestion shows up at peaks.
Writing a good ticket to a vendor
- Clear description: “one-way audio, caller cannot hear callee”, or “503 on all calls to Country Z since 14:05 GMT+8”.
- Three to five example calls with time, Call-ID and masked numbers.
- What you have already checked and ruled out.
- SIP traces or recordings as attachments where relevant.
Good tickets get faster answers. Tools such as VoxInspector provide SIP ladder traces and decoded recordings that you can attach directly.
Key takeaways
- Start with specific example calls and the scope of the problem.
- 403 often means IP, balance or permission issues; 404 often means number format or no route.
- 480 and 503 bursts usually point to vendor capacity or network problems.
- One-way audio is usually NAT: private addresses in SDP, SIP ALG or blocked RTP ports.
- Codec mismatches cause 488 or silent calls; check SDP on both legs and the DTMF method.
Quick quiz
1. A customer gets 403 on every call. Name two things to check first.
That their source IP matches the mapping gateway, and that the account is active with balance/credit (also call limits and rates).
2. What SDP clue points to a NAT problem?
A private IP address (e.g. 10.x, 192.168.x) in the c= line from a device on the internet.
3. Which response code typically indicates no common codec?
488 Not Acceptable Here.
Related reading
- How to check VoIP route quality: ASR, ACD, PDD, MOS and packet loss (blog)
- VoxInspector – VoIP monitoring, FAS detection and route testing for VOS3000
- All training lessons · VoxComms home
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.