1. Federating Cisco Jabber
Valid for CUP 8.6(X) / CUCM IM & P 9.0
Paul O’Dwyer: Technical Marketing Engineer - Jabber Solution
July 2012

2. What Business Case are you trying to solve?
Cisco Jabber Overview
Federation Models
What Business Case are you trying to solve?
Support and Feature Matrix
Inter-Domain Federation
Protocol Flows
How-to use this deck:
Cisco Jabber Overview – Brief background and overview of Jabber portfolio
Federation models– Introduce federation models
What Business Case are you trying to solve? – Align federation model from the previous section to suit your business need (e.g. a customer may want B2C)
Support and Feature Matrix – What federations are supported with Jabber; then from within those supported federations, what features are available
Inter-domain Federation (Protocol Flows) – Outline the highlights of each protocol’s federation model
Partitioned Intra-Domain federation (Routing and Migration) - Outline the highlights and gotcha’s of Partitioned Intra-domain federation
What About Third Party Clients – Highlight the flexibility of XMPP by using 3rd party clients with a Jabber backend.
Partitioned Intra-Domain federation
Routing and Migration
What About Third Party Clients?

3. Cisco Jabber Clients Jabber Product Portfolio
Provide an overview/pitch of Jabber portfolio. Highlight’s include UC-rich applications, explosion of mobile devices in the post-PC era, and well as a common UI across platforms.
Collaborate from Any Workspace
PC, Mac, tablet, smart phone
On-premises and Cloud
Integration with Microsoft Office
All-in-one UC Application
Presence & IM
Voice, Video, voice messaging
Desktop sharing, conferencing

4. Devices Share the same Infrastructure
Cisco Jabber
Cisco Jabber
Each of the devices across the spectrum all share a common backend, which results in a truly unified end-user experience
Call Control: SIP
Unified Communications Manager (CUCM)
Video Communication Server (VCS)
Presence & IM: XMPP
Unified Presence
WebEx Connect service (SaaS)
Meetings, Conferencing
WebEx (SaaS)
TelePresence MCU
Voice Messaging
Unity Connection

5. Cisco Unified Communications Lower Boundaries to Collaboration
GoogleTalk
XMPP Standard
Cisco Jabber Enterprise
Microsoft
SIP
Supported federations vary by deployment type. i.e. on-premise versus cloud. See ‘Support matrix’ in later section
IBM 5

6. Federation Models

7. Unlock B2B and B2C Collaboration
Scenario 1 Inter-Domain Federation
Inter-Domain Federation is the sharing of Enterprise Instant Messaging (IM) and Presence between corporate domains – further lowering the boundaries to collaboration for both B2B and B2C
XMPP Standard
GoogleTalk
SIP
IBM
Microsoft
Inter-Domain federation lowers corporate boundaries, and still provides secure (TLS) B2B and B2C collaboration.
Throughout out this document, any reference to Jabber refers to ANY of the Jabber portfolio clients.
Unlock B2B and B2C Collaboration

8. Scenario 2 Partitioned Intra-Domain Federation
Cisco Jabber
Partitioned Intra-Domain Federation is the sharing of Enterprise Instant Messaging (IM) and Presence between Unified Communication vendors within a single domain – this model is used as a migration tool from Microsoft to Cisco Infrastructure
Microsoft IM
Available to on-premise Cisco Jabber only. Partitioned Intra-Domain federation facilitates Cisco and Microsoft interoperability and full migration path to Cisco UC.
Throughout out this document, any reference to Jabber refers to ANY of the Jabber portfolio clients.
Seamless Migration path from Microsoft to Cisco

9. What Business Case are you trying to solve?

10. Microsoft Access Edge (DEF.COM) Microsoft Front-End Server
“I want to communicate from our Jabber platform to partners and customers on a SIP platform for real time collaboration”
‘Inter-Domain Federation’ is the sharing of Enterprise Instant Messaging (IM) and Presence between 2 or more corporate domains – further lowering the boundaries to collaboration for B2B.
Microsoft Access Edge (DEF.COM)
CUP (ABC.COM)
Cisco ASA
Microsoft Front-End Server
SIP
OCS Server
Inter-domain federation model should be used for B2B communication. SIP federation is shown in the diagram, however both SIP and XMPP federation are supported as we will see in the forthcoming sections.
OCS Server
MOC/Lync
Jabber

11. “I want to communicate from our Jabber platform to partners and customers on a XMPP platform for real time collaboration”
‘Inter-Domain Federation’ is the sharing of Enterprise Instant Messaging (IM) and Presence between 2 or more corporate domains – further lowering the boundaries to collaboration for B2B.
CUP (ABC.COM)
XMPP Based Vendor
Edge (DEF.COM)
Cisco ASA
XMPP Based Vendor
Home Node
XMPP
OCS Server
Inter-domain federation model should be used for B2B communication. XMPP federation is shown in the diagram, however both SIP and XMPP federation are supported as we will see in the forthcoming sections
XMPP Client

12. “I want to communicate from our Jabber platform to partners and customers who exist on consumer grade platforms”
‘Inter-Domain Federation’ is the sharing of Enterprise Instant Messaging (IM) and Presence between 2 or more corporate domains – further lowering the boundaries to collaboration for B2C.
CUP (ABC.COM)
XMPP
Cisco ASA
SIP
Jabber also provides federation options to consumer (B2C) vendors.
XMPP
Jabber

13. “I have Jabber cloud and I want to communicate to partners and customers”
‘Inter-Domain Federation’ is the sharing of Enterprise Instant Messaging (IM) and Presence between 2 or more corporate domains – further lowering the boundaries to collaboration for B2C.
XMPP
SIP
Jabber Cloud requires any organisation using Microsoft to deploy their XMPP gateway before Jabber Cloud will federated with them. Jabber cloud also provides a gateway to AOL.
XMPP
Jabber
XMPP
OCS Server

14. “I need to collaborate between our corporate sub-domains as we have many independent remote branches”
‘Inter-Domain Federation’ is also applicable in this case, as the presence treats each “presence domain” as an independent environment.
CUP (EMEA.ABC.COM)
CUP (APAC.ABC.COM)
Cisco ASA
Cisco ASA
XMPP
Inter-domain federation on Jabber provides a mechanism to communicate with sub-domains in an organisation.
Jabber
Jabber

15. “I Have Microsoft deployed, I want to trial Cisco Jabber on-prem and migrate all users over to Cisco”
‘Partitioned Intra-Domain Federation’ is the sharing of Enterprise Instant Messaging (IM) and Presence with the same presence domain – providing a seamless migration path from Microsoft to Cisco Infrastructure with minimal impact to the end-user
CUP (ABC.COM)
LCS/OCS R2 Home Server
(ABC.com)
SIP Static Route
OCS Server
Partitioned Intra-Domain federation is an on-premise communication from CUP to Microsoft LCS/OCS R2 via SIP (SIP is used as both vendors support SIP natively); both Cisco and Microsoft will exist in the same domain.
OCS Server
MOC
Jabber

16. Support and Feature Matrix

17. Inter-Domain Federation Support Matrix
Jabber On-Prem
Jabber Cloud
TLS**
Cost?
Google Talk
XMPP No
AOL
SIP
Yes
Yes – Licensed
MS OCS
MS Lync
IBM Sametime
Local
**TLS is for on-prem only, Jabber Cloud does not support TLS in any federation. This approach is common for cloud providers

18. Partitioned Intra-Domain Federation Support Matrix
Jabber On-Prem
Jabber Cloud
TLS**
LCS
SIP No
Yes
MS OCS R1 NA
MS OCS R2
MS Lync
Roadmap*
IBM Sametime
Local
*Support for Microsoft Lync scheduled for CUCM IM & P 9.0(2) (and CUP 8.6(X)) in Q4 CY’12 – Subject to Change
**TLS is for on-prem only, Jabber Cloud does not support TLS in any federation. This approach is common for cloud providers

19. Jabber On-Prem Inter-Domain Federation feature matrix
J Jabber On-Prem
P2P IM
Presence
Multi-Party Chat
OCS R1 & R2
Lync
IBM Same time
Jabber Cloud
GoogleTalk
AOL
XMPP Standard Vendor (e.g. Openfire)
Express support, but waiting for bug fix on Googles side

