XMPP Gateways - Are They Relevant in Today’s Fast Paced & Demanding UC Collaboration Environments?

XMPP Gateways - Are They Relevant in Today’s Fast Paced & Demanding UC Collaboration Environments?

By Stephen Leaden May 20, 2014 2 Comments
Stephen Leaden PNG
XMPP Gateways - Are They Relevant in Today’s Fast Paced & Demanding UC Collaboration Environments? by Stephen Leaden

Leading enterprises have been questioning the utility of XMPP Gateway Servers lately.  Have they outlived their usefulness and are they even still relevant in a fast-changing UC market? Google has abandoned XMPP standards and there have been no major initiatives on the part of UC vendors to close the gap on security, reliability, scalability and performance deficiencies of the XMPP Gateway Servers

In 2009, Microsoft Lync and IBM Sametime developed XMPP Gateway Servers to provide Public IM Connectivity (PIC) with Google’s popular Google Talk (GTalk) chat platform. As a result, their XMPP Gateways were optimized for presence and chat federation with Google Talk. As of 2012, market surveys showed approximately 10% to 15% of Global 1000 companies had federated with Google Talk.

That all changed a year ago though when Google announced that Google+ and Google Talk would be replaced by Google Hangouts and that they would migrate their users to Google Hangouts. This meant that Google was no longer going to support server-to-server XMPP federation. Per a Google spokesperson “The openness of Google Talk led to bad user experiences like spam attacks, and limited us in terms of supporting the various forms of communication that we're now able to achieve with Hangouts.”

As a consequence of this decision, Google Hangouts has become a walled garden environment and Microsoft Lync and IBM Sametime users can no longer federate with users on GTalk.  Thus, one of the original rationales for deploying the XMPP gateways was made, in effect, obsolete.

As a result of developing their the XMPP Gateway Servers solely for federation with Google Talk as a public IM service, IBM and Microsoft did not fully support XMPP-based UC platforms such as Cisco, OpenFire, Broadsoft, among many others. There were too many XMPP-based platforms with extensions to the standards for Microsoft and IBM to invest the necessary resources to test and certify against. Another consideration was competition and XMPP Gateway Servers being used for migration.

At the time, lack of true federation support for XMPP-based UC platforms was not really an issue. Many enterprises were in the midst of deploying their Microsoft and IBM environments and external federation did not appear to be a top priority.

Organization that did decide to use the Microsoft and IBM XMPP Gateway Servers for external XMPP federations ran into a number of issues and shortcomings, including the following:

  • Lack of multi-domain support
  • Lack of reliability based on limited support and SLAs associated with XMPP gateways
  • Lack of multi-party chat support
  • Lack of support for TLS and SSL-based encryption
  • Lack of scalability – less than 1000 federated users at a time
  • Lack of protection against XMPP flooding attacks

As customers’ requirements began to mature and evolve into demands for more secure, reliable, scalable real time B2B UC collaboration with their corporate partners on XMPP-based UC platforms, IBM and Microsoft began facing hard choices - either invest significant resources to optimize their gateways to support a wider range of XMPP UC platforms, or basically slowly End of Life (EOL) them.

So far nothing fundamentally has changed with respect to IBM and Microsoft XMPP Gateway Servers. In Lync 2013, Microsoft incorporated its XMPP Gateway as a server role with Lync’s Access Edge Server (AES). This eliminated the need to deploy additional server resources, but the same issues still remain for companies that want to deploy the gateway.

These factors have led to much speculation about the future of XMPP, and a key question arises: will IBM and Microsoft still be supporting XMPP Gateway Servers a year from now, and where will that leave them if customers are dependent on the servers?

In summary, Google’s abandonment of XMPP has left a possible ‘black hole’ regarding the future of XMPP gateways.  And shortcoming in Microsoft’s and IBM’s XMPP gateway servers further complicates the matter.  This leaves us with the question: have XMPP gateways outlived their usefulness and are they even still relevant in a fast-changing UC market? Time will tell.

 

 

2 Responses to "XMPP Gateways - Are They Relevant in Today’s Fast Paced & Demanding UC Collaboration Environments?" - Add Yours

Gravatar
Philipp Hancke 5/24/2014 3:33:53 AM

I'd note that google has so far no movement to actually turn of their XMPP servers. Hangouts users can not be reached from the outside anymore however. This is completly broken inside google.
And as of last week, several xmpp services have decided to no longer tolerate google talks complete lack of tls-encrypted federation.

Google Talk was nice for XMPP back in 2005. However, it stayed the same over the years while XMPP continued to evolve. XMPP can still be a solid technical basis for a UC platform. Whether "federation" will remain useful... time will tell. It depends on interoperability, common goals and people from different companies talking to each other which is hard to achieve.


The whole "abandonment" was IMO a rather lame attempt to cover up for the simple fact that federation does not fit their business goals. The few technical arguments I have heard were hilarious.

Disclaimer: I am on the technical council of the XMPP Standards Foundation
Gravatar
Chris Vitek 9/4/2014 4:47:44 AM

Steve,

Federation is an artifact of the telecommunications industry. It is an architecture that is not relevant because it only exists to extract money from and exert control upon its users. Further, while federation can support enterprises it does nothing for consumer collaboration, WebRTC makes inter-enterprise collaboration possible without federation and it supports consumer collaboration with a few lines of JavaScript on your web page. It uses AES encryption and there are close to 2 Billion end-points that can use it today with two clicks of a mouse. I would put a fork in federation because it is done.

Disclaimer: I am the WebRTC Evangelist at Genband.

CV

To Leave a Comment, Please Login or Register

CLP Central: Where Consultants, Vendors, and the Channel Connect
BC Summit 2016 UC Alerts
UC Blogs
UC ROI Tool RSS Feeds

Related UC Vendors

See all UC Vendors»