[SIPForum-discussion] reINVITE sent by callee before receiving ACK
Dave McBride
davemcbride123 at gmail.com
Thu Jan 9 18:50:06 UTC 2014
I believe it means the first INVITE has a lower CSeq than the reINVITE.
Thanks
David
On 9 Jan 2014 18:46, "Aniella Juverdeanu" <Aniella.Juverdeanu at telus.com>
wrote:
> Hi David,
>
>
>
> I agree in general with the logic, but the RFC 3261 extract cannot support
> my scenario – a reINVITE will always have a higher sequence number,
> wouldn’t it? (I never saw a reINVITE with lower sequence number than
> initial INVITE).
>
> So the RFC rule cannot apply, unless would actually send the sequence
> number lower because it didn’t ACK and then the rule would apply. Do you
> know if this is possible?
>
>
>
> Thanks,
>
> Aniella
>
>
>
> *From:* Dave McBride [mailto:davemcbride123 at gmail.com]
> *Sent:* January 9, 2014 10:20 AM
> *To:* Aniella Juverdeanu
> *Cc:* tester voip; AOEKING; discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] reINVITE sent by callee before
> receiving ACK
>
>
>
>
>
> 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/6444d28f/attachment-0002.html>
More information about the discussion
mailing list