Intracompany Federation with Domain Sharing for Microsoft Teams and Cisco Webex
Introduction
According to a recent survey by NextPlane, 79% of IT professionals stated that their companies are operating in a mixed collaboration environment, which can include legacy UC platforms such as Microsoft Skype for Business and Cisco Jabber.
Also, almost two-thirds of IT professionals report that collaboration platforms are the de-facto tools for communicating with colleagues inside or outside the enterprise. With user-friendly features like file sharing, group conversations, powerful search, and application integration, workers are shifting the bulk of their day-to-day communications to new collaboration tools.
But perhaps more telling is the fact that nearly half (49%) of respondents said that business discussions, tasks, or transactions happening with users outside the company have now shifted from email to team collaboration platforms.
For mixed collaboration environments to deliver the same seamless functionality as email means, users should be able to share presence status, send messages, participate in each other’s Teams or Spaces, or share files with any user inside or outside their companies.
This solution guide shows how to use NextPlane to establish interoperability across Microsoft Teams and Cisco Webex that must share the same domain.
It also covers how to connect internal Microsoft and Cisco platforms with external organizations such as customers, partners, or suppliers while these platforms share the same domain.
Using the NextPlane Intracompany Federation, Microsoft and Cisco users will be able to:
- Invite and add each other as contacts
- See each other’s profiles
- Share presence*
- Send messages with rich text and emoji reactions**
- Invite and join channels and spaces**
- Share files**
* Microsoft Teams and Cisco Webex DO share Presence with other platforms. It means that their users will appear as Present or Away on the federated platforms. NextPlane is currently working to provide accurate Presence states for the external contacts invited to Microsoft Teams or Cisco Webex.
** Coming soon.
About NextPlane ConverseCloud
NextPlane ConverseCloud acts as a universal federation and interoperability hub between Unified Communication (UC) and Team Collaboration (TC) platforms. As a result, you can quickly establish interoperability between your internal UC and TC platforms. You can also federate them externally with your customers, partners, or suppliers, regardless of their underlying platform.
As a universal hub, ConverseCloud performs a transformation of XMPP, SIP, and API-based protocols as well as the conversion between different formats of encapsulated text messages for platforms such as Microsoft Skype for Business(S4B), Cisco IM & Presence, and Slack.
ConverseCloud enables users to send messages with rich text and emoji reactions, add external contacts, and see Presence and status. Users can also participate in teams, channels, and spaces, and share files with other UC or team collaboration platforms, inside or outside of the enterprise.
For IM, some translation is also necessary for the content of messages to take into account each vendor’s support for plain text, rich text, and other embedded content.
For Presence, this translation requires handling competing standards for the format of Presence information (often called a Presence Document). ConverseCloud also performs translation to and from all of the UC vendor’s supported Presence Document formats, including standard formats such as PIDF, XPIDF, and XCAP, as well as proprietary formats such as Microsoft Enhanced Presence.
NextPlane views accurate Presence states as the foundation for any real-time collaboration within any messaging platform. You do not message colleagues if their Presence is unknown or unavailable. As a result, NextPlane ConverseCloud also performs semantic translation for Presence states within a Presence Document.
NextPlane ConverseCloud uses equivalence-based mapping to map specific Presence states on different platforms when there is no one-to-one correspondence. For example, Slack has two Presence states (Active and Away), but Microsoft Teams has five Presence States (Available, Busy, DND, Appears as Away, and Be Right Back).
After ConverseCloud terminates and decapsulates the message from each platform, ConverseCloud determines the routing destinations and reassembles each message based on what is expected by the target UC or TC platform of the message. For most federations, ConverseCloud routes the messages based on the domain of the destination address.
The intracompany federation, which is connecting different team collaboration and messaging tools that operate within a company, is another complicated interoperability problem. Different internal messaging and collaboration platforms that need to share the same domain name do not allow routing chat and other messages to other platforms within the same domain.
To solve the problem of intracompany federation across team collaboration platforms, such as Microsoft Teams and Cisco Webex, that need to share the same domain name, NextPlane uses an API-based federation. NextPlane’s solution allows for the direct collaboration between the users on team collaboration platforms without using guest accounts or multiple client applications.
To connect different TC platforms, like Microsoft Teams, and UC platforms, such as Cisco Jabber, that share the same domain name, NextPlane uses ‘virtual domains.’ Virtual domains are not real domains. They are used solely by NextPlane ConverseCloud to allow messaging platforms to differentiate the federated traffic from their local traffic. Consequently, these platforms can route their federated traffic to the NextPlane ConverseCloud Service, and from there, NextPlane ConverseCloud strips the virtual domain name and sends it to the correct destination.
NextPlane ConverseCloud uses TLS (transport layer security) for all SIP and XMPP signaling, as well as for API-based communication between federating our supported UC and TC platforms.
What is Intracompany Federation with Domain Sharing?
The intracompany federation is connecting different team collaboration and messaging tools that operate within a company.
So far, the intracompany federation—seamless interoperability across mixed team collaboration environments—remains a problem. Also, it becomes even a more complicated problem when Microsoft Teams and Cisco Webex need to share the same domain. As a result, their users are not able to share presence status, send messages, participate in each other’s Teams or Spaces, or share files with any user inside or outside their companies as seamless as with email.
There are two reasons why the intracompany federation does not work when team collaboration tools need to share the same domain. First, it is interoperability. Microsoft Teams and Cisco Webex do not interoperate.
Second, Microsoft and Cisco did not design their platforms to share the same domain names with other platforms. As a result, each platform treats the chat and presence messages sent to the other platforms users as local traffic. Thus, neither platform routes the messages to the other platform.
NextPlane supports intracompany federation with domain sharing for the following common scenarios:
- Coexistence – for organizations that have a mixed environment of Slack, Microsoft Teams, and/or Cisco Webex.
- Migration – for organizations migrating from a UC platform to a Team Collaboration one, e.g., Cisco Jabber to Microsoft Teams or Slack.
To get around the above problems, companies usually first try to put their users on both platforms. So, each user ends up with both a Microsoft Teams and Cisco Webex client application on their device.
This option is cost-prohibitive. It requires buying two licenses per user, one for Microsoft Teams and another one for Cisco Webex.
Also, aside from cost considerations, it is a productivity drain, where end-users must learn two very different systems for messaging, scheduling meetings, participating in group conversations, and making voice and video calls while dealing with the challenges of remote working.
To overcome the lack of external interoperability with suppliers and customers, most companies resort to guest accounts. Guest accounts allow users on Cisco Webex and Microsoft Teams to invite external contacts to participate on their platforms as guests with full access to chat, group conversation, calling, meetings, and files.
There are two critical issues with guest accounts: security and access control, as well as licensing limitations. Please see Appendix A for a detailed explanation of these limitations.
NextPlane offers intracompany federation with domain sharing. As a result, the users of Cisco and Microsoft platforms can send messages, share their presence status* and files**, as well as participate in Teams and Spaces** without leaving their respective client applications. Also, their external contacts can do the same without leaving their preferred tools.
Microsoft Teams and Cisco Webex Intracompany Federations
To solve the problem of intracompany federation across team collaboration platforms that need to share the same domain name, NextPlane uses an API-based federation. In this case, NextPlane ConverseCloud acts as a secure interoperability hub between the Microsoft Teams and Cisco Webex platforms.
As a result, Microsoft Teams users with username@mycompany.com IDs can communicate with their username@mycompany.com colleagues on Cisco Webex as if they were on the same platform.
NextPlane also allows both Microsoft Teams and Cisco Webex users on @mycompany.com to connect with external partners that have Microsoft Skype for Business Online, Microsoft Skype for Business Server, Slack, and Cisco Jabber.
NextPlane uses bots to act as proxies for external users on Microsoft Teams. NextPlane generates them in the NextPlane’s Microsoft account. The NextPlane Microsoft Teams bots act as proxies for Cisco users and provide NextPlane ConverseCloud with the ability to exchange messages through the Microsoft Teams Channel.
The NextPlane Apps are not executable code. They are registrations of NextPlane ConverseCloud within Microsoft Teams and Cisco Webex infrastructures. These registrations provide NextPlane ConverseCloud with access tokens to call the Microsoft Teams & Cisco Webex API methods and listen to events on behalf of the NextPlane bots.
Microsoft and Cisco users need to install the nextplane App to their respective client applications to be able to:
- Invite and add each other and external contacts
- View external contacts’ profiles
- Share presence*
- Send direct messages with rich text, GIFs, and emoji reactions**
- Share files**
Microsoft Teams and Cisco Webex Intercompany Federations
NextPlane allows users on the Microsoft and Cisco platforms that share the same domain name to connect with external partners on Microsoft Teams, Skype for Business Server, Skype for Business Online, and Slack.
External contacts on Slack and Microsoft Teams need to install and use the NextPlane App for their respective platforms.
To make the federation between the internal Cisco Webex, sharing its domain with the internal Microsoft Teams, and external partners on Microsoft Skype for Business Online work, NextPlane uses Domain Virtualization.
NextPlane virtual domains are not real domains. They are used solely by NextPlane to allow Microsoft Skype for Business Online to differentiate the federated traffic from its local traffic and route it to NextPlane ConverseCloud. From there, NextPlane ConverseCloud would strip the virtual domain name and send it to the correct destination.
Why is this important? Because Microsoft SIP Interoperability Gateway would treat the traffic from Microsoft Skype for Business Online to @mycompany.com‘s Microsoft Teams tenant as local. As a result, the users on Cisco Webex can initiate chat sessions with their colleagues on Skype for Business Online. However, Skype for Business Online users can not start a chat session.
For more information about Domain Virtualization, please see Appendix B.
The table below shows the supported platforms for intercompany federations.
|
External Platforms |
|||
Internal Platforms |
Microsoft Teams (External) |
Slack |
Skype For Business Server |
Skype for Business Online |
Microsoft Teams |
– |
Y |
Y |
Y* |
Cisco Webex |
Y |
Y |
Y |
Y* |
* Using NextPlane Domain Virtualization.
Appendix A Guest Accounts Option for External Collaboration
As an alternative to interoperability, host organizations can invite external members to specific team collaboration platforms as third-party guests on an as-needed basis. By default, guest access creates the proper levels of separation when working with external parties.
Currently, 44.2% of organizations rely on guest access for third-party collaborations—either to enable external access to their team collaboration platform or to allow their employees to use external team collaboration apps to connect with partner organizations.
Guest access works seamlessly if the external members have the same platform as the host organization. Also, depending on the team collaboration platform, the host and guest organizations using similar platforms, such as Slack, can merge, yet maintain separate access and data security.
For instance, with Slack Connect, separate organizations can collaborate in a Slack channel, each from within their own Slack workspace. Members can send direct messages, upload files, use apps and integrations, and start calls—all in a shared space.
Microsoft Teams offers an external access federation option for Skype for Business customers that do not want to use guest accounts. However, this option is limited to IM and Presence messages.
But when it comes to managing collaboration with external partners that have different platforms, things become complicated. These organizations and their users have to create and use a stripped-down freemium guest account. A free account may or may not have all the features needed for collaboration, and the external partner may be required to purchase a license.
According to Nemertes, nearly 42% of organizations run more than one team collaboration app internally. In such a case, external partners’ users may have to purchase several guest accounts to collaborate with the users of the host organization.
Also, administrators have no idea how far away from home their users are playing. Once someone accepts an invitation from another platform, everything they do inside that platform is invisible to the administrator of their home platform. For instance, given the success of Microsoft Teams, a user can end up being a guest in a surprising number of Microsoft Teams tenants.
In general, the guest access method works well when companies need to add a few external members to a team. However, this capability can quickly become unmanageable when working with a third-party company that requires hundreds or more guest accounts.
There are three critical issues with guest accounts: cost, security, and administrative burden.
Compared to enterprise account password policies, guest accounts’ password policy in most cases only requires letters and numbers and does not include Two-Factor Authentication (2FA). Also, it is nearly impossible to control whether guests have strong security measures like password complexity check and password expiration.
Also, guest accounts are not entirely free. Slack guest accounts are available only on paid plans (Standard, Plus, and Enterprise Grid) and can be either Multi-Channel or Single-Channel. Depending on the pricing plan, Slack bills between $8 to $15/person per month. As a result, 1,000 Multi-Channel guest users can cost up to $15,000.
For managing and limiting access to Cisco Webex, external accounts will require Cisco Webex Control Hub Pro Pack for an additional cost of over $30.00 per user/month.
Microsoft Teams only allows five guest accounts per paid Azure AD license. In other words, a company with 1,000 Microsoft licenses can only send out 5,000 guest account invitations.
Guest accounts require active management. For instance, contractors, clients, interns, or temporary employees come and go out of projects or change jobs or companies. Microsoft, Slack, and Cisco provide the ability to delete or remove guest accounts. However, managing guest accounts can become a security and management burden, which can result in hidden costs.
Slack administrators must manually provision guest accounts one by one. They can choose an automatic expiration date for each guest account.
Appendix B Domain Virtualization
NextPlane Domain Virtualization allows using ‘virtual domains’ to ensure intercompany federation and avoid the issue of domain routing overlap on Microsoft or Cisco cloud-based platforms.
NextPlane also uses Domain Virtualization to establish intracompany interoperability between the on-premise platforms that share the same domain name.
Let’s consider the example of DynaCorp, whose domain, dynacorp.com, was initially registered as a Cisco Webex domain. When DynaCorp registers the same domain—dynacorp.com—for Microsoft Teams, the federation between its internal Cisco Webex and the external partners on Microsoft Skype for Business Online or Microsoft Teams stops working.
The problem is that Microsoft SIP Interoperability Gateway treats the traffic from Microsoft Skype for Business Online to DynaCorp’s Cisco Webex as local and tries to route it to DynaCorp’s Microsoft Teams. As a result, the users on Cisco Webex can initiate chat sessions with their external partners on Skype for Business Online. However, Skype for Business Online users can not start a chat session.
To solve this problem, NextPlane uses virtual domains that help differentiate local traffic from the federated traffic. Using virtual domains, Microsoft SIP Interoperability Gateway can route the traffic from the Microsoft cloud-based platform to the NextPlane ConverseCloud Service. From there, NextPlane ConverseCloud strips the virtual domain name and sends it to the correct destination—DynaCorp’s Cisco Webex.
Thus, Alice from Cyberdynamics, using Skype for Business Online, can send messages to Derek on Cisco Webex, even though her platform shares its domain name with DynaCorp’s Microsoft Teams.