Version 5.4 |
||||||||||||||||||||||||||||||||||
|
|
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.
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.