Digging into Media Setup Failures using CQD Online
Published Apr 24 2017 07:55 AM 15.3K Views
Microsoft

Most media setup failures are caused by restrictions in place on the network or client computer. We look at these restrictions in 2 ways:

Deep packet inspection specifically SSL inspection - Skype for Business uses pseudo TLS which is used in media setup. This is not supported by most inspection devices such as proxies and firewalls, including host based security software; which is why we ask customers not to inspect Office 365 traffic.

Perimeter or host port/IP ACLs - Skype for Business uses specific domain names, IP subnets, and port ranges to setup media.

At a minimum Skype for Business needs the following ports and protocols

 

Source IP

Destination IP

Destination port

Client IP networks

O365 IPs for SfB

UDP 3478 thru 3481; TCP 80 and 443

 

Most environments have FQDN, IP subnet and/or port restrictions in place. These restrictions can exist on firewall/routing devices on the network, host based security software running on clients, and VPN solutions.

 

Investigating these failures using CQD:

When investigating media setup failures, the following dimensions give the best view of data to allow you to determine the root cause the issues you might find:

 

  • Client subnet
  • Date/Time
  • Relay IP
  • Failure Reason

 

In all our examples, we filter to conferencing only. Below is an example filter you can use to scope your reports to just server and client pairs: "Is Server Pair" equaling "Client : Server":

 

Filters-num1.png

 

Client Subnet

 

In an Office 365 hosted conference, the client subnet shows as the "Second Subnet" inside CQD reports. Each bar represents a month in the measures you see, Total Stream Count, Count of Setup Failures, and Setup Failure Percentage. The Month column represents the most recent month in the data shown.

 

The example below shows subnets giving you the ability to sort by the highest count of failures. In the case where you see a spike like this example it is good to leverage the Day dimension, talked about later in this document, to further isolate the issue. If a spike is not noticed but rather a high month over month setup failure rate, look to add a filter on "Relay IP" which we will show later.

 

In the picture below see that the failure rate spiked in October of 2016:

AugustFailureSpike.pngAugustSpike.png

Month/Day View

 

Another valuable dimension to isolate an issue is adding "Day". You can then map the increase to a specific change made on a specific day. It is also possible to add a "Second Subnet" filter and look at a specific client subnet.

In the below example you can see a spike started on the 24th of August. This spike happens to correlate with new Skype for Business Edge servers being added in new subnets. If customers do not monitor our URL and IP range feed, they may miss a new subnet and see the below trend:

DayFilter.png

 

 

Relay IP address Failures

 

The Relay IP represents the Skype for Business media service used in a media connection. In these examples we are only looking at conferencing so we are concentrating on the Second Relay IP. It is very important not to concentrate on the specific IP address in these reports but rather the subnet to which this IP address belongs.

 

In this example, you can see the 2 Relay IP's with the highest failure count are in the 52.112.0.0 subnet. This subnet is used by Skype for Business and is included in the listed range published in the resources below. Based on the data pictured would indicate a lack of proper ACL's or proxy bypass rules for this subnet. Note the site referenced below includes FQDN, subnet, and port requirements for Skype for Business Online.

 

In the example pictured below, the failure to 132.245.1.23 and 132.245.113.23 are consistent high month over month. The best step is to now add these 2 relay IP addresses as filters in the client subnet report we covered earlier in the article. With that additional filter, you can pivot to see if there is a trend of a specific client subnet to a specific set of relay IP addresses and associate those to the subnet from the URL and IP address list: 

 

RelayIPs.png

 

Remember, make sure you refer to the published list of subnets to see what subnets to which Media Relay IP addresses belong. Then add the subnets to the configuration in your environment that allows for access to Office 365 services.

 

Resources:

 

Access the Call Quality Dashboard

Videos to help onboard to Call Quality Dashboard

Call Quality Dashboard detailed report SOF templates

Office 365 URLs and IP address ranges

Blog on Outdated Clients causing media setup failures

Dimensions and measures available in Call Quality Dashboard in Skype for Business Online

 

 

13 Comments
Version history
Last update:
‎Jul 13 2017 04:07 AM
Updated by: