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.
- 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).
- 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.
- 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.
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.
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.
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.
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.
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 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.
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.
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 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.
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.
41 thoughts on “Understanding Lync Modalities”
Learning lync from you MAN 🙂
Thanks for another great post, 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!
Great post! Thank you.
[…] Understanding Lync Modalities: […]
Great post. One thing that I'm unclear on:
How do federated and mobile SIP traffic authenticate themselves?
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.
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?
That’s a good question. Also keep in mind that some conferences start as peer calls so I’m not sure if there is some over lap those numbers.
Awesome post! Thank you!
Awesome article…Thank You 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
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.
I’d like to send file to lync user by lync sdk in uisuppression mode. Could you please help ?
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!
Thanks Scott, glad to help make everyone’s day go a little easier 🙂
1. In hybrid, why SFB online user on public internet, authenticates with Edge server to Front end server then register with SFB online based on attribute value instead of directly authenticating & registering with Online server?
Because the autodiscover records in a Hybrid deployment always point to the on-premises deployment. Once connected if that account is homed online then the server will redirect the client.
Great information shared. You are Lync god for us. Thanks a lot for helping millions of consultants and tech support folks
very well explained… thanks for taking your time on writing this
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 .
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.
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.
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).
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?
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.
Hi Jeff, thought I should report back as I’ve seen others reporting same issue with desktop/app sharing. Our issue was down to our VPN split tunnel configuration, we had firewall blocks from on our VPN Pool to Lync FE’s to force the split tunnel behaviour. However on some occasions (when the audio freeze occurs) we saw traffic from the FE’s to the VPN IP Pool (so not split tunnel), we’ve now put a firewall block from Lync FE’s to the VPN pool which has resolved the issue. I’m guessing when all worked fine for users the process was using STUN and when there were issues TURN possibly used? from the config. documentation we thought we only needed to block client VPN Pool to FE’s but bidirectional block has resolved.
Really useful many thanks
Great article, however, could you clarify something for me please…
1. Will internal clients use the Edge internal interface for ICE (TURN) communications – i thought this was only possible via the external Edge interface?
2. If clients are on different subnets and those subnets have similar IP Address ranges (but are NATd), will clients be able to still establish connectivity with each other for payloads using STUN for example? Or alternatively, will the path go via the Edge internal? and if that’s not possible (as per my first question), will the communications simply fail?
1. Internal clients always communicate directly with the internal Edge interface to relay media. You’ll often see connection attempts from the internal clients to the external Edge, but that is part of the series of connectivity checks and is not actually used for media traversal.
2. Whether STUN is successful or not is based on several things, but TURN will always be used as a fallback so it should still work. The IP addressing scheme used on either sides of NAT (or multiple NATs) though is irrelevant. Think about the fact that nearly every SfB call between two users working in their own home networks are probably all sitting on the ubiquitous 192.168.x.x subnet. Or internal corporate users in different companies all using 10.x.x.x.
I want to thank you for this great article, it’s inspired me 9 month ago on how to restrict ClientAudioPort, ClientVideoPort, ClientAppSharingPort and ClientFileTransferPort modalities in Lync 2010 and so far no incident.
My concern is whether is the same modalities models still relevant for Skype FB 2015 ?
I am looking for some TechNet Articles about SFB 2015 clients/client, clients/server flows.
I would appreciate your help,
The same configuration still applies to the SfB clients, it’s wholly unchanged from Lync 2013.
once again … it is great article .. i appreciate it … pls i have one question …
you are writing about skype4business on-prem deployment … but is it the same in skype4business online? But instead of “lync server” is it “o365 skype4business”
for example: … signaling is going thru internet to tenant and payload is in some mentioned cases P2P ?
thanks a lot
Correct. Just move the ‘server’ to the cloud in the examples but the behavior is unchanged.
Great article. Really helpful. I have an issue though with our company, peer to peer between internal user and external contacts is working (both parties has open federation) however when adding a 3rd user on the call (turns to conference) the 3rd user is not getting the invite (ring), any advise is greatly appreciated.
I have an on-premise Skype for Business Server 2015 installed and we want to connect to an external IPPBX. We setup the mediation server. We forward TCP 5060 on both firewalls to accept incoming. Now, We can dial normally but no audio. Our IP PBX provider accept UTP 10001 to 20000 for RTP connection. Do you know how can I fix the audio issue?
I join the external lync meeting example: lync.com.
There was a question that the desktop and application share is not work. other function is normal example audio call.
Whether my lync client connected to external lync.com edge server directly？ not go through my lync server.
Is this blog post relevant for how Skype Online only ? I’m particularly interested in the communications between 2 Skype online users in a P2P video call on the same LAN.
I need to understand if the users S4B clients will still make the initial SIP/Signalling connection via the Edge Skype Online server and the rest of the media directly (providing ports/firewalls are open) for payload P2P between the 2 users. We use a Proxy for port 80 & 443 and the media/payload traverses our Microsoft express link bypassing the proxy..
Skype works the same way and it doesn’t matter if the server is on-premises or online; the clients still exhibit the same ICE behavior. Media will always attempt to take the best available path. Media should not go through a proxy.
I have skype for business 2015 on my organization I make configration to join non domain user to skype and that work I make nat configration to private ip like 192.168.1.2 to skype ip like10.10.10.2 when ping from my local network let say like 192.169.5.x to nated ip i have reply and can to join to skype now when another user in another network like 192.168.10.x can join to skype and can send message to user in 192.168.5.x network but when make call can a ring but when can not answer and the
error is network issuise
Pls any help and I am not use edge server