Troubleshooting VoIP on Cisco Meraki Networks
Overview
Voice over IP (VoIP) is a common technology used in enterprise networks, allowing users to make internal and outbound phone calls over the network. This article answers frequently asked questions about VoIP systems and technologies on Cisco Meraki networks and provides general troubleshooting tips.
Deploying VoIP with Cisco Meraki equipment
Cisco Meraki equipment is designed with network standards in mind, so VoIP deployments can typically run alongside the network stack without issues.
MX WAN appliance
The MX security appliance functions as a standard stateful firewall. If the MX is configured as the network's inter-VLAN router, configure a dedicated voice VLAN for VoIP traffic.
- If the MX performs inter-VLAN routing, configure a dedicated voice VLAN for VoIP traffic.
- If the MX has multiple uplinks, or if those uplinks are aggregated, configure voice traffic to use a specific interface. Configure this under Security appliance > Configure > Traffic shaping using uplink preferences.
- Configure traffic shaping rules to prioritize voice traffic above other traffic types.
- If the MX provides DHCP services and network phones support dynamic configuration options, configure VoIP-specific DHCP options on the MX.
For additional reading on relevant MX configuration and features:
MS switch
Cisco Meraki MS switches are standards-based switches designed for the access and distribution layers of the network.
- At the access layer, configure access switchports with a voice VLAN.
- The MS uses Link Layer Discovery Protocol (LLDP) to advertise the voice VLAN ID to connected phones.
This configuration may not work for all VoIP hardware. The optimal access layer configuration depends on the specific phone in use. Refer to the phone manufacturer's documentation for the recommended configuration.
- If a Layer 3 MS switch performs inter-VLAN routing, configure the dedicated voice VLAN on that switch.
For additional reading on relevant MS configuration and features:
MR access point
If wireless voice infrastructure is needed, take additional steps during wireless deployment to ensure a stable roaming environment.
- Conduct a wireless site survey to ensure ideal placement and configuration of access points, enabling a clean RF environment for wireless phones to roam.
- If the voice SSID uses enterprise IEEE 802.1X authentication and the wireless phone hardware supports fast roaming, enable 802.11r on the MR access points to improve roaming times between access points.
-
For additional reading on relevant MR configuration and features:
VoIP best practices
Follow these best practices when deploying a VoIP system:
- Segregate voice traffic to its own VLAN.
Voice traffic consists of large amounts of two-way UDP communication. Because UDP carries no delivery guarantee, bandwidth limitations, congested links, and non-voice traffic can all disrupt voice traffic. Separating voice traffic allows it to function independently and enables more granular traffic control.
- Use traffic shaping to allocate sufficient bandwidth.
Voice traffic uses a relatively large amount of network bandwidth. Implement traffic shaping rules to allocate additional bandwidth to voice traffic or to limit other traffic types as needed.
- Use Quality of Service (QoS) to maintain prioritization.
Many devices support QoS tags to maintain traffic priority across the network. Tag voice traffic with the appropriate QoS values so the network can prioritize voice traffic anywhere during link saturation. For more information on QoS: see MS Quality of Service Defined
- Understand firewall and NAT configurations
VoIP typically involves two types of traffic flows:
- Bidirectional communication between phones and the Private Branch Exchange (PBX)
- Bidirectional communication directly between phone peers
Specifics depend on the phone vendor and deployment preferences. Ensure all firewalls are configured according to the expected traffic flow. Determine whether traffic passes through NAT and what type of NAT is in use, as some configuration types may not work depending on your network options and limitations.
- Avoid sending VoIP traffic over non-optimized links
As discussed above, VoIP traffic is extremely sensitive to fluctuations in data transmission. As such, plan voice deployments to avoid sending VoIP traffic over links with limited bandwidth/environmental factors (wireless mesh), or over the WAN (lack of control, much more potential for failure).
Configuring the MX for voice provider requirements
If using an external voice provider, a number of requirements/questions may be presented about the network. The following questions are commonly posed by voice providers regarding network capabilities:
- Can Application-Level Gateway be enabled on the MX?
Application-Level Gateway (ALG) is a technology that allows stateful firewalls to dynamically assign ports and broker communication through a NAT.
The MX is a full-featured stateful firewall that does not include ALG functionality. Depending on the PBX in use, communication can be established without requiring ALG. Refer to your PBX documentation for NAT handling options.
- Can the UDP timeout value be changed?
The MX includes a UDP timer function that drops a traffic flow after an extended period of inactivity. This timer cannot currently be changed.
A timeout only occurs if both peers remain completely silent for an extended period. UDP communication between peers on an active call is unlikely to trigger a timeout.
- How are inbound connections handled?
The MX is a stateful firewall. Most inbound communication is only allowed as a response to an established outbound connection.
Inbound communication can be explicitly allowed using:
- Port forwarding rules
- 1:1 NAT or 1:Many NAT rules, which associate a specific internal device with a public port or IP address
When planning a VoIP solution, identify which party initiates each communication flow:
- If an internal phone initiates a connection to an external PBX, the stateful firewall allows the PBX's response back into the network.
- If an external PBX attempts to initiate a connection to an internal phone, the MX blocks the connection unless a port forwarding or NAT rule explicitly allows it.
For more information on port forwarding and NAT rules on the MX, refer to:
Troubleshooting audio issues
The following section outlines some common VoIP issues that may arise, and some recommended troubleshooting steps to narrow down the issue.
Audio only goes one way
Voice communication typically occurs as two simultaneous UDP streams, one for each direction. The two UDP streams are separate, not a single bidirectional stream. If communication in one direction does not reach the peer, the result is that only one party can hear the other's audio.
Troubleshooting steps
- Trace the flow of traffic and check all firewalls to confirm they are not blocking traffic in either direction.
- If a stateful firewall such as the MX is passing traffic between the two peers, verify that you have configured appropriate inbound communication mechanisms (1:1 NAT, port forwarding, or similar).
- If the point of packet loss is unclear, determine which direction of traffic appears to be failing based on symptoms, then take packet captures
- at each network hop to identify where the flow stops.
- If the PBX requires ALG and traffic passes through an MX, the MX may drop traffic in one direction. Refer to the PBX-specific documentation for NAT handling options that do not require ALG.
Poor audio quality
VoIP traffic is sensitive to interruptions, so low voice quality or jitter may occur due to traffic flow interruptions or bandwidth limitations.
Troubleshooting steps
- Verify that you have segregated voice traffic to a dedicated voice VLAN so normal data traffic cannot interfere.
- Check the network's bandwidth limitations and confirm that available bandwidth meets the requirements of the voice system.
- Apply traffic shaping and QoS where needed to address link saturation.
- Take packet captures to assess call quality and identify where degradation occurs. Tools such as Wireshark support RTP analysis for this purpose.
- Use distinct call characteristics to help narrow down the root cause. Refer to Recognizing and Categorizing Symptoms of Voice Quality Problems for a breakdown of different call quality symptoms.
Troubleshooting phones can't get an IP address or configuration
VoIP equipment typically receives a dynamic configuration from a TFTP server or similar service. A DHCP server commonly delivers this configuration via leases that include voice-specific DHCP options. If a phone fails to connect to the network or obtain a working configuration, follow the steps below.
Troubleshooting steps
- If a separate voice VLAN is in use, confirm that phones are assigned to the correct VLAN through one of the following methods:
- Access port configuration
- Voice VLAN configuration on the port
- A configuration set directly on the phone
- Confirm that a DHCP server is running on the voice VLAN and is configured with the appropriate scope and VoIP-specific DHCP options.
- If phones have a working IP configuration on the network, or if a static IP is assigned for testing purposes, and the phones retrieve VoIP configuration from a separate server, confirm that the server is online and reachable from the voice VLAN.
Additional resources
The following articles provide additional information beyond the scope of this article:
- Cisco Meraki VoIP Deployment Guide
- Compatibility with Cisco 7925G VoIP Phone
- Verifying Voice and Data VLAN Tags