Anonymous join from Skype for Business and Lync clients

Overview

I work with many customers and partners on Skype for Business and Lync and one of the areas that I focus on is online meetings. One question that comes up quite frequently is "can I use my Skype for Business or Lync client to join a meeting anonymously".

In short the answer is "yes" however there are many different situations and scenarios that both the meeting attendee and the meeting organizer may find themselves in. The purpose of this blog is to better explain how this anonymous join process works and to give the reader as much detail and background as I can on all the different things that you need to think about when looking at the process of joining a meeting anonymously.

Skype for Business and Lync (both 2013 and 2010 and Lync for Mac) can be used to join meetings anonymously if you are already signed in with your own Skype for Business or Lync account. This anonymous join scenario is only needed if you are trying to join a meeting hosted by a company that you are not federated with. Here is an overview of how this works is as follows:

• Client sends an INVITE message to your front end server with a request to join a meeting
• Server determines that you are not federated with the domain that the meeting organizer resides in
• Server responds with a SIP message and Diagnostic code indicating that you are not federated with the organizer's domain
• Client interprets the SIP message and Diagnostic code and decides if it should try to join anonymously
• Client does a DNS lookup to determine where to send the anonymous INVITE to
• Client sends an anonymous INVITE to the meeting organizer's Edge server in an attempt to join the meeting
• Client joins you to the meeting as an anonymous user and the word "Guest" appears next to your name in the meeting roster

There are actually many combinations of meeting join scenarios and they all differ depending on where the meeting attendee and organizer are homed. Each of these different combinations will produce a slightly different set of log files on the client however ultimately each one of them should result in either a meeting join or a successful anonymous join. This blog post focuses on the sip invite portion anonymous meeting join and does not cover media connectivity for audio and video. I will cover that part in a future blog post.

If you are interested to see how anonymous join works when you have a Lync 2013 client that is not signed in please see my previous my blog post on anonymous join via LWA - http://blogs.technet.com/b/scottstu/archive/2014/10/30/lync-2013-now-supports-falling-back-to-the-lync-web-app.aspxas we will not be covering that scneario here.

Requirements

The meeting attendee's client must be

• Able to look up SRV records in the meeting organizer's DNS domain if they are using SRV records for remote user access or must be able to look up A (host) records if the meeting organizer's company is using A (host) records for remote user access
• Able to connect directly to meeting organizer's edge server via the remote access port (typically 443 but sometimes 5061)
• Able to trust the certificate presented by the meeting organizer's edge server
• Running an appropriate client that supports anonymous join fallback (Lync 2013, Lync 2010 and Lync for Mac)

The meeting organizer's organization must have the following configuration

• Have anonymous meetings enabled for the meeting organizer
• Allow remote user access on their access edge server on the port defined in their SRV record or via port 443 or port 5061
• Have appropriate SRV records or A (host) records configured in their external DNS server
• Have configured an appropriate certificate on their edge server that is issued via a public certificate authority

Anonymous join walk through

In this section we will discuss the steps that the client takes in order to join a meeting anonymously and we will review it step by step looking at an example.

The original meeting invite that the client sends to join a federated meeting is sent via its own front end server however if the user is connected via an Edge serer then the message will be sent via the Edge. The user's front end server will determine if the user is enabled for federation or not. If they are not enabled the front end server sends back a SIP response that contains a specific ms-diagnostics value.

In this section we will walk through an example meeting join sequence where you will see the meeting attendee is karen@contoso.com and the meeting organizer is garth@tailspintoys.com.

SIP Message 1 shows a partial segment of the original invite sent by Karen to Garth.

--------------------------

03/30/2015|13:36:59.928 16EC:1030 INFO :: Sending Packet – 209.216.129.2:443 (From Local Address: 192.168.1.200:52952) 2067 bytes:

03/30/2015|13:36:59.928 16EC:1030 INFO :: INVITE sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ SIP/2.0

Max-Forwards: 70

From: <sip:karen@contoso.com>;tag=9004006031;epid=23c6af65b1

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>

CSeq: 1 INVITE

Contact: <sip:karen@contoso.com;opaque=user:epid:LKHrZjUoxV66Oi8tgk1A9gAA;gruu>

User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)

Supported: ms-dialog-route-set-update

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

Content-Type: application/cccp+xml

Content-Length: 1008

