XMPP Module

The CommuniGate Pro XMPP Module implements the XMPP protocol functionality. It uses one TCP Listener for both client-server and server-server connections, distinguishing them not by the port number the remote side connects to, but by the XML data transferred.
By default, the XMPP Module TCP Listener uses the plain-text ports 5222 and 5269 and the secure (TLS) port 5223.

When a client-server connection is established, the XMPP module authenticates a user, and creates a session for the user Account. It then sends the Real-Time Signals on that Account behalf.

When a server-server connection is established, the XMPP module receives XMPP requests, converts them into internal Real-Time Signals, and submits them to the Real-Time component for processing and further delivery. It also receives the Signals directed to it by the Real-Time component and delivers them to remote XMPP systems.

The XMPP Module maintains a separate queue for each target and source domain, i.e. there are different queues for requests to the target.dom Domain coming from addresses in the source1.dom and source2.dom domains.
The XMPP module tries to open a new TCP/IP connection for each queue. If a connection is established, it sends all enqueued requests (as XMPP XML stanzas). When all enqueued requests are sent, the module keeps the connection open waiting for new requests to be sent to this queue. If the connection stays idle for the specified period of time, the XMPP module closes it.

The XMPP message requests are sent as MESSAGE Real-Time requests, the XMPP presence requests are sent as SUBSCRIBE and NOTIFY Real-Time requests (using the presence Event package), the XMPP iq requests are sent as INFO Real-Time requests.
The XMPP request data beyond the basic information is sent as the P-XMPP-Data field data.

Use the WebAdmin Interface to configure the XMPP module. Open the Real-Time pages page in the Settings realm, then open the XMPP pages.
Click the Receiving link to open the XMPP Server Settings.

Use the Log Level setting to specify what kind of information the XMPP module should put in the Server Log. Usually you should use the Major (message transfer reports) or Problems (message transfer and non-fatal errors) levels. But when you experience problems with the XMPP module, you may want to set the Log Level setting to Low-Level or All Info: in this case protocol-level or link-level details will be recorded in the System Log as well. When the problem is solved, set the Log Level setting to its regular value, otherwise your System Log files will grow in size very quickly.

The XMPP server records in the System Log are marked with the XMPPI tag.
If the remote party specifies that the connection is used for a client session (as opposed to server-to-server transfer), the System Log tag is changed to XMPPS.

System Log records for outgoing server-to-server XMPP connections are marked with the XMPPO tag.

When you specify a non-zero value for the Channels setting, the XMPP module creates a TCP listener, and the module starts to accept XMPP connections from client applications and remote servers.
The setting is used to limit the number of simultaneous connections the XMPP module can accept. If there are too many incoming connections open, the module will reject new connections, and client applications and remote servers should retry later.

By default, the XMPP module Listener accepts clear text connections on the TCP port 5222 ("client port") and 5269 ("server port") and secure TLS connections on the TCP port 5223 ("secure client port").
Follow the listener link to tune the XMPP Listener.

The XMPP module supports the starttls command; it allows client applications and remote servers to establish a connection in the clear text mode and then turn it into a secure connection.

The XMPP module supports all available SASL authentication methods. Additionally, the module supports the legacy Jabber authentication - plain text "password" and "digest".
To disable the "digest" Jabber authentication method, you need to disable the CRAM-MD5 method for the target Domain.

Use the WebAdmin Interface to configure the XMPP module. Open the Real-Time pages page in the Settings realm, then open the XMPP pages.
Click the Sending link to open the XMPP Client Settings.

Log Level

This is the same setting as seen on the XMPP Server Settings page.

Source IP Address

This option selects the default source network address for outgoing XMPP connections. You can allow the server OS to select the proper address or your can explicitly select one of the server IP addresses as the default source network address.

Use Domain IP Addresses

This option selects source network addresses for outgoing XMPP connections. If this option is selected, the XMPP Module will use the first Assigned IP Address of the sender's Domain, if the Domain Assigned IP Addresses can be used for outgoing connections.
If this option is not selected, or if the sender's Domain does not have any Assigned IP Address, the XMPP Module uses the default source network address.

Idle Timeout

Use this setting to specify how long the XMPP module should keep an outgoing connection open if it has no data to be sent to a remote server.

Secure (encrypted) Relaying

You can configure your CommuniGate Pro Server XMPP module to use secure (encrypted) connections when relaying IM and presence data to certain remote sites. This feature is especially useful if your company has several offices and the traffic between the offices is sent via the public Internet.

You should simply list the domain names that should receive IM/Presence information from your server via secure connections:

Send Encrypted (SSL/TLS)

to Domains: (high security)	office*.company.com,partnercompany.com,!badserver.org
	wherever possible (low security)

