Understanding Lync Modalities

August 31, 2014 by · 25 Comments 

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
  image image
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

image

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

image

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

image

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.

image

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.

About Jeff Schertz
Site Administrator

Comments

25 Responses to “Understanding Lync Modalities”
  1. messagingschool says:

    Learning lync from you MAN 🙂

  2. BEdman says:

    Thanks for another great post, Jeff.

  3. ryan says:

    Hi Jeff,
    It would be great if you can dive into a little more detail about how the Lync to Lync call setup happens. I am confused on how two end points can do P2P if the windows 7 firewall is on. I can tell via the ucappi logs and looking into the SDP that even though two Windows 7 clients have their FW's on, the two lync client can communication directly between each other.

    I work at a federal agency that we have to have the Domain Profile on. If i'm correct when installing Lync client, it adds a rule to the Windows 7 firewall however, due to federal policies, we have to enable a GPO that does not allow for local firewall policies.

    What I believe happens (and please correct me if i'm wrong) is when two Lync clients want to talk they both open ports (1 UDP for RTP and 1 UDP for RTCP) on the Windows 7 computer and then sends this information in the SDP to the Lync front end (both computers do this). At this point the front end provides this information to each Windows 7 computer and the two try and reach each other on the local port that was opened up.

    I realize this question takes the ICE part out as i understand how two end points could communicate if they are relaying information It's just unclear to me how two windows 7 computers who have never communicated with each otehr can just magically start talking. It seems to me the Windows 7 FW would be having like this. Client1 sends a packet to Client2. Client2's FW "SHOULD" say "I don't have an outgoing request for this packet" and would not allow Client1's packet through……but somehow it does!

  4. Brett says:

    Nicely done.

  5. practicallync says:

    Great post! Thank you.

  6. Meir says:

    Great post. One thing that I'm unclear on:
    How do federated and mobile SIP traffic authenticate themselves?

    • Jeff Schertz says:

      The mobile clients are authenticated using the NTLM credentials that the users enter. And Lync-to-Lync federated traffic is not authenticated between each environment. The users authenticate to their local environment and the act of establishing federation with an external Lync environment 'is' the authentication or trust action. when using Open Federation then you are basically trusting all Lync deployments out there.

  7. Olu says:

    Jeff, Thanks for the great work here. I have a question for you about Lync modalities and what Lync Reporting server is reporting as total conferences in our environment. When I looked at conference summary reports, I got for instance 5080 total conferences. I clicked on 5080 value ( total conference for specific week) to leads me to Conference Activity Reports. I checked conferences by pool and conferences by conferencing server types, but neither of the two could sum up to 5080. Conferences by pool was 3401 while conferences by conferencing server type shows as 4076 for that specified week. Does that means the difference is coming the additional modalities such as Multiple Monitors, correct me if I’m wrong?

  8. Daniel Sz says:

    Awesome post! Thank you!

  9. Srini says:

    Awesome article…Thank You Jeff

  10. Dario says:

    Jeff,

    Excellent article, could you please describe the signalling and payload traffic in a multi pool environment between 2 users homed in separate pools? Is the signalling and payload always going to the homed pool for each user?

    User 1 Pool 1 (FE) Pool 2 (FE) User 2

    Cheers

    • Jeff Schertz says:

      Yes, signaling always goes from a client to their home pool/server first, then from server to server if the communications are between users homed on different servers or pools. Payload is always shortest possible path, so either client to client (P2P) or client-server-client (conferencing). Only a single server is involved in a conference as all attendees of a meeting will be connecting to the AVMCU on the organizer’s home server.

  11. Kadir says:

    Hi

    I’d like to send file to lync user by lync sdk in uisuppression mode. Could you please help ?

  12. Scott says:

    Jeff, I work at Microsoft and deal with Lync/Skype infrastructure on a daily (hourly?) basis. Your description above is one of the best written documents I’ve seen on how Lync works. Thank you, I hope everyone realizes how lucky they are to have you contributing this knowledge to an open forum. Keep up the great work!

    Sincerely, Scott

  13. raj says:

    Great information shared. You are Lync god for us. Thanks a lot for helping millions of consultants and tech support folks

  14. Jesus Gonzalez says:

    very well explained… thanks for taking your time on writing this

    Jesus

  15. Yogesh Karandikar says:

    Hello Jeff,Can you please also dive deep that How does the MRAS works in Peer to Peer Lync Call.
    I’ve an issue where after some time Internal Domain users who are trying to Peer-Peer calls have Delay in connecting the calls
    This issue gets resolved by Restarting the Edge server. And I was looking to find a Peer-Peer call flow .
    So if you can explain how MRAS works for Internal Calls….
    Thank you in advance .

    • Jeff Schertz says:

      MRAS works the same regardless of the call media path (P2P or Conference). The client is either trying to send media to another client or a server, but all of these are simply ICE clients. Restarting the Edge server to resolve any media establishment issues points to some server or configuration problem but I don’t have a guess as to what that might be.

  16. Avishek says:

    Hi Jeff,
    Thanks for the post.can you please give a brief when there is peer to peer communication is happening for desktop sharing coz in my case desktop sharing is working for remote user to internal even remote user to remote user but it’s not working for internal to remote user although it’s working when u are adding someone in the conference.

    • Jeff Schertz says:

      Desktop Sharing is identical to audio/video in terms of session establishment and traffic routing. In legacy RDP scenarios the only difference is that traffic is limited to TCP, but with newer VBSS scenarios both UDP (preferred) and TCP can be used. You should be looking at the application sharing port ranges on your internal firewalls. My first guess is that that both 443 TCP and 3478 UDP are allowed from the internal servers to your Edge server, but you may be blocking 443 TCP from internal client subnets to the internal Edge server interface(s).

      • Danny Leaf says:

        Great article as always Jeff!

        on the desktop sharing theme we have a strange issue where the audio stream is frozen for around 10 seconds for all users on the conference when desktop sharing is initiated. The only pattern we have found is this only happens when one or more participants are remote (connecting via edge) – this never happens for internal conferences. The other strange thing is the behaviour isn’t consistent in way of users affected, sometimes an identical meeting will be affected others it won’t. Reading the above article adding desktop sharing should be seamless as parties are already connected to the MCU. The only thing I could think of is that as RDP requires TCP could there be potential of a freeze if all parties were connected to the MCU via UDP?

        • Jeff Schertz says:

          Danny, I have not heard of this issue before but it does sound like it’s somehow related to TCP media setup. I would take a look at the real-time A/V streams prior to adding desktop content to see if they are flowing via UDP (as preferred) or if those are using TCP fallback.

Trackbacks

Check out what others are saying about this post...


Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!