This site is part of the Global Exhibitions Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 3099067.

Informa

The Peer-to-Peer blog is a forum for Channel Partners readers with the goal of stimulating discussion among partners about important issues impacting their business. The opinions expressed here are those of the authors and not necessarily those of Channel Partners editors or publishers. If you are interested in submitting a blog, please contact Editor-in-Chief Lorna Garey, lorna.garey@informa.com.

The Challenges of Deploying Skype for Business

- Blog

Michael FinneranBy Michael Finneran

Given the number of different suppliers involved in a typical Skype for Business deployment, it’s an ongoing challenge to get – and keep – everything working together to deliver the services end users need to do their jobs. Along with the Microsoft Skype for Business Server software, there will be switches, routers, servers, session border controllers, gateways and a variety of endpoints, all interconnected through MPLS backbones and SIP trunks from one or more service providers.

No one is more familiar with these challenges than Tom Tuttle, vice president for the Microsoft Practice at Nectar, a global provider of monitoring and diagnostics software for unified communications services. Nectar provides tools IT and partners can use to proactively ensure the end-user experience. I caught up with Tom to talk about where he sees the challenges in a Skype for Business deployment and how to manage them.

Michael Finneran: Tom, what are the biggest challenges when deploying Skype for Business, particularly with enterprise voice?

Tom Tuttle: Michael, there are several, including overall complexity and the need to coordinate the various partner elements that will be involved in delivery of the UC solution. I’ll focus on the one that we are very deeply involved in, which is ensuring a solid and maintainable network infrastructure, for both the local and wide-area environments. One of the greatest challenges in Skype for Business is monitoring and analyzing voice and video media in real time. Voice and video traffic is particularly sensitive to delay, jitter, variation in delay from packet to packet, and packet loss, so the ability to quickly identify and isolate issues is essential to an overall positive UC experience.

Providing high quality on those real-time applications depends on having sufficient bandwidth along with a quality-of-service capability to ensure all data streams are treated appropriately. A key part of that is ensuring that QoS actually stays in effect over time, given the dynamic nature of networks.

MF: What do you mean “stays in effect"? Does QoS simply disappear?

TT: Actually, you’d be amazed how many times QoS and other critical network policies get turned off accidentally – often referred to as “configuration drift." Sometimes it’s during routine maintenance, though in many cases it’s during a hardware upgrade or technology refresh and the new device isn’t configured the same way as the component it’s replacing. If QoS is disabled in one device and the QoS priority markings are stripped off, QoS is effectively disabled at every subsequent point further down the line.

MF: So I guess the phones start ringing at the help desk.

TT: Sometimes yes, sometimes no. If there’s excess bandwidth in the network, the problem might go undetected for a few days or weeks. It could also show up as an “intermittent problem" that coincides with periods of peak utilization. It is critically important to be able to isolate the component that’s causing the problem and properly reconfigure it to support the UC needs.

MF: What other types of problems do Skype for Business users typically encounter?

TT: Closely related to the QoS issue is insufficient bandwidth, particularly in the WAN. WANs connecting the various Skype for Business sites quite often use MPLS services that provide different classes of service for different applications — voice, video and data. The MPLS class of service preferred for voice is called “expedited forwarding," or EF. All voice packets must have their priority indicators, which are called DiffServ Control Points, set to 46, the setting that allows them to be treated as EF in the MPLS network.

The other side of that is that while EF guarantees the best performance for delay, jitter and packet loss, it also is the least forgiving for overrunning the allocated capacity. If the customer sends more EF traffic than they are subscribed for, that excess traffic is discarded immediately.

MF: So you start getting degraded quality on some phone calls?

TT: Not exactly. When the network starts discarding packets, it discards them randomly. That means the quality on all calls in progress over that MPLS access can be impacted.

MF: It’s important that you don’t oversubscribe voice services on MPLS.

TT: That’s definitely part of the answer. The other part gets back to QoS marking. It’s also important that only voice packets get marked with the priority indicator for voice. If other applications, say data applications, are mismarking packets as voice, that could cause you to overrun your subscribed EF capacity.

MF: What should readers be looking at in the way of tools to manage these highly complex networks?

TT: A couple of things. Before live traffic is brought onto the network, all of the elements should be subjected to an assessment test that injects simulated calls into the network at least equivalent to the traffic volume you anticipate and monitor the performance.

Once the network goes live, you will need network monitoring and troubleshooting capability. Most Skype for Business monitoring tools only report on Microsoft’s Quality of Experience, or QoE data; what we call “post-call analysis." At the end of each Skype for Business call, the endpoints generate a post-call average report that Microsoft stores in a QoE database. Those records include measures of the average voice quality the user experienced during the call.

The IT administrators then define parameters for characteristics like delay, packet loss and ultimately MOS [Mean Opinion Score] to differentiate “acceptable" from “poor" calls. The tool then sorts through the QoE data to identify those poor calls and look for characteristics they have in common, like locations, time of day, LAN versus WAN versus WLAN calls and so on, with the goal of identifying areas within the network that are the cause.

MF: What’s wrong with that?

TT: First of all, a call could have performed fine for an extended period and then failed abruptly, causing the user to hang up. The QoE record would say that on average the call was acceptable, so the analysis engine ignores it. And in the bigger picture, we’re dealing with sessions that have already failed, thus reactive. If you really want to be managing the network rather than having it manage you, you have to be truly proactive in your approach to network monitoring and management.

MF: So what should they be doing?

TT: Proactively monitor and diagnose problems before they become noticeable to the users. Our Unified Communications Management Platform, or UCMP, is one such tool designed to allow operations teams, IT departments, and service providers to gather and correlate session data in real time while calls are still in progress. Look for the ability to watch the signaling that sets up the call and then actively monitor the network to understand what’s happening as packets travel from the source to destination and back. That includes such things as recognizing mismarked packets and QoS stripping. For example, rather than waiting for a QoE record to be generated at the end of the call, our solution monitors media quality and detects problems as they develop. The ability to analyze media in real time at strategic points in the network enables network ops personnel to quickly isolate the source of a problem. All of this needs to be gathered and correlated so the root cause can be identified quickly regardless of what element is at fault.

MF: How have you worked with Microsoft on this?

TT: Nectar is one of three partners in Microsoft’s IT Pro Tools program that they announced earlier this year. Microsoft recognized that IT departments need these kinds of monitoring, reporting and diagnostics tools to deliver the level of service quality enterprise users expect and set out to select and certify partners for just this requirement. We’re very pleased that Microsoft chose us and we continue to work closely with them.

MF: What’s your sales model?

TT: We primarily sell through our global channel-partner network who in turn supports enterprise customers in every vertical market. Additionally, we have service provider customers who leverage our capabilities for both dedicated and hosted offers they market to their customers.

Michael Finneran is principal at dBrn Associates, a full service advisory firm specializing in wireless and mobility. Follow him at @dbrnwireless.

Print
Comments

comments powered by Disqus