Subject: [Sipping] About "rollback of re-Invite"

From: [email-masked]
Date: Fri, 13 Feb 2009 16:46:44 +0800

I also pay high attention to the topic of "rollback of re-Invite".
As lots of service is implemented on the network using SIP, and different 
ways 
may be carried out by different corporations, it's necessary to define a 
complete 
and clear method to solve the failure when the unsuccessful re-Invite 
happens.

   And the problems  "Commit any session parameters that have been 
sucessfully changed"
metioned in "draft-gaoyang-sipping-session-state-analysis-01.txt"  need 
further discuss,
I think.
 
   Eric.wang
   Regards!

--------------------------------------------------------
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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Feb 2009 12:35:21 +0100

Hi, 

>As lots of service is implemented on the network using SIP, and
different ways 
>may be carried out by different corporations, it's necessary to define
a complete 
happens. 

I agree, and we thought that having a generic rule, not related to
specific use-cases, would be the most clear, clean and complete
solution.

sucessfully changed" 
further discuss, 
>I think. 

The draft does not define a generic rule. It more or less says that
every time there is a new use-case, the offer/answer rollback aspects
needs to be documented for that use-case. I think that is something we
wanted to avoid.

If I understand chapter 4.3.3 correct, it says that if you have a
pending re-INVITE transaction, a NEW modification must be sent in a
re-INVITE request. That way we would get rid of the race condition
problem. That is an interesting point. I guess the question is whether
it's too lake to make such a rule.

Regards,

Christer

---

From: [email-masked]
Date: Mon, 16 Feb 2009 20:03:37 +0800

"Christer Holmberg" <[email-masked]> 
2009-02-16 19:35

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

主题
RE: About "rollback of re-Invite"

Comments in line.

Thanks.

Gaoyang

Hi, 

different ways 
a complete 
happens. 

[gaoyang] It is simple and clear. But it disregard nature property of 
nested transaction. I concluded incorrectness and drawback of such way. 
More details in 
http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-analysis-01.txt
.

sucessfully changed" 
further discuss, 

[gaoyang] It is not use-case oriented, but rules/definition oriented.
And the definition of how o/a pairs form nested transaction should be open 
for future.
Such as "a=chain" and so on extension can form more o/a pairs as nested 
transaction. It is not use-case.
We can have a further talk.

[gaoyang] Is the "lake" late? I think it can be BCP, not rules :).

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Feb 2009 14:41:59 +0100

Hi, 

>>different ways may be carried out by different corporations, it's
necessary to define
>>a complete and clear method to solve the failure when the unsuccessful
re-Invite
nested transaction. I concluded incorrectness and drawback of such way.
More details in
http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-
analysis-01.txt. 

I agree it's not the most "beautiful" solution - that's why we spent a
long time discussing it.
	
sucessfully changed" 
further discuss, 
>And the definition of how o/a pairs form nested transaction should be
open for future. 
>[gaoyang] Is the "lake" late? I think it can be BCP, not rules :).

Perhaps, yes.

Regards,

Christer

---

From: [email-masked]
Date: Mon, 16 Feb 2009 22:49:45 +0800

HI，

  The key point of this discussion is how to find out the proper state of 
the rollback.
  I think ,Some rules of using re-invite may be helpful.Such as, we 
restrict only 
  one offer/answer pair in a re-invite,if someone want to raise a new SDP 
or modification, 
  he must wait until the former re-invite is FINISHED or CANCEL/REJECT the 
former re-invite.
 
  Then finding the proper state of rollback will be easier.

  Regards,
  Eric.wang

"Christer Holmberg" <[email-masked]> 写于 2009-02-16

---

From: gaoyang <[email-masked]>
Date: Mon, 16 Feb 2009 14:31:16 +0000

Dear Christer Holmberg
 
I am gaoyang([email-masked]). And I am at home now :).
 
I MUST point out that:
Chapter 4.3.3  is not the solution in theory for race condition problem, it is just BCP level.
Chapter 4.3.2 is the solution in theory.
 
And the racing condition problem described here is not same with the one in 6.2 of "draft-ietf-sipping-sip-offeranswer".
The one in 6.2 of "draft-ietf-sipping-sip-offeranswer" does not exist here.
 
Gaoyang
 
> Date: Mon, 16 Feb 2009 14:41:59 +0100> From: [email-masked]> To: [email-masked]> CC: [email-masked]; [email-masked]> Subject: Re: [Sipping] About "rollback of re-Invite"> > > Hi, > > > >>I also pay high attention to the topic of "rollback of re-Invite". > >>As lots of service is implemented on the network using SIP, and> >>different ways may be carried out by different corporations, it's> necessary to define> >>a complete and clear method to solve the failure when the unsuccessful> re-Invite> >>happens. > > > >I agree, and we thought that having a generic rule, not related to> >specific use-cases, would be the most clear, clean and complete> >solution.> > > >[gaoyang] It is simple and clear. But it disregard nature property of> nested transaction. I concluded incorrectness and drawback of such way.> More details in> http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-> analysis-01.txt. > > I agree it's not the most "beautifu
 l" solution - that's why we spent a> long time discussing it.> > >>And the problems "Commit any session parameters that have been> sucessfully changed" > >>metioned in "draft-gaoyang-sipping-session-state-analysis-01.txt" need> further discuss, > >>I think. > > > >The draft does not define a generic rule. It more or less says that> >every time there is a new use-case, the offer/answer rollback aspects> >needs to be documented for that use-case. I think that is something we> >wanted to avoid. > > > >[gaoyang] It is not use-case oriented, but rules/definition oriented. > >And the definition of how o/a pairs form nested transaction should be> open for future. > >Such as "a=chain" and so on extension can form more o/a pairs as nested> transaction. It is not use-case. > >We can have a further talk.> > > >If I understand chapter 4.3.3 correct, it says that if you have a> >pending re-INVITE transaction, a NEW modification must be sent in a> >re-INVITE request. That way we would get
  rid of the race condition> >problem. That is an interesting point. I guess the question is whether> >it's too lake to make such a rule. > > > >[gaoyang] Is the "lake" late? I think it can be BCP, not rules :).> > Perhaps, yes.> > Regards,> > Christer> > > _______________________________________________> 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
_________________________________________________________________
MSN安全保护中心，免费修复系统漏洞，保护MSN安全！
http://im.live.cn/safe/

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Feb 2009 18:59:50 +0100

Hi,

>The key point of this discussion is how to find out the proper state of the rollback. 
>I think ,Some rules of using re-invite may be helpful.Such as, we restrict only 
>one offer/answer pair in a re-invite, 
 
I don't think we can do that, because at least some pre-condition scenarios require more offer/answer pairs.
 
And, even if you would only allow e.g. a single UPDATE within the re-INVITE, you would still have the same question: if the UPDATE suceeds, but the re-INVITE then fails, what is the state?
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Feb 2009 19:01:37 +0100

Hi,
 
>Chapter 4.3.2 is the solution in theory. 
 
Well, 4.3.3 still solves the problem :) 
 
>The one in 6.2 of "draft-ietf-sipping-sip-offeranswer" does not exist here. 
 
I know. The race condition in the offeranswer draft is about when both endpoints send a new offer at the same time, which is a completely separate issue.
 
Regards,
 
Christer

> Date: Mon, 16 Feb 2009 14:41:59 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [Sipping] About "rollback of re-Invite"
> 
> 
> Hi, 
> 
> 
> nest ed transaction. I concluded incorrectness and drawback of such way.
> More details in
> >And the defini tion of how o/a pairs form nested transaction should be
> open for future. 
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW devel opment of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

________________________________

使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ <http://im.live.cn/messenger.aspx>

---

From: [email-masked]
Date: Tue, 17 Feb 2009 08:25:30 +0800

Hi 

It is 2-17 morning here now. And I think you are sleeping now :).

Comments in lines.

Gaoyang

"Christer Holmberg" <[email-masked]> 写于 2009-02-17 

> Well, 4.3.3 still solves the problem :)

[gaoyang] Yes. :)
 
> 
> >And the racing condition problem described here is not same with 
> the one in 6.2 of "draft-ietf-sipping-sip-offeranswer".
> I know. The race condition in the offeranswer draft is about when 
> both endpoints send a new offer at the same time, which is a 
> completely separate issue.

[gaoyang] Yes. So I say this solution is racing condition free.
And you warried whether the solution is use-case oriented. And if I have 
time, I will write a new mail for further explanation.

> 
> 使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！

---

From: [email-masked]
Date: Tue, 17 Feb 2009 13:01:25 +0800

It is abstract of nested transaction in real usage.
"3.1.  Criterion description" is the rules. And 3.2 defines the level of 
sub-transaction in nest transaction, and it is also rules(definition) 
oriented.
The level of sub-transaction in nest transaction is important, because it 
form the hiberarchy of the nested transaction. 
Using this nested transaction concept, I think it has solved all the 
problem elegantly and with out any extension and violation.

There are three concept in different levels here:
Base rule: defined in "3.1.  Criterion description".
Sub-transaction definition(and its level): defined in chapter 2 and 
chapter 3.2. Sub-transaction definition is just like "precondition", and 
can be added for envolution and extension in future.
Use-cases: This solution is not use-case oriented. But use-case oriented 
testing and inspection are welcome! :)

收件人

主题

Hi, 

different ways 
a complete 
happens. 

sucessfully changed" 
further discuss, 

Regards,

Christer

---

From: [email-masked]
Date: Tue, 17 Feb 2009 19:03:15 +0800

> I don't think we can do that, because at least some pre-condition 
> scenarios require more offer/answer pairs.
> 
> And, even if you would only allow e.g. a single UPDATE within the 
> re-INVITE, you would still have the same question: if the UPDATE 
> suceeds, but the re-INVITE then fails, what is the state?
> 

There are some confuses of the offer/answer pair.
I consider negotiations of a new SDP or modification of former SDP
（not pre-condition） as one offer/answer pair,then pre-conditions 
of the same SDP  belong to the offer/answer pair caused by 
the first offer/answer.

Anyway, If only one new SDP or modificaition and its pre-condition
negotiations are allowed in a re-invite，to find out the rollback 
state becomes earier.

Regards
Eric.wang

> 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.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 Feb 2009 13:50:30 +0000

I haven't been following all of this discussion, but there is nothing explicitly to bind an UPDATE transaction to a parent INVITE or re-INVITE transaction. It is implicit in the vast majority of cases, but timing issues break this, particularly where unreliable transport is concerned. For example, if UPDATE arrives while awaiting ACK, is it because UPDATE was sent before the ACK, or because the ACK was lost? If UPDATE arrives before sending a final response to re-INVITE, is it because UPDATE is nested within the re-INVITE transaction, or has there been a CANCEL request that has been lost and will be repeated later? Without explicit binding, the only consistent thing to do is to treat each transaction separately, and not roll back. If this means pre-conditions are broken, the focus should be on fixing pre-conditions somehow.
 
John

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
	Sent: 16 February 2009 18:00
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [Sipping] About "rollback of re-Invite"

	Hi,

	 
	 
	Regards,
	 
	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Feb 2009 14:59:40 +0100

Hi John, 
 
My understanding of the proposal is that you would only send UPDATEs if they ARE nested to the re-INVITE transaction. Otherwise you would send a new re-INVITE. That way you would know that an UPDATE is nested even if it arrives after the ACK.
 
That of course means that the ongoing re-INVITE transactions needs to finish first (either by itself, or by being cancelled).
 
But, I may have missunderstood, so it's better if the authors speak for themselves :)
 
Regards,
 
Christer

	From: Elwell, John [mailto:[email-masked]] 
	Sent: 17. helmikuuta 2009 15:51
	To: Christer Holmberg; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Sipping] About "rollback of re-Invite"

	John

		Hi,

		 
		 
		Regards,
		 
		Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 Feb 2009 15:01:34 +0000

Christer,
 
I hope that is not what the authors are proposing, because UPDATE is certainly useful outside the context of INVITE/re-INVITE transactions, e.g., for session timer refreshes.
 
John

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
	Sent: 17 February 2009 14:00
	To: Elwell, John; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Sipping] About "rollback of re-Invite"

	Hi John, 

	 
	 
	Regards,
	 
	Christer

		 
		John

			Hi,

			 
			 
			Regards,
			 
			Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Feb 2009 22:11:33 +0100

Hi,
 
I agree that UPDATEs are used outside re-INVITEs, and we can, and shall, not forbid that.
 
I guess that the one could say that it is not allowed to use them as long as the re-INVITE transaction state is still alive. Or something like that...
 
Note that I am not proposing to go ahead with that proposal at this point, and for the fallback solution we did choose the race condition is not even an issue. But I think it was an interesting idea :)
 
Regards,
 
Christer

From: gaoyang [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 5:03 PM
To: Christer Holmberg; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] About "rollback of re-Invite"

Dear Christer Holmberg
 
I am gaoyang([email-masked]). And it is 23:00 here. :)

Thank you for your explanation for us. And I am glad more people join in the topic(may be back again for some people).
 
Your understanding is correct.
 
I'd like to point out for Elwell John that what Christer Holmberg mentioned is the one I called BCP.
And Chapter 4.3.2 is the solution in theory, and it allow UPDATE, which is a new modification beyond just precondition notification.
 
I'd like to have a further talk tomorrow. Good night.
 
Gaoyang

Date: Tue, 17 Feb 2009 14:59:40 +0100
From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]
Subject: Re: [Sipping] About "rollback of re-Invite"

Hi John, 

 
 
Regards,
 
Christer

	 
	John

		Hi,

		 
		 
		Regards,
		 
		Christer

		"Christer Holmberg" <[email-masked]> 写于 2009-02-16 21:41:59:
		
		> http ://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-
		> analysis-01.txt. 
		> 
		> open fo r future. 

立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！ <http://im.live.cn/safe/>

---

From: [email-masked]
Date: Wed, 18 Feb 2009 08:46:20 +0800

Dear Elwell John

From SIP signal level, UPDATE transaction have nothing to do with 
Re-INVITE transaction. And the nested-transaction is the natural property 
of session modification, so the concept of nested-transaction is 
application level issue. And that's why I emphasize that we MUST open the 
door for evolution and extension in future.

