Demystify federation between Teams and Skype for Business

It’s been a while since my last post, but I’ve been receiving several questions about the topic lately. I therefore decided to write a post which sheds some light into the federation between Teams and Skype for Business topic.
Federation is one of the topics which is evolving quite rapidly, and what’s written today (August 2018) might change in the next months.

Let’s start with some theory and describe how federation works in Skype for Business.

 

With federation we describe the possibility to talk to external organizations which are using Skype for Business/Lync.
Every company can decide to enable federation for specific domains, block specific domains and allow the federation with everyone (open federation).

 

How to configure federation in your organization

In an on-premise environment the federation can be configured from the Control Panel:

 

In O365 the federation can be configured in the Legacy Skype for Business portal à Organization à External Communication:

 

How does the federation work?

After you enable the federation at tenant level, you might wonder how the user in domainA can talk to the user in the domainB.

When the user in domainA send a message (INVITE) to the user in the domain, this is what happens:

  • Front End server checks if the domainB is federated or not
  • If it’s federated then the message is sent to the Edge
  • The Edge will query the record _sipfederationtls._tcp.<domain> and identify the FQDN and port where the message has to be sent
  • The federated Edge receives the SIP message and verifies whether it’s on allowed list, in order to determine if domainA is allowed
  • If the domainA is allowed, the message is sent to the Front End
  • Federated Front End will look up the user endpoint and deliver the messages on all the endpoints registered for that user (eg. Windows Client, Mobile App and Mac Client).
  • Federated user receives the message and can reply

If you would like to see the server interested in the communication, you can open the Skype for Business tracing and look at the INVITE received by the client.

INVITE sip:188.153.149.35:60920;transport=tls;ms-opaque=9539207e5a;ms-received-cid=1400 SIP/2.0
ms-user-logon-data: RemoteUser
Record-Route: <sip:sip.sundait.com:5061;transport=tls;opaque=state:Ci.R1400;lr;ms-route-sig=…
Record-Route: <sip:SFB-FE01.s4blab.uc.local:5061;transport=tls;opaque=state:F;lr>;tag=BAB…
Record-Route: <sip:SFB-EDGE.S4BLAB.UC.LOCAL:5061;transport=tls;lr>;tag=2B1E6CED048D824194915EA4865DD8EC
Record-Route: <sip:sipfed.microsoft.com:5061;transport=tls;epid=211512560218;lr;ms-key-info=….

Record-Route
: <sip:000dco1sb2pl4.redmond.corp.microsoft.com:5061;transport=tls;ms-fe=000DCO1SB2FE4H….
Record-Route: <sip:000dco1sb2ed1.redmond.corp.microsoft.com:5061;transport=tls;opaque=state:Sfi;lr>;tag=2….
Record-Route: <sip:sipfed.online.lync.com:5061;transport=tls;epid=211512560218;lr;ms-key-info=AAEAAXff-t-…..
Record-Route: <sip:sippoolDB42E09.infra.lync.com:5061;transport=tls;ms-fe=DB42E09FES04.infra.lync.com;opaque…
Via: SIP/2.0/TLS 192.168.70.200:5061;branch=z9hG4bKE36FB577.12A53DF496BD0A2B;branched=FALSE;ms-internal…

Microsoft Teams supports federation but there are some scenarios that might create a bit of confusion.
Let’s dig a bit more in some of the most common scenarioss:

 

Skype for Business On-Premise and Microsoft Teams

If your organization is on-premises and Skype for Business is not configured for Hybrid, the federation with Microsoft Teams won’t work (Federation between the Skype for Business environment works).

 

 

Skype for Business Hybrid and Microsoft Teams

When we are in this scenario, we can have a Skype for Business user who can be both On-Premises or Online.
Let’s see both scenarios:

 

Skype for Business On-Premise

If the On-Premises user doesn’t have an O365 license (I’d say a quite common scenarios), the following error is returned when the Teams user triess to reach the Skype for Business user.

If the Skype for Business users tried to communicate with the Teams user, the communication will work:


In some scenarios it might happen that the Skype for Business On-Premises user also has an O365 Skype for Business license.
In this case the federation works even if the Teams user starts the communication:

In any case, because the user is homed On-Premises, unified presence is not available and the Teams user client will get the presence published by Teams (used by the Skype for Business user). If the Skype for Business user didn’t start the migration to Teams yet, the presence will be unknown (as in my screenshot above)

 

Skype for Business OnLine

Users homed in Online in a Skype for Business Hybrid implementation can talk to Teams users and vice versa (if the user is homed on-premises, unified presence won’t work and the client will get the presence available in Teams. If the user never signed in into Teams, presence will be unknown).
You might also experience communication issues in case the Skype for Business user doesn’t have an O3655 Skype for Business license assigned.



 

 

Skype for Business Online and Microsoft Teams

Users homed in Skype for Business Online can talk to Teams users and vice versa.

 

 

!Important

Remember that if you are in Island Mode (both clients with the same features installed in the same PC) the default calling and chat client is Skype for Business: if you are in this situation when a federated user sends you a message, this is received by the Skype for Business client.
If the default calling and chat client is Microsoft Teams, messages from federated users will arrive on Microsoft Teams.

 

As I was mentioning at the beginning of the post, the federation is fast evolving and getting better and better.
As of today, some of these hybrid scenarios are still in TAP or present some known issues, but as Teams has demonstrated in the past months, the federation experience is becoming more reliable and robust for those who are in On-Premises scenarios too.

Advertisements

4 thoughts on “Demystify federation between Teams and Skype for Business

  1. Hello Stafano,
    Seems I am unable to get it correctly the presence flow you have described : May be you are talking about close federation, only for allowed domains in domain A’s Front End!!
    When the user in domain A send a message (INVITE) to the user in the domain B, this is what happens:
    Front End server checks if the domain B is federated or not (Is that invite query directly supposed to hit front end of domain B??
    If it’s federated then the message is sent to the Edge
    The Edge will query the record _sipfederationtls._tcp.<domainand identify the FQDN and port where the message has to be sent (Redirection of query from domain A will work as per the federation DNS record configuration of Domain B, Right ?)
    The scenario you have explained is about close federation right??

    Like

    1. Hi Shubham, no matter if you are in open federation or not, the verification is done at FE level. If you have open federation, you are basically allowing every domain. Before reaching the FE in the day domain B, the message is “approved” by the FE in domain A, send to the edge in the domain B and eventually validated (federation configuration check). Hope this comment better clarify the scenario :).

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s