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.

reinvite1

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.

reinvite2

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.

reinvite3

reinvite4

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.

reinvite5

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.

Advertisements

116 comments

  1. When we put the call on hold why does the RTP ip resets to 0.0.0.0 and when again we put the call on hold the RTP ip becomes the same.
    I’m very new to SIP please help me out to find the solutions of my queries.
    Thanks.!

    1. 0.0.0.0 indicates no media.

  2. Reinvite also sent from the UAC ,why the tag is added in To -header

  3. Rizwan Khan · · Reply

    In an inbound fax call to an analog fax machine, after an RTP session is established a re-invite is sent from CM to SM with M attribute as image and the same has been sent to Avaya SBCE. But SBCE is stripping of M attribute from SDP when forwarding the re-invite to carrier thus carrier tears down the session with stating as bad request with reason ‘information missing for M header’. How to fix this?

    1. Have you enabled T.38 on the Interworking Profile page?

  4. Mukhtar · · Reply

    Very good explanation Andrew , i have understood many things from here also share to friends.
    I want to know more in deep, please share more knowledge on VOIP/SIP
    Thanks

  5. Interesting, thanks Andrew.
    Is the re-INVITE/OK/ACK considered as a transaction in the initial dialog or a new dialog?
    Thanks.

    1. A re-invite is part of the same dialog as the original invite.

  6. Its an in-dialog request (dialog is in established state) and both parties have already shared their tags.

  7. Hi Andrew,
    If a session is setup between A & B with call flow,
    A -INV-> B
    A B
    Can B send re-INV after this confirmed dialog?

    br
    Amit

  8. What if the user is upgrading the call from Audio to video. Would that evoke SIP Re-Invite or SIP Update

    1. RE-INVITE will be used.

  9. If I have established call with 2 m= lines:
    m=video 1000
    m=video 1001

    1. Is it possible re-INVITE as
    m=audio 2000
    m=audio 0

    2. or I must firstly delete ‘video’ streams
    re-INVITE
    m=video 0
    m=video 0

    then
    re-INVITE
    m=audio 2000
    m=audio 2001

    3. or if I want only one re-INVITE:
    re-INVITE
    m=video 0
    m=video 0
    m=audio 2000
    m=audio 2001
    ?

    I know RFC3264 8.3.3 Changing Media Types and my choice number 1. But here I change media type and delete stream (port set 0) at the same time. Should I keep the media type if I want to delete a stream?

    What is more correct here? Different people interpret RFC3264 differently. My interpret: we can change absolutely everything, but not reduce the number ‘m =’.

    1. I believe that most UAs would respond best to #2. That’s not to say that #1 and #3 aren’t right. It’s just that they may not be widely supported.

Leave a Reply to Jeevan Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: