This chapter describes how to federate Oracle Communications Instant Messaging Server deployments to enable communications between users on different servers.
Instant Messaging Server supports inter-domain communication through federation. You can enable federation between two XMPP servers serving two different domains or between an XMPP server and a SIP/SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions/Session Initiation Protocol) server serving two different domains through the SIP Gateway. This solution enables users on XMPP or SIP/SIMPLE networks to be able to communicate with each other.
When federating between multiple Instant Messaging servers, end users from different servers can communicate with each other, and use conference rooms on other domains, based on their access privileges.
In an LDAP-only deployment, the two servers should reside in different domains. For enabling communication between multiple Instant Messaging servers in your network, you must perform the configuration described in this chapter.
When federating between Instant Messaging Server and a server on a SIP/SIMPLE network, end users from different servers should be able to subscribe to each other's presence, send one-to-one chat messages, and enforce the privacy preferences. For enabling communication between Instant Messaging servers and SIP/SIMPLE servers, see "Configuring the SIP Gateway".
If both XMPP and SIP open federation are enabled, and a domain has both XMPP and SIP servers, XMPP federation is the preferred option.
Secure your server-to-server communication by using transport-layer security (TLS). This is required to prevent-third party infringement of security when data is exchanged between two servers. This precaution is extremely desirable in the case where the link between the two servers uses the public Internet. See Instant Messaging Server Security Guide for information on how to configure TLS.
Note:
You can use the server-to-server federation only if the servers are using the same protocol. Instant Messaging Server uses the XMPP protocol. Thus, you can federate a server-to-server communication with GTalk or Openfire servers. In addition, Instant Messaging Server provides support for a user on an XMPP network to communicate with a user on a SIP/SIMPLE network through the SIP gateway.This section describes how to enable federated communication, either between two XMPP servers or between XMPP servers and SIP/SIMPLE servers. Both federated XMPP and SIP deployments require that you set the iim_server.federation.policy to OPEN. See "About the SIP Gateway" for more information on SIP. When you enable federation between XMPP and SIP/SIMPLE servers, additional steps are required, as described in "Configuring the SIP Gateway".
Table 16-1 lists the federation configuration properties.
Table 16-1 Federation Configuration Properties
| Property | Default Value | Description |
|---|---|---|
|
iim_server.federation.policy |
CLOSED |
Specifies whether the server is allowed to federate with all other XMPP or SIP/SIMPLE servers, where OPEN indicates that it is allowed and CLOSED indicates that it is not allowed. |
|
iim_server.federation.exceptions |
None |
Specifies a blacklist of domains where federation for XMPP or SIP/SIMPLE servers is denied. When iim_server.federation.policy=CLOSED and this property is set, the result is whitelisted domains where federation for XMPP or SIP/SIMPLE servers is allowed. |
You use the imconfutil command to set the federation configuration properties.
To enable federation, set iim_server.federation.policy=OPEN.
When this property is set, any domain is able to federate with this Instant Messaging Server host.
To disable federation, set iim_server.federation.policy=CLOSED.
When this property is set, no domain is be able to federate with this Instant Messaging Server host.
To achieve open federation, but with a few domains blacklisted, set iim_server.federation.policy=OPEN and iim_server.federation.exceptions=domain1.com,domain2.com.
In this example, federation is allowed for any domain except domain1.com and domain2.com.
To achieve federation with only a small whitelist of domains, set iim_server.federation.policy=CLOSED and iim_server.federation.exceptions=domain1.com,domain2.com.
In this example, federation is allowed only for the domain1.com and domain2.com examples, and no other domains.
Note:
The domains in the exception list can be XMPP domains or SIP domains. See "Configuring the SIP Gateway" for more information on SIP.To have the configuration change take effect, restart Instant Messaging Server:
imadmin refresh server
In a federated deployment, the XMPP server must publish _xmpp-server DNS SRV records for supported XMPP domains in the DNS server.
Table 16-2 lists the DNS SRV records required for instant messaging and conference services.
Table 16-2 DNS SRV Records for XMPP Server
| service._proto.name | TTL | Class | Type | Priority | Weight | Port | Target |
|---|---|---|---|---|---|---|---|
|
xmpp-server._tcp.example.com |
86400 |
IN |
SRV |
5 |
0 |
5269 |
xmpp.example.com |
|
_xmpp-server._tcp.muc.example.com |
86400 |
IN |
SRV |
5 |
0 |
5269 |
xmpp.example.com |
The TTL (time-to-live) value informs the other server how long to cache the DNS entry. ”muc” is a configurable service name for the conference service. xmpp.example.com is either the fully qualified domain name or IP address of the XMPP server.
To verify that the SRV record is added correctly in DNS entries, run the following nslookup command:
nslookup -type=srv _xmpp-server._tcp.example.com
If you are using SIP/SIMPLE Federation Gateway Services, then the SIP Gateway must publish _xmpp-server DNS SRV records for the SIP federated domains.
Table 16-3 lists the DNS SRV record required for the SIP Gateway.
Table 16-3 DNS SRV Record for SIP Gateway
| service._proto.name | TTL | Class | Type | Priority | Weight | Port | Target |
|---|---|---|---|---|---|---|---|
|
xmpp-server._tcp.example.com |
86400 |
IN |
SRV |
5 |
0 |
5269 |
sfs.example.com |
sfs.example.com is either the fully qualified domain name or the IP address of the Oracle Communications Converged Application Server.
Note:
The Instant Messaging Server SIP Gateway supports XMPP federation with single XMPP and SIP domains.If you are using SIP/SIMPLE Federation Gateway Services, then the SIP Gateway must discover SIP domains for Instant Messaging and presence federation.
Table 16-4 lists the DNS SRV records required for Oracle Communications Converged Application Server to discover the SIP/SIMPLE server.
Table 16-4 DNS SRV Records for SIP/SIMPLE Server
| service._proto.name | TTL | Class | Type | Priority | Weight | Port | Target |
|---|---|---|---|---|---|---|---|
|
_ sip._udp.example.com |
86400 |
IN |
SRV |
5 |
0 |
5060 |
sip.example.com |
|
_ sips._udp.example.com |
86400 |
IN |
SRV |
5 |
0 |
5061 |
sip.example.com |
|
_ sips._tcp.example.com |
86400 |
IN |
SRV |
5 |
0 |
5060 |
sip.example.com |
|
_ sips._tcps.example.com |
86400 |
IN |
SRV |
5 |
0 |
5061 |
sip.example.com |
sip.example.com is either the fully qualified domain name or the IP address of the SIP/SIMPLE server.
To verify that the SRV record is added correctly in DNS entries, run the following nslookup command:
nslookup -type=srv _sip._udp.example.com