Voice quality is surprisingly something that is often overlooked when an organization wants to move their voice infrastructure to the cloud. I’ve worked for multiple customers over the past two years where some have been well equipped to handle the media traffic whereas others were missing some of the vital pieces that proved to be a major roadblock in getting them to the cloud. This article will be geared towards the following audiences:
- Organizations planning to deploy their media workloads (i.e. conferencing) for Microsoft Teams
- Organization that have already deployed media workloads but are looking for additional operational guidance
To ensure this article isn’t too wordy I will break it into two pieces, the first part will focus on the network planning side of things and the second part will focus on the monitoring side of things. So, if you fall into one of these categories or if you’re just interested in voice quality in Teams then you’re in the right place! With all that said, let’s jump right in and do a deep dive into the mysterious beast called “voice”. 🙂
 What you need to know
Alright…alright… I know I said we would dive right in but there are some things you need to know prior to deploying any type of media workloads.
- Bandwidth planning – Do a network assessment! IR Prognosis is a fantastic tool that allows you to test your network to ensure your environment is ready to support media traffic. Take a look at one of my colleagues posts on the importance of running a network assessment.
- Test each and every network segment to verify it meets the Media Networking Requirements – The beautiful things about the IR Prognosis tool as mentioned above, is this tool will test this for you. Perficient  is a partner with IR and we have conducted multiple network assessments, so if you’re not sure where to start please feel free to reach out to us and we’ll help you get the ball rolling 🙂
- Monitor your deployment with CQDÂ – Microsoft has a plethora of information on using CQD, but for even more information on custom reporting check out another blog article here.
Great, now that we have that out of the way we can truly begin to discuss deployment and planning steps along with operational and monitoring steps required to ensure a successful move to the cloud.
Network planning… just do it!
Like the great Ben Franklin once said, “by failing to prepare, you are preparing to fail”. This applies for network planning as well. If you don’t do network planning, your deployment will fail, no if, ands, or buts. Just like with Skype for Business Online, Teams is a bandwidth heavy application. That said, if you don’t have the proper bandwidth to support media traffic, this will result in a very poor experience for you and your end users. Media traffic is very delicate and without proper bandwidth you will be the first to receive backlash if not implemented correctly. I say this because, if you take Exchange email and you send an email to a colleague which takes a few extra seconds between when an email is send and when it is received on the other end, to the end user this is practically impossible to tell nor does it have any real impact for either end user. However, if instead this were a call that is initiated and voice packets are taking longer to reach the end user it can significantly affect the voice quality and result in audio cutting out, a robot voice, and just an overall poor end user experience. Nobody wants that, so please take the time to run a network assessment, you’ll be glad that you did! Another thing to take into consideration is QoS (Quality of Service). As Korneel Bullens of Microsoft says, “You can think of QoS as a highway with multiple lanes. Each lane has its own type of traffic”:
- Audio
- EF – Expedited Forwarding
- Video
- AF – Assured Forwarding
- Other traffic (Web, Email, File transfer)
- BE – Best Effort
With audio, this is considered top priority/express lane so we want to get this type of traffic to its destination as quickly as possible. With video, we might drop a few packets along the way but we still want to get there as quickly as possible. Lastly, we have our traffic that we don’t care much about as long as it gets there eventually. The one challenge that you may face is when a specific queue has too much traffic added to it and is oversubscribed it will either drop the packets or hand them over to the next queue. If this is the case, once that traffic has been changed to a different queue (or in this scenario “lane”) it starts to push out different traffic thus affecting ALL calls in that queue. Great, so how do I know if I have enough bandwidth though? No need to worry Microsoft has you covered with the Network Planning Tool. This will allow you to specify the amount of bandwidth currently allocated to each location and from there you can check if you have sufficient bandwidth.
Firewall and Routing Planning
One thing you must not forget is your routing from the client out to Teams. If your client is taking 20 extra hops to get to the destination, it will surely impact your voice quality. That said, Microsoft’s rule of thumb is the most direct/shortest path to Office365 is the best (local internet breakouts are highly recommended over centralized internet egress). Although this may seem obvious, closing ports that the client needs to use to communicate with Office365 will only introduce quality degradation. In addition, if your traffic is traversing some type of proxy/traffic inspection this can often cause issues with the voice traffic as it will force your UDP traffic to TCP and TCP is bad in general when it comes to real time media. Microsoft states that the general flows and hops include:
- Client to network edge = 3-5 hops
- ISP to Microsoft network = 3 hops
- Microsoft Network Edge to final destination = IRRELEVANT*
*Â This is considered irrelevant because once you are on Microsoft’s network you are guaranteed to be on the best internet possible.
The requirements outlined above are Microsoft’s performance requirements to guarantee an optimal Teams experience. In addition, you NEED (not optional) to open the following ports from your client network to the internet:
- 443 TCP
- 80 TCP
- 3478 to 3481 UDP
For more information check out the official Microsoft documentation here.
This concludes part 1 of the 2 part blog article on the importance of voice quality in Teams. Check back soon for part 2!
