This integration enables the IM and Presence Service users from within any domain that IM and Presence Service manages to exchange availability information and Instant Messaging (IM) with users in external domains. The IM and Presence Service uses different protocols to federate with different external domains.

The IM and Presence Service uses the standard Session Initiation Protocol (SIP RFC 3261) to federate with:

• Microsoft Office 365 (business to business)

• Microsoft Skype for Business 2015, Standard Edition and Enterprise Edition (business to business)

• Microsoft Lync 2010 and 2013, Standard Edition and Enterprise Edition

  Note	IM and Presence Service supports interdomain federation with Microsoft Lync. For IM and Presence Service , any reference to interdomain federation with Microsoft S4B/Lync also includes Microsoft Office 365, unless explicitly stated otherwise.

IM and Presence Service uses the Extensible Messaging and Presence Protocol (XMPP) to federate with:

• IBM Sametime Server 8.2 and 8.5

• Cisco WebEx Messenger

• IM and Presence Service 9.x and up

• Any other server that is XMPP Standards compliant

Note

If you wish to enable XMPP federation with an external domain, ensure that the external domain was not previously configured as a SIP federated domain on the IM and Presence Service. Example: An IM and Presence deployment with example.com was historically configured as a SIP based federation. But example.com has now added XMPP support, so the local administrator instead wishes to enable an XMPP based federation. To allow this, the local administrator must first delete example.com as a SIP federated domain on the IM and Presence Service.

The following figure provides an example of a SIP federated network between IM and Presence Service enterprise deployment and Microsoft S4B/Lync enterprise deployment.

This example shows the messaging flows for a multi-cluster IM and Presence Service deployment where SIP Federation is enabled in one cluster only. A single routing node receives all incoming IMs from the Expressway-C and reroutes the IM to the correct node in either cluster. Outgoing IMs can be sent to the Expressway-C from any node in either cluster.

In the figure, each internal enterprise domain interconnects over the public internet using its DMZ edge server using a secure TLS connection. Within the internal IM and Presence Service enterprise deployment, the Cisco Adaptive Security Appliance provides firewall, Port Address Translation (PAT), and TLS proxy functionality. The Cisco Expressway-C routes all incoming traffic initiated from the external domain to a designated IM and Presence Service node.

The following figure provides an example of a multi-cluster XMPP federated network between IM and Presence Service enterprise deployment and an IBM Sametime enterprise deployment. TLS is optional for XMPP federation. Cisco Adaptive Security Appliance acts only as a firewall for XMPP federation; it does not provide TLS proxy functionality or PAT for XMPP federation. IMs can be sent and received from any node that has Federation enabled. However, Federation must be configured in parallel in both clusters.

There are two DNS servers within the internal IM and Presence Service enterprise deployment. One DNS server hosts the IM and Presence Service private address. The other DNS server hosts the IM and Presence Service public address and DNS SRV records for SIP federation (_sipfederationtls), and XMPP federation (_xmpp-server) with the IM and Presence Service. The DNS server that hosts the IM and Presence Service public address is located in the local DMZ.

Within the internal IM and Presence Service enterprise deployment, the Cisco Adaptive Security Appliance provides firewall, Port Address Translation (PAT) and TLS proxy functionality in the DMZ to terminate the incoming connections from the public internet, and permit traffic from specific federated domains.

Note	In an XMPP federation deployment, Cisco Adaptive Security Appliance provides firewall functionality only. If you already deploy a firewall, you do not require an extra Cisco Adaptive Security Appliance for XMPP federation.

You can deploy the Cisco Adaptive Security Appliance in a number of different ways, depending on your existing network and the type of firewall functionality you want to deploy. This section contains only an overview of the deployment models we recommend. For further details please refer to the deployment guidelines in the Cisco Adaptive Security Appliance documentation. The Cisco Adaptive Security Appliance deployment options we describe here apply to SIP federation only.

You can deploy the Cisco Adaptive Security Appliance as the enterprise firewall that protects Instant Messaging (IM) traffic, Availability traffic, and other traffic as illustrated in the following figures. This is the most cost-effective deployment, and the one we recommend for new and existing networks. You can also deploy the Cisco Adaptive Security Appliance in parallel to the existing firewall, as illustrated in the following figure. In this deployment Cisco Adaptive Security Appliance handles the IM and Presence Service traffic between IM and Presence Service and the public internet, and the pre-existing traffic continues to use any existing firewall. In the following figure Cisco Adaptive Security Appliance is also deployed as a gateway for the IM and Presence Service node, which means that you do not require a separate router to direct traffic to Cisco Adaptive Security Appliance.

You can also deploy the Cisco Adaptive Security Appliance behind an existing firewall. In this case, you configure the existing firewall to allow traffic destined for the IM and Presence Service to reach the Cisco Adaptive Security Appliance, as illustrated in the following figure. In this type of deployment the CiscoAdaptive Security Appliance is functioning as a gateway for the IM and Presence Service node.

