Subject: [Sipping] UPDATE during re-INVITE and related issues

From: "Anton Tveretin" <[email-masked]>
Date: Thu, 9 Apr 2009 00:23:49 +0600

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Apr 2009 16:07:25 -0400

Anton,

I don't think I understand you. Comments inline.

Anton Tveretin wrote:
> 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)

IIUC, you are assuming that a session has already been established with 
one or more media streams before the below?

> -->RSVP:ResvConf

If these RSVP messages are for a contemplated new media stream, where 
are you sending them? You don't know where the media stream will terminate.

> <--SIP:180(no SDP)

I think the UAS can't return 180 until it knows the resources are 
available to establish the new stream.

> I mean, 1xx responses to re-INVITE should not contain SDP, as there is 
> no reason.

The reason is so that the UAC will know if there will indeed be a new 
media stream, and where it will terminate. Until it knows that, how can 
it do the RSVP to reserve resources for the path?

I'll stop commenting here because without agreement on this its hard to 
talk about more.

	Thanks,
	Paul

> Second, UPDATE easily goes into race conditions with re-INVITE. Recall 
> Gao's diagram:
> -->re-INVITE (F1)
> <--1xx (F2)
> <--UPDATE (F3)
> 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.
> 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-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

---

From: [email-masked]
Date: Thu, 9 Apr 2009 10:34:12 +0800

1. First, I am glad to see more people support of "Rollback" and the 
concept of "part of re-INVITE transaction"(nested-transaction).

2. Your example using e2e resource reservation, then the Path(from the 
Offerer) should after first Offer/Answer. Because the destination of the 
Path is the IP address in the Answer.

3. Order problem(or say racing conditon) is solved in my draft.

4. The current focus of the topic is atomicity's semantic of Re-INVITE and 
UPDATE. And this is also discussed in my newest version of the draft.
As you are interested in the concept of "part of re-INVITE transaction", I 
am waiting for your further talk about this topic.

Newest version of the draft: 
http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-criterion-03.txt

"Anton Tveretin" <[email-masked]> 
2009-04-09 02:23

收件人
<[email-masked]>, <[email-masked]>
抄送

主题
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---
Gao's 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.