1. Precondition uage
o Precondition defined in RFC3312(Quality-of-Service 
precondition)\4032(Precondition Framework)\5027(Security Preconditions) is 
a typical nested-transaction with clear semantics of suspending\resuming 
session modification.

o Another property of Re-INVITE is "late commitment of 200OK of 
Re-INVITE", which is defined in RFC3261 and emphasized again in RFC3311. 
And it is really necessary for user's rejecting of session modification.

Based on the two rule mentioned above, as precondition notification is 
part of the original modification triggered by Re-INVITE, the 2xx final 
response of Re-INVITE is the commitment and non-2xx final response is the 
rejecting. So, rollback for Re-INVITE is clear for precondition usage.

2. Non precondition usage
If the Offer  during(not in) the Re-INVITE, such as UPDATE , is a new 
modification request, then 

o if the UA can accept the UPDATE, and after Offer/Answer, the 
modification MUST be committed.
o if the UA can not accept the UPDATE(for example, can not accept it 
without the user's permition), the UA MUST reject this UPDATE.

The proof of rule one is that: "We have no reason to say that the the new 
successful modification should be commited by the signal(2xx of Re-INVITE) 
associate to the original modification request(Re-INVITE). And in signal 
level, Re-INVITE and UPDATE is independent transaction(SIP). As the new 
modification commitment and its state have nothing to do whit final 
resopnse of Re-INVITE, the session state is clear." And I mentioned this 
in the draft.

I MUST point out that rule two is the way to get rid of a new modification 
while the orignal one in pending state. It is a choice, but not a 
constraint.

Gaoyang

"Elwell, John" <[email-masked]> 
发件人:  [email-masked]
2009-02-17 21:50

收件人
Christer Holmberg <[email-masked]>, [email-masked]
抄送
[email-masked]
主题
Re: [Sipping] About "rollback of re-Invite"

I haven't been following all of this discussion, but there is nothing 
explicitly to bind an UPDATE transaction to a parent INVITE or re-INVITE 
transaction. It is implicit in the vast majority of cases, but timing 
issues break this, particularly where unreliable transport is concerned. 
For example, if UPDATE arrives while awaiting ACK, is it because UPDATE 
was sent before the ACK, or because the ACK was lost? If UPDATE arrives 
before sending a final response to re-INVITE, is it because UPDATE is 
nested within the re-INVITE transaction, or has there been a CANCEL 
request that has been lost and will be repeated later? Without explicit 
binding, the only consistent thing to do is to treat each transaction 
separately, and not roll back. If this means pre-conditions are broken, 
the focus should be on fixing pre-conditions somehow.
 
John

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Christer Holmberg
Sent: 16 February 2009 18:00
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] About "rollback of re-Invite"

Hi,

the rollback. 
restrict only 

And, even if you would only allow e.g. a single UPDATE within the 
re-INVITE, you would still have the same question: if the UPDATE suceeds, 
but the re-INVITE then fails, what is the state?
 
Regards,
 
Christer

--------------------------------------------------------
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.
_______________________________________________
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: Wed, 18 Feb 2009 09:00:44 +0800

Dear Christer Holmberg

I agree with. And the BCP is practical.

I MUST point out that:
The BCP is not the main proposal in 
"draft-gaoyang-sipping-session-state-criterion-01.txt".

The main proposal in the draft is the session state criterion in theory. 

And with combination of yours and mine, all the problem I mentioned in "
draft-gaoyang-sipping-session-state-analysis-01.txt" is not exsit. And the 
combination obeys the issue 3GPP concerns.

Gaoyang

2009-02-18 05:11

收件人
"gaoyang" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
[email-masked]
主题
Re: [Sipping] About "rollback of re-Invite"

Hi,
 
I agree that UPDATEs are used outside re-INVITEs, and we can, and shall, 
not forbid that.
 
I guess that the one could say that it is not allowed to use them as long 
as the re-INVITE transaction state is still alive. Or something like 
that...
 
Note that I am not proposing to go ahead with that proposal at this point, 
and for the fallback solution we did choose the race condition is not even 
an issue. But I think it was an interesting idea :)
 
Regards,
 
Christer

Dear Christer Holmberg

Thank you for your explanation for us. And I am glad more people join in 
the topic(may be back again for some people).

I'd like to point out for Elwell John that what Christer Holmberg 
mentioned is the one I called BCP.
And Chapter 4.3.2 is the solution in theory, and it allow UPDATE, which is 
a new modification beyond just precondition notification.

Gaoyang

Hi John, 
 
My understanding of the proposal is that you would only send UPDATEs if 
they ARE nested to the re-INVITE transaction. Otherwise you would send a 
new re-INVITE. That way you would know that an UPDATE is nested even if it 
arrives after the ACK.
 
That of course means that the ongoing re-INVITE transactions needs to 
finish first (either by itself, or by being cancelled).
 
But, I may have missunderstood, so it's better if the authors speak for 
themselves :)
 
Regards,
 
Christer

 
John

Hi,

the rollback. 
restrict only 

 
Regards,
 
Christer

21:41:59:

> http 
://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-

立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！

---

From: [email-masked]
Date: Wed, 18 Feb 2009 12:58:03 +0800

hi John，

   Sorry for replying so late . I have had my hands full these days.
 
   I prefer no update with sdp outside INVITE/re-INVITE indeed,because 
  updates with sdp outside INVITE/re-INVITE can't be easily distinguished 
  from the pre-condition ones.

  You said :
> It is implicit in the vast majority of 
> cases, but timing issues break this, particularly where unreliable 
> transport is concerned. For example, if UPDATE arrives while 
> awaiting ACK, is it because UPDATE was sent before the ACK, or 
> because the ACK was lost?

In rfc3261 13.3.1.4
   """The 2xx response is passed to the transport with an
   interval that starts at T1 seconds and doubles for each
   retransmission until it reaches T2 seconds (T1 and T2 are defined in
   Section 17).  Response retransmissions cease when an ACK request for
   the response is received.  This is independent of whatever transport
   protocols are used to send the response."""

13.2.2.4 2xx Responses
   """The UAC core MUST generate an ACK request for each 2xx received from
   the transaction layer."""

From above chapters, we can conclude that if the network is in work well, 
the
ACK will arrive.For the sender of new SDP, waiting to send a re-INVITE 
with 
the new offer until the former re-INVITE ends is possible.And for the 
receiver ,
if he receives a new re-INVITE without receiving the former ACK, he may 
wait for
the ACK, or assume that he had received ACK and continue to process the 
new offer.

But i don't intend to eliminate update outside INVITE/re-INVITE, I just 
want to
avoid update with SDP outside INVITE/re-INVITE. 
And if updates for session timer or other usages are without SDP, it can 
go outside 
INVITE/re-INVITE.

regards
Eric.wang

"Elwell, John" <[email-masked]> 写于 2009-02-17 23:01:34:

> Christer,
> 
> I hope that is not what the authors are proposing, because UPDATE is
> certainly useful outside the context of INVITE/re-INVITE 
> transactions, e.g., for session timer refreshes.
> 
> John
> 
> From: [email-masked] [mailto:[email-masked]] On 
Behalf Of 
> Christer Holmberg

> Hi John, 
> 
> My understanding of the proposal is that you would only send UPDATEs
> if they ARE nested to the re-INVITE transaction. Otherwise you would
> send a new re-INVITE. That way you would know that an UPDATE is 
> nested even if it arrives after the ACK.
> 
> That of course means that the ongoing re-INVITE transactions needs 
> to finish first (either by itself, or by being cancelled).
> 

> I haven't been following all of this discussion, but there is 
> nothing explicitly to bind an UPDATE transaction to a parent INVITE 
> or re-INVITE transaction. It is implicit in the vast majority of 
> cases, but timing issues break this, particularly where unreliable 
> transport is concerned. For example, if UPDATE arrives while 
> awaiting ACK, is it because UPDATE was sent before the ACK, or 
> because the ACK was lost? If UPDATE arrives before sending a final 
> response to re-INVITE, is it because UPDATE is nested within the re-
> INVITE transaction, or has there been a CANCEL request that has been
> lost and will be repeated later? Without explicit binding, the only 
> consistent thing to do is to treat each transaction separately, and 
> not roll back. If this means pre-conditions are broken, the focus 
> should be on fixing pre-conditions somehow.
> 
> John
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
Behalf Of 
> Christer Holmberg

system.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 09:26:11 +0000

That would mean a change to RFC 3311, which allows UPDATE with SDP at any time.
 
John

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 18 February 2009 04:58
	To: Elwell, John
	Cc: Christer Holmberg; [email-masked]
	Subject: 答复: RE: [Sipping] About "rollback of re-Invite"

	hi John， 

	
	
	In rfc3261 13.3.1.4 
	
	13.2.2.4 2xx Responses 
	
	From above chapters, we can conclude that if the network is in work well, the 
	ACK will arrive.For the sender of new SDP, waiting to send a re-INVITE with 
	the new offer until the former re-INVITE ends is possible.And for the receiver , 
	if he receives a new re-INVITE without receiving the former ACK, he may wait for 
	the ACK, or assume that he had received ACK and continue to process the new offer. 
	
	But i don't intend to eliminate update outside INVITE/re-INVITE, I just want to 
	avoid update with SDP outside INVITE/re-INVITE. 
	And if updates for session timer or other usages are without SDP, it can go outside 
	INVITE/re-INVITE. 
	
	regards 
	Eric.wang

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Feb 2009 11:14:10 +0100

Hi,
 
I don't think we can completely forbid UPDATE outside re-INVITEs. It's just too late for that.
 
Regards,
 
Christer

	From: Elwell, John [mailto:[email-masked]] 
	Sent: 18. helmikuuta 2009 11:26
	To: [email-masked]
	Cc: Christer Holmberg; [email-masked]
	Subject: RE: RE: [Sipping] About "rollback of re-Invite"

	John

		hi John， 

		
		
		In rfc3261 13.3.1.4 
		
		13.2.2.4 2xx Responses 

		
		regards 
		Eric.wang

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 Feb 2009 10:49:31 +0000

Exactly, I would be concerned about changing RFC 3311.
 
John

	From: Christer Holmberg [mailto:[email-masked]] 
	Sent: 18 February 2009 10:14
	To: Elwell, John; [email-masked]
	Cc: [email-masked]
	Subject: RE: RE: [Sipping] About "rollback of re-Invite"

	Hi,

	Regards,
	 
	Christer

		 
		John

			hi John， 

			
			
			In rfc3261 13.3.1.4 
			
			13.2.2.4 2xx Responses 

			
			regards 
			Eric.wang

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Feb 2009 11:56:22 +0100

Hi,
 
Let's look into this precondition proposal.
 
There are some issues that needs to be taken into consideration.
 
Issue 1:
-----------
 
Assume I send a re-INVITE. I have two m- lines. For one of the m- line changes I use preconditions, and for the other m- line change I do NOT use preconditions.
 
Then I receive a relaible 18x, and the first offer/answer transaction has succeeded.
 
Then the re-INVITE fails. Now, according to the ZTE proposal, the precondition m- line is falled back to the value before the re-INVITE was changed. The non-precondition m- line is not falled back, however, since the change was comitted in the re-INVITE/18x o/a transaction.
 
So, we can NOT say that the whole SDP will be falled back to the state before the re-INVITE was sent. The precondition m- line is falled back, but the non-precondition m- line is NOT falled back.
 
Is that a correct understanding?
 
Regards,
 
Christer

 

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 18. helmikuuta 2009 2:46
	To: Elwell, John
	Cc: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: Re: [Sipping] About "rollback of re-Invite"

	Dear Elwell John 
	
	From SIP signal level, UPDATE transaction have nothing to do with Re-INVITE transaction. And the nested-transaction is the natural property of session modification, so the concept of nested-transaction is application level issue. And that's why I emphasize that we MUST open the door for evolution and extension in future. 
	
	1. Precondition uage 
	o Precondition defined in RFC3312(Quality-of-Service precondition)\4032(Precondition Framework)\5027(Security Preconditions) is a typical nested-transaction with clear semantics of suspending\resuming session modification. 
	
	o Another property of Re-INVITE is "late commitment of 200OK of Re-INVITE", which is defined in RFC3261 and emphasized again in RFC3311. And it is really necessary for user's rejecting of session modification. 
	
	Based on the two rule mentioned above, as precondition notification is part of the original modification triggered by Re-INVITE, the 2xx final response of Re-INVITE is the commitment and non-2xx final response is the rejecting. So, rollback for Re-INVITE is clear for precondition usage. 

	2. Non precondition usage 
	If the Offer  during(not in) the Re-INVITE, such as UPDATE , is a new modification request, then 
	
	o if the UA can accept the UPDATE, and after Offer/Answer, the modification MUST be committed. 
	o if the UA can not accept the UPDATE(for example, can not accept it without the user's permition), the UA MUST reject this UPDATE. 
	
	The proof of rule one is that: "We have no reason to say that the the new successful modification should be commited by the signal(2xx of Re-INVITE) associate to the original modification request(Re-INVITE). And in signal level, Re-INVITE and UPDATE is independent transaction(SIP). As the new modification commitment and its state have nothing to do whit final resopnse of Re-INVITE, the session state is clear." And I mentioned this in the draft. 
	
	I MUST point out that rule two is the way to get rid of a new modification while the orignal one in pending state. It is a choice, but not a constraint. 
	
	Gaoyang 

2009-02-17 21:50 

收件人

	John 

	
	Hi, 

	  
	  
	Regards, 
	  
	Christer

---

From: [email-masked]
Date: Wed, 18 Feb 2009 22:37:19 +0800

Dear Christer Holmberg

In my draft, Offer/Answer pair is the smallest transaction. I do not 
prefer to divide it into m lines commitment separately.

And in RFC3264, there is no definition of transaction smaller than 
Offer/Answer pair, so I use Offer/Answer pair as the base of nested 
transaction.

Your understanding is much near ours :)

For the reason I mentioned above, the commitment of session modification 
should be together for all m-lines of one Offer/Answer.
And if the Offer/Answer is by UPDATE/200OK, and it is a new modification, 
your presentation is correct. And we have the same understanding of 
semantics of "a new modification from the previous one".

