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:shin@xxxxxxxxxxxxxxx] > Sent: 6. maaliskuuta 2009 8:12> To: gao.yang2@xxxxxxxxxx> Cc: sipping@xxxxxxxx; Christer Holmberg; pkyzivat@xxxxxxxxx> Subject: offer/answer rollback issue - draft-sipping-offeranswer> > 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
