Taken from Tom Arbuthnots Post

Options and Considerations for Testing your Network for Skype for Business and Microsoft Teams

Published 18/06/2018

Ideally, and strongly recommended by Microsoft, before deploying Microsoft Teams or Skype for Business, you should test your network to ensure it can cope with real-time media and give users a good experience.

Microsoft refers to this as a “Network Readiness Assessment” and some kind of assessment is a requirement of what previously called the Skype Operations Framework, now called Practical Guidance for Cloud Voice. A series of best practices for rolling out and maintaining Skype for Business.

When testing networks, you are looking to test/understand, some or all of the following:

• Does the network allow good connectivity between all users/services (i.e. ports/protocols are not blocked)
• Does the network allow adequate throughput to support the level of traffic (i.e. plan your expected load and test the network can transfer that load in a performant way)
• Testing if QoS markings are kept intact/respected

When we say “the network”, you should be thinking about

• Site to Site. Wi-Fi and Wired (P2P sessions)
• Site to SfB Servers and or SFB Online (PSTN, Conferences)
• From the managed network to the internet, considering working from home and federated calls

Usually, network readiness will fall into two parts; a paper-based understanding of network topology and projected bandwidth use and a test where real or simulated traffic is sent over the network and actual performance measured.

“Paper Based” Exercises

For doing the “paper-based” excise, Microsoft provides an older excel calculator (considered on-premises and online, and a newer, easier to use Network Planner (only considered online):

As well as some great document resources:

https://myadvisor.fasttrack.microsoft.com/CloudVoice/Guidance

Testing the network with real traffic

When it comes to actually testing the network, Microsoft kindly provide a free test tool and there are third party options, so what are the differences/use cases?

Microsoft’s free Network Test Tool is a great way to do a basic connectivity and performance test. It’s free so it’s a quick easy place to start. It will test:

• From a PC to the nearest Azure edge for a single SfB Audio stream (i.e. Cloud PSTN Calling plan call or Conference scenario)
• By default runs a single 17-second test, but can be configured to iterate, Each call will take 17 seconds (non-configurable) + the wait interval (5 seconds default)
• Reports on:
  • Packet loss
  • Jitter
  • Round-trip latency
  • Reorder packet percentage
• Network connectivity – Verify network IP addresses and ports needed for Microsoft Teams calls can be connected to
• Outputs results to a Results.tsv file (Tab-separated)
• ‘ResultsAnalyzer.exe’ to read results.tsv and give a basic text report of network performance

What a third party can add:

• Test from PC to PC/site to site within your network, not just from site to Office 365. A common issue we see is not just bandwidth between sites and Office 365, but internal WAN links affecting User to User P2P sessions on the enterprise network
• Load Test – Microsoft’s test tool only tests one media stream, which can tell you if one media stream meets the SLA’s, but how will your network perform with 10,100 or 100’s of sessions?
• Stack multiple real SfB calls. Some network tests throw one stream of UDP from point A to point B, logic being that 64Kbps x 10 is that but can your network deal with the setup/teardown and signalling of 10,100 or 100’s of real SfB Calls – we often see Firewalls and Proxies struggle at load, dropping packets or issuing TCP resets on signalling
• Continuous testing for a period of time, centralised data and reporting
• Services to help design, deploy and interpret the results of a network assessment
• Fuller visual reports and recommended actions

Modality Systems have such an offering, Impact Assessment, by all means, consider me biased and do your own research into the options. There are other third parties like Nectar, IR Prognosis and Ixia that offer different network test solutions.

Microsoft provides a partner certification program for SfB network assessment tools. Unfortunately for Modality, part of the spec to be certified is checking packets can get from one location to another with the QoS markings intact. As our test SfB bots run on windows, there is no way for Windows applications to query the windows network stack programmatically to know if packets are marked. Just like SfB, we can QoS mark our test calls, and can do manually check they arrive marked with Wireshark where required. Other network test providers can do this via dedicated Linux machines where that level of networking stack is more available to applications.

In a Modality Systems Impact Assessment, we have two models, a basic connectivity test and a load test. Both use a real skype endpoint (virtual static user) build on UCMA making real skype calls.

A connectivity test places our Windows-based SfB “virtual users” in your sites and does a 2 concurrent call mesh, site to site and each site to an Azure VM (testing to an Azure VM). The Azure VM represents the connectivity route to Office 365. This ensures everything can route directly and not be relayed in and out of your network.

Taking it up a gear, our load test has SfB virtual users actually make multiple concurrent real SfB calls between each other. With the ability to scale to hundreds of calls (an i5, 4GB PC can do about 25 concurrent audio calls, more hardware is needed for larger call volumes). We often find a network will “pass” under a Microsoft basic test or our network connectivity test, but show issues under load. This could be due to raw bandwidth availability at certain times or the throughput capacity of network equipment under load.

Critically both types of test are performed over time, typically 30 days, to give a true appreciation of the continuous performance around other network traffic and business processes.