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 "user 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.
Each CommuniGate Pro Account has a Roster - a set of "Buddies" -
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.
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.
When an Instant Message request is delivered to a CommuniGate Pro Account,
it is processed as any other Signal Request - Signal Automated Rules
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.
The Account user can control Instant Message processing using the following Preferences:
- 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.
- Always Receive to All Devices
- If this option is set to Yes, then incoming Instant Messages are always delivered to all active XMPP and XIMSS sessions and registered SIP clients with messaging capability (if delivery to SIP clients is enabled).
Otherwise, messages sent within conversation are delivered to the session or the device specified by the sender.
CommuniGate® Pro Guide. Copyright © 1998-2016, Stalker Software, Inc.