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:
- From my desk phone, I put the call on hold. My phone sends a re-INVITE to Session Manager.
- Session Manager challenges the re-INVITE with a 407 response.
- My telephone resends the re-INVITE to Session Manger with the proper credentials.
- Session Manager sends the re-INVITE to Communication Manager.
- Communication Manager sends a PUBLISH to Session Manager indicating that the call is on hold.
- Communication sends the re-INVITE back to Session Manager.
- Session Manager sends a NOTIFY to the telephone indicating that the call is on hold.
- Session Manager sends the re-INVITE to the other party in the call.
- 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.
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.
0.0.0.0 indicates no media.
Reinvite also sent from the UAC ,why the tag is added in To -header
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?
Have you enabled T.38 on the Interworking Profile page?
Same issue.. I confirmed I did have T.38 enabled on the Interworking Profile and I see the same behavior in the trace (SBC fwds the re-INVITE without the m attribute in SDP), carries replies with a 488 – Not acceptable here… were you able to fix this?
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
Interesting, thanks Andrew.
Is the re-INVITE/OK/ACK considered as a transaction in the initial dialog or a new dialog?
A re-invite is part of the same dialog as the original invite.
Its an in-dialog request (dialog is in established state) and both parties have already shared their tags.
If a session is setup between A & B with call flow,
A -INV-> B
Can B send re-INV after this confirmed dialog?
What if the user is upgrading the call from Audio to video. Would that evoke SIP Re-Invite or SIP Update
RE-INVITE will be used.
Thanks for the article!
Is there a way to recognize an INVITE message when the call is taken off hold?
If I have established call with 2 m= lines:
1. Is it possible re-INVITE as
2. or I must firstly delete ‘video’ streams
3. or if I want only one re-INVITE:
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 =’.
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.
Thanks, I have noticed sometimes the ‘From’ and ‘To’ Numbers are swapped around in the Re-Invite from the UAS is that allowed or what scenario it can happen ?
What if a re-invite comes in without an SDP. What should happen in this case, the call to remain on hold?
If there is no SDP, there should be no change in the media (stay on hold).
Does that happen wheter the Re-INVITE is sent by the party that initiated the hold or by the other party?
Can you point me to the RFc where that is documented?
Thanks for everything, your articles have helped me a lot.
A REFER can come from either party. https://tools.ietf.org/html/rfc3515
I also have a situation where they put the call on hold. They send a re-invite without SDP, my system replys with sendonly as the call is on hold and in their ACK sdp they reply reconly. But they are expecting 2 way audio, and say their ACK is just a reply to my 200 sdp. What should happen?
What would be the Cseq value incase of Re-invite ?
Will it be same as invite or incremented or higher than invite Cseq value
I would increase it by 1.
Quick question, If UAS re-invite then it will be considered as UAC or still UAS?
UAC – Send SIP request and receive response
UAS – Receive SIP request and send response
Am also puzzled regarding session-expire header with refresher.
If refresher is UAC(Session-Expires: 1800;refresher=uac) than session refresh is done by UAC and if refresher is UAS(Session-Expires: 1800;refresher=uas) than session refresh is done by UAS.
In advance, thanks for your help and looking forward for clarification.
If invite is lost in sip .what will happen
It will be retransmitted.
what is the importance of session version in reInvte SDP ?. if UAC change the SDP in the reInvite but session version is same then UAS will not agree to the change ?
If the re-INVITE is failed or refused, will the call/session discontinued?
It would continue with the previously negotiated INVITE.