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


  1. Thanks for the explanation. I also notices the SIP re-INVITE is used in Fax over IP networks; perhaps we can have a part II😀

    1. I just might. I am always looking for something to write about.

  2. Does this work the same way in Lync or Cisco as well?

    1. Antariksh Pandey · · Reply

      Yes it does. Perfectly. There are different scenarios for that as well. Also we can see these in call transfers.

  3. I’d love to see a blog on the UPDATE part. We have been seeing a few issues with call drops that when debugged show only INVITES being sent. Upon adjusting the SIP timers, we now see UPDATES but no RE-INVITES.

    1. Roland Jesske · · Reply

      UPDATE work in the same way as re-INVITE for session refresh.
      See RFC4028.
      UPDATE do not need to contain SDP and RFC4028 recommend that re-INVITE should contain the SDP even if the session do not change.

  4. lucas · · Reply

    thanks for clear explanation. One question for the first picture, can you please share what kind of log tool you used to get this picture?


    1. lucas · · Reply

      got it. traceSM. thanks.

  5. moto_modx · · Reply

    Very good explanation. Thank you.

    1. Thanks for reading!

  6. Carlos · · Reply

    What would happen if the re-invite does not contains any SDP? It will change the media attribute to sendrecv or it will ignore it and keep the previous media attribute.

    1. The session will keep the previous media descriptions(s).

  7. Carlos · · Reply

    Thank you very much.

  8. consider a same scenario in a secure environment ( implementing SRTP) .
    Will there be a new encryption key along with re invite (when you put the call on hold)

    1. Good question. My guess is that the answer is “yes,” but I have never really looked into it.

  9. Roland Jesske · · Reply

    Good summary.

    I’m missing the note that using is not recommended by RFC3264 since this is a leftover of backwardcompatibility to RFC2543. RFC3264 :”Its usage for putting a call on hold is no longer recommended, since it doesn’t allow for RTCP to be used with held streams, doesn’t work with IPv6, and breaks with connection oriented media.”

    An additional use of Re-INVITE is for session refresh regarding RFC4028.

    1. You are correct and I will note that in the text.

  10. sunhee · · Reply

    Can i ask something?
    Regarding SIP Timers, such as Timer A, B, …. these timers should be working on re-invite just same as initial invite?

  11. does a re-invite have to include a PAI if a PAI was present in the original invite?

    1. I expect that it should, but I can’t say for sure.

  12. does reinvite occurs when callee is unreachable and calls are forwarded to other numbers?

    1. No. That is typically done with redirection headers.

  13. Jean-Luc Larcheveque · · Reply

    HI, Thanks for all these explanations.
    One question, re-Invite message can inverse fields from and to according to who is sending the re-invite ? I saw this in my sip trunk. Normal or bug ?
    I can send you the capture in any case.


    1. Does it preserve the to and from tags?

  14. Afang Emmanuel · · Reply

    Appreciate your work Andrew.
    But please, help explain re-INVITE in this Callflow below:


    *REF* A —>> INVITE —>> B (SDP: Codec 8 18 108 102 116)
    0.012 A <<— 100 Trying <<— B
    0.108 A <<— 200 OK <> ACK —>> B
    0.124 A —>> INVITE —>> B (SDP: Codec 18 116) {The re-INVITE}
    0.134 A <<— 100 Trying <<— B
    0.135 A <<— 200 OK <> ACK —>> B
    30.27 A —>> BYE —>> B
    30.28 A <<— 200 OK <<— B

    Why the re-INVITE?
    There is no 180 Ringing (but there was a Ringback tone), is it at the stage of re-INVITE that Ringback is generated (i.e. does re-INVITE replace the 180 Ringing too)?
    What can be done to improve the Callflow?

  15. Very good explanation,
    One question on this, if there are multiple proxies between Server A and Server B then can Server A send re-INVITE to ask Server B to change rtp address and the proxy in between for signalling?

    1. I am a little confused. Are you asking to change the proxies and not the characteristics of the session (e.g. codec)?

  16. Thanks for your prompt reply Andrew
    My Server B is working as UAC and I want to change characteristics of sdp as well as signalling. i.e. now onwards send rtp to different ip and signalling to different proxy/ies then the one/s which were in initial INVITE

  17. Naveenraj C G · · Reply

    Thanks for the Explanation.

    Can we send Re-invite Without SDP and sending SDP in ACK for the re-invite ??

    1. I don’t see why not.

  18. Can an INVITE have “to” tag ?

    1. In a re-INVITE it will have a to tag, but not in the initial INVITE. You may want to read this. https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/

  19. Hi Andrew,

    Thank you for this.

    I read both https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/ and https://andrewjprokop.wordpress.com/2015/02/10/understanding-sip-re-invite/.

    Still I have a question.
    Let’s say that a sniffer registers 3 INVITE and 3 OK for the same Call-ID but in random order because of this evil network.
    The call concerns only 2 clients and the 2 additional INVITE/OK couples are created because of renegociations. If I understand well, all of these are part of the same “dialog”.
    So how can I associate one OK with the right INVITE ?

    My ultimate goal is to retreive all RTP media sessions by associating each caller ip:port (based on SDP c and m parameters) with the right called party ip:port.
    (There are 3 media sessions to retrieve in my example (not necesserly different).)

    I feel like there is no way to solve this without get all the “INVITE then OK” couples in the right order.

    1. You can only have one active session for a single INVITE. Two of those call legs must be cancelled.

      1. Thanks for your answer.
        But these sessions could have been consecutive, not simultaneous.
        Let me rephrase: How can I reorder multiple INVITE and OK (describing consecutive media sessions because of renegociations) SIP messages which are in random order?

  20. Anmol Prakash · · Reply

    Can I change the Media type also in the Re-Invite message ?? I mean after resuming the call from Hold, it will use different Media Type.

    1. As long as the other side agrees with that choice, yes, you can change it.

      1. Anmol Prakash · ·

        Thanks for your reply !

        For Media type, I need to change Media description field of SDP right ??

      2. It’s all done in the SDP.

  21. Juancho · · Reply

    Hi Andrew. I have a question related to an issue I’m facing.
    I’m implementing SIP trunks between an Aura (CM-SM-SBC) with a service provider. Calls are working OK but they’re being dropped after holding them. I saw that re-invite message sent by CM does not contain SDP and SBC responds with an 200OK withot SDP as well, then CM sends an ACK and BYE. I think this is the reason why call are being dropped. Any advice?

    1. While I can’t say for certain, the dropped call might have to do with no media being sent. Some SBCs treat this as an orphan call. You may need to set a configuration value to allow the call to stay up.

      1. Juancho · ·

        I think the call is being immediatly dropped by CM because no SDP is received in 200OK message. I’m actually looking for a way to add it at some point

  22. Richard Bray · · Reply

    Hi Juancho, did you find a fix for this.

    I am experiencing the same. We change re-INVITES to UPDATES for Lync (forwarding/voicemail 491 errors with re-INVITES, but work with UPDATES). However we receive re-INVITES from original PSTN call after 7 minutes and this then goes to Lync as an UPDATE, but Lync replies with a 200OK and no SDP (even though the changed UPDATE contains SDP).

    Our provider/PSTN then reply with an ACK and BYE as you explain above.

  23. Yeshwant · · Reply

    Is it possible that in case of a SIP call that when an attempt is made to handover one leg of the call to a 3G network from 4G network and the handover fails then a Re-invite message is sent.
    The primary reason in this case would be to re-establish the ongoing SIP call.

  24. Yeshwant · · Reply

    A handover is attempted for a IMS established call from 4G network to a 3G network.
    The handover fails and in this case can a SIP Re-invite be sent with the reason : – Handover failed.
    The primary purpose of this Re-invite is to re-establish the ongoing IMS call.

    1. If the goal is to change the IP addresses used for media, that would be possible, but I suspect that it is going to take more than that to move from one network to another.

  25. shwetha · · Reply

    A session is established between two sip clients but they are unable to speak

    1. Codec mismatch or firewall issues.

  26. Hi Andrew, Consider a case where INVITE is sent by UAC and after call establishment RE-INVITE is sent by UAS , what will be the changes in the Headers (To; From; CSeq: Contact) fot that RE-INVITE compared to INVITE.

  27. Hello, can I put the call on hold using c= and change media format (from audio to image) in the same re-INVITE? My Cisco Call Manager does taht when receiving a fax. Unfortunately my re-INVITE is rejected with 488.

    1. That’s not how I would do it, but I suppose it’s technically correct.

  28. Hi
    Can a 500 message be send for answered SIP call.means if call is already ongoing the can any of node send 500 message.if yes then please let me know the specification which states the same.

    1. I don’t understand what you are asking. What is your call flow?

  29. Anil Kumar · · Reply

    Hi Andrew,

    I have a case where the re-invite should have the c-line ip address information and I have configured the same as custom variable, but I actually run it there are duplicated c-line information

    Connection Information (c): IN IP4 –> this is my requirement and I have configured this in my tool.
    Connection Information (c): IN IP4 –> this is duplicated

    I want to know why is this duplicated.

    I could see this is duplicated in both the re-invite for hold and unhold case.

    1. It makes be the platform you are using, but I have no idea why. Sorry.

  30. Great article Andrew, actually all your articles are very helpful. I am new to SIP but I have an issue that is affecting a small percentage of our outbound calls. From what I can gather is the provider is sending us an a=sendonly in the 200 OK and then shortly after (within milliseconds) sending us an a=sendrecv. The problem is we are busy processing the first message so we send a busy here and the gateway drops the call. Have you seen that before?

    1. Are you saying you get two INVITEs for the same call milliseconds apart?

  31. Yes, we acknowledge the first invite as sendonly and before the call is fully connected an invite comes back with the same call-id with SDP to set it sendrecv. Since we haven’t fully setup the call yet we respond with 486 Busy Here and then hang up.

    1. I am not sure why the carrier is doing that, but if you sent a 200 OK and received an ACK, you should be ready to accept another INVITE.

Leave a 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: