How Do You Implement Presence with SIP?

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.


Via: SIP/2.0/UDP;branch=z9hG4bK652hsge

To: <sip:>

From: <sip:>;tag=1234wxyz



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”


<tuple id=”efeef223″>








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

NOTE: click image to enlarge


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.

* * *

This article originally appeared on SIP Adventures and is reprinted with permission.


Related Articles:

How to Realize Huge Cost Savings for Enterprise Telecom

This case study shares the steps taken by Avaya to reduce a sizeable telecom bill by 50%. The methods are trending tactics used by a wide range of organizations, and in combination have proven to produce especially favorable results. Keeping in mind that most IT operation budgets are flat, cost savings of this size can give your organization a greater opportunity to invest in innovation.

When every penny counts, internal telecommunication expenses must be closely accounted for. It’s a large expense and pain point for many organizations, and adopting change in this area is often associated with fear and uncertainty.

In reality, these fears disappear with a pinch of planning and excellent execution. Prioritizing telecom costs as a business initiative, establishing expectations, and determining a reasonable timeframe are some of the leading difficulties in taking on a project of this magnitude. These steps can have a great impact on the overall success of the project.

  1. Hire an expert to properly analyze your costs.

    There are many nuances in telecom, so if your organization does not have an expert internally, then it would be worthwhile to hire a third-party consultant to analyze the cost. They can provide better financial estimates of the cost and savings to ensure adequate ROI.

  2. Centralize trunking.

    To make it simple, paying for fewer circuits reduces cost. At Avaya, we reduced our total internal global telecom costs by 50% and got a 40% overall reduction of IT operational spending by doing so. Pay close attention to the amount of money paid in relation to the locations and compare centralized trunking cost to your current expenses. There are also considerations based on regional laws—for example, telecom laws in India may prevent this practice altogether.

  3. Reduce local trunking.

    Gartner estimates that “network architects and procurement managers can leverage SIP trunking services to slash enterprise telecom expenses by up to 50%.” As we all know, telecom does not come cheap, so these are results that cannot be ignored. Since IT operating budgets are often flat, this method can be a valuable way to extract savings from existing expense.

Gartner further suggests that, “enterprises should leverage the competitive SIP trunking market as U.S. service providers are reducing rates to win new business and retire their legacy TDM networks.” Needless to say, if you have yet to board the SIP train, you should strongly consider doing so now.

Previously at Avaya, all locations had their own local trunking and now we are saving cost by routing calls through a central location. In fact, SIP trunk consolidation provided an average savings of ~40% per month over PSTN trunks. We did it by implementing Avaya Aura to connect sites between a WAN used for both voice and data.

The Benefits Speak for Themselves

Consider what your company could do with these savings. We chose to reinvest 20% of our savings towards innovation and new capabilities. Gaining support from your colleagues should be a bit easier with these proof points in your back pocket and a strategic plan of action.

Understanding SIP PRACK for Avaya Aura

As many of my readers know, every few months I teach a two and a half day class on “all things SIP.” My students are exposed to everything from “why SIP” to the nitty-gritty of SIP requests, responses and call flows. I even speak about some of the more esoteric topics such as To and From tags, the Replaces header, nonce values and TR-87.

Included in the esoteric list is the PRACK (Provisional Response Acknowledgement) method. PRACK wasn’t in the original SIP specification and was introduced later in RFC 3262. It came about after it was realized that some user agent servers need to know that a provisional response was received by a user agent client. Before PRACK, 1xx responses sent using UDP might get lost, and the sender would never know. PRACK adds a layer of reliability to an otherwise unreliable call flow.

I previously addressed PRACK in my article “Ducks Go Quack. SIP Goes PRACK.” Although I addressed most of the pertinent material, I was short on examples and real-life call flows. As I walked my most recent students through live calls on my company’s Avaya system, I happened to notice a few PRACKs and decided it was time to update my old article.

The following screenshots were gathered using the Avaya traceSM utility. I simply started traceSM on a live Aura system, let it run for a few minutes, and then stopped it after I noticed a few PRACK messages fly by. This was simply because I was unsure as to when Avaya uses PRACKs and when it does not.  In other words, “When in doubt, trace it out.”


Let’s start at the beginning. PRACK messages aren’t just sent out-of-the blue. The sender of an INVITE message must indicate that it is capable of sending PRACKS. It does that by including the header in the INVITE message:

Supported: 100Rel

This tells the recipient that, if requested, it will send PRACK messages for 1xx Responses.

The following shows an INVITE with such a header.


Now that the user agent server knows that PRACK messages are possible, it will include headers similar to the following in all 1xx Responses it wants to be PRACKed:

Require: 100Rel

Rseq: 1

The Requires header with a value of 100Rel tells the user agent client (the sender of the INVITE) that a PRACK is expected for this response. It’s important to know that the user agent server (the sender of the Response messages) has to request the PRACK. It’s not an automatic process and must be initiated with an Rseq header.

The value in Rseq is used by the user agent client when it creates a PRACK message. The user agent server is responsible for setting and incrementing this number.

The following 180 Ringing indicates that it expects a PRACK.


Upon receipt of this 180 Ringing, the user agent client must respond with a PRACK message. Of interest to this article is the Rack header. This header must contain the Rseq value sent in the previous 180 Ringing. Additionally, it will indicate the original INVITE session’s CSeq number. Look back at the INVITE in this call flow, and you will see a CSeq value of 1 (one). Therefore, the Rack will look as follows:

Rack: 1 1 INVITE


Next, the user agent server will send a 200 Ok for the PRACK. This tells the user agent client that the PRACK was received and processed.


For grins, I will now show you the 200 Ok for the original INVITE. Note that it does not have a Rseq header and 100Rel is not in the Requires header. Why not? That’s because this is not a provisional response. PRACKs are only sent for 1xx responses.


