The Presence Web Service is an open interface that allows client applications to share user presence information with IM and Presence Service. Third party developers use this interface to build client applications that can send and retrieve updates about the presence state of a user. Note the following restrictions about Presence Web Service API support:

• For interdomain federation over SIP, you can use the Presence Web Service API to obtain rich presence information from non-Cisco clients, but basic presence for non-Cisco clients is not supported.

• For interdomain federation over XMPP, you cannot use the Presence Web Service API to obtain presence information from non-Cisco clients.

For more information about the Presence Web Service, see the IM and Presence Service Developer Guide at https://developer.cisco.com/site/collaboration/call-control/unified-presence/documentation/index.gsp.

Consider how you are going to set up routing in your federated network. Consider how you route messages that are destined for an external domain address from IM and Presence Service through the Cisco Expressway-C to the external domain. You could consider deploying a routing entity (router, switch or gateway) between the IM and Presence Service enterprise deployment and Cisco Expressway-C. The routing entity routes messages to the Cisco Expressway-C, and Cisco Expressway-C routes these messages to the external domain.

You can also deploy Cisco Expressway-C as a gateway between the IM and Presence Service and the external domain. If you use the Cisco Expressway-C as a gateway for the IM and Presence Service, within your local enterprise deployment, you must consider how the Cisco Unified Communications Maanger, and the IM and Presence Service client access the IM and Presence Service node. If the Cisco Unified Communications Maanger and the IM and Presence Service clients are in a different subnet from the IM and Presence Service, they must access the IM and Presence Service using the Cisco Expressway-C.

If you deploy the Cisco Expressway-C behind an existing firewall in your network, consider how you route traffic to the Cisco Expressway-C and to the IM and Presence Service. On the existing firewall, configure routes and access lists to route traffic to the public IM and Presence Service address. You must also configure routes to the external domain using the existing firewall.

Related Information

Cisco Adaptive Security Appliance Deployment Options

For SIP federation, you require a publicly accessible IP address for the public IM and Presence Service address. If you do not have an IP address that you can assign, use the outside interface of the Cisco Expressway-C as the public IM and Presence Service address (once you only use the Cisco Expressway-C for availability and IM traffic).

For XMPP federation, you can choose to either expose a public IP address for each IM and Presence Service node on which you enable XMPP federation, or expose a single public IP address:

• If you expose multiple IP addresses, you use NAT on Cisco Expressway-C to convert the public addresses to private addresses. For example, you can use NAT to convert the public addresses x.x.x.x:5269 and y.y.y.y:5269 to the private addresses a.a.a.a:5269 and b.b.b.b:5269 respectively.

• If you expose a single IP address, you use PAT on Cisco Expressway-C to map to the correct IM and Presence Service node. For example, the public IP address in your deployment is x.x.x.x, and there are multiple DNS SRV records for _xmpp-server. Each record has a different port, but all records resolve to x.x.x.x. The external servers sends requests to x.x.x.x:5269, x.x.x.x:15269, x.x.x.x.25269 through the Cisco Expressway-C. The Cisco Expressway-C performs PAT on the IP addresses, whereby it maps each address to the corresponding internal IP address for each IM and Presence Service node.

  For example, the public IP address x.x.x.x:5269 maps to the private IP address a.a.a.a:5269, the public IP address x.x.x.x:15269 maps to the private IP address b.b.b.b.b:5269, and the public IP address x.x.x.x:25269 maps to the private IP address c.c.c.c:5269, and so on. All IP addresses map internally to the same port (5269) on the IM and Presence Service.

Related Information -

External and Internal Interface Configuration

DNS Configuration

For SIP federation, request messages are routed based on the FQDN. Therefore, the FQDN of the routing IM and Presence Service node (publisher) must be publicly resolvable.

The AOL SIP Access Gateway provides federated services, which permit a company’s SIP/SIMPLE-based instant messaging servers to communicate with other instant messaging users on the network. Using the AOL SIP Access Gateway, it is possible for users of a company’s SIP/SIMPLE-based messaging server to obtain availability information for, and hold conversations with, public users of the AIM or AOL services. The AOL SIP Access Gateway also enables users of the AIM or AOL systems to send instant messages and to display availability information for users of the company’s internal SIP/SIMPLE-based system.

The AOL SIP Access Gateway acts as the front end to a translator for internal AOL protocols. All communications between the company server and AOL uses SIP. The AOL SIP Access Gateway handles the translation into the protocols needed by internal AOL systems. It is not necessary to add any translation capabilities to external servers; from that perspective the AOL protocols are hidden. If the company server communicates using SIP/SIMPLE, it should still be possible to connect to AOL through the AOL SIP Access Gateway.

The AOL SIP Access Gateway supports connections by TLS over TCP only. The AOL SIP Access Gateway server should be defined within your instant messaging servers or proxies with this address:

Server Name: sip.oscar.aol.com

Server Port: 5061

The server name sip.oscar.aol.com resolves to 205.188.153.55 & 64.12.162.248.

Note

If you configure these IP addresses statically anywhere in your network, we recommend that you periodically check with AOL for potential changes to these addresses. We recommend that you ping the FQDN of AOL SIP Access Gateway (sip.oscar.aol.com) to confirm the IP address as it may be subject to change, for example ping sip.oscar.aol.com.

You need to consider how you are going to configure redundancy in your federated network. The Cisco Expressway-C supports redundancy by providing the Active/Standby (A/S) deployment model.

If you wish to make your IM and Presence Service federation capability highly available you can deploy a load balancer in front of your designated (federation) IM and Presence Service cluster.

In the local IM and Presence Service enterprise deployment, the IM and Presence Service must publish a DNS SRV record for the IM and Presence Service domain to make it possible for other domains to discover the IM and Presence Service node through DNS SRV. The DNS SRV records reside on the DNS server in the enterprise DMZ.

If the local IM and Presence Service deployment is managing multiple domains, you must publish a DNS SRV record for each local domain. The DNS SRV record you publish for each local domain should resolve to the same public FQDN IP address.

For SIP federation with Microsoft S4B/Lync, you must publish the DNS SRV record "_sipfederationtls". The Microsoft enterprise deployment requires this record because you configure the IM and Presence Service as a Public IM Provider on the Access Edge server. In the external enterprise deployment, in order for the IM and Presence Service to discover the Microsoft domain, a DNS SRV record must exist that points to this external domain. If the IM and Presence Service node cannot discover the Microsoft domain using DNS SRV, you must configure a static route on the IM and Presence Service that points to the public interface of this external domain.

See the following figure for a sample DNS configuration for the DNS SRV record "_sipfederationtls_tcp.example.com" .

Because DNS SRV records are publicly resolvable, if you turn on DNS forwarding in the local enterprise, DNS queries retrieve information about public domains outside of the local enterprise. If the DNS queries rely completely on DNS information within the local enterprise (you do not turn on DNS forwarding in the local enterprise), you must publish DNS SRV record/FQDN/IP address that points to the external domain. Alternatively. you can configure static routes.

For XMPP federation, you must publish the DNS SRV record "_xmpp-server". This record enables federated XMPP domains to discover the IM and Presence Service domain so users in both domains can exchange IM and availability information over XMPP. Similarly, external domains must publish the _xmpp-server record in their public DNS server to enable theIM and Presence Service to discover the external domain.

See the following figure for a sample DNS configuration for the DNS SRV record "_xmpp-server".

For SIP federation, the Cisco Adaptive Security Appliance in the IM and Presence Service enterprise deployment, and the external enterprise deployment, share IM and availability over a secure SSL/TLS connection.

Each enterprise deployment must present a certificate that is signed by an external Certificate Authority (CA), however each enterprise deployment may using a different CA. Therefore each enterprise deployment must download the root certificate from the external CA of the other enterprise deployment to achieve a mutual trust between the two enterprise deployments.

For XMPP federation, you can choose whether or not to configure a secure TLS connection. If you configure TLS, on the IM and Presence Service you need to upload the root certificate of the Certificate Authority (CA) that signs the certificate of the external enterprise. This certificate must exist in the certificate trust store on the IM and Presence Service because the Cisco Expressway-C does not terminate the TLS connections for XMPP federation; Cisco Expressway-C acts as a firewall for XMPP federation.