<?xml version="1.0"?>

<request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ" from="sip:karen@contoso.com" requestId="387792480"><addUser>

--------------------------

SIP Message 1 – Invite sent by karen@contoso.com to join a meeting organized by garth@tailspintoys.com

As you can see in SIP Message 1 the from: tag shows karen @contoso.com while the to: tag shows garth@tailspintoys.com and the message is being sent to IP address 209.216.129.2 which is the IP address of Karen's edge server.

At this point Karen's front end server determines that federation is not enabled and sends the response that you can see in SIP Message 2 below.

--------------------------

03/30/2015|13:28:27.682 16EC:1030 INFO :: Data Received -209.216.129.2:443 (To Local Address: 192.168.1.200:52952) 1033 bytes:

03/30/2015|13:28:27.682 16EC:1030 INFO :: SIP/2.0 504 Server time-out

ms-user-logon-data: RemoteUser

Authentication-Info: TLS-DSK qop="auth", opaque="21A773E9", srand="5EA20BA7", snum="33", rspauth="e4e881d3db7c97b7b49d552966315c3b5d0481d6", targetname="server.contoso.com", realm="SIP Communications Service", version=4

Via: SIP/2.0/TLS 192.168.1.200:52952;received=42.157.86.172;ms-received-port=52952;ms-received-cid=2C00

Content-Length: 0

From: "Karen Berg"<sip:karen@contoso.com>;tag=0fa5a85424;epid=23c6af65b1

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>;tag=BA6EAB929067DF296876B3B74D35748D

Call-ID: ab166f84d6db431c8c461da04d3c3407

CSeq: 1 INVITE

ms-diagnostics: 1017;reason="Cannot route From and To domains in this combination";summary="Cannot route between the source and destination domains because partner discovery is not enabled";external-domain="tailspintoys.com";external-type="domain-type-remote";internal-domain="contoso.com";internal-type="domain-type-local";source="sipfed.contoso.com"

Server: RTC/5.0

--------------------------

SIP Message 2 – Server response received by karen@contoso.com.

Karen's client receives a SIP 504 response code along with a 1017 diagnostic code and now knows that it should invoke the anonymous join process.

In general the client examines the SIP response and diagnostic code it receives back and triggers the anonymous join process if it finds a valid response code OR a valid ms-disagnostics code.

All valid response and ms-diagnostic codes are as follows:

Table 1 – Valid response and ms-diagnostic codes

Now that the client has decided to join anonymously it must determine where to deliver the new anonymous meeting invite to. The client leverages the same functionality that would be used by to sign in to Skype for Business as a remote user in the meeting organizer's domain.

If you look in the sip traces of the client log file you will notice that Karen's client has started to query DNS to determine how to deliver this anonymous invite. Trace Message 1 below shows the first record that Karen looks for.

--------------------------

QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tailspintoys.com]

--------------------------

Trace Message 1 – DNS query for _sipinternaltls record

Karen's client will continue querying these DNS records until it is successful in finding a destination. The DNS records that it will search are:

• _sipinternaltls._tcp.tailspintoys.com
• _sip._tls.tailspintoys.com
• sipinteral.tailspintoys.com
• sip.tailspintoys.com
• sipexternal.tailspintoys.com

If it receives a result for the SRV record it will use the port that was provided however if it only succeeds in matching an A record the client will try to connect on port 443 and then on port 5061.

In our example Karen's client receives a DNS response for _sip._tls.tailspintoys.com which returns a host record of sip.tailspintoys.com on port 5061. Karen's client then resolves the value of sip.tailspintoys.com to the IP address 206.555.123.456.

SIP Message 3 shows a partial segment of the anonymous invite sent by Karen to Garth.

--------------------------

03/30/2015|13:37:01.769 16EC:1030 INFO :: Sending Packet - 206.555.123.456:5061 (From Local Address: 192.168.1.200:53025) 2050 bytes:

03/30/2015|13:37:01.769 16EC:1030 INFO :: INVITE sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ SIP/2.0

Via: SIP/2.0/TLS 192.168.16.221:53025

Max-Forwards: 70

From: "Karen Berg" <sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid>;tag=1152deba20;epid=4edd74c4be

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>

CSeq: 1 INVITE

Contact: <sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid>;proxy=replace;+sip.instance="<urn:uuid:CC4F4797-4760-58C5-8CAB-8AB72E4546BC>"

