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
OKUMURA Shinji <shin@xxxxxxxxxxxxxxx>>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>>gao.yang2@xxxxxxxxxx>>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 <shin@xxxxxxxxxxxxxxx>>>发件人: sipping-bounces@xxxxxxxx>>2009-03-06 00:10>>>>收件人>>gaoyang <gao.yang.seu@xxxxxxxxxxx>, christer.holmberg@xxxxxxxxxxxx,>>sipping@xxxxxxxx>>抄送>>>>主题>>Re: 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_______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
