CommuniGate Pro
Version 5.4

XMPP Module

The CommuniGate Pro XMPP Module implements the XMPP protocol via TCP/IP networks.

The XMPP module implements the client-server XMPP protocol. The module allows end-user applications (XMPP clients) to log into the CommuniGate Pro Server and to execute Real-Time Signal operations.

The XMPP module implements the server-server XMPP protocol. The module allows the remote XMPP systems (remote servers) to connect to the CommuniGate Pro Server, and it allows the CommuniGate Pro Server to connect to the remote XMPP systems, so they can exchange Real-Time Signal requests and responses.

The module implements the basic XMPP protocol and its extensions (XEPs).

Extensible Messaging and Presence Protocol (XMPP)

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.

XMPP Server Settings

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.

Log Level: Listener Channels:

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.

XMPP Client Settings

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: Idle Timeout:
Log Level
This is the same setting as seen on the XMPP Server Settings page.
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)
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, but the computer with the address has the "main" DNS name and its Certificate is issued to that name (its Certificate subject contains in the cn field).

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

NoRelay:company.dom =
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:

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.

Monitoring XMPP Activity

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.

Chat Rooms

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:
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 domain, then all Signal requests directed to any address in the 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).

Supplementary Discovery Items

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.

CommuniGate® Pro Guide. Copyright © 1998-2012, Stalker Software, Inc.