Home > Communications > MC Network Administrator Guides > Other Topics > Ensuring VoIP Readiness

Ensuring VoIP Readiness



The Cisco Meraki line of cloud based VoIP phones is designed to require minimal intervention from the end user and network administrators which has been a consistent theme across each Cisco Meraki product family. While the majority of MC installations will result in good voice quality regardless of what preparation has been undertaken for voice traffic, voice traffic poses a different set of challenges than other types of non-realtime traffic such as web browsing and email. Voice IP packets must be transmitted and received in order from point A to point B every single time to ensure a voice conversation is comprehensible for all involved parties. If voice packets arrive at the destination out of order, artifacts and drops in audio can be introduced to the audio stream resulting in a poor experience for everyone on that call.


The Network Mean Opinion Score (MOS) is the network’s impact on the listening quality of a VoIP conversation. The score ranges from 1 to 5, with 1 being the poorest quality and 5 being the highest quality and has historically been judged subjectively by end users of telephones. Many customer sites will require initial LAN/WAN planning and configuration to ensure voice call traversing these networks experience a high MOS.

Bandwidth planning considerations 


One of the benefits of the Meraki MC solution is it's ability to operate on top of existing public Internet uplinks in an over the top (OTT) fashion. While this poses both a significant monetary cost saving in addition to a reduction in administrative overhead, ISPs providing commercial public internet links will generally select paths to a destination based on the lowest monetary cost.


Before VoIP services leveraging the public internet are installed at the customer site, network administrators can improve chances of success by completing simple bandwidth calculations. Given that calls will be traversing the public internet to reach both the Cisco Meraki signaling servers and upstream SIP provider media servers, bandwidth calculations can safeguard against a lack of Internet bandwidth for mission critical voice traffic.


There are two call flows that must be accounted for when completing these bandwidth calculations: internal handset to handset calls and internal handset to external Public Switched Telephone Network (PSTN)  calls. The amount of concurrent external outbound and inbound voice calls that will be active during any period will depend on the user base size in addition to their reliance on phone calls to conduct business. For a typical VoIP deployment at an office of 20 active handsets, typically a ratio of 2:1 users per SIP trunk is viable. Meraki's easy onboarding providers within dashboard have varied levels of coverage for concurrent calls which are explained in this set of KB articles


The VOIP industry standard codec for external calls is G711 which utilizes approximately 90Kbps of bandwidth per voice stream. Basic calculations can be conducted in order to ensure enough bandwidth will be dedicated to voice traffic at any one time:


eg. 10 * 90Kbps = 900Kbps


Hence a minimum of 900Kbps must be available to service voice calls at any one time. Depending on what type of routing infrastructure is installed on-site, it might be possible to place voice traffic in a higher priority outbound queue. It would be worthwhile undertaking a routing equipment audit with onsite I.T. staff to establish what traffic shaping capability is possible with current equipment. If no such equipment is installed, it would be extremely beneficial to the end result of the project to include a routing device with such capabilities (eg. Cisco Meraki MX Security Appliance) in the final bill of materials.


As a general rule of thumb, the following best practices should be adhered to when determining whether an uplink is suitable for voice traffic:

  •  Traffic utilizing a shared internet link should never account for more than ~75% of all traffic on that shared link. 
  • Jitter should not exceed 20ms
  • Latency should not exceed 150ms
  • Packet loss should not exceed 1%


Note that aside from voice traffic, the Meraki MC also requires periodic firmware updates from the cloud that require firmware downloads. This can be a problem when encountering slow network links. We highly recommend you leave enough overhead on your internet connection to allow for all of your phones to download several hundred megabyte downloads when updates occur.

LAN planning (ports, PoE, speed, etc) 


MC phones are fitted with a two port ethernet bridge to only require one network wall port and switch port for both the users PC and phone. Gigabit switches with a high aggregate bandwidth on the back plane will ensure that sufficient bandwidth is supplied for both local and SIP provider voice calls


As a contingency against periods of high bandwidth utilization between devices on a LAN (ie. backups, file replication etc.), switching equipment should be configured with layer 2 and 3 QoS mechanisms to prioritise voice traffic. In the event that the current switch infrastructure does not support QoS and issues are reported, recommendations should be made to upgrade switching hardware. 

Unsupported Firewall Features


Cloud based VoIP poses unique challenges to current firewall implementations in that many of the NAT traversal techniques used by MC phones can be broken by security features that are enabled by default on third party firewalls. The goal of this section is to provide guidance on firewall voice features that may result in dropped audio calls or unidirectional audio.


Any voice specific NAT traversal features on firewalls upstream of MC phones should be disabled. The MC leverages ICE to traverse NAT borders meaning ALG (Application Layer Gateway) functionality is not required. If these features are enabled, audio issues may be encountered by the end user.


The following block of configuration is an example of timeout settings that are commonly present on Cisco ASA routers and can cause MC calls to end prematurely. If this configuration is present in CLI, the administrator should endeavor to have the lines of configuration removed.


timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00





Given that MC voice traffic will traverse the public internet and no layer 2 or 3 QoS tags will be processed upstream of the customer premises, packet prioritization is crucial on the voice Internet gateway in addition to other LAN devices. The Meraki full stack of managed networking devices allows an administrator to configure Layer 2 and 3 QoS rules from within the same single pane of glass. Meraki MC phones tag all outbound traffic with DSCP value 46 which will ensure expedited forwarding (EF) if upstream equipment has been configured in accordance with best practices.

MS Switch QoS


To ensure that this tagged traffic is placed in the correct layer 2 queue, Dashboard administrators can choose to trust incoming DSCP in the Switch > Switch Settings Dashboard page. This rule will be followed by all switches in the switch network:


MX Security Appliance QoS


To ensure that this tagged voice traffic is prioritized when leaving LAN infrastructure via the WAN uplink port, Dashboard administrators can choose to apply a high priority to all VoIP & video conferencing traffic. 

Priority can be set to HighNormal, or Low, allowing the MX series to prioritize a given network flow relative to the rest of the network traffic. The ratios are as follows:

  • High: 4/7

  • Normal: 2/7

  • Low: 1/7

HA design 


Meraki MC phones require a persistent, always-on internet connection in order to make calls to other MCs, external numbers or emergency services. To ensure that MCs enjoy continuous phone service, administrators need to ensure that multiple forms of Internet link are available for redundancy purposes. Meraki MX Security appliances can be configured in Warm Spare architectures with multiple WAN ethernet uplinks in addition tertiary 3G/4G uplink failover in the event of an outage. 


Last modified



This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 5000

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community