Simple Understanding of Media Traversal in Lync / Skype for Business

Howdy everyone,

Hope you all had a nice holiday and wish you a happy and successful new year .

This is one of my “Simple Understanding” articles to provide an easy way to understand how ICE “Interactive Connectivity Establishment” protocol is used in Lync and Skype for Business to find available media path for an audio, video, desktop sharing sessions to overcome the Firewall / NAT obstacle in an infrastructure.

This article was really hard to write as I found myself too many times getting into too much details which lead into deleting or cutting paragraphs in it, and finally after 2 weeks I got this, so let’s start.

Understanding ICE

ICE is a protocol that is used to find & establish media path in a call, simply like with SIP, we have a SIP server “your Lync / Skype for Business Frontend” and a SIP client “Lync / Skype for Business client”, also with ICE we have an ICE server “Lync / Skype for Business Edge” and an ICE Client “Lync / Skype for Business client”

ICE uses two other Protocols to find and establish a suitable media path for a call, those Protocols are:

• STUN (Session Traversal Utilities for NAT)
• TURN (Traversal Using Relays around NAT)

because this is a simple understanding article and not a deep dive, I won’t go into details about the mechanism of STUN and TURN, a simple search online will gives tons of articles about that. but we need to understand the difference between those two is simply:

• STUN: the media travels directly between both endpoints in a call (the NAT device is considered an endpoint)
• TURN: the media will be proxied using the TURN server between both endpoints in a  call

understanding this will help when we talk about the scenarios later in this article

in a Lync / Skype for Business deployment, STUN server or TURN server is always the Lync / Skype for Business Edge server (A/V Server)

Candidates List

what is a Candidates list?

It is simply a list of IP-addresse(S), ports and protocols (wither UDP or TCP) that is shared between the call endpoints to tell each other what is the possible media path that can be used in this call, the candidates list is sent in the INVITE message inside the SDP part of the message.

in a SIP Stack file it look like this

a little deeper look, the Candidates list is composed of:

• Host Candidates: the local IP address and ports of all active network cards on the client machine (most preferred by Lync / Skype for Business).

• Reflexive Candidates (STUN): list of IP-address & ports allocated by a NAT device (second preferred candidate in Lync)

• Relay Candidates (TURN): list of IP-addresses & ports of the TURN servers (used when STUN cannot be used)

the Lync / Skype for Business client test each of those candidates till it find a suitable media path for the session (will talk more about that later in the article)

Media establishment mechanism

so how does it actually work?, I divided the mechanism of finding a suitable media path into 3 main stages

1. Register and locate the media relay server.
2. Create the Candidate list.
3. Connect & Establish a media session.

I created a simple traffic animated video describing each one of the steps, after all they say a picture worth thousand words, what about a video then?

1. Register & Locate the media relay server

The animated video can be found here

Deeper Look

1. External client does a SRV lookup to find the Edge server to register
2. External client send a REGISTER request to the frontend via the Edge access services
3. Frontend register the client and send back a SIP 200/OK telling the client there is an Edge server for Media relay
4. client sends a SERVICE request with its location (External or Internal) to the Frontend.
5. Frontend authenticate with the Edge server on behalf of the client (MRAS Request)
6. Edge Server creates credentials (valid for 8 hours) for the client using the private key in the “Public SSL Certificate” installed on the A/V services and send them to Frontend (MRAS Response)
7. Frontend sends a SIP 200/OK to the initial SERVICE request from the client with the name of the Edge server & credentials the client should use for Media relay

HINT: if you wondering about step 6 and 7, those take place because Edge server is not joined to the domain and cannot authenticate users, it create the credentials using the Private Key associated with the public SSL certificate installed on the A/V services and that’s why it is required to use the same SSL certificate with private key on all the Lync / Skype for Business Edge servers in the same Edge pool in case one node goes down.

2. Create the Candidates list

the video can be found here

Deeper Look

in this stage the client go through some steps to create the candidate list explained previously in this article, so let’s say client_1 (located in home office) is inviting client_2 (located in the HQ) for an audio call.

1. Client discover Local Host candidate which is the local IP-address of every active network card on the machine, which is using only UDP as it is peer-to-peer connection.
2. Client connect to media relay server (the Edge server) and discover STUN Candidates whish are:
   • UDP candidates equal to the IP-address that the Edge server sees the client coming from.
   • TCP candidate equal to the IP-address that the Edge server sees the client coming from.
3. Client connect to media relay server (the Edge server) and discover TURN Candidates which are:
   • UDP candidate equal to the IP-address of TURN server (the Edge server)
   • TCP candidate equal to the IP-address of TURN server (the Edge server)
4. Client_1 send INVITE request with its Candidates list to Client_2
5. Client_2 does the same and discover its own Candidate list
6. Client_2 reply to the INVITE with 183 Session Progress with its own Candidates list

3. Connect & Establish a media session

the video can be found here

Deeper Look

in our scenario:

1. Client_1 will try to connect using the local candidate first, which will fail because both are in different networks
2. Then it will try the STUN candidates as it is the preferred by Lync
3. If for some reason STUN fail, client will failback to TURN/UDP
4. If TURN/UDP did not work, client will try TURN/TCP

so in SIP stack traffic it happens on 5 steps (not always, just to make it simple) as described in this video

• Client_1 send SIP INVITE with its Candidates lists to Client_2

• Client_2 reply with SIP 183 Session Progress with its own Candidate list to Client_1

• Client_2 send SIP 200 OK with best Candidates to Client_1

• Client_1 choose STUN candidate as the best suitable path for Media and send a re-INVITE to Client_2 telling it that

• Client_2 choose TURN candidate as the best suitable path for Media and send a SIP 200 OK to Client_1 telling it that

• call established and now both clients knows how they can send media to each other

Summary

so that’s how it works:

• The Client will use the Lync / Skype for Business Edge server to create its Candidates list
• Client will INVITE another to a call while providing its Candidate list
• Both clients test the candidates list and choose the best suitable media path
• inform each other with the chosen candidate
• establish the call

till next time