The specified names can contain a wildcard - the asterisk (*) symbol.

When the CommuniGate Pro XMPP module connects to a relay of one of the listed domains, it checks if that relay supports the starttls protocol command. Then the XMPP module uses this command to initiate a secure connection with that relay.

The CommuniGate Pro XMPP module checks the validity of the remote relay Certificate using the specified set of the Trusted Certificates.
The remote relay Certificate subject must contain the cn (Common Name) field that matches either the domain name of the remote site, or the name of this relay. This can often cause a problem, since the domain company.dom may have the SRV record xmpp.company.dom, but the computer with the xmpp.company.dom address has the "main" DNS name server.company.dom and its Certificate is issued to that name (its Certificate subject contains server.company.dom in the cn field).

To solve this problem, you should explicitly route all traffic to the company.dom domain via the server.company.dom relay, using the following Router record:

Note: this feature ensures that information sent from your server to the remote relay is transferred securely. To provide complete end-to-end security, you should verify that:

• users submit data to servers either using a private network, or using TLS/SSL connections over the public Internet;
• all XMPP/SIP servers and relays exchange messages either using a private network, or using TLS/SSL connections over the public Internet;
• users receive data either using a private network, or using TLS/SSL connections over the public Internet.

If the domain is listed in the Send Secure To Domains list, and the receiving server does not support the starttls command, or the remote server certificate cannot be validated, or the remote server certificate Subject does not match the domain or domain relay name, all Signals sent to that domain are rejected, ensuring that no data is sent via a potentially insecure link.

wherever possible

Select this option if you want the XMPP module to try to use SSL/TLS connections with all remote XMPP servers that support this feature. If the remote domain is not listed in the Send Secure To Domains list, but the remote server supports the starttls command, the XMPP module tries to establish a secure (SSL/TLS) connection with that server.
The module does not check the remote server Certificate validity or the Certificate Subject in this case. If the starttls command or secure connection negotiations fail, the server defaults back to plain-text communication and sends data via an unencrypted channel.
Some servers advertise starttls support, but fail to accept SSL/TLS connections. When this option is selected, it is impossible to send Signals to those servers. To solve this problem, inform the broken server administrator, and enter the server domain into the Send Secure To Domains list, prefixed with the exclamation point (!) symbol. The XMPP module will not try to use SSL/TLS connections with that server/domain.

The Monitors realm of the WebAdmin Interface allows Server Administrators to monitor the XMPP module activity.

Click the Real-time link in the Monitors realm to open the XMPP Monitoring page. This page has the same format as the IMAP Monitoring WebAdmin page.

The XMPP module implements the XEP-0077 extension (registration and password changes).

The Auto Signup option allows users to 'register' (to create Accounts for themselves).

If the Allow to Modify Password option is enabled, the users can modify their passwords themselves.

The XEP-0045 extension (Multi-User Chat) is implemented outside the XMPP module itself, using the CG/PL chatroom Named Task.

The Named Task is started automatically when the first user tries to access it. The Named Task receives all Instant Message and Presence requests sent to it from various clients (XMPP, XIMSS, other Tasks, etc.), and distributes these Signal requests to the room participants.

The XMPP module implements the XEP-0114 extension (Jabber Component Protocol). It allows "trusted components" to connect to the CommuniGate Pro XMPP module. Usually these "trusted components" are external servers acting as gateways to some other IM/Presence networks.

Use the WebAdmin Interface to open the Receiving page in of the XMPP Module Settings.

Component Password

Use this field to set a password ("shared secret") string. When "trusted components" connect to the XMPP module, they must present this password in order to establish a connection.

The "trusted components" specify the domain name they are serving. The XMPP Module accepts all Signal addresses routed to any domain specified by any "trusted component" and it relays these Signals to the "trusted component" via the extablished XMPP connection.
If, for example, a "trsuted component" has connected to the XMPP Module to serve the icq.company.dom domain, then all Signal requests directed to any address in the icq.company.dom domain is accepted with the XMPP module, and it delivers the Signal request to this "trusted component" (which is likely to be a gateway to the ICQ network).

The XMPP module allows you to specify additional XMPP entities (domains, JIDs, resources) that are returned when the 'item discovery' request is sent to the Server or to any of the Server Domains. These items are returned together with the list of all chatrooms and registered Components.

You may want to use this feature to add the commonly-used external Gateways and Chatrooms to the 'item discovery' lists retrieved with the XMPP and XIMSS clients.

Use the WebAdmin Interface to open the Receiving page in of the XMPP Module Settings.

Supplementary 'Discovery' Items

To add a new item, enter its name into the last, empty field and click the Update button.
To remove an item, delete its name, and click the Update button.