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.
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.
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.