20. Jabber Cloud Inter-Domain Federation feature matrix
J Jabber Cloud
P2P IM
Presence
Multi-Party Chat
OCS R1 & R2*
Lync*
IBM Same time
Jabber On-Prem
GoogleTalk
AOL
XMPP Standard Vendor (e.g. Openfire)
*Support for Inter-Domain federation from Jabber Cloud to Microsoft is based on the use of Microsoft XMPP gateway

21. Option 1 : Inter-Domain Federation Protocol Flows

22. Microsoft Edge Server (DEF.COM)
Scenario 1 – On-Premise Inter-Domain Federation - SIP
TLS Initiated to federated side
ASA Initiates TLS to federated Edge
Upon TLS success, message reaches federated side
SIP Profile Configured on CUP
Microsoft Edge Server (DEF.COM)
CUP (ABC.COM)
Cisco ASA
Microsoft
Front End
SIP
OCS Server
TLS Proxy on ASA
CUP Domain is Authorized host on Edge
OCS Server
Message flow for SIP Inter-Domain federation. Note the ‘TLS Proxy’ functionality in the ASA, thus ensuring no traffic originating in the internet will pass directly through to CUP, it will be terminated and proxied in the DMZ.
ASA is a requirement for SIP Inter-Domain federation
MOC
*ASA is required for TLS Proxy

23. Scenario 1 – On-Premise Inter-Domain Federation - SIP
Service Type
SIP Port
FQDN of host offering SIP Service
DNS SRV record for SIP inter-domain federation. This must be available to your federated partner company (via Public DNS). Note the port number is for SIP TLS.

24. IBM Gateway Server (DEF.COM) IBM Lotus Sametime Server
Scenario 1 – On-Premise Inter-Domain Federation - XMPP
TLS Initiated to federated side
Upon TLS success, message reaches federated side
Connection is secured over TLS
XMPP Node status enabled
IBM Gateway Server (DEF.COM)
CUP (ABC.COM)
Cisco ASA
IBM Lotus Sametime Server
XMPP
TLS connection will be passed through port 5269
XMPP Node Status is enabled
OCS Server
The are a few subtle differences between XMPP and SIP inter-domain federation, namely the way its handled in the DMZ. SIP (via ASA) provides TLS proxy functionality, whereas XMPP does not, it is pass-through on port 5269 in the firewall (which is why ASA is not required, any generic firewall will suffice).
There is a workaround to place a CUP node in the DMZ to proxy inbound messaging, however it does not take care of the outbound case.
IBM Sametime
*TLS is optional. With No TLS selected, regular TCP will follow this path.
ASA is optional for XMPP Inter-Domain Federation. Generic Firewall will suffice

25. Scenario 1 – On-Premise Inter-Domain Federation - XMPP
When enabling XMPP federation, you must select security type. This depends on your organisation security requirements and that of the federated side
XMPP Federation has security options on the CUP admin GUI, as described above. If ‘No TLS’ (server dialback) is selected as the security type, you must enter an arbitrary secrit in “Dialback secret” field, which will be shared with the federated partner.
No TLS – TLS will NOT be attempted, the most basic form of security, server dial back, will occur
TLS Optional – A TLS handshake will occur first, if it fails, the connection will be allowed to fall back to server dialback
TLS Required – TLS will first be attempted, upon failure, the connection will be closed

26. Scenario 1 – On-Premise Inter-Domain Federation - XMPP
Service Type
XMPP Port
FQDN of host offering XMPP Service
DNS SRV record for XMPP inter-domain federation. This must be available to your federated partner company (via Public DNS). Note the port number is for XMPP server to server federated traffic.

27. Option 1 – On-Premise Inter-Domain Federation
For detailed configuration steps on Inter-Domain federation, please ALWAYS use this guide:
/integration_notes/Federation/CUP_8.6_Interdomain_Federation. html
For useful debugging information for this integration, please see:
/integration_notes/Federation/Debugging_reference.html
When configuring InterDomain federation, ALWAYS use the integration guide as a source of reference

