The Unified Communications (UC) landscape had been changing quite fast, as it is, the interoperability of multiple standards had become more confusing than before. This poses serious business and technical decisions for customer's as to which way to move forward. Which vendor to go for, which type of solution to deploy ? Federation is one aspect of that UC landscape that is not an exception. With more and more Enterprise customers advocating for Open Federation, it makes sense in today's world for the Vendors to support multiple standards seamlessly, so that the core concept of UC that is ease of communication, increased productivity and improved user experience is maintained. Cisco and Microsoft are the forerunners in this domain and how far have they addressed the issue or they are at WAR, is there a solution in sight ?
Few years back IBM SAMETIME ruled the IM and Presence domain (IMP), where Enterprises were limited to IM and Presence within the boundaries of the Enterprise network. Then the emergence of XMPP and SIP/SIMPLE happened. Customers where now looking for intra-domain federation, with so many big companies going for mergers and acquisitions. It made sense to have a solution that would integrate multiple IMP standards between subsidiaries within the parent company. This meant the vendors (Cisco, Microsoft) would need to support both the protocols. XMPP and SIP/SIMPLE are completely different protocols and they are not even variations of each other, they are like completely two different protocols. Cisco and Microsoft both claims to support these two protocols. Then came the era of inter-domain federation where Enterprise customers now wanted to be able to chat openly (Open Federation) to any domain. Enterprise customers were now working with multiple service providers. Service providers (SP) that provided financial, Auditing, engineering, law services, the list is endless. These service providers would be required to communicate with their customers using IM&P clients like Jabber or Lync or skype. Now let's think about this for a moment, SP1 uses XMPP to communicate, whereas SP2 uses SIP. Now the questions for The Enterprise customer are, what do they support ? Preference is to support Open federation (that is able to chat freely with any domain without restriction), but which protocol ? Either of the one or both ? The dilemma is also in front of the Service Providers, because they would want to support both protocols to support various clients who might be divided between XMPP and SIP. Even though both vendors supports both protocols at same time in their solution, there are several key decision making questions that customers needs to get resolved. Does the solution of either vendor support anchoring of sessions on their edge devices ? Can both protocols be supported on same edge devices ? If not, what's the additional cost to deploy the same. Does an upgrade suffice or a separate hardware is required ? Can the additional device be used for other features or functionalities apart from just running as XMPP or SIP proxy ? What about redundancy/ High availability? Everything comes down to ease of deployment (complexity and time to deploy and go-live), Cost to deploy the solution, feature set supported and licensing cost (number of session audio/video).
From a marketing perspective these two vendors does a great job in showcasing the world about the capabilities of their products and solutions to support inter-domain federation using both protocols. But do they ? Those who designed and deployed or even sold Cisco and Microsoft products will know that Microsoft had always been a proponent of SIP/SIMPLE while Cisco marketed XMPP subtly. From a standards perspective it's a discussion for another day on which protocol is better XMPP or SIP, how easy it is to develop extensions for XMPP and how confusing the SIP/SIMPLE had been or how less secured XMPP was or how SIP/SIMPLE is restricting open federation. Microsoft always supported SIP/SIMPLE with their Lync and Skype, OCS being used primarily as the Edge server to federate with other domains. Cisco on the other hand acquired Jabber and since supported XMPP. Cisco expressway Edge (E) servers supports only XMPP (As of VCSe 8.8.x version, 10.5.x CUCM). To enable SIP federation anchoring, customers would be required to have ASA as a proxy, thus increasing the cost of deployment. Cisco does support SIP/XMPP at same time on the IMP presence servers, but whether anyone wants to allow internet traffic to anchor on IMP application servers in a secured zone is anybody's guess.
(In a recent Cisco Live event in Melbourne while attending a tech seminar for hybrid Cisco Spark and On-premise deployment, the TME proposed that Cisco expressway C can be used to anchor sessions for Jabber connecting from internet, expressway C sits on same secured zone as UC applications. Hands were raised and questions asked by several attendees from various partner organizations on the feasibility and sensibility of such design, rather than using an edge device. TME was quick to take a step back and said it was a good feedback and take it up with BU.)
In such scenarios customers are left to either use XMPP or SIP. Even if customers deploy both SIP and XMPP using multiple edge devices or let's say for Cisco (upgrade to CUCM 11.5 and VCSe to 8.9) the solution doesn't support open federation for both protocols. Cisco supports static SIP routes only and supports open federation for xmpp, whereas its the reverse with those that has deployed Microsoft. The challenge is everytime a Cisco customer is going to federate using XMPP protocol with a Microsoft customer, the microsoft customer needs to configure xmpp domain of the Cisco customer and the same is true for SIP protocol in reverse scenario where Cisco customer has to configure SIP static routes/ Domain for the Microsoft customer.
So it seems customers or partners are still some time away from deploying a true open federation solution. Not until at-least the industry has adopted a single standard for federating. Till then the WAR will continue between XMPP and SIP backed by Cisco and Microsoft respectively.
Comments