You can use the SIP Presence service to enable the buddy list features of SIP clients that implement the SIP/SIMPLE specification.

Clients can view the online status of their registered contacts ("buddies"), and update their own online status for other clients to see. Many SIP clients require users' buddy lists to work before they can send instant messages — so the Presence service also enables sending instant messages for many SIP clients.

To use the Presence service, you need at least two SIP clients. They may be either different clients on a single host, or multiple instances of the same client on different hosts. (The same SIP client on different hosts may mean fewer interoperability issues, because many SIP clients only implement selected parts of the SIP/SIMPLE specification, or include custom extensions to the specification.)

Below are instructions for setting up SIP clients to demonstrate the Presence service, a sample message flow and details of basic and rich Presence.

Setup

Setting up the SIP clients to demonstrate the Presence service is similar to setting up to demonstrate the Registrar service:

  1. Start Rhino and deploy the Presence service.

  2. Start the clients you want to use.

  3. Create new SIP user accounts, pointing to the IP address and port that Rhino is using to run the Presence service.

  4. If the SIP clients implement the SIP/SIMPLE specification, you should then be able to add contacts to the buddy list, and send instant messages between clients.

Note

Some example SIP clients that can be used to demonstrate the Presence service are:

Sample message flow

The Presence service accepts SIP SUBSCRIBE and PUBLISH requests, and sends NOTIFY requests when appropriate.

The client sending SIP SUBSCRIBE requests lets user agents subscribe to the Presence information of other users (adding them as contacts in the "buddy list"). The client sending PUBLISH requests lets user agents publish changes to their own Presence state.

The Presence service responds by providing Presence information through NOTIFY requests. The Presence service amalgamates the Presence information available to it for any given user, and composes the information into a single Presence state for that user. When this composed Presence state changes (either by the user publishing a change to their status, or by registering or de-registering with the Registrar), the Presence service notifies any users who have subscribed to that information. Thus, if user A registers user B as a contact, an example SIP message flow could resemble the one below:

                    Presence
User A              Service               User B
    |      SUBSCRIBE    |                    |
    |------------------>|                    |
    |       200 OK      |                    |
    |<------------------|                    |
    |       NOTIFY      |                    |
    |<------------------|                    |
    |       200 OK      |                    |
    |------------------>|                    |
    |                   |                    |
    |                   |       PUBLISH      |
    |                   |<-------------------|
    |                   |        200 OK      |
    |                   |------------------->|
    |                   |                    |
    |       NOTIFY      |                    |
    |<------------------|                    |
    |       200 OK      |                    |
    |------------------>|                    |

The Presence service responds to the user A’s initial SUBSCRIBE request with a NOTIFY containing the current Presence information of user B, and informs user A with a further NOTIFY request when user B’s Presence state changes.

Basic Presence

At the most basic level, Presence describes whether or not a client is online or offline. The Presence service determines the basic Presence state of users from any PUBLISH requests it has received from the user’s client, and through determining whether the user is registered as online with the Registrar.

Many SIP clients implement basic Presence. You can demonstrate this using two clients on a single host.

Note WengoPhone, Windows Messenger, Pidgin, and X-Lite are all SIP clients that implement basic Presence. Most of them will either use SIP/SIMPLE by default, or will have SIP/SIMPLE listed as a protocol that they support.

To demonstrate the use of basic Presence:

  1. Start Rhino and deploy the Presence service.

  2. Set up two (or more) clients to use the Rhino host running the Presence service (identified by the Rhino host’s IP address and port) as their SIP server. The clients may either be on different hosts, or all on the same host.

  3. Make sure that each client has a unique user account, and ensure that each one successfully registers with the Registrar.

  4. In each client, add the other client accounts as contacts in the buddy list. The online status of the other client accounts should automatically display in the buddy list as either online or offline as appropriate.

  5. Register or deregister one of the clients (log on or off). The online status of that client should change from online to offline (or vice versa) in the buddy lists of the other clients.

Once the buddy list feature of the clients is working, most clients will also allow instant messages. Note that there are exceptions (for example, Microsoft Messenger uses proprietary extensions to the messaging part of the protocol, and will not exchange instant messages).

Rich Presence

The SIP/SIMPLE protocol also lets clients share more detailed Presence information. The Presence service implements the Presence information data format set out in RFC3863, "application/pidf+xml", which lets them communicate an extra layer of information (above the basic states of online and offline — for example publishing states such as "On the phone").

Note
Use instances of the same client

The extra layer of Presence information has been left entirely open to implementations — there are no standard states (as is the case with basic Presence). Many clients do not implement this part of the protocol, and many add extensions to it. Because of these differences, using different clients to demonstrate extended Presence can therefore be difficult.

To demonstrate the use of extended Presence information with the Presence service, you can set up two instances of WengoPhone on separate hosts:

  1. Start Rhino and deploy the Presence service.

  2. Configure two instances of WengoPhone, each on separate hosts, to use the Rhino host running the Presence service as their SIP server.

  3. In each client, add the other account as a contact in the buddy list. The status of each account should automatically update, once it has been added into the buddy list.

  4. Set the status of one of the clients to "Away" or "Do Not Disturb", by clicking on the circular button to the left of the account’s user name, and selecting the option from the drop-down list. The new status of the account should display in the buddy list of the other client.

Once the client’s buddy lists work, they should be able to exchange instant messages.

Previous page Next page