Lync and Skype for Business SIP, Media and Call Flows
Recently I have been asked a lot how the SIP and Media flow among SFB users based on various scenarios, such as Lync/Skye for Business users in the office, out of office, in the Cloud, On-premise and so on. Some seemed flummoxed how they flow once an SFB user's homing environment whether in the SFB Online or On-premise and its location in the office, out of office, on the public Internet changed. This post comes out of curiosity, interest, and answering the questions I was grappling with and sharing you all so that you could have a very good head start in understanding SIP and Media flows. Before we try to understand how they flow, it's imperative that we understand what Modality is first so that it will help us understand a very basic and fundamental "Signal and Payload" flows in Unified Communication specific to Microsoft Lync and Skype for Business perspective, at least. There is a comprehensively explained post already out there about "Modality", so I'll just repost a gist here. For further reading: http://blog.schertz.name/2014/08/understandinglync-modalities/
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.
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 Peer-to-Peer 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, no longer Peer-to-Peer once becomes MCU modal, it goes through Frontend server already.
Signaling Vs Media
Once we understood what's modality, how it flows and Signaling Vs Media, it's the right time to look at how an SFB user register itself with On-premise SFB server and Online SFB server based on its locations. Terminology 1. If a user is registered with On-premise SFB server then it's termed "on-premise SFB user". 2. SFB homed user = users who are enabled enterprise voice and on-premise user. Remark: 1 and 2 are the same, just mentioned separately as some user different terms to differentiate between the two. 3. SFB Frontend server = Skype for Business Server co-located with Mediation Server. 4. SFB Online homed user = users who are enabled enterprise voice and Hybrid Online user. 5. If a user is registered with Online SFB server then it's termed "Online SFB user". Remark: 4 and 5 are the same, just mentioned separately as some user different terms to differentiate between the two.
An SFB user has been enabled Enterprise voice in SFB On-premise server. I don't intend to have an in-depth registration process as the main theme here is all about "How SIP and Media Flow" in various scenarios.
Registration Process - Scenario-1 1. An SFB user, Kathy is residing in the SAME office LAN where an SFB Frontend Server (co-located with Mediation Server) resides and runs on-premise.
o
o
Client will look up "lyncdiscoverinternal.domain.com" record from internal DNS server to reach to SFB server on-premise, if it cannot find it, it will move on to another record, "lyncdiscover.domain.com". The SFB user registered itself with SFB server on-premise as shown above.
Registration Process - Scenario-2 2. An SFB user, Kathy is on public Internet.
o SFB on-premise user, Kathy looks up external SRV record to find Edge server and sends register request to the SFB Frontend server through Edge server. o SFB users notifies its location whether external or internal to the SFB Frontend server through Edge server. o SFB Edge server authenticates with SFB user on behalf of SFB Frontend server o Connection established as shown follow. o SFB Frontend server accepted the client's registration, took note of "where is the client currently residing based on where it registered from. o This is important to understand how an SFB server knows where the client is residing currently, and subsequently where it should send the traffic to, internal or external after looking up the client registration information.
It's worth mentioning general rules to determine optimal SIP and Media flows. o The SFB user always try to reach out to the Mediation Server where it's homed, first of all. o The SFB is tracing/looking for the “target destination” and how to reach it, through which path(s). o No media path involved between Edge and Frontend server as long as both user are located in the same LAN environment where Frontend and Edge severs are running. o The mediation path is between only Frontend server(s) and user(s) and Frontend server(s) and gateway(s) as long as both user are located in the same LAN environment where Frontend and Edge severs are running. o There is no direct signaling and media flows between user(s) and gateway(s). It always goes through Mediation Server. o Lync clients do not and cannot send signaling messages directly to each other. It always goes through Mediation Server. o If the user is on public internet, the media will relay through Edge on behalf of FE to client. Media always uses and prefers shortest path possible. o Reverse Number Lookup (RNL) is done by the FE server where the user is homed, for example SFB on-premise server will perform RNL if the SFB user is homed on-premise. Likewise, SFB Online server will perform RNL if the SFB user is homed Online SFB. o If integrated with on-premise PSTN, when call or called, there is no media path from SFB Online servers though the users are homed SFB Online. o If Mediation server is not reachable directly, media path is most likely through the on-premises Edge Server; if not, between the online and on-premises Edge Servers. o Media Bypass occurs only when users and media gateway are on the same subnet and having matching Bypass ID.
On-Premise SFB server with PST Gateway Scenario-1 Communication between two SFB users when both are residing in the same network as of SFB server.
o
o
o o
Kathy calls John both are residing in the same LAN and both are on-premise users, she signals her intention to talk to John to SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. SFB Frontend performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with John in a local database, and noticed that John is currently residing in the same network based on his latest registration. Then the SFB server exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. The two SFB users are now connected and optimal media path has been established as peer-to-peer as both users are located in the same network
Scenario-2 Communication between two SFB users when one user is residing in the same network as of SFB server and the other user is on public Internet.
o
o
o
o o
Kathy calls John both are residing in the separate network, she signals her intention to talk to John to SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. SFB Frontend performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with John in a local database, and noticed that John is currently residing in outside network based on his latest registration. Unlike previous scenario, the receiving end is on public network, so the Edge server is acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and John. Then the Edge server exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. The two SFB users are now connected and optimal media path has been established through on-premise Edge server as both are on separate network.
Scenario-3 Communication between two SFB users when both users are residing on public Internet.
o
o o
o o
o
Kathy calls John both are on-premise server but residing on public Internet, she signals her intention to talk to John to SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list through on-premise Edge server. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and John relays SIP messages to the Frontend Server. SFB Frontend performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with John in a local database, and noticed that both Kathy and John are currently residing in outside network based on their latest registration. The Edge server is acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB relays the SIP messages to John. John exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list with the on-premise Edge sever which in turn relay them to the Frontend server. The two SFB users are now connected and optimal media path has been established through the on-premise Edge server.
Hybrid - Online SFB and on-premise SFB with PSTN GW Registration Process - Scenario-1 - SFB Online user residing in on-premise network.
o
o o
o
o o
Keith, Online SFB user, logs into his computers, and his SFB client is configured to automatic configuration. For automatic login, there will be an SRV record created on the SIP domain, for example, _sipinternaltls._tcp.contoso.com or lyncdisover.contoso.com. Then this happens. Keith's client performs a DNS SRV record lookup. Because Keith is accessing form inside the corporate network, the internal DNS SRV record will be returned. This resolves to the on-premises SFB deployment. Keith will then authenticate to the on-premise pool. The SFB on-premise pool will redirect Keith with a SIP 301 to the SFB Online service. It knows to do this because of Keith’s AD attribute, "msRTCSIPDeploymentLocator" Keith will then register against SFB Online environment. For Keith to successfully register with the SFB Online service, he needs to have access to the Internet so that he can reach the service.
Registration Process - Scenario-2- SFB Online user residing on public Internet.
o
o o
o
o o
Keith, SFB Online user logs into his computers, and his SFB client is configured to automatic configuration. For automatic login, there will be an SRV record created on the SIP domain, for example, _sipinternaltls._tcp.contoso.com or lyncdisover.contoso.com. Then this happens. Keith's client performs a DNS SRV record lookup Because Keith is accessing form outside corporate network, the external DNS SRV record will be returned. This resolves to the on-premises Edge server. Keith will then authenticate to the on-premise Frontend server through Edge server. The SFB on-premise pool will redirect Keith with a SIP 301 to the SFB Online service. It knows to do this because of Keith’s AD attribute, "msRTCSIPDeploymentLocator" Keith will then register against SFB Online environment. For Keith to successfully register with the SFB Online service, he needs to have access to the Internet so that he can reach the service.
Scenario-1 Communication between on-premise homed user and Online SFB homed user located in the same local network.
o
o
o
o o
o
o
Kathy, on-premise user calls Dave, Online SFB user and both are residing in the same local network, she signals her intention to talk to Dave to SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. SFB Frontend performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with Dave in a local database, and noticed that Kathy is currently residing in the local network based on her latest registration information. The SFB on-premise pool will redirect Dave with a SIP 301 to the SFB Online service. It knows to do this because of Dave’s AD attribute, "msRTCSIPDeploymentLocator" through on-premise Edge server. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and Online SFB server. Online SFB server performs authentication and "noticed that both Kathy and Dave are currently residing in the local network based on his last registration information. SFB Online server sends and exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list directly with Dave. The two SFB users are now connected and optimal media path has been established peer-to-peer as they are located in the same network.
Scenario-2 Communication between on-premise homed user located in the local network and Online SFB homed user located on public internet.
o
o
o
o o
o
Kathy residing on-premise calls Keith, SFB Online user who is residing on public network, she signals her intention to talk to Keith to SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. SFB Frontend performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with Keith in a local database, and noticed that Kathy is currently residing in the local network based on her latest registration. The SFB on-premise pool will redirect Keith with a SIP 301 to the SFB Online service. It knows to do this because of Keith’s AD attribute, "msRTCSIPDeploymentLocator" through on-premise Edge server. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and Online SFB server. Online SFB server performs authentication and noticed that Keith Dave is currently residing on public network based on latest registration and by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. The two SFB users are now connected and optimal media path has been established through on-premise Edge server as both users are located in a separate network.
Scenario-3 Communication between on-premise homed user located on the public internet and Online SFB homed user located in the local LAN.
o
o
o o
o
Keith Online SFB user residing on-premise calls Kathy, on-premise user who is residing on public network, he signals his intention to talk to Kathy to Online SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list directly to SFB Online server. Online SFB server performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with Kathy in a local database, and noticed that Kathy is on-premise user and communicate with on-premise Edge server which in turn will redirect the SIP messages to on-premise SFB server. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and Online SFB server. On-premise SFB server knows that Kathy is currently in outside network based on her latest registration information and exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. The two SFB users are now connected and optimal media path has been established through on-premise Edge server as both users are located in a separate network.
Scenario-4 Communication between both Online SFB homed user located on public Internet.
Keith Online SFB user residing on public Internet calls Kathy, also Online SFB user who is also residing on another public internet, he signals his intention to talk to Kathy to Online SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. Online SFB server performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with Kathy in a local database, and noticed that Kathy is on a public internet based on her latest registration information and exchanges series of SIP messages including Session Description Protocol detailing about Media and its candidates list with her. The two SFB users are now connected and optimal media path has been established through Online SFB server.
Scenario-5 Communication between both Online SFB homed users located in on-premise network.
o
o
o
Kathy, Online SFB homed user residing in on-premise network calls Keith, SFB Online user who is also residing in the same on-premise network, she signals her intention to talk to Keith to Online SFB Frontend Server by exchanging a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. Online SFB server performs authentication and "Reverse Number Lookup (RNL)" and found a matched number associated with Keith in a local database, and noticed that both Kathy and Keith are in the same on-premise network based on their latest registration information and exchanges series of SIP messages including Session Description Protocol detailing about Media and its candidates list with Keith. The two SFB users are now connected and optimal media path has been established through Online SFB server as peer-to-peer as both users are located in the same on-premise network.
Incoming and Outgoing PSTN Calls Scenario-1 Incoming PSTN call while Online SFB homed user on public network.
o o
o
o o
o
A PSTN incoming call hits PSTN Gateway. The PSTN Gateway lookups the configuration and knows that on-premise SFB Frontend server is responsible for the called number, and sends and exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list. On-premise SFB server performs "Reverse Number Lookup (RNL)" and found a matched number associated with John in a local database, and redirect John with a SIP 301 to Online SFB server through Edge server since he is an Online SFB user. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and Online SFB server. Online SFB server notices that John is on outside network based on his latest registration information and exchanges series of SIP messages including Session Description Protocol detailing about Media and its candidates list with him directly. The caller and receiver, John are now connected and optimal media path has been established through on-premise Edge server as both caller and callee (receiver) are located in the separate public network.
Scenario-2 Outgoing PSTN call while Online SFB homed user on public network.
o o
o
o o
o
A PSTN outgoing call is made by Online SFB homed user, John. John sends and exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list signaling to Online SFB server that he is making a call. Online SFB server performs authentication and "Reverse Number Lookup (RNL)" and found no matched number associated with the called number in its local database, and noticed that John is on public network and connect John with on-premise SFB through on-premise Edge server. Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend) between Frontend SFB and Online SFB server. On-premise SFB server sends and exchanges a series of SIP messages including Session Description Protocol detailing about Media and its candidates list signaling to the receiver through local PSTN gateway as it knows that this call is for PSTN network. The PSTN Gateway lookups the configuration and knows that this call is for PSTN network and send ands exchanges a series of SIP messages including
o
Session Description Protocol detailing about Media and its candidates list signaling to the receiver on the other end through PSTN service provider. The caller, John and PSTN end receiver are now connected and optimal media path has been established through on-premise Edge server as both caller and callee (receiver) are located in the separate public network.
Scenario-3 Incoming PSTN call while Online SFB homed user in local on-premise network.
Scenario-4 Outgoing PSTN call while on-premise SFB server homed user in local on-premise network.
Scenario-5 Outgoing PSTN call while on-premise SFB server homed user is on public network.
