A Deep Dive into SIP Subscriptions

When asked about SIP, most people will tell you that it’s used to make telephone calls over an IP network. While that is certainly a true statement, it’s far too limiting. Ask me about SIP and I may mention telephone calls, but I will also tell you about media that has nothing to do with human speech.

When I called myself a programmer (sadly, these days I mostly talk about writing code), I wrote SIP applications that did things that had nothing to do with voice. For instance, my coworker, Mike, and I developed a desktop client that used SIP to send files, copy clipboard data from one PC to another PC, implement a shared whiteboard, and even play chess. Yes, there is nothing in SIP that prohibits a media stream of chess pieces.

Besides creating real-time media sessions, SIP is also a platform for creating distributed IP services. This is what makes it more than just a replacement for older protocols such as H.323. This makes SIP a true communications platform.

I addressed SIP services at a fairly high level in my article SIP Subscribe, Notify, and Publish. This time around, I want to take you a little deeper into the protocol aspects. Specifically, I want to expose you to the details of the SUBSCRIBE request and the concept of creating a SIP subscription.

Without repeating too much of my previous article, SUBSCRIBE binds a listener to a service. The reasons why you would create these associations are nearly infinite. Common binds include a SIP telephone subscribing to its voice mail state and a user subscribing to presence. In all cases, a subscription indicates that a SIP entity is interested in a particular event and wishes to be informed when something about that event changes. For example, when the user receives a new voice mail or one of his or her friends goes off-line.

The following is a SUBSCRIBE that I captured using the Avaya traceSM utility.

There are a number of things worth pointing out in this particular SUBSCRIBE.

• The Event header conveys what is being subscribed to. In this case, a SIP telephone is subscribing to “presence.”
• How did I know this was a SIP telephone? The User-Agent header contains the value “Avaya one-X Deskphone.” I can even see that it is running firmware version 6.4.0.33.
• The Expires header is used to request how long (in seconds) the subscription is valid. Here, the user is requesting a presence subscription for “86400” seconds (24 hours).
• The To header is used to indicate who you are subscribing to. In this example, the To and From headers contain the same value. This indicates that the user is subscribing to his or her own presence.
• The Accept header informs the subscription server of the kinds of responses the user can handle. For this subscription, the user is willing to accept a number of different formats.

Prior to subscription expiration, a new SUBSCRIBE must be sent to refresh the existing one. This is accomplished by sending a SUBSCRIBE with the same To, From, and Call-ID headers as the previous one.  The new SUBSCRIBE must be sent before the time in Expires is reached.

The sender knows that the SUBSCRIBE was accepted when a positive final response is received. Avaya returns a 202 Accepted, but other vendors send a 200 Okay. Both are fine.

• Note that the CSeq in the 202 response is the same as the CSeq in the SUBSCRIBE.
• The value in the Expires header is not the same as the one sent in the SUBSCRIBE. A subscription server does not have to honor the requested number of seconds and in this case, the subscription will only last for 43200 seconds and not 86400 seconds.

Once the subscription is established, the subscription server will “prime the pump” by informing the listener of the current state of the subscribed event. This is accomplished with a NOTIFY message.

There are a few things you need to pay attention to.

• As with the SUBSCRIBE, the To and From headers contain the same value.
• The Event is “presence.”
• The Content-Type is “application/pidf+xml.” This is one of the types the listener was willing to accept. Pidf stands for Presence Information Document Format and is a recognized method of conveying presence status.
• The message body contains the XML-encoded presence information.

NOTIFY messages will be sent for further changes in the subscription. A subscription is cancelled by sending a SUBSCRIBE with an Expires header of 0 (zero) seconds.

Although I showed a client subscribing to its own presence, subscribing to another SIP entity is simple.   All that changes is the To header. It now contains the value of the entity the user wishes to subscribe to.

Mischief Managed

I hope this helped. It should be easy to envision all sorts of uses for SUBSCRIBE messages. In fact, an Avaya telephone routinely sends five different SUBSCRIBE messages. Other clients and other vendors will send more or less, but the flows will look nearly identical.

Tags: Avaya, Presence, SIP, SUBSCRIBE, Unified Communications