Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager, Release 9.1(1)
Configuration of IM and Presence Service for XMPP federation
Download this chapter
Configuration of IM and Presence Service for XMPP federationConfiguration of IM and Presence Service for XMPP federation
Download the complete book
Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager, Release 9.1(1)Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager, Release 9.1(1) (PDF - 5 MB)
 Feedback

Configuration of IM and Presence Service for XMPP federation

Configure general settings for XMPP federation

XMPP federation overview

IM and Presence Release 9.0 and later supports XMPP federation with the following enterprises:

  • Cisco WebEx Messenger Release 7.x
  • IBM Sametime Release 8.2 and 8.5
  • GoogleTalk
  • Cisco Unified Presence Release 8.x
  • IM and Presence Release 9.x or greater

Note

The IM and Presence Service does not support XMPP federation between an IM and Presence Release 9.x 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:

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.

    What to Do Next

    Configure security settings for XMPP federation

    Configure security settings for XMPP federation

    Before You Begin
    • 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:
      1. 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.
      2. 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.
      3. 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.
      Related Tasks

      DNS configuration for XMPP federation

      DNS SRV records for XMPP federation

      To allow IM and Presence Service 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 Service 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 Service, 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 Service routes all incoming requests from foreign domains to the node running federation. Internally IM and Presence Service reroutes the requests to the correct node for the user. IM and Presence Service 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 Service 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 Service enterprise domain. As a result, IM and Presence Service 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 Service 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 Service can route the request to any of the servers that DNS publishes. Internally IM and Presence Service reroutes the requests to the correct node for the user. IM and Presence Service 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 Service routes all incoming requests to that single node, rather than load-balancing the incoming requests across the nodes running XMPP federation. IM and Presence Service will load-balance outgoing requests and send outgoing request from from any of the nodes running XMPP federation.

      Related References

      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:

      1. Configure the DNS SRV for the chat node alias to point to port 5269.
      2. 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.

      1. Configure the DNS SRV for the chat node to use some arbitrary port other than 5269, for example, 25269.
      2. 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.

      Related Tasks

      Configure DNS SRV record for chat node for XMPP federation

      Procedure
        Step 1   To retrieve the chat node alias:
        1. Select Cisco Unified CM IM and Presence Administration > Messaging > Group Chat Server Alias Mapping.
        2. Select Find to display a list of chat node aliases.
        3. 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 in step 2 is "conference-2-StandAloneCluster ", and you skip step 3. In step 4, create the domain '_tcp' under 'conference-2-StandAloneCluster'.

        Figure 2. DNS SRV for "_xmpp-server" for Chat Feature



        Figure 3. DNS configuration for Chat Feature



        Related References

        Policy settings configuration for XMPP federation

        Policy exception configuration

        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:
          1. Select Add New.
          2. Specify the domain name or the hostname of the foreign server.
          3. Specify the direction to apply the policy exception.
          4. 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.

          Related References

          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) 
          

          nat (inside,outside) source static obj_host_<private cup2 ip> obj_host_<public cup2 IP> serviceobj_udp_source_eq_5269 obj_udp_source_eq_5269
nat (inside,outside) source static obj_host_<private cup2 ip> obj_host_<public cup2 IP> service
obj_tcp_source_eq_5269 obj_tcp_source_eq_5269

nat (inside,outside) source static obj_host_<private cup3 ip> obj_host_<public cup3 IP> service
obj_udp_source_eq_5269 obj_udp_source_eq_5269
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_5269
          

            
          

          

          Related References
          


          

          

          Turn on email for XMPP federation
          

          When you turn on IM and
			 Presence to use
                the email address for XMPP federation, IM and
			 Presence changes the JID of
                the local user to the email address of the contact. 
          

          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.
          

           If you have an intercluster deployment, you must turn on the email address for federation on all intercluster nodes in your deployment. You must then restart the Cisco XCP Router service after the email for federation feature is turned on.
          

          To turn on email for XMPP
                federation, follow the same procedure as for SIP federation, see the procedure in
                the Related Topics section below. 
          

          

          

          Related Tasks
          


          

          

          Turn on XMPP federation service
          

          
		
          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.
		
          

	 
          

          Before You Begin
		
          Turn on XMPP Federation for the node from 
		  Cisco Unified CM IM and
			 Presence Administration, see 
		  Turn on XMPP federation on a node.
		
          

	 
          
Procedure
            Step 1  
            Select 
			 Cisco Unified
				  IM and
			 Presence Serviceability > Tools > Service
				  Activation. 
		  
            

            Step 2  
            Select the server from the Server list box. 
		  
            

            Step 3  
            Select 
			 Go. 
		  
            

            Step 4  
            Select the radio button next to the 
			 Cisco XCP XMPP Federation Connection
				Manager service in the IM and
			 Presence Services section. 
		  
            

            Step 5  
            Select 
			 Save. 
		  
            

            

            

            Related Information