But if the Offer/Answer is in Re-INVITE, such as Offer(in 
Re-INVITE)/Answer(in 18x) or Offer(in 18x)/Answer(in PRACK), so this 
Offer/Answer(or say this modification) is triggered by Re-INVITE. And 2xx 
of Re-INVITE is the late commitment of this modification. This is the 
property I called "late commitment of 200OK of Re-INVITE", which is 
defined in RFC3261 and emphasized again in RFC3311. It is really necessary 
for user's rejecting of session modification. So, this case, the 
modification need rollback.

And if there is not new modification (such as the one in UPDATE/200OK), 
and the new one committed, the previous one(triggered by Re-INVITE) will 
be discarded, no matter the final response. And curently, if the 
Offer/Answer in UPDATE/200OK is not precondition notification, it would be 
a new modification. And this obeys the issue 3GPP concerns.

Gaoyang

2009-02-18 18:56

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

主题
[Sipping] About "rollback of re-Invite" - case with precondition and 
non-precondition

Hi,

 
Issue 1:
-----------
 
Assume I send a re-INVITE. I have two m- lines. For one of the m- line 
changes I use preconditions, and for the other m- line change I do NOT use 
preconditions.
 
Then I receive a relaible 18x, and the first offer/answer transaction has 
succeeded.
 
Then the re-INVITE fails. Now, according to the ZTE proposal, the 
precondition m- line is falled back to the value before the re-INVITE was 
changed. The non-precondition m- line is not falled back, however, since 
the change was comitted in the re-INVITE/18x o/a transaction.
 
So, we can NOT say that the whole SDP will be falled back to the state 
before the re-INVITE was sent. The precondition m- line is falled back, 
but the non-precondition m- line is NOT falled back.

Regards,
 
Christer

 

From: [email-masked] [mailto:[email-masked]] 
Sent: 18. helmikuuta 2009 2:46
To: Elwell, John
Cc: Christer Holmberg; [email-masked]; [email-masked]; 
[email-masked]
Subject: 答复: Re: [Sipping] About "rollback of re-Invite"

Dear Elwell John 

1. Precondition uage 

Gaoyang 

收件人

John 

Hi, 

the rollback. 
restrict only 

  
Regards, 
  
Christer

---

From: [email-masked]
Date: Wed, 18 Feb 2009 22:42:28 +0800

Dear Christer Holmberg

Gaoyang

---

From: [email-masked]
Date: Wed, 18 Feb 2009 22:50:00 +0800

Hi Christer,

I agree with you, it's hard to forbid UPDATE outside re-INVITEs now.
As to find a perfect solution that solve all use-cases is difficult,
 I think we are nearly finding out the way to solve the rollback 
of re-INVITEs.

*UPDATEs have no SDP, they can coexist with re-INVITEs.
*UPDATEs have a new SDPs,not for pre-condition, 
  if no re-INVITE is processing, the update will be accepted correctly.
  if the UPDATEs is in one re-INVITE, and the re-INVITE is accepted at 
last,
       the UPDATEs will be accepted, but if the re-INVITE is rejected,then 

       the state recorded by the UPDATEs may be discarded incorrectly.

It may be a problem ,but as re-INVITE give people the right to reject the 
SDP carried by re-INVITE, re-INVITE is a preferred way to modify SDP.

regards
Eric.wang

"Christer Holmberg" <[email-masked]> 写于 2009-02-18 

with 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> > Christer Holmberg
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> > Christer Holmberg

system.

system.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Feb 2009 15:54:44 +0100

Hi, 

>In my draft, Offer/Answer pair is the smallest transaction. I do not prefer to divide 
>it into m lines commitment separately. 

Yes, but if one m- line uses preconditions, and the other doesn't, the failure of the re-INVITE may have different impacts on them. That is at least how I understand your proposal.

>And in RFC3264, there is no definition of transaction smaller than Offer/Answer pair, so I use Offer/Answer pair as the base of nested transaction. 

Sure. But you define different fallback rules for preconditions and non-preconditions, and you may have both those in a single offer/answer pair.
	
>For the reason I mentioned above, the commitment of session modification should be together for all m-lines of one Offer/Answer. 
>And if the Offer/Answer is by UPDATE/200OK, and it is a new modification, your presentation is correct. And we have the same understanding of semantics of "a new modification from the previous one". 
>	
>But if the Offer/Answer is in Re-INVITE, such as Offer(in Re-INVITE)/Answer(in 18x) or Offer(in 18x)/Answer(in PRACK), so this Offer/Answer(or say this modification) is triggered by Re-INVITE. And 2xx of Re-INVITE is the 
>late commitment of this modification. This is the property I called "late commitment of 200OK of Re-INVITE", which is defined in RFC3261 and emphasized again in RFC3311. It is really necessary for user's rejecting of 
>session modification. So, this case, the modification need rollback. 

Ok, so in this case there are no nested offer/answers - only a SINGLE offer/answer (re-INV/18x OR 18x/PRACK), and then the re-INVITE fails. Right?

>And if there is not new modification (such as the one in UPDATE/200OK), and the new one committed, the previous one(triggered by Re-INVITE) will be discarded, no matter the final response. And curently, if the 
>Offer/Answer in UPDATE/200OK is not precondition notification, it would be a new modification. And this obeys the issue 3GPP concerns. 

Again, for one m- line it may be a precondition notification, but for another m- line it may be a modification (or a copy of a previous modification which took place e.g in the re-INV/18x).

For example, for one m- line you may want to remove a codec, and for another m- line you may want to add a codec. You normally don't need preconditions to remove something, but the m- line where you add a codec may need preconditions.

Regards,

Christer

	Hi, 

	  
	Issue 1: 
	----------- 

	  

	  
	Regards, 
	  
	Christer 

	  

	

	Dear Elwell John 

	1. Precondition uage 

	

	
	Gaoyang 

	

	2009-02-17 21:50 

		收件人

	

	John 

	
	Hi, 

	 
	 
	Regards, 
	 
	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Feb 2009 20:24:04 +0100

Hi, 

  
Issue 2: 
----------- 
  
Assume I send a re-INVITE, and I use precondition. I modify the SDP, and
indicate that preconditions are not met.
  
Then I receive a relaible 18x, and the first offer/answer transaction
has succeeded. 
 
Later I send an UPDATE request, where I indicate that preconditions are
met.
 
Then I receive a 200 for the UPDATE, indicating that preconditions are
met also at the other end.

Then the re-INVITE fails. Now, according to the ZTE proposal, is there a
full fallback? The UPDATE was sent as part of the nested precondition
procedure, but the preconditions were fullfilled before the re-INVITE
failed?
 
Does it matter what the precondition state is when the re-INVITE fails,
or is there always a full fallback?
 
Regards,
 
Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 08:33:35 +0800

Hi Christer,

In my opinion,the re-INVITE should fallback to the state before the 
re-INVITE.
And it doesn't matter what the precodition state is. Because the re-INVITE 
is 
rejected,the state of its precondition state seems useless.

