IM and Presence
Release 9.0 supports XMPP federation with the following enterprises:
Cisco WebEx Connect Release 6.0
IBM Sametime Release 8.2 and 8.5
GoogleTalk
(Another) IM and Presence Release 9.0
enterprise
Note
The IM and Presence
Service does not support XMPP federation between an IM and Presence
Release 9.0 enterprise and a Cisco Unified Presence Release 7.x enterprise.
When IM and Presence is
federating with Webex Enterprise, it is not possible for Webex Connect client
users to invite IM and Presence users to temporary or persistent chat rooms. This is due
to a design constraint on the WebEx Connect client.
To allow IM and Presence to
federate over XMPP, you must enable and configure XMPP federation on IM and Presence, following the procedures we describe in this chapter.
If you have multiple
IM and Presence clusters, you must enable and configure XMPP federation
on at least one node per cluster. The XMPP federation configuration must be
identical across clusters. The Diagnostics Troubleshooter compares the XMPP
federation configuration across clusters, and reports if the XMPP federation
configuration is not identical across cluster.
If you deploy Cisco Adaptive Security Appliance for firewall purposes, note the
following:
See section Integration preparation for
considerations on routing, scale, public IP addresses and the CA
authority.
Important notes about restarting services for XMPP federation
Note
If you make a change to any of the XMPP Federation
settings, you must restart these services in IM and Presence Serviceability:
Cisco XCP Router (select
Tools > Control Center -
Network Services), Cisco XCP XMPP Federation
Connection Manager (select
Tools > Control Center -
Feature Services). When you restart the Cisco XCP
Router service,
IM and Presence restarts all the XCP services.
If you enable or disable XMPP federation on a node, you must
restart the Cisco XCP Router on all nodes within a cluster, not just on the
node where XMPP federation has been enabled or disabled. For all other XMPP
federation settings, a Cisco XCP Router restart is only required on the node
to which the setting is being changed.
Turn on XMPP federation on a node
This setting is turned off by default.
Procedure
Step 1
Select
Cisco Unified CM IM and
Presence
Administration > Presence > Inter
Domain Federation > XMPP
Federation > Settings.
Select
On
in the XMPP Federation Status menu.
Step 2
Select
Save.
Troubleshooting Topics
You cannot start the XCP XMPP Federation Connection Manager
service on the
IM and
Presence node, unless you turn on XMPP Federation on the
node.
Determine whether the
foreign domain that you are federating with supports TLS connections.
The TLS and SASL specific
settings are only configurable if you select the SSL mode ‘TLS Optional’ or
‘TLS Required’.
If you are configuring
federation between
IM and Presence and IBM using TLS, you must configure the SSL mode
‘TLS Required’, and you must enable SASL.
Procedure
Step 1
Select
Cisco Unified CM IM and Presence
Administration > Presence > Inter
Domain Federation > XMPP
Federation > Settings.
Step 2
Select a security mode from the menu:
No TLS -
IM and Presence will not establish a TLS connection with the foreign
domain. The system uses a non-encrypted connection to federate with the foreign
domain, and uses the server dialback mechanism to verify the identity of the
other server.
TLS Optional -
IM and Presence attempts to establish a TLS connection with the
foreign domain. If
IM and Presence fails to establish a TLS connection, it reverts to
server dialback to verify the identity of the other server.
TLS Required - The system guarantees a secure (encrypted)
connection with the foreign domain.
Step 3
Check
Require client-side security certificates if
you want to enforce strict validation of certificates from foreign domain
servers against an installed root CA certificate. This setting turns on, by
default, if you select either TLS Optional or TLS Required security settings.
Note
If you are configuring XMPP federation with WebEx, do not check
Require client-side security certificates.
Step 4
Check
Enable SASL EXTERNAL on all incoming
connections to ensure that IM and Presence advertises
support for SASL EXTERNAL on incoming connection attempts and will implement
SASL EXTERNAL validation.
Step 5
Check
Enabling SASL on outbound connections to
ensure that IM and Presence sends a SASL auth id to the foreign domain
if the foreign server requests SASL EXTERNAL.
Step 6
Enter the dialback secret if you want to use DNS to verify the
identity of a foreign server that is attempting to connect to IM and Presence. IM and Presence will not accept any packets from the foreign
server until DNS validates the identity of the foreign server.
Step 7
Select
Save.
Troubleshooting Tips
For further information on the security settings, see the
Online Help.
If the server is part of an intercluster deployment, then you
must configure each cluster with the same security settings. Run the System
Troubleshooter to ensure that your configuration is consistent on all nodes.
To allow
IM and Presence to discover a particular XMPP federated domain, the
federated enterprise must publish the DNS SRV record "_xmpp-server" in its
public DNS server. Similarly,
IM and Presence must publish the same DNS SRV record in the DNS for its
domain. Both enterprises must publish the port 5269. The published FQDN must
also be resolvable to an IP address in DNS.
The record required is:
"_xmpp-server._tcp.<domain>"
See the following figure for a sample DNS configuration for
the DNS SRV record "_xmpp-server".
Figure 1. DNS SRV for "_xmpp-server"
If you have remote root access to
IM and Presence, you can run nslookup to determine if the federated domain
is discoverable.
Tip
Use this sequence of commands for performing a DNS SRV lookup:
nslookupset type=srv
_xmpp-server._tcp.<domain>
(<domain> is the domain of the federated enterprise.)
This command returns an output similar to this (where
"example.com" is the domain of the federated server):
_xmpp-server._tcp.example.com service = 0 0 5269 hostname.example.com.
For a single cluster, you only need to enable XMPP
federation on one node in the cluster. You publish one DNS SRV record for the
enterprise in the public DNS.
IM and Presence routes all incoming requests from foreign domains to the
node running federation. Internally
IM and Presence reroutes the requests to the correct node for the user.
IM and Presence also routes all outgoing requests to the node running XMPP
federation.
You can also publish multiple DNS SRV records, for example,
for scale purposes, or if you have multiple
IM and Presence clusters and you must enable XMPP federation at least once
per cluster. Unlike SIP federation, XMPP federation does not require a single
point of entry for the
IM and Presence enterprise domain. As a result,
IM and Presence can route incoming requests to any one of the published
nodes in the cluster that you enable for XMPP federation.
In an intercluster and a multi-node cluster
IM and Presence deployment, when a foreign XMPP federated domain initiates a
new session, it performs a DNS SRV lookup to determine where to route the
request. If you publish multiple DNS SRV records, the DNS lookup returns
multiple results;
IM and Presence can route the request to any of the servers that DNS
publishes. Internally
IM and Presence reroutes the requests to the correct node for the user.
IM and Presence routes outgoing requests to any of the nodes running XMPP
federation.
If you have multiple nodes running XMPP federation, you can
still choose to publish only one node in the public DNS. With this
configuration,
IM and Presence routes all incoming requests to that single node, rather
than load-balancing the incoming requests across the nodes running XMPP
federation.
IM and Presence will load-balance outgoing requests and send outgoing
request from from any of the nodes running XMPP federation.
DNS SRV records for chat feature for XMPP federation
If you
configure the Chat feature on a IM and Presence server in an XMPP federation deployment,
you must publish the chat node alias in DNS.
The hostname, to which the DNS SRV record for the
chat node resolves, resolves to a public IP address. Depending on your
deployment, you may have a single public IP address, or a public IP address for
each chat node within your network:
Single public IP address, multiple nodes
internally:
To
route all chat requests to the XMPP federation node, and
then on to the chat node:
Configure the DNS SRV for the
chat node alias to point to port 5269.
Configure a NAT command
configured on Cisco Adaptive Security Appliance or firewall\NAT
server that maps publicIPAddress:5269 to
XMPPFederationNodePrivateIPAddress:5269.
Multiple public IP addresses, multiple nodes
internally:
If
you have multiple public IP addresses, you can choose to
route chat requests directly to the appropriate chat node.
Configure the DNS SRV for the
chat node to use some arbitrary port other than
5269, for example, 25269.
Configure a PAT command on
Cisco Adaptive Security Appliance or firewall\NAT server that
maps textChatServerPublicIPAddress:25269 to
textChatServerPrivateIPAddress:5269.
Note
To
allow the chat node handle incoming federated text
requests, you must turn on the Cisco XCP XMPP
Federation Connection Manager on the chat node.
For information
on configuring the Chat feature on IM and Presence, see
Deployment Guide for IM and Presence Release 9.x.
Configure DNS SRV record for chat node for XMPP federation
Procedure
Step 1
To retrieve the chat node alias:
Select
Cisco Unified CM IM and Presence
Administration > Messaging > Conference
Server Alias Mapping.
Select
Find to display a list of chat node
aliases.
Select the chat node alias that you want to publish in DNS,
for example "conference-2.StandAloneCluster.example.com".
Step 2
In the public DNS server for the "example.com" domain, create the
domain "StandAloneCluster".
Step 3
In the domain "StandAloneCluster", create the domain
"conference-2".
Step 4
In the domain "conference-2", create the domain " _tcp".
Step 5
In the domain "_tcp", create a new DNS SRV record for
"_xmpp-server". See the following figures for a sample DNS configuration.
Note
If the text conference server alias is
"conference-2-StandAloneCluster.example.com" then the domain at step 3 is
"conference-2-StandAloneCluster ", and you skip step 4.
Figure 2. DNS SRV for "_xmpp-server" for Chat Feature
You can configure exceptions to the default policy for XMPP
federation. In the exception, you must specify the foreign domain to which you
want to apply the exception, and a direction rule for the exception. When you
configure the domain name for a policy exception, note the following:
If the URI or JID of the user is "user@example.com", configure the
foreign domain name in the exception as "example.com".
If the foreign enterprise uses hostname.domain in the URI or JID
of the user, for example "user@hostname.example.com", configure the foreign
domain name in the exception as
"hostname.example.com".
You can use a wildcard (*) for the foreign domain name in the
exception. For example, the value "*.example.com" applies the policy on
"example.com" and any subdomain of example.com, for example,
"somewhere.example.com".
You must also specify the direction that
IM and Presence applies the policy exception. These direction options are
available:
all federated packets from/to the above domain/host -
IM and Presence allows or denies all traffic going to and coming from the
specified domain.
only incoming federated packets from the above domain/host
- Allow
IM and Presence to receive inbound broadcasts from the specified domain, but
IM and Presence does not send responses.
only outgoing federated packets to the above domain/host -
Allow
IM and Presence to send outbound broadcasts to the specified domain, but
IM and Presence does not receive responses.
Related Tasks
Configure policy for XMPP federation
Caution
If you make a change to any of the XMPP Federation settings, you
must restart these services in Cisco Unified IM and Presence Serviceability: Cisco XCP
Router (select
Tools > Control Center - Network
Services), Cisco XCP XMPP Federation Connection
Manager (select
Tools > Control Center -
Feature Services). When you restart the Cisco XCP
Router service,
IM and Presence restarts all the XCP services.
Procedure
Step 1
Select
Cisco Unified CM IM and Presence
Administration > Presence > Inter
Domain Federation > XMPP
Federation > Policy.
Step 2
Select the policy settings from the menu:
Allow -
IM and Presence permits all federated traffic from XMPP federated
domains, except those domains that you explicitly deny on the policy exception
list.
Deny -
IM and Presence denies all federated traffic from XMPP federated
domains, except those domains that you explicitly permit on the policy
exceptions list.
Step 3
To configure a domain on the policy exception list:
Select
Add New.
Specify the domain name or the hostname of the foreign server.
Specify the direction to apply the policy exception.
Select
Save on the policy exception window.
Step 4
Select
Save on the policy window.
Troubleshooting Tips
See the Online Help for federation policy recommendations.
Configure Cisco Adaptive Security Appliance for XMPP federation
For XMPP Federation, Cisco Adaptive Security Appliance acts as a firewall
only. You must open port 5269 for both incoming and outgoing XMPP federated traffic
on Cisco Adaptive Security Appliance.
These are sample access lists
to open port 5269 on Cisco Adaptive Security Appliance Release 8.3.
Allow traffic from any
address to any address on port 5269:
access-list ALLOW-ALL
extended permit tcp any any eq 5269
Allow traffic from any
address to any single node on port 5269:
access-list ALLOW-ALL
extended permit tcp any host <private IM and Presence IP address> eq 5269
If you do not configure the
access list above, and you publish additional XMPP federation nodes in DNS, you must
configure access to each of these nodes, for example:
object network obj_host_<private cup ip address>#host <private cup ip address>
object network obj_host_<private cup2 ip address>
#host <private cup2 ip address>
object network obj_host_<public cup ip address>
#host <public cup ip address>
....
Configure the following NAT
commands:
nat (inside,outside) source static obj_host_<private cup1 IP> obj_host_<public cup IP> serviceobj_udp_source_eq_5269 obj_udp_source_eq_5269
nat (inside,outside) source static obj_host_<private cup1 IP> obj_host_<public cup IP> service
obj_tcp_source_eq_5269 obj_tcp_source_eq_5269
If you publish a single
public IP address in DNS, and use arbitrary ports, configure the following:
(This example is for two
additional XMPP federation nodes)
nat (inside,outside) source static obj_host_<private cup2 ip> obj_host_<public cup IP> serviceobj_udp_source_eq_5269 obj_udp_source_eq_25269
nat (inside,outside) source static obj_host_<private cup2 ip> obj_host_<public cup IP> service
obj_tcp_source_eq_5269 obj_tcp_source_eq_25269
nat (inside,outside) source static obj_host_<private cup3 ip> obj_host_<public cup IP> service
obj_udp_source_eq_5269 obj_udp_source_eq_35269
nat (inside,outside) source static obj_host_<private cup3 ip> obj_host_<public cup IP> service
obj_tcp_source_eq_5269 obj_tcp_source_eq_35269
If you publish multiple
public IP addresses in DNS all using port 5269, configure the following:
(This example is for two
additional XMPP federation nodes)
When you turn on IM and
Presence to use
the email address for XMPP federation, IM and
Presence changes the JID of
each federated contact to the email address of the contact.
To turn on email for XMPP
federation, follow the same procedure as for SIP federation, see the procedure in
the Related Topics section below.
The email address for
federation feature (in an XMPP federation deployment) does not currently support
temporary or persistent chat rooms in a multi-cluster IM and
Presence
deployment. In the deployment scenario where there are multiple IM and
Presence clusters in the local domain, the local users actual jid may be sent to the
federated user. The only impact to the chat room is that the name that displays to
the federated user is the userid of the local user, instead of the email address of
the local user; all other chat room functionality operates as normal. This only
occurs in temporary or persistent chat rooms with federated users.
You need to turn on the Cisco XCP XMPP Federation
Connection Manager service on each
IM and
Presence node that runs XMPP federation. Once you turn on the
Federation Connection Manager service from the Service Activation window,
IM and
Presence automatically starts the service; you do not need to
manually start the service from the Control Center - Feature Services window.