Presence server implementation | SIP Notify, publish and subscribe messages by andrew jprokop

 (Source : http://andrewjprokop.wordpress.com/ )

Are you familiar with busy lamps on telephones? For many years, they were the only way you could “see” the telephone status of a coworker.

For example, let’s say that Andrew is the administrative assistant to Debbie and as part of his job, Andrew needs to know when Debbie is on and off the phone. For that to happen, a busy lamp is configured on Andrew’s telephone. Now, when Debbie is on the phone, the busy lamp on Andrew’s telephone lights up. When Debbie is off the phone, the lamp goes dark.

Pretty simple, isn’t it?

However, despite the fact that Andrew knows when Debbie is on her desk phone, does he know when she is on her cell phone? He doesn’t. The busy lamp only informs Andrew of Debbie’s desk phone activity. It has no idea about Debbie’s other devices.

Does it tell Andrew the nature of Debbie’s call? Can he distinguish an important call from something that can be interrupted? Nope.

Also, what does the lamp being unlit say? Well, it tells Andrew that Debbie is off the phone. Does it tell him that Debbie is in the office? No. Does it tell him that Debbie is in the office, but busy working on huge proposal and doesn’t want to be disturbed? Again, no. It’s just a light that’s either on or off.

Clearly, a busy lamp is fairly limited in its usability in today’s hyper-connected world and something more informative is required.

Enter presence. Presence conveys on-the-phone and off-the-phone information like a busy lamp, but that’s just the beginning. Presence can also tell you that the user is out of the office, hasn’t touched his or her PC in so many minutes, doesn’t want to be disturbed, is in a meeting, is on a conference call, has left for lunch, is sick and working from home, etc.

In other words, presence is a busy lamp on steroids.

Presence and SIP

Full disclosure, SIP is not the most common way to implement presence. That distinction goes to XMPP. However, SIP is gaining fast on XMPP and more and more applications are replacing XMPP with SIP. Case in point, Google Hangouts has recently announced that it will soon be using SIP for presence and Instant Message.

For a deeper dive into XMPP vs. SIP, please refer to my article Some Pontification on XMPP and SIMPLE.

Before I go too much further, allow me to define a few of the terms used in presence.

Watcher. A watcher is a SIP entity interested in the presence status of another SIP entity. A watcher sends a SIP SUBSCRIBE message to express its desire to receive presence information.

Presentity. A presentity is the entity being watched. It sends a SIP PUBLISH message when its status changes.

Presence Server. A presence server acts as a broker between the watcher and the presentity. The presence server receives SUBSCRIBE messages from watchers and PUBLISH messages from presentities.   Upon receipt of a PUBLISH, the presence server will send SIP NOTIFY messages to all subscribed watchers.

Expressed in a simple picture, we have this:

The next thing we need is a way to convey presence information from the presentity to the watcher. Although this could be accomplished in a number of different ways, most SIP applications have standardized on XML. Specifically, the PUBLISH message from the presentity and the NOTIFY message to the watcher will contain something referred to as Presence Information Data Format (PIDF).   PIDF will be represented in XML and labeled PIDF+XML within the NOTIFY and PUBLISH messages.

Over the years, I have seen the PIDF variants extended PIDF, xpidf+xml, and rich PIDF, rpidf+xml. These variants provide additional information about the presentity’s state.

As an example, here is a PUBLISH message that might be sent from a presentity when it goes on-line.

PUBLISH sip:Andrew@example.com SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

To: <sip: Andrew@example.com>

From: <sip: Andrew@example.com>;tag=1234wxyz

Call-ID: 81818181@pua.example.com

CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: 241

<?xml version=”1.0″ encoding=”UTF-8″?>

<presence xmlns=”urn:ietf:params:xml:ns:pidf”

entity=”pres: Andrew@example.com”>

<tuple id=”efeef223″>

<status>

<basic>open</basic>

</status>

<timestamp>2014-05-01T17:00:19Z</timestamp>

</tuple>

</presence>

Rather than trying to explain the PUBLISH message and PIDF+xml in great detail, allow me to point out a few of the most important aspects.

• The To and From headers are the same and always refer to the presentity. In this case, Andrew is advertising his presence status update.
• Content-Type is set to application/pidf+xml. This defines the format of the message body.
• The Event is presence.
• The status element contains the presence state. In this case, “open” maps to on-line. A status of “closed” would indicate off-line. A status of “inuse” would indicate on-line and busy.
• The presentity is Andrew. You will see that in the PUBLISH message and the XML message body.

On-line and off-line are certainly important to know, but the goal of presence is not to simply mimic a busy lamp. That’s where additional XML elements come into play.

For instance, an activities element further defines status.  A status of “inuse” and an activities of “on-the-phone” indicates that the user is active on a telephone call.

A note element might tell the watcher that the presentity is in a meeting until 1:00.

There is even a mood element that conveys information such as afraid, amazed, and disgusted.

It’s also possible to pass location information in a presence update. Knowing that someone is available at work on Monday or available at home on the weekend might elicit different behavior on the part of those who wish to contact the presentity.

There are endless possibilities of how presence might be refined.

Finally, presence can be aggregated. This allows the presence from your desk phone, mobile client, calendar, and other sources to be merged together to create a single presence status for a user.

Real-Life Example

To prove that I am not making this up, let’s take a look at a real-life example.  My company uses Avaya Aura for our communications and I have a 9641 SIP telephone on my desk.  I started traceSM (the Session Manager trace utility) and placed, answered, and released a call to my phone.  The following PUBLISH message was sent when I released the call.

Note the Content-Type of application/pidf+xml and the various XML elements that convey presence:

• status
• activities
• phonestate

Lit, Unlit, and Beyond

I hope this helps. I haven’t shown you all the possible element that might be sent in a presence update, but it’s not hard to imagine what they might be. The point is that a textual representation allows you to define presence to your heart’s content. Gone are the days of the two-state busy lamp. We are so much more than either lit or unlit.