CMS Architectures for SfB Interoperability

Reference Architectures for Cisco and Microsoft Interoperability

Introduction 

Cisco Systems and Microsoft provide popular tools for allowing businesses to effectively communicate, and enterprises have widely adopted the solutions from both vendors. In many cases, standard protocols allow seamless integration between these tools, however Cisco and Microsoft have also created proprietary protocols which must interwork with each other. The purpose of this document is to provide suggested interoperability architectures which can overcome the challenges of cross-vendor integration. 

• Collaboration solutions can be broadly divided into the following categories: 
• Audio only communication using desk phones and soft clients 
• Audio/video communication using video endpoints and soft clients 
• Group meetings between audio only and audio/video participants 
• Email 
• Instant messaging (chat) and presence status 
• Business to business communication involving all of the above methods

Support for these communication functions can be provided on premise, through a cloud service, or a combination of both. When all of the collaboration tools and deployment options are taken into account, numerous architectural options emerge, 

The Cisco Collaboration Solutions Architecture

Cisco Systems has been the world leader in “call control” through the Cisco Unified Communications Manager (CUCM), and also the acquired Tandberg Video Communications Server (VCS) which has been renamed “Expressway”. Cisco’s currently preferred architecture is centered on both of these components as shown in the following diagram from their latest CVD for release 11.6. 

Cisco is predominately based on standard SIP and H.323 call control protocols, but also supports other variants where required to interoperate with third parties. 

The Microsoft Collaboration Solutions Architecture 

Microsoft’s core strength in enterprise communications has always been through their Exchange email system, and to some extent their Lync call control for desktop clients. They have evolved this over time by acquiring Skype to replace Lync, and focusing on cloud services to provide a complete solution today. The diagrams below show the basic components for a Microsoft A/V/IM&P collaboration solution. 

These components can be deployed on premise, in the cloud, or in a hybrid combination. Notice that Microsoft’s MCUs use a non-standard “Microsoft SIP variant”, which is supported by Cisco’s Expressway servers. 

Microsoft and Polycom 

Microsoft has partnered with Polycom to provide SIP and H.323 interoperability with their proprietary protocols using a solution called “Polycom RealConnect”, which is also available on premise, as a cloud service, or as a hybrid. The following diagram nicely illustrated the four possible combinations: 

Cisco and Acano 

Cisco Systems acquired Acano 2 years ago in order to replace their on premise MCUs with a new model renamed the “Cisco Meeting Server” (CMS) that provides numerous features, including interoperability with Skype for Business: 

• Highly scalable MCU for ad-hoc, scheduled, and permanent video conference resources 
• Support for personal meeting spaces with integration to Active Directory 
• Lync/Skype interworking for point-to-point calls, and calls into a single meeting 
• Support for WebRTC   
• Meeting recorder and streamer 

 Basic A/V calling between Cisco and Microsoft endpoints 

Now let’s look at step one, which is to support calls between Standard and Microsoft SIP. The Cisco Meeting Server contains gateway functionality that interworks standard SIP and the Microsoft SIP variant, therefore it must be placed in every call path between the dissimilar endpoints. This can be accomplished in different ways using route patterns and search rules depending on the topology, taking into consideration both on premise and remote parties 

Basic on premise A/V call flows 

The following table shows the on premise call control components involved in calls between Telepresence standard SIP, H.323 (e.g. Polycom) endpoints, and SfB SIP endpoints. 

	Telepresence SIP EP	Telepresence H.323 EP	Skype Client
Telepresence SIP EP	CUCM	Expressway-Core	CUCM and CMS
Telepresence H.323 EP	Expressway-Core	Expressway-Core	Expressway-Core and CMS
Skype Client	SfB servers, CUCM and CMS	SfB servers, CUCM and Expressway	SfB Servers

The topology for this basic use case, considering clustered CMS servers for scalability and HA, is shown below. Note that there are four separate SIP domains (CUCM, Expressway-Core, CMS, and SfB): 

