This document describes a detailed view on the TCP TURN message exchange between the CMS, Expressway and Skype for Business components.
Cisco recommends that you have knowledge of these topics:
CMS (Cisco Meeting Server)
Skype for Business (previously Lync) server
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Expressway version X8.9 introduced support for TCP TURN, allowing presentation sharing calls between CMS and Skype for Business (Lync) where CMS would use Expressway-E as its TURN server. Content media from the Skype client is then expected to flow towards Expressway-E, which then forwards it to CMS on premise.
This document is supposed to provide a detailed view on the TCP TURN message exchange between all the components to help troubleshoot the potential issues. It does not explain the fundamentals of TURN or the use of UDP TURN for regular audio or video call.
Tip: The TCP TURN is an extension to TURN documented under the following RFC6062.
This document focuses on the TCP part, which is unique for Skype presentation sharing calls, and adds extra complexity to the classic TURN operation.
In the test lab scenario described in this document, we have Skype client communicating to CMS over Skype Edge server, Expressway-E and Expressway-C. Expressway-E is configured in CMS as a TURN server. Additionally, the Skype client has no IP connectivity to the Expressway-E server, so we expect the only working media path to be over the Skype Edge towards the Expressway-E server.
The following image shows the new INVITE with m=applicationsharing is sent from Skype to initiate the presentation sharing.
(it does not show the initial audio and video call invites, which are already negotiated at this stage):
Working with packet captures
In some situations, in order to get quick overview of the STUN communication, it may be enough to set a Wireshark filter as tcp and stun:
Looking for STUN packets in TCP payload
Wireshark may not always decode the TCP communication as STUN.
You will have to filter out on the TCP port which is used for communication, look for TCP packets with [PSH, ACK] flag and investigate the TCP payload:
In the the image above the payload begins with data 00 6c 00 01. The different values in the 3rd and 4th byte represent the following STUN packets:
00 01 - Binding Request
01 01 - Binding Success Response
In order for the STUN pair to work, there has to be one of each in each direction.
Using Wireshark to decode MSSTUN messages
Microsoft has made additions to the base IETF standards which are not recognised by Wireshark. You can install a plugin into Wireshark which will make these packet capture more readable.