CommuniGate Pro
Version 5.4
Real-Time
 
 
IM & Presence

Instant Messaging and Presence

The CommuniGate Pro Real-Time component can receive, send, and relay Instant Message requests. These requests usually contain small text strings, but they also can contain service information (such as "using is typing a message"), and/or some non-text data.

The CommuniGate Pro Real-Time component maintains and distributes the "presence" information, and exchange the presence updates with external systems.

Roster

Each CommuniGate Pro Account has a Roster - a set of "Buddies" - username@domainname addresses with the associated status information.

When the Account user adds a Buddy to the Roster (using any XIMSS, XMPP, or SIP client, or the WebUser Interface), a Signal request is sent to the Buddy address. If the receiver confirms this request "to become friends", then the Buddy status in the Roster status information becomes "confirmed", and both sides can see the Presence status of each other.

Roster Buddies can be assigned to one or several Roster Groups, and client applications usually show Roster Buddies sorted by Groups.

Presence

Each CommuniGate Pro Account can have zero, one, or several client application connected to it using SIP, XMPP, XIMSS or other real-time protocols. Each client can specify its "presence state" - such as "online", "away", "busy", etc.

The CommuniGate Pro Server "aggregates" all reported "presence states" to compose the presence state of the Account itself. For example, if at least one client application reports the "busy" state, the Account state is set to "busy", otherwise if there is at least one client application reporting the "online" state, the Account state is set to "online", etc. If there is no client application connected to (or registered with) the Account - the Account state is set to "offline".

When presence information is distributed, the CommuniGate Pro server adds the "hash" of the Account avatar (read from the Account File Storage), so avatar changes can be detected by other users.

Instant Messages

When an Instant Message request is delivered to a CommuniGate Pro Account, it is processed as any other Signal Request - Signal Automated Rules are applied, the request is forked to all active XIMSS and XMPP sessions, and, optionally, to registered SIP devices.

Incoming and outgoing IMs are stored in the Account File Storage.

If an IM cannot be delivered because there is no session or device to relay it to, the message is appended to a special file in the Account File Storage.
When the Account user launches an XMPP or XIMSS client application, all stored IMs from that file are delivered to the user via that client application, and the file is removed.

Incoming IMs can be rejected without processing if the IM sender is not a confirmed Buddy in the Account Roster. See the Preferences section below.

Preferences

The Account user can control Instant Message processing using the following Preferences:
Instant Messaging Accepted Senders besides Buddies
IM Offline Storage
Accepted Senders besides Buddies
This setting controls incoming IMs from addresses not included into the Account Roster. The following values are supported:
  • everybody
    • - all Instant Messages are accepted
  • authenticated
    • - Instant Messages from the same CommuniGate Pro system Accounts are accepted.
  • same domain
    • - Instant Messages from Accounts in the same CommuniGate Pro Domain are accepted.
  • nobody
    • - Instant Messages are rejected
IM Offline Storage
If this option is enabled, and there is no active XMPP or XIMSS session, nor any SIP device registered (if IM delivery to SIP devices is enabled), then the "no address found" error is not returned to the sender. Instead, the IM is stored in the File Storage file, and the positive response is returned to the IM sender.
CommuniGate® Pro Guide. Copyright © 1998-2012, Stalker Software, Inc.