Today’s blog post is a special one for us at Stack8. We are honored to be presenting a post written by a fellow UC expert Abhijit Bhowmick who graciously reached out and told us that he wanted to create the following article for everyone to read.
The Unified Communications (UC) landscape had been changing quite fast, as the interoperability of multiple standards has become more confusing. This poses serious business and technical decisions for the customer as to which way to move forward. Which vendor to go for, which type of solution to deploy?
Federation is one aspect of the UC landscape that is not an exception. With 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 concepts within UC are maintained. Cisco and Microsoft are the forerunners in this domain but just how far have they addressed this issue, and is there a solution in sight?
A 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 came the emergence of XMPP and SIP/SIMPLE with the results that customers were now looking for the intra-domain Federation.
With so many big companies going through mergers and acquisitions, it made sense to have a solution that would integrate multiple IMP standards between subsidiaries within the parent company. This meant that the vendors (Cisco, Microsoft) would need to support both these protocols. However, XMPP and SIP/SIMPLE are completely different protocols; they are not even variations of each other. Cisco and Microsoft both claims to support these two protocols.
In today’s era of inter-domain Federation Enterprise customers now want to be able to chat openly (Open Federation) to any domain. Enterprise customers are now working with multiple service providers (SP) that provide 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 is 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 service providers also face this dilemma because they want to support both protocols to service their various clients who might be divided between XMPP and SIP. Even though both vendors support both protocols at the same time in their solutions, there are several key decision-making questions that customers need 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? Does an upgrade suffice or is separate hardware required? What are the additional costs?
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 implement the solution, feature set supported and licensing cost (number of sessions audio/video).
From a marketing perspective, these two vendors do a great job of highlighting the world about the capabilities of their products and solutions to support inter-domain Federation using both protocols. But do they?
Those who design and deploy or even sell 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 secure 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 has supported XMPP. Cisco Expressway Edge (E) servers support 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 the 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 the 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 for Cisco (upgrades to CUCM 11.5 and VCSe to 8.9) the solution does not support open Federation for both protocols. Cisco supports static SIP routes only and supports open Federation for XMPP, whereas it’s the reverse with those that have deployed Microsoft. The challenge is that every time a Cisco customer is going to Federate using XMPP protocol with a Microsoft customer; the Microsoft client needs to configure the XMPP domain of the Cisco customer. The same holds 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. Until then the WAR will continue between XMPP and SIP backed by Cisco and Microsoft respectively.
Other Blogs You Might Enjoy
Ready to take your unified communications from headache to hassle-free?
No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.