Point to point calls between CUCM and SfB 

The SIP call flow for the topology depicted above is as follows: 

1. Standard SIP EP registered on CUCM dials an SfB SIP URI <user>@skype.company.com. This may be a video endpoint or an audio only desk phone. 

2. CUCM has a SIP Route Pattern that routes the call to the CMS standard SIP trunk. 

3. CMS has an Inbound Call Forwarding and associated Outbound Call rule that routes the call to the SfB FE server. Since this “trunk” is identified as “Lync” type in the CMS configuration, CMS automatically knows it must interwork the two sides. 

4. The same thing happens in reverse for SfB calls to standard SIP URI “<user or number>@video.company.com”. 

5. Note the importance of maintaining separate SIP domains for CUCM and SfB to aide in the call routing. 

Calls into a CMS Conference Bridge 

A similar call flow as above takes place for calls that terminate on a CMS conference bridge meeting “space”, which is standard SIP: 

1. Standard SIP EP dials a meeting URI <user or number>@meet.company.com. 

2. CUCM has a SIP Route Pattern or DN Route Pattern that routes the call to the CMS standard SIP trunk. 

3. Again note that the CMS spaces are in a separate SIP domain “meet.company.com”. 

4. CMS recognizes the inbound call as a URI associated with a meeting space and joins the call without needing to interwork it. 

5. The same thing happens in reverse for SfB calls to the same standard SIP URI “<user or number>@meet.company.com”, except in this case CMS knows again to interwork the call. 

H.323 endpoint calls from Expressway-Core 

The H.323 call flow for the topology depicted above is as follows: 

1. H.323 EP dials an SfB SIP URI <user>@skype.company.com. 

2. Expressway-Core has a Search Rule that routes the call to the CMS standard SIP trunk and automatically knows to interwork H.323 and standard SIP. 

3. CMS has an Inbound Call Forwarding and associated Outbound Call rule that routes the call to the SfB FE server. Since this “trunk” is identified as “Lync” type in the CMS configuration, CMS automatically knows it must interwork the two sides. 

4. The same thing happens in reverse for SfB calls to H.323 ID “<user or number>@vcs.company.com”. 

Variations in dial plans 

The architecture just described makes use of four separate SIP domains to aide in URI call routing. Sometimes this is not possible due to legacy dial plan implementations. For example, the CUCM TLD and Skype SIP domains may already be the same (not recommended), and workarounds would need to be implemented in the user calling process. A real implementation may resort to making use of DN route patterns instead of relying on separate SIP domains, which is more cumbersome to maintain. 

PSTN calls 

A PSTN gateway trunk and associated dial plan could be added to CUCM which would allow all endpoint types to utilize PSTN dialing. 

Presentation Sharing 

During interworked calls, users can share presentations as normal, because the CMS also automatically interworks the BFCP protocol and Microsoft RDP protocol across the presentation video channel. 

CMS Conference Types 

The CMS supports the following conference types which are known as “spaces”: 

1. Ad-hoc escalation from CUCM 

1. CMS can be configured as a CFB with an associated MRGL on CUCM 

2. Permanent bridges 

3. Scheduled meetings 

1. Only scheduled meetings would require TMS and possibly TMSXE (for Exchange integration) 

4. Personal meeting spaces 

1. Requires integration with Active Directory/LDAP to assign user spaces (cannot be assigned manually). 
   
   

Meetings between Telepresence and Skype for Business Participants 

The CMS contains the single meeting conference bridge mentioned in the prior call flows, which can be joined by either standard SIP or SfB participants. The user experience for both types is the CMS participant layout as normally seen on a Telepresence video call. 

In order to preserve the native SfB experience, the CMS dual homing feature can be used to essentially cascade the CMS MCU with the on premise Microsoft AVMCU.  

Dual homed meeting workflow for on premise SfB 

Note that the TMS and TMSXE are optional for this workflow, but the IVR feature of CMS must be used. 

1. An SfB user schedules a meeting through Outlook/Exchange inviting both users with SfB clients, and users with Telepresence endpoints. 

2. Exchange sends an email to all participants which includes the SfB meeting ID 

3. SfB users join the meeting as any other SfB meeting. 

4. TP users dial the CMS IVR, and then enter the SfB conference ID contained in the email. 

5. The TP user is placed into a CMS space automatically created for the dual homed feature. 

6. CMS performs a lookup of the SIP URI associated with the SfB meeting ID through the SfB FE server, and then places a cascade call from its local meeting space and the S4b meeting. 

7. TP participants and SfB participants have their native experience preserved. 

Instant Messaging and Presence 

SfB Cloud (O365) 

Integration with SfB cloud can be accomplished by adding the Expressway-Edge component to the basic CMS architecture as shown in the following topology diagram. If the CMS dual homed feature is needed for s4B cloud meetings, then the TMS and TMSXE are required as explained below. 

In this case, there is no longer a direct Lync type “trunk” from the CMS to the on premise SfB FE server(s), but instead, a Lync type trunk has been created with Expressway-Core. Expressway-Edge then handles inbound and outbound calls as in a normal B2B call, but recognizes the Microsoft SIP variant for SfB calls. Search rules on both Expressway-Edge and –Core include this parameter when making routing decisions. Calls between Standard SIP or H.323 and SfB clients are again “threaded” through the CMS based on these search rules.  

Note that CMS is utilizing the TURN server on Expressway-Edge (TCP and UDP 3478), as it is required for SfB cloud calls due to NAT firewalls in between. 

SfB cloud call flows  

Outbound calls to SfB from CUCM registered devices: 

1. Standard SIP EP registered on CUCM dials an SfB SIP URI <user>@skype.company.com. 

2. CUCM has a SIP Route Pattern that routes the call to the CMS standard SIP trunk. 

3. CMS has an Inbound Call Forwarding and associated Outbound Call rule that routes the call to the Expressway-Core. Since this “trunk” is identified as “Lync” type in the CMS configuration, CMS automatically knows it must interwork the two sides. 

4. Expressway-Core has a search rule applied to the CMS inbound trunk that includes the “Microsoft SIP variant” parameter and routes it to the Expressway-Edge over the B2B traversal zone. 

5. Expressway-Edge DNS zone detects the Microsoft SIP variant in the outbound call SIP headers and performs a lookup of the SIP federation SRV record for the destination domain skype.company.com (instead of the standard SIP SRV). 

6. TURN services are negotiated between SfB and Expressway-Edge. 

Outbound calls to SfB from Expressway-Core registered devices: 

1. H.323 EP registered on Expressway-Core dials an SfB SIP URI <user>@skype.company.com. 

2. Expressway-Core has a search rule that routes the call to the CMS standard SIP trunk. 

3. CMS has an Inbound Call Forwarding and associated Outbound Call rule that routes the call back (hairpin) to the Expressway-Core. Since this “trunk” is identified as “Lync” type in the CMS configuration, CMS automatically knows it must interwork the two sides. 

4. Expressway-Core has a search rule applied to the CMS inbound trunk that includes the “Microsoft SIP variant” parameter and routes it to the Expressway-Edge over the B2B traversal zone. 

5. Expressway-Edge DNS zone detects the Microsoft SIP variant in the outbound call SIP headers and performs a lookup of the SIP federation SRV record for the destination domain skype.company.com (instead of the standard SIP SRV). 

6. TURN services are negotiated between SfB and Expressway-Edge. 

Dual homed meeting workflow for cloud SfB 

This requires the Cisco TMS and TMSXE integrated with the Exchange email server because joining a cloud SfB meeting requires the Telepresence “one button to push” (OBTP) feature on the Cisco endpoints. The reason for this is that the CMS cannot automatically translate a meeting ID to the SfB URI from the SfB cloud edge server as it could when it was on premise.  Since the SfB URI is very long and cumbersome to dial, TMS “hides” it behind the OBTP speed dialer.