As a VoIP professional with many years experience, I have come across just about every problem and error imaginable in the wholesale VoIP market – some more common than others. In this article, I’m going to share with you some of the more common problems I’ve encountered and how to fix them.
This one is very common. Time and again I have seen a new interconnect having issues with authentication. What makes the problem more difficult is upstream carriers often have limited information available. What we have to remember is, that if you are not authenticated, you will get a ‘401 unauthorized’ message back.The problem is, until you are authorised, your traffic will belong to that less desirable group of traffic – ‘the unauthenticated’.
Make sure that if you are performing an interconnect and have problems, you can see, and identify, if the call is authenticated or not. Be aware of when your switch sends 401s, if you don’t, you won’ know whether the traffic is hitting your switch, or even worse, your client will tell you that they are getting 401s and you will say “well I don’t see traffic here!”
After authentication and authorization, the second most common problem is incorrect routing. If your customer complains that their calls are not working, you need to be able to take control.
You can too and fro with your customer, but it is a much better experience for them if you identify the problematic call. If it’s not obvious from the logs, instantly pull up an always-on SIP trace, identify the root cause and once you believe you have a fix in place, run a simulation to confirm it works before informing your customer it’s been resolved.
Rate cards are easy, right? Yes, in theory looking at a rate card is pretty simple, but what about more expensive, longer prefixes – how do you handle them? And, what about the knotty issue that is Interstate and Intrastate billing, or even add a bit of LRN on top of that? It can quickly get confusing!
Make sure that you understand your product, if you don’t know what NPA-NXX, on-net / off-net or LRN stand for, or how they work, find out. However, there’s no need to worry, as I will be writing an article about this soon.
When is a 404, not a 404? When it is implemented incorrectly. Maybe I’m being a bit too harsh, after all we still have to deal with POTS and SS7. It is forgivable, that errors in translation can incur, however, not knowing your SIP codes is inexcusable.
You should fail 404s ONLY when the underlying terminating carrier returns it. If your switch decides to return a 404 code because your customer has ran out of credit, you have set-up your switch incorrectly.
Do you know the difference between a 408 and a 487? Both take place before the call is connected, but a 487 occurs when a CANCEL command is sent.
100 Trying code: these are normal and part of every call. If they weren’t, then something is wrong. If your switch is not able to provide you with detailed error information, then you will need to identify and resolve the problem for yourself.
Some PBXs insert extra headers to help provide a more informative response. These are a great idea if you wish to convey more information and fix errors quicker.
Some switches route the calls by the To header rather than the URI. This is something to be aware of incase the two ever accidentally differ. It’s a good idea to keep both of these consistent.
Human error plays a big part in common wholesale VoIP problems and can often delay solving issues.
“My call’s not going through”- what you actually mean is: “my call is unable to complete because I am getting a 404 back, I have checked the number my side from an independent route and I can confirm that this number 1900654321 is valid”.
If this error gets reported to you, do your due diligence. Make sure you have a way to confirm the error, whether that be a HLR, a Number Ping or an independent route. If you have the capabilities of performing an instant search for the number don’t ask for dates and times, unless there are duplicates and you need to isolate one to solve the issue – help the customer out.
Once the problem is resolved, tell the customer is it solved, don’t just say “dial now”. It is always reassuring to let the customer know what caused the error and how you resolved it, because it keeps them involved and informed. Furthermore, it is best practice to put measures in place to stop the same error happening again.