This article comes to you from one of our Technical Support Representatives, Mike Dichazi, and is going to touch upon a couple of basic VoIP issues that VoIP Innovations sees on a daily basis. Two of the topics that Mike will discuss in this post are how to identify VoIP audio issues as well as some common e911 errors you might encounter. Take it away, Mike!
First off, I will start with how to notice audio issues and how you will need to go about resolving them. As a customer, one of your clients may inform you that they are experiencing dead air, one way audio, or no audio at all. Below are some tips that you could use to possibly resolve these issues yourself.
The primary tool VoIP Innovations uses to troubleshoot audio issues is Wireshark. Please visit our Wiki article on this subject for more information on how to use this program.
After downloading Wireshark, capture a call and open it up. First, you will want to check to see if your firewall is blocking any of our carriers’ media gateway IP addresses. This is because VoIP Innovations does not proxy the audio of calls – it’s exchanged directly between you and our underlying carriers. The audio port range you will want to have opened on your switch would be UDP ports 10,000 to 20,000. As long as your equipment is configured to send and receive audio on the agreed upon ports, you should be fine. Next, you will want to check your trunk configuration for the types of codecs you allow. We recommend G.729, G.711 (ULAW and ALAW), and RFC 2833 for DTMF.
For outbound calls, you may offer as many of these codecs as you would like, but for inbound calls, we recommend only accepting one audio codec to prevent any possible codec mismatches. A codec mismatch is easily identified in Wireshark. An example of this would be our carrier sending audio in G.729 while your switch is sending audio back to them in G.711u. If this were to occur, neither side would be able to hear the other.
Another thing you will want to check is the ptime. The most common ptime value is 20. If a ptime of 20 is agreed upon, but your switch sends RTP packets in a ptime of 10, then the call will experience audio problems. You can check what the actual ptime is going to be by capturing a call in Wireshark, filtering a call down to only RTP, and subtracting the timestamp of the packets. In the example below, when you subtract the timestamp of two packets we receive 160, which in return equals a ptime of 20. If the difference in the timestamp is 80, this would be a ptime of 10.
You will also want to make sure that you are not requesting audio on an internal IP address. You can check this by opening a capture of your call and looking at the packet for your INVITE to VoIP Innovations on an outbound call or your 200 OK on an inbound call. Expand Session Initiation Protocol > Message Body > Connection Information. If this contains a private IP such as 192.168.1.1, the call will likely exhibit one-way audio. Since audio is sent over the public internet, you will need to ensure that you request audio on a public IP address to ensure that it is delivered correctly.
If you are still unable to determine the cause of your audio issue, you are welcome to send your capture to VoIP Innovations via a ticket attachment or e-mail. For best results, we recommend filtering the capture down to a single affected call, and it should only contain the relevant SIP and RTP streams.
Another common issue customers may run into is provisioning e911 for their DIDs. There are two common errors that you will encounter:
- This location could not be geocoded
- URI locked / LockedException
First you will want to navigate in the back office to E911 > Add New DID. If after you fill in all the required fields and are still receiving an error such as “location could not be geocoded”, you can check melissadata.com and use their address lookup tool.
Once on the site, click on the “Lookups” tab and then you will see “Address Check” on the left hand side. Next, you will want to input the address in the text box to check to see if the address has been verified. Common errors are entering “drive” when it should be “Dr.” and so on. After taking the address from melissadata.com and entering it into the VI BackOffice exactly as it appeared, open a ticket with support if you are still receiving this error.
If you receive a URI locked error, this typically happens when a DID is newly ported into VI. When you receive this error, you will want to allow at least 48 hours for the losing carrier to remove the old 911 information. If you have a business relationship with the losing carrier, you may reach out to them to have them release this information quicker than waiting the 48 hours. After the 48 hours have passed and you are still receiving this error, you may open up a ticket with VI Support for further assistance.
Hopefully this article helped you identify some of the common VoIP issues you might encounter as well as some ways that will help resolve these types of issues for the future. Technical Support is always here to help so don’t hesitate to ask!