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

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?

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

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

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

Federation Models

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

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

What Business Case are you trying to solve?

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

“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

“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

“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

“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

“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

Support and Feature Matrix

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

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

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

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

Option 1 : Inter-Domain Federation Protocol Flows

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

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.

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

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

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.

Option 1 – On-Premise Inter-Domain Federation For detailed configuration steps on Inter-Domain federation, please ALWAYS use this guide: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english /integration_notes/Federation/CUP_8.6_Interdomain_Federation. html For useful debugging information for this integration, please see: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english /integration_notes/Federation/Debugging_reference.html When configuring InterDomain federation, ALWAYS use the integration guide as a source of reference

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

Option 1 – Cloud Inter-Domain Federation For detailed configuration steps on Inter-Domain federation, please ALWAYS use this guide: http://www.webex.com/webexconnect/orgadmin/help/cs_im_fed.htm When configuring InterDomain federation, ALWAYS use the integration guide as a source of reference

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

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)

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)

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) Email Address employeeNumber telephoneNumber **Caveat Alert**: Email address can be mapped to UCM userID, that does not mean that userID equals email address. It will become <email- address>@<cupdomain>, e.g. bobjones@bar.com@example.com bobjones@example.com 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.

Scenario 2 Partitioned Intra-Domain Federation For detailed configuration steps on Partitioned Intra-Domain federation, please ALWAYS use this guide: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english /integration_notes/Federation/Intradomain_Federation/Partitioned _Intradomain_Federation.html For useful debugging information for this integration, please see: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english /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

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.

“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.

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

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.