Howdy,
This is another one of my “Simple Understanding”
articles to provide an easy way to understand how ICE “Interactive Connectivity Establishment” protocol is used in Lync to find available media path for a Lync audio, video, desktop sharing sessions to overcome the Firewall / NAT obstacle in an infrastructure.
the difference with my article is as always the use of simple words and animated diagram to make it easy to visualize how does it works and understand it which will help you planning for your Lync deployment as well as troubleshooting problem related to media session.
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 “Lync Frontend” and a SIP client “Lync Client”, also with ICE we have an ICE server “Lync Edge” and an ICE Client “Lync 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 I promised a simple explanation, I won’t go into details about the mechanism of STUN and TURN, you can research that online, a lot of nice article is out there. but you 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 deployment, STUN server or TURN server is always the Lync 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 can be used in this call, and is sent in the INVITE request.
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 (first preferred candidate in Lync).
-
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 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 steps
- Register and locate the media relay server.
- Create the Candidate list.
- Connect & Establish Media session.
I created a simple traffic animated video to describe each one of the steps, after all they say a picture worth thousand words, what about a video then?
Register and Locate a Media Relay server
Deeper Look
- External Client does a SRV Lookup to find the Edge Server to register
- External Client send a REGISTER Request to the Frontend via the Edge.
- Frontend Register the Client and send back a SIP 200OK telling the Client there is an Edge server for Media relay
- Client Send a SERVICE request with its location (External or Internal) to the Frontend.
- Frontend Authenticate with the Edge server on behalf of the Client (MRAS Request)
- Edge Server create 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)
- Frontend send a SIP 200OK 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 (Big Thank to Ryan for pointing this out) and that’s why Microsoft said you must use the same SSL certificate with private key on all the Edge nodes in the same Edge pool in case one node goes down.
Create the Candidates List
Deeper Look
in this step 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.
- 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.
- Client connect to media relay server (Lync Edge) and discover STUN Candidates whish are:
- UDP candidates of the IP-address that the Edge server sees the client coming from.
- TCP candidate of the IP-address that the Edge server sees the client coming from.
- Client connect to media relay server (Lync Edge) and discover TURN Candidates which are:
- UDP candidate of the IP-address of TURN server (Lync Edge)
- TCP candidate of the IP-address of TURN server (Lync Edge)
- Client_1 send INVITE request with its Candidates list to Client_2
- Client_2 does the same and discover its own Candidate list
- Client_2 reply to the INVITE with 183 Session Progress with its own Candidates list
Connect & Establish Media Session
Lync Client start testing the candidates simultaneously until it receive first response and used it to establish “Early Media” connection.
Deeper Look
in our scenario:
- Client_1 will try to connect using the local candidate first, which will fail because both are in different networks
- Then it will try the STUN candidates as it is the preferred by Lync
- If for some reason STUN fail, client will failback to TURN/UDP
- 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 the following diagram
- 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 as simple as i can put it
- The Client will use the Lync 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
hops i did a good job simplifying how Media traversal works in Lync