Federating Presence
One of the topics we will be discussing in Episode 39: ‘Pushing the Boundaries of Collaboration’ is Presence. Specifically the status and challenges around federated presence which holds the alluring promise of extending these advanced productivity tools out to interoperate with associates not on our same network or domain. Dave Lizotte is an extremely gracious and knowledgeable guest to have with us and was willing to share more of the detail he will be discussing on the show.
Please enjoy!
Robb
* * * *
Working for Cisco Advanced Services under the collaboration services umbrella I have been deeply
focused on UC architecture, Cisco-Microsoft interoperability, federation, SIP, and presence. The more I see this umbrella of UC solutions transform the customers usage models, the more I see customers requesting additional capabilities for social networking. People want information real time and they want it to cross all boundaries seamlessly, regardless if it is on a private or public network, fixed or mobile device. I see a transition occurring where basic IM and presence technology is becoming a critical service that must integrate deeper into the application space to enhance customer business value. Are we listening to our customers? What business problems can we solve for them? The control and selection options of how customers want to be communicated with is really placed in the end users hands. Users are requesting the ability to define their own business presence states, and integrate this information into applications and all kinds of endpoints. To accomplish this goal open standards, presence federation and protocols will play a very critical and important role.
First of all what does it mean to get two disparate presence networks to talk to each other? Federation is the Key.
THE BASICS
Federation is basically the ability to get two different networks to share and exchange information as transparent to the end users as possible. In order to federate, the two networks will need to agree on how they are going to communicate with each other. They may need to speak the same language using a standard protocol or having some form of translator between them such as a gateway or transport agent device. You speak English and I speak French, well my friend speaks both languages so let him translate for us. The networks must have some form of solution in mind so they must have a level of trust and security. They must be able to listen and agree upon what informational messages are being sent to them so they can be understood and have value. The information shared can be messages, user account information user, presentity status and informational messages and many other into the work flow and application space. Most federation types do have some form of security like TLS. Other components can also be required if trying to pass information through firewalls or once through the firewall to route users to proper cluster locations like Cisco does for their presence architecture. Cisco’s approach to presence is to collect, aggregate and share presence status information over the network. Federation can be from a business to another business or from a business to a public entity. Federation is quick and can be accomplished in a very short time frame vs.. a costly deployment for a whole new system between enterprise businesses or public entities. So why do we hear different federation terms such as inter and intra-Domain federation.
DOMAINS
Inter-Domain Federation is defined as to separate enterprise network domains to exchange information and communicate. A good example of this would be A@cisco.com <mailto:A@cisco.com> and B@Microsoft.com <mailto:B@Microsoft.com> . Intra-Domain Federation is defined as two or more different presence solutions within the same enterprise domain to exchange information and communicate. This type of federation is harder to accomplish due to the level of complexity with numerous different systems in the environment They do not speak to each other natively and more then one system is going to try to act as the lead system with the most up to date and accurate information on user presentity and other account and informational messages. It even gets more complex since it is all now being tied into the email,telephony and other solutions like workflow applications and mobile devices. Routing and addressing to multiple user accounts for the same person will be extremely difficult. Can all of these systems understand all the different translations for messages? Real-time Presence out of synch will not be acceptable to users or business processes that affect Book, Bill, Ship and Close decisions for customers or vendors. So what are the main protocols being used in the industry for IM and Presence? The key to this comment is what protocols are leading the industry, not what protocols are standards in the industry.
PRESENCE PROTOCOLS: SIP/SIMPLE & XMPP
Cisco’s approach to presence is to collect, aggregate and share presence status information over the network.
The two main leading or standard industry protocols used for presence are SIMPLE SIP Instant Messaging and Presence Leveraging Extensions, and XMPP Extensible Messaging and Presence Protocol. XMPP is a protocol that routes XML messages between entities, in our case Presence and IM. SIMPLE is also XML based as an event package mechanism and rides on SIP. After reviewing a few other blogs and articles it is clear that SIMPLE became more popular with businesses and their VOIP solutions to utilize the SIP feature sets that can be accomplished. Even Service Providers are using SIP in their fixed and mobile networks. Most Businesses are using SIMPLE like Cisco. Although Jabber which is now owned by Cisco uses XMPP, as well as most public internet companies like Google and Yahoo. There are a few other protocols that are proprietary. This separation of protocol direction has created immature IM and presence standards an industry where open standards is very much required to deliver strong integrated and federated solutions to our customers.
STANDARDS?
Lack of Standards: The lack of standards also causes presence states, status and information exchanges to vary, thus limiting what information messages can be shared and understood between systems. Users are wanting the ability to create their own presence states to match their business requirements. Customers are demanding presence and status be placed into their business applications. Once again, our Collaboration technology must enhance customer business value. Companies are not ripping out their systems every time they need an new solution. The solutions must integrate and I believe that most integration is not that difficult technically. The key again is open standards and stronger vendor partnerships. It is one thing to have an agreed upon standard to communicate, but it a completely another issue to get two vendors or companies to agree upon what level and type of information they are willing to open up and share within their solutions. A clear example of this is with Cisco and Microsoft Interoperability. A good example for a lack of standards is Microsoft with their integration between Cisco and Microsoft. Even though we have inter-domain federation with some presence states available MSFT’s OCS does not follow the RFC 3261 description of how to perform a register request. This is why a MOC client can not register with another SIP proxy or B2BUA like Cisco Unified Communications Manager and this is also why compliant RFC SIP devices can not register with OCS.
Dave Lizotte
Solutions Architect




