Cisco Meraki
Table of Contents
Current Status Suggestions Comments Meraki VoIP Best Practices How do I configure the MX? Troubleshooting Audio only goes one way. Poor audio quality Phones can't get an IP address/configuration. Additional ResourcesCurrent Status
Compatible
Suggestions
None
Comments
Meraki VoIP Best Practices
Generally speaking, it is best to stick to the following best practices when deploying a Hosted Voice system on any network:
-
Segregate voice traffic to its own VLAN.
Voice traffic tends to come in large amounts of two-way UDP communication. Since there is no overhead on UDP traffic ensuring delivery, voice traffic is extremely susceptible to bandwidth limitations, clogged links, or even just non-voice traffic on the same line. Separating out your voice traffic allows it to function independently of other network traffic, and allows for more granular control over different types of traffic.
-
Use traffic shaping to offer voice traffic the necessary bandwidth.
Due to the relatively large amounts of data that voice uses on the network, it is important to ensure that your voice traffic has enough bandwidth to operate. As such, traffic shaping rules can be implemented to allow voice traffic to use additional bandwidth, or even limit other types of traffic to help out voice.
-
Use Quality of Service to maintain prioritization.
Many devices support Quality of Service (QoS) tags to maintain traffic priority across the network. It may be beneficial to tag your voice traffic with the appropriate tags, so it can be prioritized anywhere in the network in case of a saturated link.
-
Understand firewall and NAT configurations.
In Hosted Voice, there will typically be two types of flows: bidirectional communication from phones to the Private Branch Exchange (PBX) and bidirectional communication directly between phone peers. As such, it is highly important to understand the expected flow of traffic and ensure that all firewalls have been configured accordingly.
Furthermore, it is important to understand if traffic will pass through some form of NAT and, if so, what type of NAT is in use. The network's options and limitations may make certain configuration types infeasible.
-
Avoid sending Hosted Voice traffic over non-optimized links
As discussed above, Hosted Voice traffic is extremely sensitive to fluctuations in data transmission. As such, plan voice deployments to avoid sending Hosted Voice traffic over links with limited bandwidth/environmental factors (wireless mesh), or over the WAN (lack of control, much more potential for failure).
How do I configure the MX?
Many requirements/questions may be presented about the network.
-
Can Application-Level Gateway be enabled on the MX?
ALG is a technology that allows stateful firewalls to dynamically assign ports and broker communication through a NAT. The MX security appliance is a full-featured stateful firewall that does not have any ALG functionality.
-
Can the UDP timeout value be changed?
The MX does have a simple UDP timer function, which will drop a traffic flow after an extended period of inactivity. This timer cannot currently be changed. However, a timeout would require both peers to be completely silent for an extended period of time in order to take effect. For example, UDP communication between peers on an active call is highly unlikely to be dropped due to a timeout.
-
How are inbound connections handled?
The MX is a stateful firewall, so most inbound communication will only be allowed as a response to an established outbound conversation. Inbound communication can be explicitly allowed by means of port forwarding or 1:1 NAT/1:Many NAT rules, whereby a specific internal device is associated with a public port/IP.
For more information on port forwarding and NAT rules on the MX, please refer to the following articles:
Troubleshooting
The following section outlines some common Hosted Voice issues that may arise, and some recommended troubleshooting steps to narrow down the issue.
Audio only goes one way.
Consider that voice communication typically happens as two simultaneous UDP streams, one for each direction of communication. These are two separate streams, as opposed to a single two-way stream. If communication in one direction does not reach the peer, then the symptom is that only one party can hear the other's audio.
To address this issue, check the following:
- Trace the traffic flow, and check any firewalls to ensure they are not blocking traffic.
- If a stateful firewall like the MX is passing traffic between the two peers, ensure appropriate mechanisms are in place to allow inbound communication (1:1 NAT, port forwarding, etc.).
- If it's unclear exactly where the traffic is being dropped, determine based on the symptoms which direction of traffic seems to be failing, and take packet captures at network hops to see where the flow stops.
Poor audio quality
Due to the sensitive nature of VoIP traffic, low voice quality (or "jitter") may be experienced due to interruptions in traffic flow or bandwidth limitations.
To improve voice quality, ensure that the following best practices are in place:
- Ensure voice traffic is segregated to its voice VLAN, so normal data cannot interfere.
- Check the network's bandwidth limitations and ensure there's enough bandwidth (as recommended/required by the voice system).
- In the event that a link on the network is saturated, use traffic shaping/QoS where necessary.
- Take packet captures to get an idea of call quality and where it is degraded. Many capture analysis tools, including Wireshark, can perform RTP analysis.
Take note of the "symptoms" exhibited in a poor-quality phone call. Specific traits of the call can help narrow down the issue. Please refer to this Cisco guide for a breakdown of different call quality symptoms.
Phones can't get an IP address/configuration.
Typically, Hosted Voice equipment will get a dynamic configuration from a TFTP server or other service on the network. A DHCP server will commonly levy this, where leases to Hosted Voice endpoints will include voice-specific DHCP options. In the event that the phone fails to connect to the network/get a working configuration, consider the following recommended steps:
- If a separate voice VLAN is being used, ensure that phones are being put on the appropriate VLAN by means of an access port, voice VLAN configuration on the port, or even configured on the phone itself.
- If this is being done, ensure that a DHCP server is up and running on that VLAN and configured with the appropriate scope and options.
- If phones have a working IP configuration on the network (or a static assignment is given for test purposes) and are told to get their VoIP configuration from another server, ensure that the server is online and reachable from the voice VLAN.
Additional Resources
The following Cisco articles provide additional information not covered in this article, and may be helpful as a reference: