It goes without saying that SIP is a protocol. After all, it is Session Initiation Protocol. It’s a series of request methods, responses, headers, and documented call flows. You send an INVITE and expect to receive a 100 Trying, 180 Ringing, and eventually a 200 OK. That’s the way I was taught SIP and that is what most people assume they will see when they trace SIP calls.
However, SIP as a solution can be quite different. Yes, you will see an INVITE to make a call (most of the time), but you may also see one, two, three, or even more subsequent INVITE requests for that one call.
Case in point is an Avaya Aura system and how SIP messages are processed by Session Manager and Communication Manager. It’s not that Avaya is doing anything wrong. There is no huge diversion from SIP as a protocol. It’s just that SIP as a solution requires network elements to take an active role in how call processing occurs. The value that Avaya adds to SIP calls leads to something more complicated than INVITE – 100 Trying – 180 Ringing – 200 OK – ACK.
In my latest article for the Avaya Connected Blog, I present Part One of my deep dive into Avaya Aura call processing.