Skip to main content

Call Quality Network Troubleshooting

  • Updated

 

CALL QUALITY NETWORK TROUBLESHOOTING

This is an internal document to help the customer solve their own network problems.

Indications of call quality issues:

  • Likely Network related
    • Choppy calls
    • Dropped calls
    • Echo on calls
    • 3-second delays when talking
    • 1-way audio
    • The phone will not register/connect to SV
    • Phone not on the wifi network
    • Multiple phones affected

 

  • Likely Equipment-related
    • Static or crackling sounds
    • Cordless phone range issues
    • Won’t power on
    • Dead batteries
    • Sticky keys

 

Troubleshooting Steps – Network Related

  1. Verify voice traffic is using the primary circuit, and all phones at the site are on the same path. SimpleVoIP portalHover over phone count and view the IP addresses to see if they match. Check the router to determine if the IP is shown is primary or backup.
    1. If the site is on backup, determine why and update the customer/ticket that the phones are routing over a backup cellular connection, and quality may be degraded. Go to CELL BACKUP CHECK.
    2. If the site is on primary but phones are, inconsistent, go to FIX INCONSISTENT ROUTING.
    3. If location is on primary and phones are on primary, continue to #2.

  2. Look at the circuit history for packet loss (any amount if it’s consistent, or bursts) and high latency (above the historical average). Use data from the Meraki/another router. If available this is preferred over NPM for granularity.
    1. Packet Loss or high latency found?
      1. Open ticket with ISP
      2. Push voice only to cell backup, if available
  • When ISP is repaired, move voice back to primary

  1. Look at bandwidth utilization (including bursts) to see if QoS is an issue. Verify (or apply) a proper QoS policy for this site based on recently tested upload and download speeds. QoS policies are implemented differently by client and platform, however they will all involve bandwidth throttling at around 90% of available tested speeds in each direction. For example, if a site is tested at 10Mbps downstream x 2Mbps upstream, then the throttling should be set for the entire circuit at 9Mbps x 1.8Mbps.
    1. No QoS policy? Create a QoS policy.
    2. QoS policy exists but is not configured properly for the site? Update QoS policy.

  2. Wifi review/tuning
    1. Goal is to find the optimal AP between WAP1 and WAP2 in Meraki and set this as preferred by tweaking radio power and SSID Availability.
    2. Go to TUNE WIFI NETWORK.

  3. Registration issues
    1. Check the SV portal, go to the site and hover over the phones. Select the phone and click the icon. View the “Phone Alerts” tab for recent registrations (Yealink only) and look for activity. For all phones you will also see recent “CONFIG DOWNLOAD” events, indicating the phone is reaching out to our config server. If nothing there, the phone is not attempting to register. Go to NETWORK REVIEW.

 

TS Modules

 

FIX INCONSISTENT ROUTING

  1. Reboot each phone that is not on the correct network. Wait 2 minutes and check the SV Portal by clicking the green Refresh Status button while hovering over the site and then opening the popup again to see the updated IP registration information. If not fixed, continue.

  2. Clear NAT translations in the router. This can only be done by rebooting a Meraki. Wait until the network is back up and refresh the site status to check like in #1.

 

TUNE WIFI NETWORK

  1. In Meraki go to the wireless->Access Points and click on WAP1. Select each phone and click the pencil icon to change the label. Add the word HOST or BAR as appropriate by matching the LAN IP (not MAC). You can find the LAN IP in the SimpleVoIP portal by clicking “JSON” and it’s at the very bottom.
    • Are both phones connected at >25db? If yes, go to 3. If not, continue.

  2. In Meraki go to the wireless->Access Points and click on WAP2. Select each phone and click the pencil icon to change the label. Add the word HOST or BAR as appropriate by matching the LAN IP (not MAC). You can find the LAN IP in the SimpleVoIP portal by clicking “JSON” and it’s at the very bottom.
    • Are both phones connected at >25db?

  3. Click on each phone and check the event logs. An ideal environment will show each phone authenticating at around 2:20am daily and re-joining the same AP (not jumping around). If phones are moving around, do the following:
    1. Go to WirelessSSID Availability
    2. Select the Voice ssid and choose “this ssid is enabled on some APs…” and then select either WAP1 or WAP2 only where it says “select tags”
    3. If these tags do not exist you must edit the actual APs to add the tags and then come back here.
    4. Click save. Phones will move to this AP in a couple minutes. Check the signal strength. If both are above 25db you are done.
    5. If not, try the other WAP by going back and removing the tag for WAP1 and replacing it with WAP2. Wait for the phones to re-join the network and check the signal strength. If both are above 25db you are done. If not, move to D.

 

  1. If only 1 phone can get over 25db consistently, identify that phone and select the best AP for it. Then immediately open a PM ticket for a cable run at the other location.

  2. If you see a phone connecting to (Store example)_GUEST, replace the wifi dongle.

 

APPLY QOS TEMPLATE – DELAY

  1. Apply the XXXX template specifically for Comcast/delay issues

NETWORK REVIEW

  1. Verify phones are routing over the correct WAN and have full access to the internet.
  2. Verify phones are plugged into the correct switch port if the customer is utilizing VLANs
  3. Verify there are no duplex mismatches that may cause packet loss
  4. View PCAPs to watch the phones attempt to register. Often in the Meraki we will see a phone send traffic out but not receive anything back. A router reboot may fix this, as will checking the “New Port” button in the SV Portal for the phone on the Events popup and then click the reboot button. This will tell the phone to attempt to use a new port for RTP traffic the next time it reboots.

CELL BACKUP CHECK

  1. Check the cell backup for packet loss, excessive latency, availability, signal strength, etc
  2. If site should not be on cell backup, get them back on primary
  3. If site should be on cell backup now but not long term, create a mechanism to track this and get them back on primary later

 

Related articles