cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

VOIP Traffic Shaping Best Practice Troubleshooting

Comes here often

VOIP Traffic Shaping Best Practice Troubleshooting

Re: Voip traffic shaping

Hello,

 

We have similar traffic shaping rule setup on MX64 to handle voip traffic.  We migrated to hosted voip about 4 weeks ago adding that traffic to both existing sites using MX64 appliances.  We've encountered problems, at both of our sites, since migration.  The Avaya phones intermittently re-register and retrieve their settings...If this event occurs while phone in conversation all ability to manage the call is gone... (conversation continues however ability to manage call is lost.  Cannot transfer, conf, forward, hang-up etc....)  Our phone vendor believes the problem to be result of poor jittery internet connection or MX configuration which is not optimum for VOIP traffic. I'm still in the process of eliminating what IS NOT contributing to this behavior while pushing on noise found on internet paths.

 

Anyone have input into best configuration to shape voip traffic on MX64?  To avoid the behavior in one of the buildings we're moving VOIP Traffic in/out of building over different internet path.  This means we've also isolated Data/Voip.  This solved issue in one building and results would appear to indicate the problem to be exclusively quality of internet connection, however can't rule out the separation of Data and Voice as the real solution.  (Noting that Data is remains uninterrupted on same internet path were VOIP was encountering all kinds of trouble.) Of course VOIP traffic less forgiving to jitters or poor internet connections.  One distinction between the traffic shaping screen shot posted and our rule are the limits on bandwidth for VOIP traffic set to 5Mbps rather than unlimited. This would seem most important, however other building with same behavior had no traffic shaping rule and still encountered same problem phones reregistering and retrieving their settings.

 
4 REPLIES 4
Kind of a big deal

Re: VOIP Traffic Shaping Best Practice Troubleshooting

There is a VoIP guide for MX:

https://documentation.meraki.com/MC/MC_Network_Administrator_Guides/Other_Topics/Ensuring_VoIP_Readi...

 

Then you need to measure you upstream bandwidth (using a tool like www.nperf.com or www.speedtest.com) and then configure this number as your WAN uplink bandwidth (so the MX actually knows how much bandwidth you have available).

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Traffic_Shaping_Settings#Uplink_ban...

Building a reputation

Re: VOIP Traffic Shaping Best Practice Troubleshooting

I would also upgrade to 14.31 firmware.  Then setup a traffic shaping rule and change VOIP traffic to DSCP 46.  They changed the functionality of traffic shaping in 14.x fimrware with traffic that has DSCP 46.

 

Also, do Avaya phones use standard compliant SIP - or is it some proprietary protocol?  If proprietary, then you need to configure the correct ports in a custom traffic shaping rule.

 

Setup a host under Traffic Shaping -> Uplink Statistics.  Set it to the IP of your hosted PBX - this way you can track latency/loss to this host over time.

 

I'm honestly not sure that this is a traffic shaping issue or a jitter issue.  Make sure that any SIP ALG is turned off on ISP modems and you aren't double natting.

A model citizen

Re: VOIP Traffic Shaping Best Practice Troubleshooting

Are you using Meraki MS switches? I would recommend go got "Switch > Switch Settings" and setting the DSCP value for your phone VLAN to 46. Then in traffic shaping on the MX have it NOT change the DSCP value, it can still prioritize VoIP traffic though. This will set the traffic priority higher closer to the VoIP phone so as it traverses your internal network it has the higher priority, then when it gets to your MX you don't want it to be slowing that traffic down by changing the DSCP value again.

Head in the Cloud

Re: VOIP Traffic Shaping Best Practice Troubleshooting

I think your issue sounds like it could be related to UDP timeout which you cannot change on the Meraki.  You could try changing the timeout on your Avaya system to be longer though.  Too much jitter would more likely cause poor audio quality, but not phones re-registering like you describe.

Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.