User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)

Supported: ms-dialog-route-set-update

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

Content-Type: application/cccp+xml

Content-Length: 1121

<?xml version="1.0"?>

<request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ" from="sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid" requestId="387813728"><addUser>

--------------------------

SIP Message 3 – Anonymous Invite sent by karen@contoso.com to join a meeting organized by garth@tailspintoys.com

As you can see in SIP Message 3, the from: tag shows 36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid while the to: tag still shows garth@tailspintoys.com. The message is being sent to IP address 206.555.123.456 which is the IP address of Garth's tailspintoys.com edge server. You will also notice that Karen's client has extracted her display name and sent that in the from: tag which is how her name will appear in the roster when she has joined the meeting as shown in Figure 1 below.

Figure 1 – Meeting window showing Karen joined as a Guest

That is all there is to it! We have walked through a step by step example that shows how the anonymous meeting join works.

Common Meeting Join Scenarios

As you may have noticed in the above example I didn't specifically say where the meeting attendee and the meeting organizer were homed. Lync (and soon to be Skype for Business) is available in both an on-premises version via Lync Server 2013 or Lync Server 2010 as well as in a service model via Lync Online. There are many scenarios in which a user may be trying to join a meeting that is organized by a user in another organization that is hosted in a different domain.

Table 2 below shows some of the most common combinations of meeting join scenarios.

Table 2 – Meeting join scenarios

The reason that it is important to understand these various scenarios is due to the fact that the SIP response codes returned by the meeting attendee's registrar server will vary depending on whether the user is homed on-premises or if they are homed online. The response received will also vary depending on how the federation setting is configured in both environments.

We will now look at 4 specific combinations of meeting attendee/organizer.

Scenario 1

Table 3 – Scenario 1

ms-diagnostics: 1017;reason="Cannot route From and To domains in this combination";summary="Cannot route between the source and destination domains because partner discovery is not enabled";external-domain="tailspintoys.com";external-type="domain-type-remote";internal-domain="contoso.com";internal-type="domain-type-local";source="sipfed.contoso.com"

ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="tailspintoys.com";PeerServer="sip.tailspintoys.com";source="sipfed.contoso.com"

ms-diagnostics: 1064;reason="Cannot route to blocked domain";domain="tailspintoys.com";suffix="tailspintoys.com";source="sipfed.contoso.com"

Scenario 2

Table 4 –Scenario 2

Note– The results shown in Table 4 above assume that you have configured a hosting provider pointed to sipfed.online.lync.com. If you do not have this hosting provider configured then some of the scenarios may produce different results.

ms-diagnostics: 1028;reason="Domain resolved by DNS SRV to a configured hosting service but the domain is not in the allow list";domain="contoso.onmicrosoft.com";fqdn1="sipfed.online.lync.com:5061";source="sipfed.contoso.com"

ms-diagnostics: 1036;reason="Previous hop shared address space peer did not report diagnostic information";Domain="contoso.onmicrosoft.com";PeerServer="sipfed.online.lync.com";source="sipfed.contoso.com"

ms-diagnostics: 1064;reason="Cannot route to blocked domain";domain="contoso.onmicrosoft.com";suffix="contoso.onmicrosoft.com";source="sipfed.contoso.com"

Scenario 3

Table 4 –Scenario 3

ms-diagnostics: 1002;reason="From URI not authorized to communicate with federated partners";from-uri="garthf@contoso.onmicrosoft.com";destination="karenb@contoso.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="contoso.com";PeerServer="sipfed.contoso.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 27000;reason="To-Uri Domain is not in the sender-tenant allow list";source="SN20A05FES03.INFRA.LYNC.COM";appName="OutgoingFederation"

Scenario 4

Table 5 –Scenario 4

ms-diagnostics: 1002;reason="From URI not authorized to communicate with federated partners";from-uri="garthf@contoso.onmicrosoft.com";destination="bonniek@tailspintoys.onmicrosoft.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 4033;reason="To User not authorized for Federation";processing-cluster="sippooldm21a05.infra.lync.com";processing-frontend="DM21A05FES06.infra.lync.com";target-user-primary-pool="sippooldm21a05.infra.lync.com";source="DM21A05FES06.infra.lync.com"