By limiting UDPATEs for new modification outside re-INVITE,we can find the
right state to fallback.

What do you think about this?

Best wishes,
Eric.wang

"Christer Holmberg" <[email-masked]> 写于 2009-02-19 
03:24:04:

> Assume I send a re-INVITE, and I use precondition. I modify the SDP,
> and indicate that preconditions are not met.
> 
met.
> 
> Then I receive a 200 for the UPDATE, indicating that preconditions 
> are met also at the other end.
> 
> Then the re-INVITE fails. Now, according to the ZTE proposal, is 
> there a full fallback? The UPDATE was sent as part of the nested 
> precondition procedure, but the preconditions were fullfilled before
> the re-INVITE failed?
> 
> Does it matter what the precondition state is when the re-INVITE 
> fails, or is there always a full fallback?
> 
> Regards,
> 
> Christer
>

---

From: [email-masked]
Date: Thu, 19 Feb 2009 09:38:39 +0800

Dear Christer Holmberg

Very nice question. Or say that it is important. It is about the fine 
semantics of suspending/resuming of session modification.

Considering the session modification with more than one preconditions. And 
there are more than one Offer/Answer pairs used as preconidtion 
notification(such as more than one UPDATE/200OK before final response of 
Re-INVITE).

The session modification would be suspended until all the precondition is 
OK. And at that time, the session modifcation resumed(just resumed, mot 
committed. Commitment may by other thing, such as "late commitment of 
200OK of Re-INVITE".). And at that time, the effect of all Offer/Answer 
pairs with precondition can be same as one Offer/Answer pair without 
precondition.

So, the rollback of session state with precondition would not according as 
precondition state.
And the two sides can have different precondition. Even if one side's 
preconditon OK and the other side is not, both sides would rollback.

Gaoyang

2009-02-19 03:24

收件人

主题
Re: [Sipping] About "rollback of re-Invite" - case with preconditions met 
when reINVITE fails

Hi, 

  
Issue 2: 
----------- 

 
 
Then I receive a 200 for the UPDATE, indicating that preconditions are met 
also at the other end.

Does it matter what the precondition state is when the re-INVITE fails, or 
is there always a full fallback?
 
Regards,
 
Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 10:21:35 +0800

This is further answer to "Issue 1". The orignal message is for "Sipping 
awaits moderator approval"(more 40KB).

So, I send it again. :)

Dear Christer Holmberg

One m- line uses preconditions, and the other doesn't is legitimate SDP in 
Offer/Answer pair.

But the semantics of suspending/resuming of session modification defined 
in RFC3312 is session level definition. So, any m-line with precondition 
would make the session with precondition. And RFC3264 do not define the 
ability of accepting/rejecting of m-line separately, so I think make 
Offer/Answer pair as the smallest transaction is adequate currently. And 
make m-line level accepting/rejecting/suspending/resuming is attractive 
for me, and I'd like to talk it(later).

But the new Offer/Answer pair can be treated as precondition notification 
of the previous modification only when its other parts of SDP without 
modification. So, removing/adding of codec in any m-line(precondition 
m-line or no-preconditon m-line) will make it beyond precondition 
notification. 

Gaoyang

---

From: [email-masked]
Date: Thu, 19 Feb 2009 11:25:03 +0800

Dear Christer Holmberg

It is really a good question. And I'd like to extend this question.

F3/F4 is the precondition notification(there can be other precondition 
notification between F2 and F3).

After F4, the precondition is OK and session modification is resumed. And 
at that time, the UA can show the session modification windows to the 
user. Or just commit the modification with 200OK of Re-INVITE(such as 
RFC5027(Security Preconditions) without user permition).

But if one UA send another UPDATE(F6) with the SDP just same as the 
precondition notification(version num +1), what will happen?

It is really legitimate message here, though we can hardly say what the UA 
send it for. And in theory, we need to show the session state.

In semantics of suspending/resuming of session modification, the session 
state after F5 is the same as the one after F2 without precondition. And 
what will happen if one side send F3.

Under my understanding, I think this behavior can be explained as the UA 
want to use the SDP immediately(and before F1, he did not have such 
imminency. Beacuse he can replace F1 with UPDATE if he have such 
imminency.)

The other side can reject it with 504 for example, can not accept it 
without the user's permition. But if it accept it, it just means 
commitment(this if obey the sender's imminency).

So, I think F6(Figure 1) and F3(Figure 2) are new modification, even 
though the SDPs are the same as the previous one. 
And it obeys the original explanation: the precondition notification in 
suspending state is part of the orignal modification.

What mentioned above is just by definition in RFC3312.

And there is a more situation: if the precondition notification with the 
orignal precondition OK and add another new precondition(it is legitimate, 
but unordinary). As the precondition of the session is still exist, the 
session is still in suspending state. And the one is precondition 
notification.

Waiting for your comments.

Gaoyang

Addenda:
 
Precondition(Figure 1)
   UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         | <- UPDATE request include state
       |-------------------->|    notification
       | F4 2xx UPT          |
       |<--------------------|
       |                     |
       | F5 180 ringing      |
       |<--------------------|
       | F6   UPDATE         | <- UPDATE request same as state
       |-------------------->|    notification
       | F7 2xx UPT          |
       |<--------------------|
       |                     |

Without Precondition(Figure 2)
  UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         | <- UPDATE request with same SDP as F1
       |-------------------->|
       | F4 2xx UPT/504      |
       |<--------------------|
       |                     |

收件人

主题

Hi, 

  
Issue 2: 
----------- 

 

 
 
Regards,
 
Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 12:19:04 +0800

Orignal description:

Chapter 8 of RFC3312:
When a UAS, acting as an answerer, cannot or is not willing to meet the 
preconditions in the offer, it SHOULD reject the offer by returning a 580 
(Precondition-Failure) response.

So, the precondition can be rejected for wishes of user or UA. So, 
modification of precondition itself(not precondition satisfied state) MUST 
be treated as a new modification. And it obeys the natural demand of one 
side to reject the other side's Offer with too much precondition. :)

As a new modification, the session state would be judge by the way as 
other new modification.

So the original description in the mail to Christer Holmberg is not 
correct. I apologize for that.

Gaoyang

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 19 Feb 2009 09:24:03 +0100

Hi,

>In my opinion,the re-INVITE should fallback to the state before the re-INVITE. 
>And it doesn't matter what the precodition state is. Because the re-INVITE is 

This issue does only talk about UPDATEs "inside" the re-INVITE.

Regards,

Christer

	
	"Christer Holmberg" <[email-masked]> 写于 2009-02-19 03:24:04:
	
	> Later I send an UPDATE request, where I indicate that preconditions are met. 
	>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 19 Feb 2009 09:34:23 +0100

Hi,

>One m- line uses preconditions, and the other doesn't is legitimate SDP in Offer/Answer pair. 

Yes, and that is why I raised the issue :)

>But the semantics of suspending/resuming of session modification defined in RFC3312 is session level definition. So, any m-line with precondition would make the session with precondition. 

>And RFC3264 do not define the ability of accepting/rejecting of m-line separately, so I think make Offer/Answer pair as the smallest transaction is adequate currently. And make m-line level 
>accepting/rejecting/suspending/resuming is attractive for me, and I'd like to talk it(later). 