All new presence subscriptions from x@externaldomain.com to user@local.comare sent by the Cisco Expressway-C, as shown in the following figure. The Cisco Expressway-C checks the inbound SIP subscriptions against the list of permitted external domains. If the domain is not permitted, the Cisco Expressway-C denies the presence subscription.

Note	In an XMPP federation deployment, the Cisco Expressway-C does not perform any domain checks.

On receipt of the inbound subscription, the IM and Presence Service verifies that the external domain is one of the permitted federated domains that you define at the administration level on the IM and Presence Service node. For SIP federation, you configure a federated domain. For XMPP federation, you define the administrator policy for XMPP federation. If the subscription is not from a permitted domain, the IM and Presence Service denies the subscription (without contacting the local user).

If the subscription is from a permitted domain, the IM and Presence Service checks the authorization policies of the local user to verify that the local user has not previously blocked or allowed either the federated domain or the user sending the presence subscription. The IM and Presence Service then accepts the incoming subscription and places it in a pending state.

The IM and Presence Service notifies the local user that x@externaldomain.com wants to watch their presence by sending the client application a notification message for the subscription. This triggers a dialog box on the client application that enables the local user to allow or deny the subscription. Once the user has made an authorization decision, the client application communicates that decision back to the IM and Presence Service. The authorization decision is added to the policy list of the user stored on the IM and Presence Service.

A deny decision is handled using polite blocking, which means that the presence state of the user appears offline on the external client. If the local user allows the subscription, the IM and Presence Service sends presence updates to the external watcher.

The user can also block subscriptions on a per user and a per domain basis. This can be configured by the Cisco Jabber client.

The IM and Presence Service sends all outgoing subscriptions through the Cisco Expressway-C, the Cisco Expressway-C then forwards these subscriptions to the external domain. The IM and Presence Service sends an outgoing subscription even if an active subscription already exists between a different local user to the same external user in the same external domain. The following figure illustrates an outgoing presence subscription flow.

The external user is added to the contact list on the client application and the IM and Presence Service User Options interface as user@externaldomain.com.

Note	The domain level authentication check is not applied on the Cisco Expressway-C for XMPP federation.

Note

Microsoft S4B/Lync performs a refresh subscribe every one hour and 45 minutes. Therefore, if an IM and Presence Service node restarts, the maximum duration a Microsoft S4B/Lync client is without the presence status of the IM and Presence Service contacts is approximately two hours. If Microsoft S4B/Lync restarts, the maximum duration an IM and Presence Service client is without presence status of Microsoft S4B/Lync contacts is approximately two hours.

Related Information -

Availability State Mappings

Instant Messaging

Federation is fully supported in IM and Presence Service deployments with multiple domains provided the remote domain is not managed by the local IM and Presence Service deployment.

You must create DNS records for all local domains to enable Federation for all users in the local cluster.

For XMPP federation, the cup-xmpp security certificate must have all local domains included as Subject Alt Names.

The IM and Presence Service supports the following subdomain scenarios:

• The IM and Presence Service belongs to a subdomain of the external domain. For example, theIM and Presence Service belongs to the subdomain "imp.cisco.com". The IM and Presence Service federates with an external enterprise that belongs to the domain "cisco.com". In this case, the IM and Presence Service user is assigned the URI "impuser@imp.cisco.com", and the external user has the URI "foreignuser@cisco.com".

• The IM and Presence Service belongs to a parent domain, and the external enterprise belongs to a subdomain of that parent domain. For example, the IM and Presence Service belongs to the domain "cisco.com". The IM and Presence Service federates with a external enterprise that belongs to the subdomain "foreign.cisco.com". In this case, the IM and Presence Service user is assigned the URI "impuser@cisco.com", and the external user is assigned the URI "foreignuser@foreign.cisco.com".

• The IM and Presence Service and the external enterprise each belong to different subdomains, but both of these subdomains belong to the same parent domain. For example, the IM and Presence Service belongs to the subdomain "cup.cisco.com" and the external enterprise belongs to the subdomain "foreign.cisco.com". Both of these subdomains belong to the parent domain "cisco.com". In this case, the IM and Presence Service user is assigned the URI "impuser@cup.cisco.com" and the external user is assigned the URI "foreignuser@foreign.cisco.com".

If you federate with subdomains, you only need to configure separate DNS domains; there is no requirement to split your Active Directory. If you configure federation within the enterprise, the IM and Presence Service users or external users can belong to the same Active Directory domain. For example, in the third scenario above, the Active Directory can belong to the parent domain "cisco.com". You can configure all users under the "cisco.com" domain in Active Directory, even though a user may belong to the subdomain "imp.cisco.com" or "foreign.cisco.com", and may have the URI "impuser@imp.cisco.com" or "foreignuser@foreign.cisco.com".

Note that even though an LDAP search from Cisco Jabber may return users in the other domain, or subdomain, a Cisco Jabber user cannot add these federated users from the LDAP lookup on Cisco Jabber. TheCisco Jabber user must add these users as external (federated) contacts so that the IM and Presence Service applies the correct domain and not the local domain.

Note	The IM and Presence Service also supports the scenarios above if you configure federation between two IM and Presence Service enterprise deployments.