28. Scenario 1 – Cloud Inter-Domain Federation - XMPP
Service Type
‘Inter-Domain Federation’ in the cloud is configured from the Organisation Administration Tool.
TLS is not supported in the cloud, all communication is over TCP.
To enable Inter-domain federation in the cloud, simply publish the DNS SRV records to point at your federation service.
For AOL Federation, this needs to be ordered; the Jabber cloud provisioning team will then configure it
XMPP Port
Cloud IM providers generally tend to use TCP, and not TLS as customer are reluctant to place their enterprise security certificates in a public space.
For AOL Federation, the customer will need to order it (Licensed federation). Once ordered, the Jabber Cloud team provisioning team will configure the federation.
FQDN of host offering XMPP Service

29. Option 1 – Cloud Inter-Domain Federation
For detailed configuration steps on Inter-Domain federation, please ALWAYS use this guide:
When configuring InterDomain federation, ALWAYS use the integration guide as a source of reference

30. Scenario 2 : Partitioned Intra-Domain Federation (On-Premise Only) Routing & Migration

31. Both Jabber and MOC have full contact search
Scenario 2 Partitioned Intra-Domain Federation
Example.com AD
Both Jabber and MOC have full contact search
XMPP
SIP
SIP Static Route
CUP8.6/ CUCM IM & P 9.0
Static route for OCS added in CUP: .com.example.*
OCS adds CUP for host authorization (FQDN/IP)
This slides demonstrates SIP static routing between CUP and Microsoft LCS/OCS R2.
This integration is completely transparent to the end-users, as full AD contact search is available to both platforms; each user will be unaware what platform their ‘buddy’ will be on.
Both servers are listening on port 5060 (TCP)

32. Scenario 2 Partitioned Intra-Domain Federation
How do I migrate users from Microsoft to Cisco?
Example.com
SIP Static Route
CUP8.6/ CUCM IM & P 9.0 1:
GetContacts.wsf (VB Script) – Exports users contact lists to be imported to CUP using BAT
2: DisableCommunicationsAccount .exe
3: DeleteOCSUserData.exe
All 3 support migration scripts to be run on Microsoft are available for download on CCO with CUP 8.6(4)

33. Scenario 2 Partitioned Intra-Domain Federation
When planning Intra-Domain Federation, what should I look out for?
When userID’s are sync’ed from LDAP, UCM/CUP will support:
sAMAccountName
UserPrincipleName (UPN)
Address
employeeNumber
telephoneNumber
**Caveat Alert**:
address can be mapped to UCM userID, that does not mean that userID equals address. It will become < - e.g.
UserID comes from UCM Database
CUP will append presence domain to create full JID
These slides highlight some common caveats when preparing partitioned Intra-domain federation routing and migration, AND ARE NOT TO BE IGNORED BEFORE IMPLEMENTING A POC, TO AVOID BACkTRACKING on AD configuration.

34. Scenario 2 Partitioned Intra-Domain Federation
For detailed configuration steps on Partitioned Intra-Domain federation, please ALWAYS use this guide:
/integration_notes/Federation/Intradomain_Federation/Partitioned _Intradomain_Federation.html
For useful debugging information for this integration, please see:
/integration_notes/Federation/Intradomain_Federation/Troublesho oting_chapter.html
When configuring Partitioned Intra-Domain federation, ALWAYS use the integration guide as a source of reference

35. What About Third party clients?
We have seen the federation models. CUP can locally (I.e. no federation) have third party clients logged in to it if the clients are XMPP standards compliant.

36. “I have deployed Jabber, but a sub-section of my employees also use third party clients”
‘Third Party Clients’ can interoperate with a Jabber backend, as Jabber is XMPP standards compliant; any XMPP standards based client can log directly into either CUP or Jabber cloud
Third party clients can be logged into on-premise or cloud deployment models.

37. Third Party Clients – On-Premise
To use third party clients with CUP, simply configure (from the respective client configuration):
Username and Password
CUP IP Address or FQDN
Domain name
XMPP Client port: 5222
For on-premise, you can directly edit the third party clients configuration to talk to CUP

38. Third Party Clients – Cloud
To use third party clients with Jabber Cloud, simply configure DNS SRV:
_XMPP-client
Presence domain: <example.com>
Port 5222
Host: c2s.example.com.webconnect.com
For cloud, you can directly edit the third party clients configuration to talk to cloud as well as configure DNS SRV records.