Mischief Managed

Before I close things out, I want to address the question I hinted at near the top of this article.  When does Avaya use PRACK?

While I honestly don’t know all the permutations, it appears that an INVITE from an Avaya endpoint will always indicate that it supports PRACK (Supported: 100Rel).  However, as you just learned, it’s the recipient of the INVITE that indicates if PRACK messages are required.

In the example above, the Avaya Modular Message voice mail server requests PRACK messages.  Additionally, PRACK is used when direct media is enabled.

There is a good chance that PRACK is used in other situations, but I am going to have to start up a few more traceSM sessions to learn where they show up.

That’s about all I really need to say about PRACK. I invite you to take a look at the RFC if you want to learn about any PRACK subtleties I might have missed, but for all practical purposes, I’ve said all that needs to be said. I hope you had as much fun today as I did. As is often the case, I learned something in the process of writing this article, and that’s always a good thing.

Understanding Avaya Aura SIP Registration

“Let’s start at the very beginning/a very good place to start/when you read you begin with A B C/when you sing you begin with Do Re Mi.”

I have always loved musicals, and Rogers and Hammerstein’s “The Sound of Music” is high on my list of favorites. Sure, it’s corny and far from historically accurate, but that doesn’t bother me in the least. I’m always willing to set aside any sense of reality for good singing, romance and adventure, and “The Sound of Music” has them all.

So … what does this have to do with unified communications? REGISTER, of course. Like Do Re Mi, you begin SIP with REGISTER.

This article is a continuation of the concepts I presented in A Close Look at Avaya Aura IMS Call Processing and An Even Closer Look at Avaya Aura IMS Call Processing, and I’d suggest you take a look at those before tackling this one.

Can you get SIP devices to communicate without REGISTER? Absolutely. In fact, when I teach my SIP class, the students put their SIP clients into point-to-point mode, which does not require REGISTER. This means that clients send SIP requests and responses directly to the other clients, not through a proxy. The clients can do everything all by themselves.

However, point-to-point without REGISTER has a serious downfall. The clients are required to know the IP addresses of all the other clients they wish to communicate with. While this is fine in a limited classroom environment, it becomes unwieldy after you grow beyond a handful of endpoints.

As an analogy, imagine having to know the IP address of everyone you wanted to send an email to. That’s the same problem you have if you don’t use REGISTER. It’s simply not practical.

The Tie that Binds

REGISTER associates a user’s identification, or Address of Record (AOR), with one or more locations. Note that I said locations. You are not limited to registering an AOR to a single device. Personally, I routinely register my AOR to a physical desk phone and multiple SIP soft-clients. Avaya Aura supports up to ten such registrations per user. That’s enough to make even the most device-crazy nerd happy.

You bind an AOR to an IP address with a Contact header.  For example, one of my soft clients might tell a SIP registrar that aprokop can be reached at with this Contact header.

Contact: Andrew Prokop <SIP:aprokop@>

Registrations are time-based and will eventually expire. This requires the client to periodically refresh a REGISTER with a new REGISTER. Actually, new isn’t the correct word to use for this. Subsequent REGISTER messages must contain the same Contact, To, From, call-ID and From Tag as the original registration. This allows the SIP registrar to know that it’s simply a refresh and not a new registration for the same AOR.

Note that CSeq will increment with each REGISTER sent.

Keeping Things Secure

I might tell my communications system that I am Andrew Prokop, but it would be foolish to trust me at face value. That’s why SIP allows a REGISTER to be challenged.

Before I go through a REGISTER challenge, allow me to define something known as a nonce.

Nonce stands for Number Once and is an arbitrary number used only once in a cryptographic communication. The recipient of a nonce will use it to encrypt his or her credentials. Number Once refers to the fact that encryption with this nonce can only be done one time. If someone were to sniff the LAN and obtain someone’s encrypted password, it won’t do them any good because it can only be used in a single transaction. It becomes stale and useless immediately after its first use.

A REGISTER flow is fairly simple and follows these steps:

  1. A user sends a REGISTER to the SIP registrar. For Avaya Aura, this is a Session Manager. The To and From headers contain the user’s AOR. The user specifies the number of seconds the registration should be valid in the Expires header. This value can be later raised or lowered by the registrar.
  2. The registrar returns a 401 Unauthorized response with a WWW-Authenticate header.  This header contains data that must be used to encrypt the user’s communications password. Specifically, it contains a nonce along with the name of the encryption algorithm that the client must use.
  3. The user sends a second REGISTER to the SIP registrar. This REGISTER contains an Authorization header. Within Authorization is the user’s encrypted password.
  4. If the correct password is received by the registrar, a 200 Ok response is sent to signify a successful registration. An Expires header may be present with a different value than what the user requested. This is the time the registration will be valid as determined by the registrar’s policies.

A registration is removed by sending a REGISTER with an Expires header value of 0 (zero).

In a picture, we have this.

Reg1Using the traceSM tool on an Avaya Aura Session Manager, I captured the following trace that shows a REGISTER, the challenge and a REGISTER with encrypted credentials.  Take a look at the headers, and you’ll see that they’re doing exactly what I said they would do.

Reg2 Reg3 Reg4


In the case of my daily work life, my various SIP devices will each send a REGISTER, be challenged and resend the REGISTER with the encrypted credentials. They periodically refresh their registrations to ensure that I am able to make and receive calls on all my devices until I am finished for the day.

Speaking of finished for the day, that’s about all I have to say about REGISTER. It’s not that complicated once you understand the basics. Just keep in mind that while registration isn’t absolutely mandatory, it enables a secure, scalable and easy to manage SIP solution.

… And these are a few of my favorite things!

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.