ms-diagnostics: 27000;reason="To-Uri Domain is not in the sender-tenant allow list";from-uri="garthf@contoso.onmicrosoft.com";destination="bonniek@tailspintoys.onmicrosoft.com";source="sipfed0A.online.lync.com"

Federation Configuration

The various meeting join scenarios described above showed various federation configuration settings so we will now describe how to configure each of them.

On premises Configuration – Allowing Domain Federation

There are methods that a Lync on-premises administrator can use in order to configure an "allowed" domain for federation. The following section will cover those different methods and provide details on how to configure each.

Partner Domain Discovery

In this scenario the administrator can allow "partner domain discovery" which means that the target domain is not added directly but rather it is allowed to be discovered. The partner company must publish an SRV record for _sipfederationtls._tcp.domain.com in order for this to work.

To do this navigate to the "Access Edge Configuration" tab that is located under the Federation and External Access tab in the Lync Server control panel and check the box next to Enable partner domain discovery as shown in Figure 2 below.

Figure 2 – Configuring partner domain discovery

Allowed Domain

If you choose not to enable partner domain discovery as documented above then you should navigate to the "Access Edge Configuration" tab that is located under the Federation and External Access tab in the Lync Server control panel and uncheck the box next to Enable partner domain discovery as shown in Figure 3 below.

Figure 3 – Disabling partner domain discovery

If you have disabled partner domain discovery then you must specifically add the federated domain to the SIP Federated Domains tab as shown in Figure 4 below where we have allowed contoso.com.

Figure 4 – Allow domain federation with contoso.com

On premises Configuration – Blocking Domain Federation

There are three ways to block domain federation and which one you choose depends on whether or not you want to block federation completely or whether or not you want to block it for a specific domain.

1. Uncheck the Enable federation and Public IM connectivity check box under the Access Edge Configuration tab.

If you choose this option then you are blocking federation for all domains and can't turn on or off a specific domain. To do this uncheck the box next to Enable federation and public IM connectivity as shown in Figure 5 below.

Figure 5– Disabling federation and public IM connectivity

2. Disable partner domain discovery and not allow a specific domain

If you choose this option you should uncheck the box next to Enable partner domain discovery as shown in Figure 6 below. With this configuration set and no domains configured in the SIP Federated Domains tab then you have disabled federation with all domains.

Figure 6– Disabling partner domain discovery

3. Enable partner domain discovery but block a specific domain

If you choose this option you should check the box next to Enable federation and public IM connectivity as shown in Figure 7 below.

Figure 7 – Configuring partner domain discovery

You should also add the domain that you want to block to the list under SIP Federated Domains as shown in Figure 8 below.

Figure 8 – Adding northwindtranders.com as a blocked domain

Online Configuration – Allowing Domain Federation

There are a few ways to allow domain federation in Lync Online.

1. On except for blocked domains

To allow federation to all domains you should navigate to the organization/external communications tab in the Lync Admin center and select On except for blocked domains as shown in Figure 9 below.

Figure 9 – Configuring On except for blocked domains access in Lync online admin center

2. On only for allowed domains

To allow federation in an online tenant you should navigate to the organization/external communications tab in the Lync Online control panel and select "On only for allowed domains" as shown in Figure 9 below. You also need to specifically add the domain to the list of allowed domains as shown in Figure 10 below.

Figure 10 – Configuring On only for allowed domains in Lync online admin center

Note: When making changes to the external access configuration in Lync Online the changes do not take effect immediately. It can take up to 30 – 45 minutes for the changes to take effect.

Configuring Anonymous Meeting Access

On-premises configuration

To configure anonymous meeting join on a user's conferencing policy navigate the Conferencing tab on Lync Server Control Panel. From there go to the Conferencing Policy sub tab and make sure to check the box next to All participants to invite anonymous users.

Figure 11 – Configuring anonymous user access

If you try to join a meeting as an anonymous user and the meeting organizer has not been assigned a conferencing policy that enables permits anonymous join as show in Figure 11 above then you will get an error as shown in Figure 12 below.

Figure 12 – Anonymous join error message

Conclusions

I hope that this document has helped you understand the anonymous join process that exists in the Lync client today and the required configuration pieces that need to be in place to make it work. Please review the blog post and let me know you have any thoughts/comments as I do read them all and will make adjustments if needed.

Special thanks to the Boston MTC for their support in my testing of these scenarios.

Thanks for reading.

Scott