UPDATE during re-INVITE and related issues

Hi,
First, preconditions could (and IMHO SHOULD) be satisfied before re-INVITE. 
So anyway, they will be rolled back explicitly if re-INVITE fails. IMHO 
normal diagram for re-INVITE would look like this, am I right? (Adding a new 
stream)
-->RSVP:Path
<--RSVP:Resv
-->RSVP:ResvConf
-->SIP:INVITE(offer);
<--SIP:180(no SDP)
<--RSVP:Path
-->SIP:PRACK
<--SIP:200 PRACK
-->RSVP:Resv
<--RSVP:ResvConf
---waiting for user to accept or reject new media---
<--SIP:200 INVITE(answer)
-->SIP:ACK
I mean, 1xx responses to re-INVITE should not contain SDP, as there is no 
reason.
Second, UPDATE easily goes into race conditions with re-INVITE. Recall Gao's 
diagram:
-->re-INVITE (F1)
<--1xx (F2)
<--UPDATE (F3)
F2 and F3 may be delivered out of order. So there will be no way to tell 
whether F1 or F3 came out first. This is also true even both re-INVITE and 
UPDATE were sent by the same UA. Only SDP versioning helps.
So UPDATE is not a part of re-INVITE transaction if it contained no SDP.
IMO everything that clearly is a part of re-INVITE transaction, must be 
rolled back.
Consider the following:
-->re-INVITE(offer1)
<--180(answer1)
-->PRACK
<--200 PRACK
-->UPDATE(offer2)
<--200 UPDATE(answer2)
<--603 INVITE
-->ACK
Still, UA at left might not commited the second O/A pair (if responses to 
the re-INVITE and UPDATE were re-ordered).
Regards 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP