Gao, I feel your proposal is no bad for a summary. BUT, The biggest drawback is which UPDATE is "part of the original modification" or "new modification". it is very very ambiguous. the distinction seems to impossible. It is no doubt that an UPDATE without SDP is "new modification". UPDATE after ACk is "new modification" too. but it has a racing condition. new UAS behavior reject all UPDATEs received between 4xx and ACK can the above rule solve the problem ? Regards, Shinji gao.yang2@xxxxxxxxxx >My proposal has no racing condition > >1 UPDATE and 4xx/5xx/6xx of Re-INVITE > > UAC UAS > | session established | > |<===================>| > | | > | F1 re-INVITE (SDP) | > |-------------------->| > | F2 1xx-rel (SDP) | > |<--------------------| > | F3 PRACK | > |-------------------->| > | F4 2xx PRA | > |<--------------------| > | | > |F5 UPDATE F6 4xx INV | > |---------\ /--------| > | \/ | > | /\ | > |<--------/ \------->| > | | > >Currently, there are only two cases for the Offer in UPDATE: > > o part of the original modification; > > o a new modification request. > >If it is part of the original modification, the session state is clear. >That >is the state before F1. > >If it is a new modification request, there are only two cases for the > UPDATE: > > o accepted by 200OK; > > o rejected by 4xx/5xx/6xx, such as 504. > > If it is accepted by 200OK, the new modification is committed. And > the session state is committed state of the modification triggered by > F5. > > If it is rejected, and the original modification failed, the session >state is one before F1. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