Note that I am not talking about rejecting m- lines. All offer/answers succeed, but the question is related to the fallback when the re-INVITE fails.

>But the new Offer/Answer pair can be treated as precondition notification of the previous modification only when its other parts of SDP without modification. So, removing/adding of codec in any m-line(precondition m-line 
>or no-preconditon m-line) will make it beyond precondition notification. 

For the m- line which uses preconditions the offer/answer may be treated as a notification, but for the m- line which does NOT use preconditions it is more than that. So, in case of re-INVITE failure one needs to know whether the "fate" of the two m- lines are different.

Let's take an example:

The SDP before the re-INVITE:

m=audio codec1
m=video codec2

SDP offer in re-INVITE:

m=audio codec2
m=video codec9, precon=not met

SDP answer in 18x:

m=audio codec2
m=video codec9, precon=not met

Now, after this the audio m- line o/a should be comitted, because no preconditions were used.

SDP offer in UPDATE

m=audio codec2  		(No change)
m=video codec9, precon=met	("notification")

SDP answer in 200 (UPDATE)

m=audio codec2
m=video codec9, precon=met

4xx response to the re-INVITE.

Now, according to your proposal, the video m- line should be rolled back to codec2 (the state before the re-INVITE), since preconditions were used.

But, what happens to the audio m- line modfication?

Regards,

Christer

	

	2009-02-18 22:54 

		收件人
		<[email-masked]> 
		抄送
		<[email-masked]>, <[email-masked]> 
		主题
		RE: [Sipping] About "rollback of re-Invite" - case with precondition and non-precondition

	Hi, 

	

	

	

	Regards,
	
	Christer

	

	                Hi, 

	                  
	                Issue 1: 
	                ----------- 

	                  

	                  
	                Regards, 
	                  
	                Christer 

	                  

	                

	                Dear Elwell John 

	                1. Precondition uage 

	                

	                
	                Gaoyang 

	                
	
	                2009-02-17 21:50 

	                                 收件人

	                

	                John 

	
	                
	                Hi, 

	                 
	                 
	                Regards, 
	                 
	                Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 18:06:04 +0800

Dear Christer Holmberg

The audio should rollback. The reason is "late commitment of 200OK of 
Re-INVITE".

Make your example simple:

m=audio codec1

SDP offer in re-INVITE:

m=audio codec2

SDP answer in 18x:

m=audio codec2

And the session state should rollback to code1, too.

The reason is that 200OK(Re-INVITW) is the final commitment of the 
modification triggered by Re-INVITE. And this is defined in RFC3261, 
emphasized again in RFC3311.

Gaoyang

2009-02-19 16:34

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: RE: [Sipping] About "rollback of re-Invite" - case with precondition 
and non-precondition

Hi,

in RFC3312 is session level definition. So, any m-line with precondition 
would make the session with precondition. 

>And RFC3264 do not define the ability of accepting/rejecting of m-line 
separately, so I think make Offer/Answer pair as the smallest transaction 
is adequate currently. And make m-line level 
>accepting/rejecting/suspending/resuming is attractive for me, and I'd 
like to talk it(later). 

Note that I am not talking about rejecting m- lines. All offer/answers 
succeed, but the question is related to the fallback when the re-INVITE 
fails.

m-line 
>or no-preconditon m-line) will make it beyond precondition notification. 

For the m- line which uses preconditions the offer/answer may be treated 
as a notification, but for the m- line which does NOT use preconditions it 
is more than that. So, in case of re-INVITE failure one needs to know 
whether the "fate" of the two m- lines are different.

Let's take an example:

m=audio codec1
m=video codec2

SDP offer in re-INVITE:

m=audio codec2

SDP answer in 18x:

m=audio codec2

Now, after this the audio m- line o/a should be comitted, because no 
preconditions were used.

SDP offer in UPDATE

m=audio codec2

Now, according to your proposal, the video m- line should be rolled back 
to codec2 (the state before the re-INVITE), since preconditions were used.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 19 Feb 2009 11:09:03 +0100

Hi,
 
Maybe my example was bad.
 
What if the audio m- line is modified in one of the UPDATEs, and not in the re-INVITE.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 19. helmikuuta 2009 12:06
	To: Christer Holmberg
	Cc: [email-masked]; [email-masked]
	Subject: 答复: RE: RE: [Sipping] About "rollback of re-Invite" - case with precondition and non-precondition

	Dear Christer Holmberg 
	
	The audio should rollback. The reason is "late commitment of 200OK of Re-INVITE". 

	
	m=audio codec1
	
	SDP offer in re-INVITE:
	
	m=audio codec2

	SDP answer in 18x:
	
	m=audio codec2 

	
	The reason is that 200OK(Re-INVITW) is the final commitment of the modification triggered by Re-INVITE. And this is defined in RFC3261, emphasized again in RFC3311. 

	Gaoyang 

2009-02-19 16:34 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]> 
主题
RE: RE: [Sipping] About "rollback of re-Invite" - case with precondition and non-precondition

	Hi,

	

	

	Let's take an example:

	m=audio codec1
	m=video codec2
	
	SDP offer in re-INVITE:
	
	m=audio codec2

	SDP answer in 18x:
	
	m=audio codec2

	SDP offer in UPDATE

	
	m=audio codec2

	

	Regards,
	
	Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 18:24:46 +0800

Dear Christer Holmberg

If it is a new modification in UPDATE(no matter it is after Re-INVITE or 
during Re-INVITE), session modification would commit.

And there is a interesting thing: 
If the SDP in UPDATE has precondition, and the Offer/Answer has 
changed(UPDATE/200OK). What will happen?

o if its precondition is mandatory, I think the other side should reject 
it with 504.

o if its precondition is not mandatory, the other side can accept it. And 
in signal level, it would commit. But on one can assure the media level.
But I think the signal level should not take the responsibilty for that 
the precondition is not mandatory.

Gaoyang

2009-02-19 18:09

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: RE: RE: [Sipping] About "rollback of re-Invite" - case with 
precondition and non-precondition

Hi,

What if the audio m- line is modified in one of the UPDATEs, and not in 
the re-INVITE.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: 19. helmikuuta 2009 12:06
To: Christer Holmberg
Cc: [email-masked]; [email-masked]
Subject: 答复: RE: RE: [Sipping] About "rollback of re-Invite" - case with 
precondition and non-precondition

Dear Christer Holmberg 

m=audio codec1

SDP offer in re-INVITE:

m=audio codec2

SDP answer in 18x:

m=audio codec2 

Gaoyang 

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

Hi,

Let's take an example:

m=audio codec1
m=video codec2

SDP offer in re-INVITE:

m=audio codec2

SDP answer in 18x:

m=audio codec2

SDP offer in UPDATE

m=audio codec2

Regards,

Christer

---

From: [email-masked]
Date: Thu, 19 Feb 2009 19:11:40 +0800

Dear Christer Holmberg

Perphas you are trying to find a case, in which modification of part of 
the m-lines commit, and the others rollback.

I tried to do the same thing :).

Based on chapter 3.2(of the draft), in transaction level, "late commitment 
of 200OK of Re-INVITE" contains "precondition".
So the m-lines without preconditon is committed in semantics of 
precondition level. And the m-lines with precondition can only be 
committed after the preconidtion notification.
But the modification of all of the m-lins can only be committed after 
200OK(Re-INVITE) in semantics of "late commitment of 200OK of Re-INVITE" 
level.
So, the final commitment or rollback of the modification triggered by 
Re-INVITE is same for all the m-lins(no matter with precondition or 
without preconditin).

And for modification triggered by UPDATE, the thing is interesting. And I 
explain something in the previous mail :).

Gaoyang

---

From: [email-masked]
Date: Thu, 19 Feb 2009 19:54:02 +0800

Hi，

I agree, we should find a way cover all use-cases.

Firstly, i think, we should try to find a way  to solve all problem in 
certain 
terms, and then make the way as a suggestion. 

   Just as the words in RFC3311:
   ""Although UPDATE can be used on confirmed
   dialogs, it is RECOMMENDED that a re-INVITE be used instead.""

Secondly, we use the finding way to all use-cases, and enrich the way with
some patches in order to let the suggested way cover all use-cases.

For UPDATEs and re-INVITEs, there are three common cases.

case 1: UPDATEs are for pre-condition in the re-INVITEs.
case 2: UPDATEs are new modifications outside the re-INVITEs.
case 3: UPDATEs are new modifications just during the re-INVITEs,
    but obey the offer/answer model.

Followed are solutions for the above three case.

case 1: It's just a pre-condition notification, if failure happens, 
    rollback to the state before the re-INVITE.

case 2: This UPDATE can be distinguished from others easily, and should
    refresh the state if successful, and remain the state just before
    UDPATE if failure.

case 3: We should record the state if negotiation is successful,and 
rollback
    to the state before UPDATE if failure happens.

    And there is a rule: if both UPDATE and re-INVITE success, we should 
    record the state commited by UPDATE. if UPDATE successes and re-INVITE 
fails,
    we should record the state commited by UPDATE. if UPDATE fails and 
re-INVITE
    successes ,we should record the state commited by re-INVITE.If both 
fail,
    we should rollback the state before re-INVITE.
 
    This case is also mentioned in 
"draft-gaoyang-sipping-session-state-criterion-01"
    4.3.1  Problem.

From above, UPDATEs outside re-INVITEs make the solution much more 
difficult,
we have to find which UPDATEs are for notifications and which are not. We 
should
determine which state to commit when both success.Also if UDPATEs can be 
raised at
any time ,more 491 and 500+retry will be found, and so on.

So i suggest UPDATEs with SDP should better be replaced by re-INVITE，but 
that not
means forbidden，just a suggestion.
And there also are solutions to solve all UPDATEs.

Begards,

Eric.wang

16:24:03:

>    ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail
system.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 20 Feb 2009 09:47:20 +0100

Hi,

>Very nice question. Or say that it is important. It is about the fine semantics of suspending/resuming of session modification. 
>	
>Considering the session modification with more than one preconditions. And there are more than one Offer/Answer pairs used as preconidtion notification(such as more than one UPDATE/200OK before final response of Re-
>INVITE). 
>	
>The session modification would be suspended until all the precondition is OK. And at that time, the session modifcation resumed(just resumed, mot committed. Commitment may by other thing, such as "late commitment of 200OK 
>of Re-INVITE".). And at that time, the effect of all Offer/Answer pairs with precondition can be same as one Offer/Answer pair without precondition. 

I thought that your proposal is that offer/answers without preconditions are committed immediately, so a re-INVITE would not affect them?
	
>So, the rollback of session state with precondition would not according as precondition state. 
>And the two sides can have different precondition. Even if one side's preconditon OK and the other side is not, both sides would rollback. 

That would have been my follow-up question :)

Regards,

Christer

	

	2009-02-19 03:24 

		收件人
		
		主题
		Re: [Sipping] About "rollback of re-Invite" - case with preconditions met when reINVITE fails

	Hi, 

	 
	Issue 2: 
	----------- 
	 
	Assume I send a re-INVITE, and I use precondition. I modify the SDP, and indicate that preconditions are not met.

	  
	Then I receive a 200 for the UPDATE, indicating that preconditions are met also at the other end. 
	
	Then the re-INVITE fails. Now, according to the ZTE proposal, is there a full fallback? The UPDATE was sent as part of the nested precondition procedure, but the preconditions were fullfilled before the re-INVITE failed? 
	  
	Does it matter what the precondition state is when the re-INVITE fails, or is there always a full fallback? 
	  
	Regards, 
	  
	Christer

---

From: [email-masked]
Date: Fri, 20 Feb 2009 17:04:03 +0800

Dear Christer Holmberg

The "Precondition" and "Late commitment of Re-INVITE 200OK" are all 
(nested) transaction. And nested transaction can be combined to form 
bigger nested transaction.

The level(or say nested rule) is in Chapter 3.2 of the draft. "Late 
commitment of Re-INVITE 200OK" contain "Precondition".

So the modification with precondition triggered by Re-INVITE can be in a 
static state in the semantics of "Precondition", but it is still in 
pending state in the semantics of "Late commitment of Re-INVITE 200OK". 

So, the unsuccessful Re-INVITE will make modification in static state in 
the semantics of "Precondition" rollback.

Gaoyang

2009-02-20 16:47

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: Re: [Sipping] About "rollback of re-Invite" - case with preconditions 
met when reINVITE fails

Hi,

> 
>Considering the session modification with more than one preconditions. 
And there are more than one Offer/Answer pairs used as preconidtion 
notification(such as more than one UPDATE/200OK before final response of 
Re-
200OK 
>of Re-INVITE".). And at that time, the effect of all Offer/Answer pairs 
with precondition can be same as one Offer/Answer pair without 
precondition. 

I thought that your proposal is that offer/answers without preconditions 
are committed immediately, so a re-INVITE would not affect them?

Regards,

Christer

 

                 2009-02-19 03:24 

                                 收件人
                                 <[email-masked]>, 
<[email-masked]>, <[email-masked]> 
                                 抄送
 
                                 主题
                                 Re: [Sipping] About "rollback of 
re-Invite" - case with preconditions met when reINVITE fails

                 Hi, 

                 There are some issues that needs to be taken into 
consideration. 
 
                 Issue 2: 
                 ----------- 
 
                 Assume I send a re-INVITE, and I use precondition. I 
modify the SDP, and indicate that preconditions are not met.
 
                 Then I receive a relaible 18x, and the first offer/answer 
transaction has succeeded. 
 
                 Later I send an UPDATE request, where I indicate that 
preconditions are met. 
 
                 Then I receive a 200 for the UPDATE, indicating that 
preconditions are met also at the other end. 
 
                 Then the re-INVITE fails. Now, according to the ZTE 
proposal, is there a full fallback? The UPDATE was sent as part of the 
nested precondition procedure, but the preconditions were fullfilled 
before the re-INVITE failed? 
 
                 Does it matter what the precondition state is when the 
re-INVITE fails, or is there always a full fallback? 
 
                 Regards, 
 
                 Christer 

                 --------------------------------------------------------
                 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.