A Deep Dive into Logging Out a SIP Client

It’s said that all good things come to an end. At the same time, I’ve heard that there are no ends — just new beginnings. No matter how you see it, life is full of changes and very few things last forever. That’s certainly true in the world of communications. There is no lack of new technologies replacing or augmenting old ones.

Today, I would like to write about one form of ending. I want to walk you through the process of logging out of a SIP endpoint. Specifically, I want to show you the SIP messages generated when I log out of my Avaya One-X Communicator for iPhone.

To better understand this article, you may want to take a look at this one first.

The Steps Involved with Booting an Avaya SIP Telephone

To gather SIP messages for this article, I started the Avaya traceSBC tool, launched my Avaya SIP client for iPhone, let it log in, and then logged it out. To keep the amount of packets to a manageable number, I cleared the traceSBC buffer before logging out.

As you will see, there are some Avaya specific aspects to the log out process, but for the most part, it’s all standard SIP.

To get the ball rolling, here is a screenshot of most of the messages generated during log out. Notice that I said most of the messages. There are at least two screens of SIP messages that pass through traceSBC from the moment I click log out to the last transaction. They are mostly the same types of messages, though, and I will point out the important things that happen on page two and beyond.


I want you to notice a few things. First, there are a lot of messages. There isn’t just one SIP message that says, “So long. It’s been good to know you.”  This is a step-by-step process.

Next, Avaya’s security policies require that messages are challenged to guarantee that they are coming from authenticated sources. That’s why you see a SUBSCRIBE request followed by a 401 Unauthorized response. You then see the SUBSCRIBE resent with the user’s encrypted credentials.

To better understand the authentication process, please refer to Understanding SIP Authentication and Proving it with SIP Authentication.

Lastly, you will see quite a few SUBSCRIBE messages sent by the iPhone client (IP address  These are used to unsubscribe from a particular service. There is no UNSUBSCRIBE message, but the effect is achieved by using SUBSCRIBE and setting the Expires header to 0 (zero).

Let’s take a look at one of those SUBSCRIBE messages to understand what I am saying.


As I explained above, Expires contains a value of 0. This indicates that the subscription needs to be removed.

You will find the service that is being unsubscribed to in the Event header. Here, it is set to avaya-cm-feature-status. This is one of the many subscriptions that an Avaya SIP client creates when it logs in. The full set of subscriptions is:

  • message-summary
  • avaya-ccs-profile
  • avaya-cm-feature-status
  • reg
  • dialog

This is challenged with a 401 Unauthorized response message.


Take note of the WWW-authenticate header. Its data will be used to create a Proxy-Authorization header in the subsequent SUBSCRIBE.


This SUBSCRIBE is identical to the previous one with the exception of the  Proxy-Authorization header and the user’s encrypted password.

This will be followed with SUBSCRIBE messages to cancel the remaining subscriptions (message-summary, avaya-ccs-profile, etc.).

The next message is a surprise to me. The Avaya SIP client uses INVITE to tell Communication Manager (CM) that the endpoint is no longer reachable. Why Session Manager doesn’t inform CM that the endpoint logged out is beyond me. One day I hope to find someone at Avaya who can tell me why they chose to use an INVITE for this step.


There are a few things about this INVITE that caught my eye.

There is no SDP. None is necessary since we are not launching a real call.

Also, take a look at the parameters in the To header. Specifically, avaya-cm-action=off appears to tell Communication Manager that this endpoint is waving bye-bye.

At this point, the endpoint has released its subscriptions and told Communication Manager that it is no longer active. Next, the SIP client needs to unregister. This is accomplished by sending a REGISTER message with the same call-ID as the one that registered the client in the first place. To indicate that this is an unregister operation, Expires is set to 0 (zero).


Now that the subscriptions are complete and the client has unregistered, we are left with one piece of unfinished business. The pseudo call created by the previous INVITE needs to be released. This, of course, is accomplished with a BYE message from the iPhone client to Communication Manager.


For reasons known only to Avaya, CM responds with a 481 Call Leg/Transaction does not exist. I can’t tell you why this happens, but at least the call has been released and the client has officially severed all ties with Session Manager and Communication Manager


Mischief Managed

Well, there you have it. I have missed writing these deep in the weeds articles and hope you appreciated this one. Now, I am off to the next fire that needs fighting.  Until the next time, keep on sipping!


  1. What should the response be to a BYE sent to an INVITE that has no SDP? Isn’t the 481 a proper response to that?

    1. I would be happy with a 200 OK since there is a dialog regardless of whether or not there is a media path. At least that’s the way I see it.

  2. I can see that in the context of this process that a 200 OK would be fine. But how is the CM supposed to know that this is the context and not some malformed request? I suppose it could check the user agent and send a 200/481 based on that. I am working on the assumption that 481 isn’t wrong, just not what you expected.

    1. It knows that’s not a malformed request because it’s not. Everything is fine. The BYE also includes the “avaya-cm-action=off” from the INVITE so it should know what is going on.

      The CM already deals with INVITE messages without SDP. They occur every time you take an Avaya SIP phone off-hook.

      I still say that 200 OK is an appropriate response.

  3. Thanks for the quick responses and helping me understand what is going on!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: