Microsoft Lync Server 2010 Resource Kit: External User Access

Microsoft Lync Server 2010 communications software allows users to connect to each other remotely. This chapter describes the most common remote access scenarios, and then provides detailed call flow diagrams, traces, and related ms-diagnostics codes. Overviews of the basic scenarios are provided, giving context for how users make various connections. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.



Authors: Randy Wintle, Dustin Hannifin

Publication date: August 2011

Product version: Lync Server 2010, Lync 2010

The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Lync Server 2010. The book will focus on professionals who want to understand more about how the product works internally. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

Internals (technical details of remote user access capabilities) are discussed in depth in this chapter and figure prominently in the scenarios. An introduction to the Interactive Connectivity Establishment (ICE) protocol, Simple Traversal Underneath NAT (STUN), and Traversal Using Relay NAT (TURN) implementations in Lync Server are provided.

Lync Server 2010 allows users to access instant messaging (IM) and presence remotely by using the Lync Server Access Edge service. The scenarios in this chapter describe remote IM and presence in remote user access, federation, and public IM connectivity.


The most common call flow scenarios that involve remote user access are described in detail and as follows:

  • Instant Messaging: peer-to-peer, internal user to federated partner, and internal user to PIC user.
  • Conferencing: application sharing conference (desktop sharing), and audio and video Conferencing.
  • Enterprise Voice: peer-to-peer audio, involving two remote participants; peer-to-peer audio, involving a federated partner; and a PSTN gateway audio call, involving a remote user.

Lync Server Resources

We Want to Hear from You

Keywords: Presence, IM, instant messages, Enterprise Voice, peer to peer, conferencing, PSTN, gateway, remote access, federated, user, partner,

Comments (5)
  1. Great job on this chapter Randy and Dustin. You both rock!

  2. Attila Kovács says:

    Very nice material, I've learnt a lot from it. But I've found some figures confusing and not in sync with the scenario (e.g. peer-to-peer call flow). It would be also good to see IPs on the network diagrams. A bit more details about how candidate IP-port pairs are obtained would be good to.

  3. Attila, thanks for the feedback. Just sent a note to the authors on this.

  4. Randy Wintle says:

    Hi Attila, can you comment with some more specific details with errors in the diagrams?

    As for your comment about allocation:

    Ice will look at all available IPv4 addresses available on the client. Using these addresses in addition to the default port range, or administrator configured port range, the client will randomly allocate a pair of ports in that range per call. In addition, the client will also discover the closest public ip address which is being used for nat purposes and allocate ports there (these are the reflexive or home ip addresses). For the relay addresses, the client will send an allocate request to the av edge with the information provided in the initial MRAS response. The edge will validate the client credentials, then randomly allocate ports not current in use in the defined edge port range. The client combines all of this and sends with that initial INVITE. The callee will follow the same process and respond with a 200 OK. I think the chapter outlines the rest. If not, please feel free to ask any more questions, thanks!

  5. Attila says:

    Hi Randy, on page 37: "In this scenario, two remote Lync 2010 users…", but diagram shows one Lync user inside.

    Thanks for the explanation. For me the most mysterious are the ports on the external IP of the NAT device, since those are out of control. I know that using STUN (at least how it was before), you can figure out the behavior of the NAT device: so you make a "hole" by sending a packet to the STUN server and then you test from a 1st and 2nd IP of the STUN server if that "hole" lets in packages from what IP and port combinations.

    I also know that now STUN is something more than just figuring out the NAT type. Are the STUN messages themselves testing and opening the ports for media?

    It is also strange to me that internal users will use external IP of edge if relaying is needed with an external participant. It means, that internal clients will use the (site) local Internet access to connect the edge server. Doesn't it spoil the CAC?

    I'm studying these because I'm experiencing random problems with Polycom HDX and RMX devices, especially when Lync clients are outside. Anyway, I keep learning and hopefully understand everything better soon.

Comments are closed.

Skip to main content