[SIPForum-discussion] reINVITE sent by callee before receiving ACK

[Dave McBride]

Hi Aniella

Alice should send a 500 error with a Retry-After header telling Bob to back
off for a few seconds.

The initial INVITE isn't complete until the associated 200 OK is ACK'ed, so
Bob shouldn't send reINVITE before receiving ACK.

RFC 3261:

14.2 UAS Behavior


A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE and MUST include a Retry-After header field with a
   randomly chosen value of between 0 and 10 seconds.

Thanks

David

On 9 January 2014 00:57, Aniella Juverdeanu <Aniella.Juverdeanu at telus.com>wrote:

> But it looks like the ACK is after the re-Invite (I don’t see the arrow in
> the diagram but it seems so)
>
>
>
> I had similar case in the network where I pushed the vendor of the called
> party (Bob) to not send the re-Invite before sending the ACK (in my case
> the vendor for Alice was dropping the call with clear reason that is 200 OK
> was not ACKed yet). The vendor for Bob argued that RFC 3261 allows this
> behaviour. Anyway I could not conclude in the end because I had to pursue
> the vendor for Alice to change the call flow (it was quite complicated due
> to HOLD and transfer back and forth) that eliminated this behaviour.
>
>
>
> So it is still not clear for me if re-Invite before ACK-ing is correct
> upon RFC. Makes sense to not be correct but so many things make sense and
> they are not correctJ
>
>
>
> Aniella
>
>
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *tester voip
> *Sent:* January 8, 2014 01:55 AM
> *To:* AOEKING
> *Cc:* discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] reINVITE sent by callee before
> receiving ACK
>
>
>
> nuwan,
>
>
>
> you are corect in saying that the re-invite should get rejected if it is
> received before dialog establishment.
>
> but for the cale the dialog is already established as it has sent the
> ack.so it shouldnt reject the reinvite.
>
>
>
> On Sat, Jan 4, 2014 at 10:45 PM, AOEKING <aoeking at gmail.com> wrote:
>
> If the re-INVITE received before the dialog establishment that re-INVITE
> will be rejected.
>
>
>
> Use SIP UPDATE mechanism to avoid this kind of race conditions
>
>
>
> Cheers
>
> Nuwan
>
>
>
> On Thu, Dec 19, 2013 at 11:18 PM, tester voip <tester.voip1 at gmail.com>
> wrote:
>
> hi,
>
> as per the rule re-invite is sent by either party when the dialog is
> estabnlished.
>
> here the caled party sends before receiving ack i.e dialog not established.
>
>
>
> although alice wont reject it as it has sent the ack already.
>
> alice sends 200ok for it.
>
>
>
> please corect me if m wrong.
>
>
>
> On Tue, Dec 17, 2013 at 7:58 PM, Talha Koc <talha.koc at huawei.com> wrote:
>
> Hi all,
>
>
>
> I would like to get your opinions about the race condition shown below.
>
> In this scenario, Bob sends a re-INVITE with a new offer before receiving
> the ACK for the offer 1.
>
>
>
> Does this violate the offer/answer model? What is the correct behavior for
> Alice here in this position?
>
> Should Alice accept the offer and respond with 200OK with offer2, or
> should Alice reject it based on the following rule?
>
>
>
> RFC 6337 2.2:
>
> “There may be ONLY ONE offer/answer negotiation in progress for a
>
>    single dialog at any point in time.”
>
>
>
>
>
>         Alice                             Bob
>
>           |                                |
>
>           |        INVITE w/offer1         |
>
>           |------------------------------->|
>
>           |             180                |
>
>           |<-------------------------------|
>
>           |                                |
>
>           |      200 INVITE w/answer1      |
>
>           |<-------------------------------|
>
>           |                    reINVITE    |
>
>           |   ACK              w/offer2    |
>
>           |-------------     --------------|
>
>           |              \ /               |
>
>           |               X                |
>
>           |              / \               |
>
>           |<------------     ------------->|
>
>           |             ???                |
>
>           |------------------------------->|
>
>           |                                |
>
>
>
> *Note: I checked RFC 5407 3.1.4 for a similar scenario, but in that case
> reINVITE is sent by the caller, not callee.*
>
> *Note2: This is my first post in the mailing list.*
>
>
>
> Regards,
>
> Talha
>
>
>
>
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140109/2cf7502f/attachment.html