White Paper

Real-Time Person-To-Person Presence Subscription/Notification
Using
Session Initiation Protocol and Its Extensions

1. Introduction

Presence in a network is defined as the ability and willingness of a user to communicate with others. Using presence mechanism a user can publish his or her presence status to others who are interested in the presence information of the user. On the basis of the presence information of a user i.e. if the user is active, busy, away, unavailable etc, an array of services could be offered to the subscribers of the presence information. Instant Messaging, user presence status indication, making calls to idle terminals etc services are to name a few. On the basis of the presence information of the user, the user could be monitored, contacted, called or some message could be left in case of unavailability.

Session Initiation Protocol (SIP) has emerged and evolved as a standard Internet Protocol for Internet telephony or Voice Over IP (VoIP) because of its extensibility and flexibility. Enterprises in view of low operative cost and central management & maintenance are more and more using VoIP based solutions. SIP which is primarily build to transmit/ receive media (audio, video) among users in a session, has evolved to perform numerous functionalities other then media exchange. Now a days SIP is used to exchange presence information, Instant Messages, uses endpoints status(Busy, free, not available, etc) and much more.

SIP, which is used to maintain sessions i.e. create, modify and terminate session, has numerous extensions written as RFCs to describe how SIP could be used to implement various telephony features and other informative features. SIP (RFC 3261 [1]) describes the messages exchange and their flow to create a simple multimedia session, modify and terminate it. Along with SIP supporting RFCs the features like Calls Transfer, Conference, Music On Hold, Intercom, Call divert, etc. could be implemented in the SIP servers and endpoints. Apart from the telephony features the SIP extensions RFCs also describe the features for user presence notification and Instant Messaging as well.

2. Technology

As an extension of SIP, a standard has been written which defines a framework for subscription and notification capabilities to enable the SIP user agents to subscribe for some particular event and get notified when the event occurs (RFC 3265 [2]). Using this extensible framework IETF's SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) working group has defined the 'Presence Event Package'. This package describes the model, requirements, components and implementation rule set for SIP based user presence event notification. The package includes a set of related RFCs which describe the whole presence information subscription/ notification mechanism. Presence Information Data Format (PIDF - RFC 3863 [6]) document is used to provide the presence information and some other useful information of interest to the subscribers.

The two components in the Presence Event Package that comprise the presence functionality is Subscription and Notification for the Presence Event.

Subscription which is the first half of the functionality enables the user to request the presence information of other users in the network. Once subscribed the subscriber will get the presence status of the user whenever the status changes. The subscribers ask for the presence information from a central agency, named as presence server that contains the presence information of the entities on the network. This central agency is responsible to store presence information, accept subscriptions and inform the presence status changes to the parties who are interested in getting this information i.e. subscribers. Along with this the presence server has the capability to restrict the users and impose the accessibility policy on the presence information.

Once the subscription request is successfully responded by the server, the user could get the presence status information from the server. To notify the user the server sends a NOTIFY request which contains the presence information within. This process is called as Notification process and is the second half of the presence information functionality. The NOFITY message contains the body which along with the presence information contains other information that could be of interest. For e.g. location of the user, contact details, language, some custom message, email addresses, timestamp etc.

3. Functional Description

When a user registers with the SIP network, its presence is recorded by the element that is responsible for keeping and managing the presence information. The element in our case is Presence Server.
In the two steps of presence feature Subscription and Notification, the Presence Server is contacted for the presence information.

Subscription: This step allows the users to ask for the presence information of other users. In this step a SIP packet with SUSBCRIBE method is sent to the Presence Server. The packet is sent to get a presence information subscription to the party whose presence information is required by the user. This packet asks the presence server for a subscription for "presence" event. The presence event is the event that occurs as the presence status of the users change. So, whenever the presence status of a user changes the server will get to know about it and it will notify all the users who have subscribed for the presence event of the party whose presence status has just changed.

Since the Presence Information is a very critical knowledge, security issues arise on whether to allow subscription or not. The access policy decision is implemented as per the requirement and the nature of the application which uses the presence service. The policy could be implemented on the server and also the end point could also decide whether to allow the user to fetch the presence information of the end point or not.

Fig 3 a. An example SIP SUBSCRIBE request packet

Notification: Notification is the second step to the presence feature and it is used to provide the subscriber with the presence information to which the subscriber has subscribed for. The SIP method used to send notification is NOTIFY. This is sent from the server to the user agent as a SIP request. The body of the message contains the PIDF document which actually contains the presence information.

Same as subscription, sending presence notification also has security implications. One issue is whether the party to be notified is really authorized to get the presence status or not. Presence information being sensitive in nature could be exploited in many ways, so, when sending the notification it is necessary to confirm that the party to be notified is a legitimate party. The policies to provide the notifications and to deny them could be implemented on the server and the endpoints as well. This depends largely on what is the use of the information and what application is built upon the information. The policies could depend on the hierarchy of the working positions in an organization, the working group, work nature of the person receiving the information etc.

Fig 3 a. An example SIP NOTIFY request packet

PIDF Document: The presence information is sent in the NOTIFY message across the network, but the part which really contains the information is the body of the packet. The body contains the PIDF (Presence Information Data Format) document which contains the presence information to exchange. PIDF document is an XML document which includes various parts constituting the presence information as a whole.

Some of the information contained in the document is:
a) Entity name
b) Entity Contact details and their priorities
c) Presence tuples containing the presence information
d) Language
e) Email addresses
f) Custom notes

This PIDF document could be parsed at the receiver's end and the information could be used to trigger some action on the basis of the information.

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="userB@sipserver.com">
     <tuple id="id1234">
       <status>
   <basic>open</basic>
       </status>
<contact priority="0.8">1234@grp1.sipserver.com
</contact>
  <note xml:lang="en">Don't Disturb Please!
</note>
  <note xml:lang="fr">Ne derangez pas, s'il
 vous plait</note>
     </tuple>
  <tuple id="idabcd">
       <status>
         <basic>open</basic>
       </status>
       <contact priority="1.0">
mailto:alice@sipmail.com</contact>
     </tuple>
     <note>I'll be offline for next week</note>
   </presence>

Fig 3 a. An example PIDF document

4. Q3 Technologies User Presence information knowledge solution

Leveraging the capability and flexibility SIP offers, Q3 Technologies, Inc. has developed the solution to integrate the SIP/SIMPLE based presence mechanism with the applications that use the presence status for their operations. Using this generic solution for presence in SIP based infrastructure, an array of applications could extent to support various presence based functionalities. The users of the applications could get the status of the parties even before they start communicating with them, resulting in lowering the number of failed attempts to connect and hence providing the ease of use. Various applications like chat clients, soft/hard phones, monitoring terminals etc could used the solution to provide their users the presence information of the parties they want to know. The presence information output could be used differently in different applications as per the need, such as in chat clients the name of the contact could become bold if he/she is online i.e. have an active presence status. A telephone could display the active users list in their LCD or glow some LED on the operator's terminal. The monitoring terminal could maintain a log of user's presence on their desks, terminals based upon the presence output.
The solution strictly based on the standards and is widely deployed in a variety of applications. The solution is well tested with leading SIP servers including the Open Source SIP servers for interoperability with positive results and seamless working.

5. References

[1] "Session Initiation Protocol", RFC 3261, June 2002
[2] "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002
[3] "A Model for Presence and Instant Messaging", RFC 2778, February 2000
[4] "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000
[5] "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, February 2000
[6] "Presence Information Data Format (PIDF)", RFC 3863, August 2004
[7] "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004