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
