Subject: [Sipping] offer/answer rollback issue - draft-sipping-offeranswer

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 06 Mar 2009 15:11:31 +0900

Gao,

Thank you for the chart.
I like these whiteboard discussion. :)
but an attached images may be refused by a security server 
for some domain. 

I see your chart, it is interesting and very unfortunate network.

    A                 P-CSCF                B
    |                   |                   |
  S0|  reINVITE/18x   S0|S0  reINVITE/18x   |S0
    |<----------------->|<----------------->|
  S1|                 S1|S1                 |S1
    |                   |               4xx |
    |   UPDATE          |             /-----|
    |------------------>|  UPDATE    /      | rollback to S0
  O2|                O2 |-----------/------>|
    |                   | O2       /        |O2
    |                   |         /         |
    |                   |  200   /          |
    |                   |<------/-----------|
    |              /----| S2   /            |answer2=S2
    |   4xx       /  S2 |     /             |
    |<-----------/------|<---/              |
  S0|           /    S0 | S0                |
    |          /        |                   |
    |   200   /         |                   |
  S2|<-------/          |                   |
    |                   |                   |

there is a problem in the right side dialog.
this problem is just related to not b2bua but UAC(a part of P-CSCF).

>4. UAS should reject UPDATE received between 4xx and ACK.
>   UAC should NOT send UPDATE between 4xx and ACK.

By Ian's suggestion, I thought the above rule was meaningless, 
but it seems to be still effective.

According to this rule, B reject the UPDATE request.

    A                 P-CSCF                B
  S0|  reINVITE/18x   S0|S0  reINVITE/18x   |S0
    |<----------------->|<----------------->|
  S1|                 S1|S1                 |S1
    |                   |               4xx |
    |   UPDATE          |             /-----|
    |------------------>|  UPDATE    /      | rollback to S0
  O2|                O2 |-----------/------>|
    |                   | O2       /        |O2
    |                   |         /         |
    |                   |  4xx   /          |
    |                   |<------/-----------|
    |              /----| S1   /            |S0
    |   4xx       /  S1 |     /             |
    |<-----------/------|<---/              |
  S0|           /    S0 | S0                |
    |          /        |                   |
    |   4xx   /         |                   |
  S0|<-------/          |                   |
    |                   |                   |

all states of entities are in synch.

Another scenario.
UPDATE request was later than ACK...

    A                   B
  S0|  reINVITE/18x     |S0
    |<----------------->|
  S1|                   |S1
    |                   |
    | UPDATE            |
  O2|-----\             |
    |      \       4xx  |
  S0|<------\-----------|
    |        \          | rollback to S0
    |         \         |
    | ACK      \        |
    |-----------\------>|
    |            \      |
    |             \---->| O2
    |               200 |
  S2|<------------------| answer2=S2
    |                   |

This is no problem too.

Newer rule

UAC Behavior
    After receiving 4xx, if UAC receive 200 response with answer
    to UPDATE that sent before receiving 4xx, UAC SHOULD treat it
    as if UAC sent the UPDATE after sending ACK.
    (UAC should NOT send UPDATE between 4xx and ACK.)

UAS Behavior
    UAS SHOULD reject UPDATE received between 4xx and ACK.

This rule seems to be suitable for draft-sipping-sip-offeranswer/6.2.

I want to hear the opinion of Paul Kyzivat.

Regards,

Shinji

[email-masked]
>1. Chart
>By your rule, in A/B's view, UPDATE/200OK is after 4xx(/failure of
>Re-INVITE).
>
>But in P-CSCF's view, UPDATE/200OK is before 4xx.
>
>2. My proposal has no such problem.
>Because: even if A/B/P-CSCF has different view of the order, but the state
>is decided by the property of Offer/Answer in UPDATE/200OK.
>
>If the Offer/Answer is just "refresh precondition state table", it has no
>influence on the final session state.
>If the Offer/Answer has modification, it is committed.
>
>OKUMURA Shinji <[email-masked]>
>发件人:  [email-masked]
>2009-03-06 00:10
>
>收件人
>gaoyang <[email-masked]>, [email-masked],
>[email-masked]
>抄送
>
>主题
>Re: [Sipping] My proposal has no racing condition
>
>Gao,
>
>AFAIK, providing aspecific service, P/S-CSCF and AS are defined as B2BUA.
>
>>Yes. I agree with you.
>>
>>But I tried to give you one example(P-CSCF).
>>
>>The order of signals in P-CSCF's view can be different with UAC's view.
>>
>>For example, UPDATE and 200OK before 4xx. Then P-CSCF can have different
>>session state.
>>
>>
>>
>>> Christer,
>>>
>>> >Hi,
>>> >
>>> >There are also "B2BUAs acting as proxies", that do not terminate the
>>> >dialogs.
>>>
>>> "B2BUAs acting as proxies" is a terrible entities !
>>> It should behave as B2BUA.
>>>
>>> Regards,
>>>
>>> Shinji

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Mar 2009 07:45:24 +0100

Hi Shinji,

Regarding your rule:

"UAS Behavior
    UAS SHOULD reject UPDATE received between 4xx and ACK."

I think Ian showed that it may not work, since the ACK is hop-to-hop. So, even if the UAS receives the ACK before the UPDATE, it doesn't mean that the UAC (and intermediates) received the 4xx before they sent the UPDATE.

Regards,

Christer

> -----Original Message-----
> From: OKUMURA Shinji [mailto:[email-masked]] 
> Sent: 6. maaliskuuta 2009 8:12
> To: [email-masked]
> Cc: [email-masked]; Christer Holmberg; [email-masked]
> Subject: offer/answer rollback issue - draft-sipping-offeranswer
> 
> Gao,
> 
> Thank you for the chart.
> By Ian's suggestion, I thought the above rule was 
> meaningless, but it seems to be still effective.
> 
> >Because: even if A/B/P-CSCF has different view of the order, but the 
> >state is decided by the property of Offer/Answer in UPDATE/200OK.
> >
> >If the Offer/Answer is just "refresh precondition state 
> table", it has 
> >no influence on the final session state.
> >>For example, UPDATE and 200OK before 4xx. Then P-CSCF can have 
> >>different session state.
> >>
> >>
> >>
> >>> Christer,
> >>>
> >>> >Hi,
> >>> >
> >>> >There are also "B2BUAs acting as proxies", that do not terminate 
> >>> >the dialogs.
> >>>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 06 Mar 2009 18:40:15 +0900

Hi, all

Unfortunately a disproof was shown by Gao.

    A                   B
  S0|  reINVITE/18x     |S0
    |<----------------->|
  S1|                   |S1
    |  UPDATE           |
  O2|------------------>|O2
    |                   |
    |       200(UPDATE) |
    |         /---------|A2=S2
    |        /          |
    |       /      4xx  |
  S0|<-----/------------|S0
    |     /             |
    |    /              |
  S2|<--/               |
    |                   |

The both state is NOT sync.

Regards,

Shinji