Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

From: Ofer Goren <[email-masked]>
Date: Thu, 7 Mar 2013 09:20:06 +0000

Hi

I checked RFC 5407 for race condition in various scenarios but I failed to find any indication of crossover between BYE and UPDATE.
So I have a connected callLeg, and I send an UPDATE transaction from A to B. At the same time, I send BYE from B to A.
Should A re-transmit the UPDATE in case B did not answer even after A replied with 200OK for the BYE?
What about other general transactions (such as OPTION)? Is UPDATE special in this case and should be treated differently than other general transactions on that call?

Thanks,
Ofer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 11:26:37 +0000

Hi,

As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests associated with that dialog, as the dialog doesn't exist anymore.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: [email-masked]
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

Hi

Thanks,
Ofer

---

From: Robert Sparks <[email-masked]>
Date: Thu, 07 Mar 2013 08:42:17 -0600

On 3/7/13 5:26 AM, Christer Holmberg wrote:
>
> Hi,
>
> As the BYE terminates the dialog, I see no reason why you should 
> re-transit the UPDATE, or any other mid-dialog requests associated 
> with that dialog, as the dialog doesn't exist anymore.
>
Transactions complete independently. If you were to follow the 
specifications, you will retransmit the UPDATE until it gets a final 
response or the appropriate timer fires ending the transaction.

The real problem is that the request may actually have gotten to the UAS 
before the BYE was processed, but the response to it is what got lost. 
Your retransmission will stimulate retransmission of that response, and 
you need to receive that response in order to have a consistent view of 
state at both endpoints.

Christer - it's not hard to imagine an applicaitons use of an INFO 
package that you would break with the optimization you propose.

RjS
>
> Regards,
>
> Christer
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Ofer Goren
> *Sent:* 7. maaliskuuta 2013 11:20
> *To:* [email-masked]
> *Subject:* [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)
>
> Hi
>
> I checked RFC 5407 for race condition in various scenarios but I 
> failed to find any indication of crossover between BYE and UPDATE.
>
> So I have a connected callLeg, and I send an UPDATE transaction from A 
> to B. At the same time, I send BYE from B to A.
>
> What about other general transactions (such as OPTION)? Is UPDATE 
> special in this case and should be treated differently than other 
> general transactions on that call?
>
> Thanks,
>
> Ofer
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 14:52:35 +0000

Hi,

My point was more that any state synchronization etc shouldn't matter, as the dialog is anyway terminated.

But, Robert is correct, if you follow the specification (lots of implementations don't :), and re-transmitting until you get a response will make sure you're on the "safe side".

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 7. maaliskuuta 2013 16:42
To: Christer Holmberg
Cc: Ofer Goren; [email-masked]
Subject: Re: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests associated with that dialog, as the dialog doesn't exist anymore.
Transactions complete independently. If you were to follow the specifications, you will retransmit the UPDATE until it gets a final response or the appropriate timer fires ending the transaction.

The real problem is that the request may actually have gotten to the UAS before the BYE was processed, but the response to it is what got lost. Your retransmission will stimulate retransmission of that response, and you need to receive that response in order to have a consistent view of state at both endpoints.

Christer - it's not hard to imagine an applicaitons use of an INFO package that you would break with the optimization you propose.

RjS

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ofer Goren
Sent: 7. maaliskuuta 2013 11:20
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] Question on RFC 5407 (crossover of BYE and UPDATE)

Hi

Thanks,
Ofer

sipcore mailing list

[email-masked]<mailto:[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 07 Mar 2013 10:02:56 -0600

> as the dialog is anyway terminated.
I think you are assuming that the state you are synchronizing is limited 
to dialog state.
There are application side-effects of processing many of these messages 
that you can't predict,
and the applications really do care about the result of that transaction 
at the other end.
>
> But, Robert is correct, if you follow the specification (lots of 
> implementations don't :),
>
And risk causing grief for doing so.
>
> and re-transmitting until you get a response will make sure you're on 
> the "safe side".
>
> Regards,
>
> Christer
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* 7. maaliskuuta 2013 16:42
> *To:* Christer Holmberg
> *Cc:* Ofer Goren; [email-masked]
> *Subject:* Re: [sipcore] Question on RFC 5407 (crossover of BYE and 
> UPDATE)
>
> The real problem is that the request may actually have gotten to the 
> UAS before the BYE was processed, but the response to it is what got 
> lost. Your retransmission will stimulate retransmission of that 
> response, and you need to receive that response in order to have a 
> consistent view of state at both endpoints.
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Ofer Goren
> *To:* [email-masked] <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 08 Mar 2013 16:16:03 +0900

Hi,

Additionally, if any subscription exist, the dialog does not terminate.

Shinji.

Christer Holmberg <[email-masked]>
Thu, 7 Mar 2013 11:26:37 +0000
>Hi,
>
>As the BYE terminates the dialog, I see no reason why you should re-transit the UPDATE, or any other mid-dialog requests 
>associated with that dialog, as the dialog doesn't exist anymore.
>
>Regards,
>
>Christer
>
>

---

From: Ofer Goren <[email-masked]>
Date: Fri, 8 Mar 2013 23:43:40 +0000

Thank you all for the clear answers.

Sent from IPhone 7

ב-8 במרץ 2013, בשעה 09:15, "OKUMURA Shinji" <[email-masked]<mailto:[email-masked]>> כתב/ה:

Hi,

Shinji.

Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Thu, 7 Mar 2013 11:26:37 +0000
Hi,

Regards,

Christer

Hi

I checked RFC 5407 for race condition in various scenarios but I failed to find any indication of crossover between BYE and
UPDATE.
So I have a connected callLeg, and I send an UPDATE transaction from A to B. At the same time, I send BYE from B to A.
Should A re-transmit the UPDATE in case B did not answer even after A replied with 200OK for the BYE?
What about other general transactions (such as OPTION)? Is UPDATE special in this case and should be treated differently than
other general transactions on that call?

Thanks,
Ofer