Once again, we're handing over the blog to Tim Klein, a Technical Service Representative II here at VoIP Innovations. He works on the front lines assisting our customers and knows all about finding solutions. Let's hear it from Tim!
There are many problems that can arise in the VoIP world that cause issues for end users. This blog post will touch upon six of the more common issues that MSPs may encounter.
In Technical Support, we receive a wide variety of calls from our customers who are seeking help in resolving issues for their customers. One of the most common issues we deal with are audio issues. Our customers call in reporting no audio, one-way audio, static, jitter, etc. There are several reasons this can occur, so the first thing we like to do is to get a Wireshark Packet Capture from the customer with the SIP/RTP streams.
Customers can download Wireshark on their equipment, as it is a free packet analyzer, and it is very powerful in assisting these types of issues. This will allow us to see the traffic being sent to/from the customer from their network’s perspective. This will show the packets being sent across the public internet to their network and before it traverses through any equipment (SBC, Firewall, Router, etc.) on the customer’s side.
If it appears to possibly be an issue with one of our Underlying Carriers (ULCs), then we will open a ticket with them asking to investigate the call example and packet capture to see if they are aware of any issues. Now, just because we can confirm via the customer’s packet capture that there is an issue with one of our ULCs, it does not necessarily mean such. Our ULC may be sending out the audio cleanly to its peering partner, but when the packets reach the customer the problem is present. If it appears that the ULC is sending out the media cleanly, then this can be an issue on the public internet itself. Major packet loss or latency over a backbone network could be the cause of audio issues. We would then ask the customer to reach out to its ISP to see if they are aware of any issues.
Calls Not Completing
Customers will also call in about their inbound/outbound calls not completing. If this is an outbound call from their network, the first thing we ask for are call examples so we can verify the reported issue. If the calls are not in our CDRs, doing a live call test would help us determine if the calls are even reaching us.
If the problem is inbound to the customer’s DIDs we would troubleshoot this the same way as above. We would check our CDRs to see if the calls are reaching our network from the carrier, and we would also set up live testing. If we can confirm the issue is with our carrier, then we will escalate to them for investigation.
Many MSPs offer T38 faxing for their customers. Our Efax service allows end users to create emails that get converted to a fax or receive a fax that gets converted to an email. If a customer is using our Efax service and they are reporting issues, we can pull the packet captures from our servers for investigation. Sometimes T38 faxing can fail for several reasons so I will list some of the common ones.
- End user’s SPF record not set up correctly
When customers send us an Efax our server will do an SPF (Sender Policy Framework) to check on the email address to ensure the email is legitimate. If the fax failed due to an improperly configured SPF, then we can see these logs in our fax server. We can also double check third party sites such as mxtoolbox.com, and Kitterman.com to check the SPF record listing they are pulling. If we can confirm the faxes failed due to the SPF being wrong, then we can bring this to the attention of the MSP who then can relay this back to the admin that is responsible for the MX server.
- Customer may report not receiving inbound faxes
We can troubleshoot the same way as above and grab the appropriate Wireshark packet captures. If we can confirm via the packet capture that the fax completed successfully, we can then SSH into our Mail Servers to ensure we sent out the emails. If the Mail Servers show a successful handoff to the receiving MX Relay (SMTP 250), then the issue would reside with the receiving Mail Server. We can always provide logs of this handoff to the customer so they can forward it off to the appropriate parties if need be.
MSPs may reach out to us in regards to Abnormal Disconnects. This generally means the call disconnected without the Originating/Terminating parties ending the call. If that is the case, we can look in our CDRs to see where the Disconnect came from. If the disconnect came from our ULC, then we will escalate to them and have them investigate to determine if the call was indeed an Abnormal Disconnect, or if the call ended with an RCC 16 (SS7 log for Normal Call Clearing). If that is the case (RCC 16), then the originating party would want to open a ticket with its Provider to see why they ended the call. If the disconnect came from the MSP’s equipment, then they would want to search their switch logs to determine why it ended the call.
Translations happen when a number moves (ports) from one carrier to another, but the losing carrier does not remove all routing from their equipment for the TN. For example, a number might move from Comcast to Level 3, but Comcast may not remove all the routing from their equipment. Once the port is complete, calls originating from Comcast numbers may get routed to the wrong destination. This is because Comcast’s equipment is initiating the call, but when they send the call out, the call is being directed back to an old piece of equipment on Comcast that used to have the TN provisioned. If we can confirm this is the issue, we would then reach out to the gaining ULC and ask them to work with the Losing Service Provider (LSP) to ensure all residual translations have been removed from the LSP’s equipment.
Customers may call in reporting outbound CNAM (Caller ID) issues. If the CNAM Storage was updated in our BackOffice, then we would see when this was applied as all new/updated CNAM entries take up to 72 business hours to propagate to the National Database. If the Entry is past this window, we would then log into our CNAM provider’s portal to ensure the correct entry is on file.
If we can confirm the information has been successfully pushed to our vendor, we then check our own Dip vendor and verify if they are displaying the correct information. If both our CNAM Storage vendor and CNAM Dip vendor (which are separate entities) verify the correct information, then the customer would need to contact the receiving phone company doing the dip as it is up to the receiving LEC of the call to properly display this. We are able to test this internally.