Page 1
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/understanding-
lync-modalities/
Page 2
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.
Page 3
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.
Page 4
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 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".
o The SFB user registered itself with SFB server on-premise as shown above.
Page 5
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.
Page 6
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.
Page 7
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 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.
o 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.
o Then the SFB server exchanges a series of SIP messages including Session
Description Protocol detailing about Media and its candidates list.
o 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
Page 8
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 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.
o 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.
o 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.
o Then the Edge server exchanges a series of SIP messages including Session
Description Protocol detailing about Media and its candidates list.
o 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.
Page 9
Scenario-3
Communication between two SFB users when both users are residing on
public Internet.
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.
o 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.
o 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.
o 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.
o 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.
o The two SFB users are now connected and optimal media path has been
established through the on-premise Edge server.
Page 10
Hybrid - Online SFB and on-premise SFB with PSTN GW
Registration Process - Scenario-1 - SFB Online user residing in on-premise network.
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.
o Keith's client performs a DNS SRV record lookup.
o 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.
o 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, "msRTCSIP-
DeploymentLocator"
o Keith will then register against SFB Online environment.
o 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.
Page 11
Registration Process - Scenario-2- SFB Online user residing on public Internet.
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.
o Keith's client performs a DNS SRV record lookup
o 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.
o 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, "msRTCSIP-
DeploymentLocator"
o Keith will then register against SFB Online environment.
o 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.
Page 12
Scenario-1
Communication between on-premise homed user and Online SFB homed user
located in the same local network.
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.
o 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.
o 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, "msRTCSIP-
DeploymentLocator" through on-premise Edge server.
o Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend)
between Frontend SFB and Online SFB server.
o 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.
o 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.
o 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.
Page 13
Scenario-2
Communication between on-premise homed user located in the local network and
Online SFB homed user located on public internet.
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.
o 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.
o 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, "msRTCSIP-
DeploymentLocator" through on-premise Edge server.
o Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend)
between Frontend SFB and Online SFB server.
o 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.
o 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.
Page 14
Scenario-3
Communication between on-premise homed user located on the public internet and
Online SFB homed user located in the local LAN.
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.
o 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.
o Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend)
between Frontend SFB and Online SFB server.
o 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.
o 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.
Page 15
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.
Page 16
Scenario-5
Communication between both Online SFB homed users located in on-premise
network.
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.
o 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.
o 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.
Page 17
Incoming and Outgoing PSTN Calls
Scenario-1
Incoming PSTN call while Online SFB homed user on public network.
o A PSTN incoming call hits PSTN Gateway.
o 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.
o 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.
o Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend)
between Frontend SFB and Online SFB server.
o 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.
o 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.
Page 18
Scenario-2
Outgoing PSTN call while Online SFB homed user on public network.
o A PSTN outgoing call is made by Online SFB homed user, John.
o 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.
o 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.
o Edge server acting as a SIP Proxy and Media Relay (On behalf of Frontend)
between Frontend SFB and Online SFB server.
o 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.
o 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
Page 19
Session Description Protocol detailing about Media and its candidates list
signaling to the receiver on the other end through PSTN service provider.
o 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.
Page 20
Scenario-4
Outgoing PSTN call while on-premise SFB server homed user in local on-premise
network.
Page 21
Scenario-5
Outgoing PSTN call while on-premise SFB server homed user is on public network.
