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.

  32. Hi Andrew, perhaps this question belongs to your posting on timers, but I have a question regarding Session refresh defined in RFC 4028. The reason I am posting it here is because my question is about session refresh using Re-INVITE (Sec. 7.4). Let’s say SubA sends INVITE(SDP1) and SubB responds with 200 OK(SDP2). If SubA takes the role of being the refresher, does SubA send Re-INVITE with SDP1 or SDP2? Likewise, what if SubB is the refresher?

    1. Just trying to follow up… any thoughts?

  33. I have a question ..

    if invite is lost, what will happen. What is the
    difference between first and second transmission…

  34. Hi Andrew, I have a question please. I currently have a fault where BOTH the A and the B end send a re-invite at almost exactly the same time. Is there a ‘priority’ in the SIP world as there is in TDM, ( fro clashes or glare). IE which re-invite would take priority ??. Thanks

    1. I am not aware of anything in the protocol. I did find this, though. It appears that others are thinking the same thing as you. https://www.google.ch/patents/US20150358361

  35. Ist is allowed to send Re-invite with same SDP “state” again ?

    R Sara

    1. Sure. I’m not sure of the purpose of that, though.

  36. I am facing one problem and need your support to answer my queries

    Whenever SBC detects minor packet loss towards IMS (in Milliseconds) then SBC does not forward messages towards egress leg, you can refer below traces where SBC received Re-Invite from ingress and it should forward this towards IMS ipv6 egress leg but SBC detects packets loss in milliseconds towards IMS and instead of sending this INVITE message to further leg , SBC sends BYE message towards Egress leg and release ingress leg session with SIP 504.

    Due to this issue we are facing call drop on ongoing calls and calls not maturing for new calls because SBC does not forward the INVITE to egress and release ingress leg with SIP 504.

    We want from SBC perspective that SBC should retry invite towards egress although there was packet loss in ms but SBC should forward ingress leg messages towards Egress leg just like SBC is sending new BYE message to Egress after restoration of minor packet loss.

    1. Message transmission should be retried. Why do you think this has to do with packet loss? That doesn’t make a lot of sense. How would the SBC know that?

  37. Hello Andrew,

    Thanks for this post.
    One question please:
    A re-INVITE coming from the UAS towards the UAC switches the From and To tags of the initial dialog.
    A SIP dialogue is defined by the From tag, To tag and the Call-ID.So, even if the Call-D remains the same, since the UAS-generated re-INVITE has different From and To tags, can we say that it consists a whole new dialogue?

  38. Hi Andrew i have one question , i have an issue in that call is getting dropped after 30 seconds . CUCM to avaya via sip trunk .I am getting these on the logs
    sipSPIStopHoldTimer: Stopping hold timer State change from (SIP_STATE_MIDCALL_RECD_SUCCESS, SUBSTATE_NONE) to (STATE_ACTIVE, SUBSTATE_NONE) sip_stop_timer: timerContext=0x10d27128 type=SIP_TIMER_DISCONNECT value=500 retries=10 sipSPICheckResponseExt: non-INVITE response with no RSEQ – do not disable IS_REL1XX any idea ?

    1. Could be a firewall or SBC issue. The SIP pinhole is perhaps being closed while the call is in progress. Is media coming through during that 30 seconds?

  39. No media , call is disonnecting after 30 sec…do we need to increase the session timer on CUCM ?

    1. Sounds like a firewall problem.

  40. From: “Jerome Pirie” ;tag=174935998~a0d300a9-ca58-454f-9ac5-4e80d50789ca-47447183
    To: ;tag=54453f75395eb792
    Date: Thu, 27 Jul 2017 20:59:38 GMT
    Call-ID: 79477d80-97a15430-4dfc379-c258b0a@
    User-Agent: Cisco-CUCM10.5
    Max-Forwards: 70
    P-Asserted-Identity: “Jerome Pirie”
    CSeq: 102 BYE
    Reason: Q.850;cause=16
    Content-Length: 0

    54195445.000 |07:00:46.498 |AppInfo |SIPSocketProtocol(2,100,14,544636)::handleWriteComplete
    54195446.000 |07:00:46.498 |SdlSig |SdlDataInd |active |LBMInterface(2,100,176,1) |SdlTCPConnection(2,100,14,1) |2,100,14,1.4843932^*^* |*TraceFlagOverrode
    54195446.001 |07:00:46.498 |AppInfo |LBMIF: REL XML< (4843920) 14195206529230699501 S A:N,0 V:N,0 I:N,0
    54195446.002 |07:00:46.498 |AppInfo |LBMIF: CI: 47447182 BW REL<S 1702893
    54195433.004 |07:00:46.498 |AppInfo |EnvProcessCdr::outputCdrData CDR data (size-677)- 1,2,466709,47447182,1501189168,2,47447182,220629770,"33103","",0,16,4,315984650,20386,2,20,0,0,0,0,0,0,"0","0",47447183,2,47447183,505358090,"66483349","66483349","",0,0,4,505358090,51992,2,20,0,0,0,0,0,0,"0","0",1501189168,1501189246,"66483349","9cd5609c-bdd2-44b9-9b30-01d669af2d8f","VCS_TP_PT","","VCS_TP_PT","VCS_TP_PT",78,"CORP_CLUSTER_SIP","VCS_TP_SIP",12,0,0,0,0,0,0,"AUSMECluster",0,"","",0,"",3,2,0,0,64,64,"","","","","",0,0,0,0,0,0,0,0,0,0,0,0,1,"79477D80000100000034BDDB0D268B0A",1,"79477D80000100000022D2160C258B0A",0,0,0,"","",5,"","","","","","","","",0,0,"33103@iag.com.au","","","","","","","",0,0,0,"664833XX","664833XX","664833XX",""

    54195447.000 |07:00:46.512 |SdlSig |SIPTimer |wait |SIPHandler(2,100,79,1) |SdlTimerService(2,100,3,1) |2,100,10,5.16161260^^* |[T:H-H:0,N:0,L:0,V:0,Z:0,D:0] TimerType=SIP_TIMER_REMOVE_TRANSACTION value=32000 numRetries=0
    54195447.001 |07:00:46.512 |AppInfo |//SIP/SIPHandler/ccbId=0/scbId=0/wait_SIPTimer: TimerExpired type=SIP_TIMER_REMOVE_TRANSACTION value=32000 retries=0
    54195447.002 |07:00:46.512 |AppInfo |//SIP/SIPHandler/ccbId=0/scbId=0/sip_stop_timer: timerContext=0x10d81620 type=SIP_TIMER_REMOVE_TRANSACTION value=32000 retries=0
    54195447.003 |07:00:46.512 |AppInfo |//SIP/Stack/Info/0x0x10d80640/sipSPIFlushEventBufferQueue: There are 0 events on the internal queue that are going to b
    54195447.004 |07:00:46.512 |AppInfo |//SIP/Stack/Transport/0x0/sipConnectionManagerUnregisterCtxtInCon: gConnTab=0xdfd6480, addr=, port=5068, unregistering context=
    54195447.005 |07:00:46.512 |AppInfo |//SIP/Stack/Transport/0x0x10d80640/sipSPITransportContextCleanup: Could not purge context gcb=0x10d80640 from the connection; gc
    54195447.006 |07:00:46.512 |AppInfo |//SIP/Stack/Info/0x0x10d80640/sipSPIUfreeOneCCB: Freeing ccb 10d80640
    54195448.000 |07:00:46.522 |SdlSig |SIPTimer |wait |SIPHandler(2,100,79,1) |SdlTimerService(2,100,3,1) |2,100,10,6.17892915^^* |[T:H-H:0,N:0,L:0,V:0,Z:0,D:0] TimerType=SIP_TIMER_REMOVE_TRANSACTION value=32000 numRetries=0
    54195448.001 |07:00:46.522 |AppInfo |//SIP/SIPHandler/ccbId=0/scbId=0/wait_SIPTimer: TimerExpired type=SIP_TIMER_REMOVE_TRANSACTION value=32000 retries=0
    54195448.002 |07:00:46.522 |AppInfo |//SIP/SIPHandler/ccbId=0/scbId=0/sip_stop_timer: timerContext=0x109ef2b0 type=SIP_TIMER_REMOVE_TRANSACTION value=32000 retries=0
    54195448.003 |07:00:46.522 |AppInfo |//SIP/Stack/Info/0x0x109ee2d0/sipSPIFlushEventBufferQueue: There are 0 events on the internal queue that are going to b
    54195448.004 |07:00:46.522 |AppInfo |//SIP/Stack/Transport/0x0/sipConnectionManagerUnregisterCtxtInCon: gConnTab=0xdfd6480, addr=, port=5063, unregistering context=
    54195448.005 |07:00:46.522 |AppInfo |//SIP/Stack/Transport/0x0x109ee2d0/sipSPITransportContextCleanup: Could not purge context gcb=0x109ee2d0 from the connection; gc
    54195448.006 |07:00:46.522 |AppInfo |//SIP/Stack/Info/0x0x109ee2d0/sipSPIUfreeOneCCB: Freeing ccb 109ee2d0
    54195449.000 |07:00:46.543 |AppInfo |SIPSocketProtocol(2,100,14,544636)::handleReadComplete send SdlReadRsp: size 506
    54195450.000 |07:00:46.543 |SdlSig |SdlReadRsp |wait |SIPTcp(2,100,71,1) |SdlTCPConnection(2,100,14,544636) |2,100,14,544636.123777^^* |*TraceFlagOverrode

  41. if reinvite receive 500 response from endpoint. then what should be expected behavior?

    1. Hmmm…I expect that the original call would stay up with the previous SDP/etc. However, if the server is failing, it all might start tumbling down very soon.

  42. Chavdar Baramov · · Reply

    Is there a UPDATE article out?

    1. Sorry, but I never got around to writing one.

  43. Hi Andrew ,I have asked this question earlier also where scenario is that SBC receives invite from ingress leg and then try to forward same towards egress leg but at same time it observe packet loss in milliseconds towards egress leg then it drops the invite and doesn’t forward further towards egress and send 504 to ingress leg,SBC vendor Genband is saying SBC is doing correct as per RFC 3261 clause (handling transport error) but I assume that this implementation is not good and invite should retransmit towards egress . please suggest and share RFC clause where it is mentioned such scenario handling.

    1. I read those sections of the RFC and have to say that Genband is doing the correct thing.

  44. Hi Andrew, Quick question please for call using a normal (early Invite)….
    I have a scenario where the far end ‘never’ sends a 200ok WITH SDP info in it, it just sends an empty 200ok ?? it does send a 183 WITH SDP and the call does work, but my understanding was that it is the 200ok which is the FINAL acceptance to an early Invite (ie INVITE containing SDP info), not a 1xx as these are just provisional responses. (Even with a LATE invite the ACK, then should be the FINAL acceptance ??)
    Is sending the SDP info only in the 183 acceptable ?? do they not need to send a 200ok containing the exact same SDP as in the 183 to confirm everything ??

    1. Interesting. Since SIP doesn’t require SDP, I would be surprised if there was any requirement that it appear in a 200 OK. Thinking about your scenario I find no reason why it wouldn’t be “legal.”

  45. Hi Andrew ; Quick question please, I have a problem with seven re-invite in 32 seconds.
    I thinking Caller side(A) cant detect 100 Trying and 180 Ringing messages. No ringback tone.
    This is Timer T1 – B – Z problem ? And we can extend the time for 100 trying and 180 Ringing message ?

    A —->>> B

    0 INVITE —>

    <—100 TRYING

    <—180 RINGING

    Many Thanks,

    1. You’ve got big problems if provisional responses can’t be detected. I would fix that before I attempted to fiddle with timers.

  46. DO you offer RSS feed to be published on our blog

    1. No, but I should. I will look to see how hard that might be.

  47. Igor Nikolaev · · Reply

    Hi Andrew, please add some wording around using local and remote tags in the in-dialog requests in the direction opposite to the original invite. Your phrasing assume that attribution of an request (e.g.re-invite) to a particular dialog is based on Call-ID and From tag only, which kind of implies they should be the same in all requests within a dialog. Obviously (1)in the reverse direction the From-tag will be the local tag of the Party-B (callee) which equals to the To-tag of the original request (2) To-tag will be the remote tag equal to the From-tag of the original request, and (3) both tags are important to identify a dialog. I now have a customer who references your post so I need to untangle his doubts. And you had similar comment from a puzzled reader Jean-Luc Larcheveque · September 18, 2015

  48. Olivier THOMAS · · Reply

    Certainly a stupid question, but I don’t find any answer.
    Can we send a BYE just after a Re-INVITE or must we send a CANCEL first ?
    Must we terminate the transaction in progress before to end the call ?

    1. You can only send a BYE to an established session. Until it is established, send a CANCEL.

      1. Olivier THOMAS · ·

        Even if none 200 OK has been received as answer to the Re-INVITE ?
        Thanks a lot for your help !

  49. So a re-INVITE is the same that a “retransmission invite”?

    1. No. A retransmission is sent when a SIP timeout occurs. A re-INVITE is a separate transaction. Read this: https://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/

  50. How to filter reinvites in a pcap. I can see only Invite, update, options request

    1. A re-INVITE is an INVITE.

      1. Thanks Andrew, i filtered using string in-dialog. Re-invite will have in-dialog tag.

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 )

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: