There are multiple ways to initiate communications sessions in Lync across different modalities and features.  These various options can utilize a few different network paths to reach the intended destination(s).  The path that each takes depends primarily on the type of communication involved and is also influenced by the number of parties involved.

In Lync, and going all the way back to Office Communications Server, there are a few constants that can be defined.

1. All communication data can be categorized as either Signaling data where the session setup and handling is performed, or as Payload which would be be the actual content itself (e.g. media, instant messages, shared files).
2. For signaling data Lync clients will always be connected to a Lync Server and this traffic will always go from client to server to client.  Lync clients do not and cannot send signaling messages directly to each other. 

3. For payload data all modalities can utilize either a two-party Peer-to-Peer (P2P) model or a Multiparty Conferencing Unit (MCU) model.  Again the primary signaling path is always handled by the Lync Server as previously defined, but the payload can take different routes depending the scenario.  While most modalities can leverage either model depending on the type of call in session, some of them only support a single model and will always communicate in that fashion.

Using these constants the various ways that sessions can be initiated and how the different modalities are utilized can all be defined to understand exactly what is sending network data to where, and what actions trigger changes in these paths.

Models

The following table can be used to quickly reference which types of modalities support which of the two communications models. For the purposes of simplicity media traversal through and Edge Server is not included here but regardless of the model the Edge server may be involved in transparently proxying one or both of the two data streams.

	Peer-to-Peer (P2P) Model	Multiparty Conferencing Unit (MCU) Model
Instant Messaging		X
Audio Calls	X	X
Video Calls	X	X
Desktop Sharing	X	X
Application Sharing	X	X
File Transfer / Images	X
PowerPoint		X
Whiteboarding		X
Meeting Poll / Q&A		X
Attachment Upload		X

As noted some only support a single model while other can work in either model depending on the type of session currently in use when the specific modality is added.  Modalities which only support the MCU model will trigger an immediate escalation from an existing P2P session up to an MCU session when selected.

Escalation

For example say that a basic audio call has been established between two Lync clients which utilizes the P2P model by default.  Then one of Lync users decides to add whiteboarding to the session, which requires the MCU as it is not a modality that is supported directly between the Lync clients.  The act of enabling the Whiteboard modality will automatically escalate the audio call to a conference call and at this time the P2P media payload session will be stopped and both Lync clients will then negotiate media paths directly to the MCU on the Lync Front End server.  This escalation can happen only once per session and is permanent.  From this point on the addition of any more participants or MCU-only modalities are seamless as the session has already been moved to the MCU.  Regardless of how many other participants or modalities are added to the call removing all of these will never trigger any sort of de-escalation back to a P2P session.  So even if there are only two participants remaining in the conference call and audio is the only modality left in use the call remains hosted on the MCU.

Instant Messaging

The most basic communications type simply invites the user to an instant message conversation.  The act of locating the other user, showing their presence, and sending the initial IM message as basically an invitation is all handled by the signaling path through the Lync server.  The payload, or the instant messages themselves, are embedded in the SIP signaling traffic for instant messaging and thus are one in the same.

This is the only modality in which the payload is included in the signaling path as SIP messages.  Additional features like sending files or pasting images into the IM window will trigger a different type of session establishment.  Only text and emotions (which are represented by their text values) are included in this single stream.

• Internal clients connect directly to the primary Lync Front End server in the user’s home pool.  This traffic is always sent as TCP traffic to port 5061 on the Front End server, encrypted using TLS.

• Externally connected clients connect to an Edge Server via TCP to port 443 (by default) on the Access Edge external IP, also encrypted as TLS.

• Federated, Lync Online, and other supported public IM platforms will connect to the same Access Edge external IP but on port 5061 (by default) which is used for federation communications.

• If a third Lync client is added to an active IM conversation window then the session is automatically escalated to the Lync Front End server and is handled by the IM Conferencing service.  Because the IM session and payload was already handled by the server end-to-end then there is no change in the communications path between the original two clients.

Audio Calling

Selecting an entry on the phone menu will place an outgoing audio call to the contact, depending on which option or number is selected.  Just hitting the button will place a call to either the only option (e.g. Lync Call) or to the last used option when the contact contains more than one choice.  As is true with all the actions in Lync the server is handling the signaling traffic so this includes the call invitation, reply, media establishment instructions, and anything else involved in the call setup.  Once a secondary media connection is established then the payload may be delivered to a few different locations.

Signaling traffic is sent to the same servers as defined in the previous section for either internal or external clients.  This is consistent throughout the rest of the scenarios covered in this article and from this point forward only the payload traffic patterns will be discussed specifically.

Among the multiple calling options which may be available on a Lync contact they will all fall into one of three categories: a native Lync Call, a Telephone Call, or Voice Mail.

Lync Calls

Lync Calls to other Lync clients in the same environment, federated companies, Lync Online, and soon even Skype clients will utilize native media establishment rules which dictate that a direct connection between both parties is negotiated whenever possible, otherwise the Internet Connectivity Establishment (ICE) protocol will be utilized to provide fallback assistance by leveraging the Edge Server.

• In the event that a direct connection is available between both clients then the media payload will be delivered to randomly selected UDP or TCP ports on both clients somewhere between 1024 and 65535 by default.  It is possible to reduce this port range via Lync Server client policy configuration as documented here by selecting a custom range of contiguous ports.  This approach provides the ability to open a much smaller range (no less than 40 ports) on any firewalls which may sit between internal client subnetworks.  For audio streams UDP is the default protocol but if that cannot be established then Lync can fallback to using TCP, which is less desirable for delivery of real-time media over IP networks.
• If direct connectivity between the two clients fails for any reason then ICE will be used to leverage the Edge Server for assistance.  Each leg of the bidirectional audio stream could potentially used different paths, whichever is the most efficient for each side.  Clients will either negotiate media connections directly to the client through one or more firewalls (STUN) or be forced to send media directly to the Edge Server (TURN).  For STUN connections the media payload would again be sent to any range of high-ports (1024-65535) on the remote client’s firewall.  For TURN connections the client would establish a media session with the Edge Server directly.  Internal clients would prefer to send media to UDP 3478 on the Edge Server’s internal interface, or to TCP 443 for media fallback if UDP connectivity to the Edge Server is not available.  External clients would negotiate media in the same UDP-before-TCP preference to the Edge Server’s external A/V interface over a dynamically-assigned port in the range of 50000-59999.  Fallback attempts in the event that ports in this range are not reachable can also utilize 3478 and 443.  Realistically ICE is a complex topic that is difficult to summarize in a single paragraph, so the important concept here is that the payload delivery will always attempt to be delivered directly and if that is not possible then there are many different options available to insure that the call is completed somehow.

Telephone Calls

Calls placed to telephone numbers can be routed a few different ways.

• First, if the called Work number belongs to another Lync user who is actively signed into Lync then the server will leverage reverse number lookup to simply perform a Lync call as there is no need to send this call to any outbound PSTN destination.  This call routing will be identical to the scenario just covered n the Lync Call section above.
• If the resolved Lync user is offline then the call will be forwarded to another destination based on the rule defined for that user (Call Forwarding, Simultaneous Ring) or sent to an Exchange UM server for voice mail.

• If the called number is an external number like a cell phone or other PSTN destination then the signaling path is still client to server but the Lync Server will handle the reset of the call out through an mediation services to the PSTN.  The media payload for this call may be sent to a Mediation Server over either UDP or TCP to a dynamically assigned port in the range of 49152-57500.  Alternatively if Media Bypass is enabled and available for this call then the payload would not go to the Mediation Server but instead directly to a media gateway.

• For external Lync clients the media payload session would need to travel to the Mediation Server by way of the Edge Server to first get into the internal network and then reach the mediation services, before be routed back out to the PSTN.

Voice Mail

Calls to voice mail are essentially a P2P session even though a server is technically involved.  The Exchange Unified Messaging service is not an MCU though and is really just another client in this communications path.  So calls to the Subscriber Attendant are categorized as a peer call between a client and server as these are the only two parties involved.

• Calls placed to Voice Mail will be routed to the appropriate Exchange Unified Messaging server and will utilize the same UDP and TCP rules for RTP media as any other Lync audio call.
• The Exchange UM service be default will dynamically assign a port in the 1024-65535 range just as Lync clients do, but this can also be configured although it is not technically supported by Microsoft.

Video Calling

Video calls will follow the exact same behavior as audio calls in Lync except that the additional video modality will is also included in separate media sessions.  From the signaling to the media payload delivery both audio and video utilize the same paths, protocols, and selection logic explained in the previous section.

Additional Modalities

Once a session has been established there are a number of additional modalities when can be added or certain features which leveraged will trigger additional sessions in the background.  Some of these additional options will retain the existing P2P communications pattern while others are capabilities provided only in multi-party conference calls be one of the Lync Server services, which will automatically escalate the existing P2P session to a conference up on the Lync Front End server even if there are still only two parties connected.

The layout of the content menu in the Lync 2013 client incidentally makes it very easy to understand which options fall into which category.

• The Desktop and Application sharing options on the top row will respect the current call model, either establishing additional P2P sessions for the payload, or when already in a multiparty conference call simply connecting to the MCU directly.
• The options along the bottom row will all trigger the creation of a conference call and move the current peer session up to the server.

Although these concepts are not new to  Lync (or OCS, or even LCS for that matter) when moving over from a different type of collaboration platform it is important to understand the models that Lync adheres to when planning for or troubleshooting an existing environment.