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.
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.
Lastly, you will see quite a few SUBSCRIBE messages sent by the iPhone client (IP address 188.8.131.52). 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:
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
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!