Last week, I walked you through how Avaya implements IMS processing between Session Manager and Communication Manager. Even though it may have looked fairly complicated and slightly convoluted, I actually did you a favor by greatly simplifying the call flow. The complete call flow is even worse.
I also did myself a favor by presenting an abbreviated call flow. There were parts that baffled even me. So, I took it as a personal challenge to figure out the confusing parts as best as I could and put them into writing. Therefore, this latest article…
If you missed my previous article, it can be found at A traceSM view of Avaya Aura IMS Processing.
Allow me to begin by saying that nothing I wrote in my first article is incorrect. All that jazz about imsorig, origdone, imsterm, and termdone is accurate. However, in terms of an outbound call from a SIP telephone, I started in the middle of the flow. There are quite a few messages that fly around the system before the actual IMS processing begins.
In the Beginning
Everything begins when an Avaya telephone informs Communication Manager that it has gone off-hook. In Avaya documentation, they refer to this as “Line Reservation.” Exactly what Communication Manager does at the time of Line Reservation is a mystery to me, but I assume that it sets aside resources required for call processing.
The telephone uses an INVITE message to kick everything off. However, this isn’t a typical INVITE. The To and the From headers both refer to the caller. This is understandable because the user hasn’t started entering any dialing information.
There also isn’t any SDP in the INVITE. That’s because dial tone will be generated locally by the phone. No media stream is required.
Lastly, the telephone tells Communication Manager that this is an off-hook event by putting the following in the To header.
avaya-cm-fnu=off-hook
I captured one of these INVITE messages with traceSM.
Upon receiving an off-hook INVITE, Communication Manager responds with a 183 Session In Progress. Now, I am used to 183 being used to deliver some form of early media, but there is no SDP in this response message. I can only assume that it is used to tell the telephone that the INVITE was received and it’s safe to start playing dial tone.
Next, Communication Manager tells Session Manager that the phone is off-hook. This, of course, is done with a PUBLISH message. Since the telephone subscribed to Dialog events during its boot cycle, Session Manager will then send a NOTIFY message to the phone. I am going to take a guess and say that the NOTIFY causes the phone to indicate an active line appearance.
There are no more SIP messages until the user has finished entering the complete dial string. Since the telephone is aware of the configured dial pattern (through Personal Profile Manager), it will wait until all digits have been entered before sending a new INVITE.
I have to admit to something. Since the dawn of time, I have always thought that an UPDATE was sent prior to a session being established and a re-INVITE was sent after the session was established. However, this new INVITE from the telephone is clearly a re-INVITE even though the off-hook session has not been established. I say this because the call-ID and From tag are identical between the two INVITE messages. This screams re-INVITE.
There are differences between the two INVITE messages, though. The To header now contains the dialed digits and the message body contains SDP. This INVITE looks like the kind of INVITE you would have expected in the first place. This INVITE can actually be used to make a call.
From here on out the call flow will look like the one I described in my previous blog. There is still something that needs to occur, though. The off-hook INVITE is out there and needs to be attended to.
To close out the first session, Communication Manager will send a 484 Address Incomplete response. This will cause the telephone to respond with an ACK.
Here now is the entire call flow. Note that I did not discuss the 407 Proxy Authentication Required response messages. For now you can ignore them, but be assured that I will return to that subject in the very near future.
As you look at the flow, there is one more thing I want you to notice. Session Manager sends both INVITE messages to Communication Manager as part of the imsorig processing, but only the re-INVITE will go through the origdone phase. That makes sense, though, because the first INVITE received a 484 response. There is no point in sending it back to Session Manager for further processing.
Mischief Managed
Well, there you have — an even more complicated Avaya call flow than the last time around. I hope this helps you understand what I was saying in my previous article about the differences between SIP as a protocol and SIP as a solution. Clearly, what Avaya is doing with SIP is far more involved than what you will find in a generic text book. Of course, a full blown PBX requires a little more than your run-of-the-mill call flows.
Tao, Zen, and Tomorrow 
Very useful traces and explanations, Andrew – thanks!
One small comment regarding re-INVITE: Based on RFC 3261, it appears to me that this INVITE (off6.jpg) is a new, initial INVITE rather than a re-INVITE. From section 14, “An INVITE request sent within an existing dialog is known as a re-INVITE”. And section 4 defines a dialog as including a to-tag: “The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.”
As you noted, the original INVITE had never been answered with a 2xx or 101-199 response, which would have established a dialog. Since there is no To tag in the second INVITE, I think it would count as a new initial INVITE rather than a re-INVITE.
According to RFC 3311, “The UPDATE method … can be sent by a UA within a dialog (early or confirmed) to update session parameters without impacting the dialog state itself.” But then later “Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead.”
So it sounds to me like your long-held view of UPDATE is still valid 🙂