In any Lync media session used to provide audio, video, desktop sharing, or a combination of each there are three potential routes that media can possibly travel between two endpoints. Also understand that the media stream may not always use the same solution on both legs as STUN may be possible for one endpoint but not for the other endpoint. The key difference between these two types of solutions though is that media will travel directly between both endpoints if STUN is used, whereas media will be proxied through the Edge Server if TURN is utilized. the Lync Edge Server) is utilized to setup the media session and provide the list of potential candidates to both parties in a call regardless of which media delivery option is selected for each leg of the call. This IP would always be the Internet-facing public IP address (either assigned directly to the server interface or assigned to an external NAT-device).Ī media relay server or ‘ICE’ server (e.g. Traversal Using Relays around NAT (TURN) – This protocol allows a dedicated ICE server to provide its own public IP address as a media candidate to one or both parties in a call and will act is a relay or proxy for the media session.When the protocol was updated to include support for TCP the name was changed to Session Traversal Utilities for NAT to reflect that it was no longer limited to UDP traffic and retained the same well-known acronym. This IP would be assigned to the Internet-facing side of the NAT device which the client is located behind.Īnecdotally the acronym STUN may also be seen referred to as Simple Traversal of UDP through NAT which was the protocol’s original name (as defined in now obsolete RFC 3489). Session Traversal Utilities for NAT (STUN) – This protocol basically allows an ICE client which is located behind a firewall providing Network Address Translation to discover the public IP address as well as identify the type of NAT in use and then provide that IP to the other party as a potential candidate to send media to.Although Lync nearly always finds a way to connect media, when it does not work it can be very beneficial to know what one is looking for even when performing basic troubleshooting steps. These two protocols are commonly referred to together and the difference between them is not widely understood. ICE provides two protocol-level solutions that nearly every Lync client and server role can leverage to find some available path to establish media between each other. Only the Edge Server role is defined as an ICE Server and is capable of providing the information needed by ICE clients to initialize these connections. Windows client, Front-End AVMCU, Mediation Server, etc) and utilize the Edge Server to negotiate media sessions between each other. In Lync 2010 nearly every client or server can act as an ICE Client (e.g. These solutions provided by the implementation of ICE in Lync Server applies to both UDP and TCP transmission of data so audio, video and desktop sharing sessions can all take advantage of ICE. The primary purpose of this article is to help explain the difference in the available media paths provided by the Interactive Connectivity Establishment (ICE) protocol.