Understanding SIP Re-INVITE

For the most part, SIP isn’t all that complicated. The messages are fairly easy to understand and the call flows are straightforward enough.   In previous articles, I have shown how vendors like Avaya have implemented SIP solutions that make it more difficult to follow some call flows, but even they become manageable once you understand the basic piece parts and architectures.

Still, there are aspects that can be a bit confusing. This is even true for someone like me who has worked with SIP since the late 1990s. I continue to have my own ah-ha moments as I wade through Wireshark traces or read RFCs.

One thing that often confuses people new to SIP is the concept of re-INVITE. I’ve encountered that confusion in my SIP class and from emails and comments from my blog readers. They sort-of, kind-of get it, but are still unsure as to what they actually get.

To help alleviate any questions and doubts, I decided that a couple pages of explanation and traceSM screen shots would be worthwhile.

Let’s Get Started

You need to know that re-INVITE is not a new message. A re-INVITE looks just like any other INVITE. In fact, if you saw a re-INVITE out of the context of its call flow, you might not be able to tell it from an INVITE used to create a new session.  You will see most of the same headers and a similar message body.  The one exception is that you will see a tag on the To header.  This clues you in that something is different.

---

If you aren’t familiar with SIP tags, please see Let’s Play (SIP) Tag.

---

A Re-INVITE, it comes after a session has been established. This means that it will apply to an existing INVITE after a final response has been received and an ACK has been sent.

You send an UPDATE message prior to session establishment, but that’s an article for another day.

A re-INVITE will have the same Call-ID and From tag as the INVITE it is modifying. It can change every other header as well as the message body, but those two things tell the SIP stack that this is not a new INVITE.

The most common use for re-INVITE is call hold. The party putting the call on hold sends a re-INVITE with SDP indicating that media will no longer be sent. That same party will take the call off hold by sending another re-INVITE with SDP indicating that media transmission will resume.

To demonstrate this, I placed a call to my desk telephone, answered it, started up the Avaya traceSM utility, put the call on hold, stopped traceSM, and then took a few screen shots of the resultant call flow.

Here is the complete flow from the point of me pressing hold.

At a high level, you should see the following:

1. From my desk phone, I put the call on hold. My phone sends a re-INVITE to Session Manager.
2. Session Manager challenges the re-INVITE with a 407 response.
3. My telephone resends the re-INVITE to Session Manger with the proper credentials.
4. Session Manager sends the re-INVITE to Communication Manager.
5. Communication Manager sends a PUBLISH to Session Manager indicating that the call is on hold.
6. Communication sends the re-INVITE back to Session Manager.
7. Session Manager sends a NOTIFY to the telephone indicating that the call is on hold.
8. Session Manager sends the re-INVITE to the other party in the call.
9. The other party answers the re-INVITE with a 200 OK.

From the standpoint of this article, the re-INVITE at step 3 is the most important message in the flow.

I want you to notice a few things.

• Although I didn’t show you the INVITE that created the call, trust me when I say that it has the same Call-ID and From tag as the re-INVITE.  We are not creating a new call.  We are simply modifying an existing one.
• If this were an INVITE for a new session, there would be no To tag.  The presence of a To tag tells you this is a re-INVITE.
• An Avaya SIP telephone adds a Reason header that states this call is going on hold. This is not part of the SIP specification and is not required for hold. An Avaya system may use this for something, but it has no bearing on whether the call is going on hold or not.
• The SDP in this INVITE looks pretty typical with one exception. Note the line that says a=sendonly. If you were to look at the original INVITE, this single attribute line would be the only difference. It’s a big difference, though. This stops the flow of media between the telephones. This attribute is the most important part of the re-INVITE.
• I have also seen hold accomplished by setting the SDP connection line to a null IP address — c=0.0.0.0.  However, the above attribute approach is the correct way to indicate hold.  The null IP address approach should be avoided.

For grins, let’s take a look at the PUBLISH and NOTIFY messages used to inform the telephone that the call is on hold. Like the Reason header above, this is not necessary for the hold operation itself. Instead, it can be used for lamp state or aggregated presence.

The last thing I want you to look at is the re-INVITE that is sent to the other party.  It will look a whole lot like the original re-INVITE, but I included it for the sake of completeness.

That’s All Folks

I hope you found this helpful. While there are other use cases for re-INVITE, hold is the most common.   Different SIP telephones and call servers might have unique variations, but the basics will always be the same.

Tags: Avaya, SIP, VoIP