...applied technology

  • Increase font size
  • Default font size
  • Decrease font size
Home SIP Practicalities Presence Basics
E-mail Print PDF

SIP Presence Basics

What is presence? Many think of 'available' / 'not available' indications only.  In fact presence can do much more. It is visioned that presence will convey mood, what exactly a person is doing, e.g. out for lunch, readiness for discussions, if tired and more such things. Even calender entries could be used for presence information. Many extensions exist to the original RFC, but only a fraction is used widely.

Terms and Basic Procedures

As a user, I want to get informed about my communication peer's status. Are they technically available? Are they free to talk?
My device (UA=User Agent) getting and displaying this status is called a "WATCHER".

To get presence information about selected peers, I need to subscribe by sending a SIP SUBSCRIBE message to the presence server. The presence server takes care of regularly updating my UA by sending the presence information in NOTIFY messages.

The peer being "watched" is called "PRESENTITY" and sends his presence information in PUBLISH messages to the presence server.

E.g.: PRESENTITY -> presence server -> WATCHER

The PRESENTITY sends PUBLISH to the presence server,
the WATCHER sends SUBSCRIBE to the presence server and get NOTIFY messages back.

A simple example

The presence information in PUBLISH and NOTIFY is sent in the SIP message's body in XML format. A simple presence information can look like this (body only):

<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="">
<tuple id="Grandstream">
<contact priority="0.5"></contact>

This is being sent from the Grandstream GXP2020 desktop phone in a PUBLISH message after SIP registration to signal availability. If the DND (Do Not Disturb) button is pressed, a new PUBLISH message is sent with the basic status 'closed'.

The GXP2020 can also be a WATCHER. As the display has limited space and capability, some LED buttons can be assigned WATCHER functions to watch a limited number of SIP peers. If the basic status of a subscribed peer is received on a GXP2020 in a NOTIFY message, the LED would light green in case of 'open' and red in case of 'closed' status.

A closer look at NOTIFY

Below you can see a complete NOTIFY message (without IP and transport headers) with SIP headers and a somewhat more complex XML body. The source is different to the example above, it is the Nokia Siemens Softclient "NCS". The priority for the contact is missing, but otherwise the presence information is much richer.

NOTIFY;transport=tcp SIP/2.0                           <= Addressee for this message, e.g. the WATCHER
Via: SIP/2.0/TCP;branch=z9hG4bKpd03ae3068n1drs252k0.1         <= Traversed over this proxy
To: "Stefan Polakowski" <>;tag=ed36ec8992b3f82a          <= Original addressee, often same as in line 1
From: <>;tag=SDfpr2399-10.25812.1277953991.19503748      <= Origin, e.g. PRESENTITY
CSeq: 1 NOTIFY                                                                                                                                  <= Command Sequence: Request numbering within a dialog
Call-ID: 11449270cac93f47@                                                                                <= globally unique id for this dialog
Content-Length: 1600                                                                                                                         <= Byte count of message body
User-Agent: OpenSIPS (1.4.2-notls (i386/linux))                                                                           <= Client originating the request
Max-Forwards: 11                                                                                                                                <= Limits number of proxies. Decremented on each hop.
Event: presence                                                                                                                                   <= This NOTIFY is used for presence
Contact: <;transport=tcp>                                           <= Route to originator
Subscription-State: active;expires=3600
Content-Type: application/pidf+xml

<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pdm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:ietf:params:xml:ns:pidf:oma-pres" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" entity="">
<tuple id="T_1">
<op:description>This is the NCS Message service</op:description>
<tuple id="s1">
<op:description>This is the NCS voice service</op:description>
<pdm:person id="P_1">
<pdm:note xml:lang="en">Call me!</pdm:note>
There are a couple of different specifications for the presence information format.

The XMLNS, or XML Name Space, tells us that parameters inside <presence> element are according to the PIDF (Presence Information Data Format) format. It is defined in RFC 3863.

The entity parameter inside the <presence> element contains the presentity's url, e.g. who has published this information.

Tuples are used to segment presence information according to device or different applications on the same device. The id parameter inside the <tuple> element is an arbitrary string to identify different tuples of the same presentity within the <presence> element.

The <status> element is mandatory. The <contact> element is optional, but should be present, if the basic status is present.
The <basic> element of the of the <status> is optional, but there must be at least one child element inside status. Therefore the above PIDF presence can be seen as the minimum composition.

The basic status can take the values 'open' or 'closed'. It indicates, e.g. if the contact is able to receive instant messages or is available for other communication means, depending on the tuple context.

The contact element indicates the address under which the presentity can be contacted. It has an optional priority parameter for the address. Priority value range is 0..1 with up to 3 digits after the the decimal. '1' is the highest priority, no priority parameter deafults to the lowest priority, e.g. '0'.

Other optional elements:

  • <note> child of presence, human readable content
  • <timestamp> date and time of tuple

Specifications overview

RFC 3863's PIDF can be seen as the baseline for presence. Several extensions followed.

RFC 4479 introduced A Data Model For Presence.
Introduces the concept of SERVICE, DEVICE and PERSON.

RFC 4480 brings Rich Presence Extensions to the PIDF.
It introduces e.g. a <mood> element, <activities> and many more elements.

The Open Mobile Alliance (OMA) specifies which IETF components how to be used for presence under the 3GPP framework.