Subject: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 1 Mar 2009 22:30:56 +0100

Hi Hadriel,

I guess Gonzalo will provide his summary soon, but I don't think there
is currently a disagreement regarding pre-conditions. You call them
"conditional offers", Gao calls them "notifications", but that's just
wording... :)

I think the one of the main issues at the moment is what happens after
preconditions have been met on both sides:

1) Is the change now commited/in-use, and a re-INVITE failure would not
change that?                                       <----- "in-use"
alternative

OR

2) Would a re-INVITE failure cause a fallback (this is what is meant by
"late commitment")?                                <---- "late
commitment" alternative

If preconditions have NOT been met, and the re-INVITE fails, I think
most agree that there will be a rollback to the "last committed state".

Gao's draft also talk about other changes which would not be considered
as "real" SDP offers, for example if you reduce codecs. But, at least I
strongly prefer NOT to go into such details, because that would for sure
cause interop issues. I am not sure what Gao's view on that is at the
moment, though?

Regarding the race condition, I think we can avoid that with some BCP-
and guidance text.

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, February 28, 2009 5:26 PM
To: Christer Holmberg; Gonzalo Camarillo; sipping
Subject: Summary of Closing the offer/answer rollback issue?

Is there an email in this long thread that summarizes the issues?
It's impossible to follow this thread. :)

I'm not clear on what the issues are with pre-conditions that make
failed offers concept break.  To me, pre-conditions are basically not
real SDP offers; they're conditional offers.  Until the *all* the
conditions are met, it's not "committed".  You continue using the last
committed state.  I know there are race conditions, but considering how
rare pre-conditions are in the real world (especially in re-Invite's),
that I'm having trouble imagining why we should care about corner cases
of such.  Regardless, I vote for any fixing that needs to happen because
of pre-conditions should be around changing pre-condition logic, even if
it means completely re-writing how pre-conditions works - don't change
normal SIP or SDP. (not that anyone is proposing it, I just can't tell
form this thread)

Re-Invites and SDP offer/answer have so many interop issues in the wild
even without pre-conditions, that this whole thread scares me. :(

-hadriel

---

From: [email-masked]
Date: Mon, 2 Mar 2009 11:46:39 +0800

My draft is open for evolution and extension. My view is that: 

Considering RFCs, "refine codecs" is "a new modification". And if some 
one(org/operator/internal usage) think "refine codecs" is part of the 
original modification. It still can assure its session state by nested 
transaction concept.

Some custom-built one really treated it as part of the original 
modification.

"Christer Holmberg" <[email-masked]> 
发件人:  [email-masked]
2009-03-02 05:30

收件人
"Hadriel Kaplan" <[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>, "sipping" <[email-masked]>
抄送

主题
Re: [Sipping] Summary of Closing the offer/answer rollback issue?

Hi Hadriel,

OR

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, February 28, 2009 5:26 PM
To: Christer Holmberg; Gonzalo Camarillo; sipping
Subject: Summary of Closing the offer/answer rollback issue?

-hadriel

_______________________________________________
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

--------------------------------------------------------
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: Hadriel Kaplan <[email-masked]>
Date: Sun, 1 Mar 2009 23:33:50 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Sunday, March 01, 2009 4:31 PM
>

Ahh.  Well if that's the issue, I vote for doing exactly whatever would happen if a normal (non-pre-conditional) SDP offer/answer is exchanged and the re-INVITE fails.  I have absolutely no idea what that would be, but it should be the same. :)
(I mean I know what 3261 says, that it reverts all the way back, but I have no idea if that's actually what most people do)

If I had my druthers the SDP change would stick (not revert), because I personally think it's cleaner, but I can see an argument for both ways.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 07:18:02 +0100

Hi, 

alternative
commitment" alternative
> 
>Ahh.  Well if that's the issue, I vote for doing exactly 
>whatever would happen if a normal (non-pre-conditional) SDP 
>offer/answer is exchanged and the re-INVITE fails.  I have 
>absolutely no idea what that would be, but it should be the 
>same. :) (I mean I know what 3261 says, that it reverts all 
>the way back, but I have no idea if that's actually what most 
>people do)

Sure, the issue is valid also for non pre-condition use-cases.

For example.

The UAC sends an SDP offer in a re-INVITE, and receives an SDP answer in
a reliable 18x. But, then what happens when the re-INVITE fails?

OR

>If I had my druthers the SDP change would stick (not revert), 
>because I personally think it's cleaner, but I can see an 
>argument for both ways.

Yes.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 07:21:44 +0100

Hi,
 
Again, I strongly do NOT think we should choose an "evolution and extension" approach, and let organizations decide what is a new modification, and what isn't. Again, you can have entities which belong to DIFFERENT organizations´communicating with each other, and those should have a common understanding of the rules.
 
If you have a closed network, where you know that every entity belongs to a single organization, you can of course do whatever you want. But, in that case you don't need to standardize it.
 
Regards,
 
Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 2. maaliskuuta 2009 5:47
	To: Christer Holmberg
	Cc: Gonzalo Camarillo; Hadriel Kaplan; sipping; [email-masked]
	Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Considering RFCs, "refine codecs" is "a new modification". And if some one(org/operator/internal usage) think "refine codecs" is part of the original modification. It still can assure its session state by nested transaction concept. 
	
	Some custom-built one really treated it as part of the original modification. 

2009-03-02 05:30 

收件人
"Hadriel Kaplan" <[email-masked]>, "Gonzalo Camarillo" <[email-masked]>, "sipping" <[email-masked]> 
抄送
主题
Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Hi Hadriel,

	
	
	OR

	Regards,
	
	Christer

	-----Original Message-----
	From: Hadriel Kaplan [mailto:[email-masked]] 
	Sent: Saturday, February 28, 2009 5:26 PM
	To: Christer Holmberg; Gonzalo Camarillo; sipping
	Subject: Summary of Closing the offer/answer rollback issue?

	
	
	-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 07:30:56 +0100

>Then that is: Considering RFCs, "refine codecs" is "a new modification". 
>	
>Not considering "evolution and extension", it is still a solution without any violation of RFCs. 

Yes, but that was not the point. I am trying to figure out what the differences between the proposals are.

So, again: is the "late commitment" currently the ONLY difference between yours and Gonzalo's proposals, or is there something else?

Regards,

Christer

	

	2009-03-02 14:21 

		收件人
		<[email-masked]> 
		抄送
		"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "sipping" <[email-masked]>, <[email-masked]> 
		主题
		RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Hi, 

	  
	Regards, 
	  
	Christer 

	

	

	2009-03-02 05:30 

		收件人
		
		主题

	

	Hi Hadriel,

	
	
	OR

	Regards,
	
	Christer

	-----Original Message-----
	From: Hadriel Kaplan [mailto:[email-masked]] 
	Sent: Saturday, February 28, 2009 5:26 PM
	To: Christer Holmberg; Gonzalo Camarillo; sipping
	Subject: Summary of Closing the offer/answer rollback issue?

	
	
	-hadriel

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 2 Mar 2009 02:00:30 -0500

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>Sent: Monday, March 02, 2009 11:48 AM
>To: Hadriel Kaplan; Gonzalo Camarillo; sipping
>Subject: Re: [Sipping] Summary of Closing the offer/answer 
>rollback issue?
>
>
>Hi, 
>
>whatever would 
>>happen if a normal (non-pre-conditional) SDP offer/answer is 
>exchanged 
>>and the re-INVITE fails.  I have absolutely no idea what that 
>would be, 
>>but it should be the same. :) (I mean I know what 3261 says, that it 
>>reverts all the way back, but I have no idea if that's actually what 
>>most people do)
>
>The UAC sends an SDP offer in a re-INVITE, and receives an SDP 
>answer in a reliable 18x. But, then what happens when the 
>re-INVITE fails?

To complicate it even futher, there may be some UPDATE transacations
with sdp between the two endpoints in session, before there is a final
response to re-Invite. 
Since the transaction is complete in media plane, I think it should stay
even if actual signaling transacation finally fails. And that's not what
RFC 3261 says.

Sanjay

>because I 
>>personally think it's cleaner, but I can see an argument for 
>both ways.
>
>Yes.
>
>Regards,
>
>Christer
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 08:00:53 +0100

>[Gao] Yes. 
>But what I think important for "evolution and extension" is nested transaction. And if using something like "a= chain"(RFC3108) in Offer/Answer, nested transaction concept can be more 
>effective.

Yes, but we can have "something likes" - we need clear rules.

>[Gao] IMO, "Late commitment" is the most important branching for current SIP/SDP usage. 

That is not what I asked.

Regards,

Christer

                

                2009-03-02 14:21 

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

                Hi, 

                  
                Regards, 
                  
                Christer 

                

                

                2009-03-02 05:30 

                                 收件人
                                 
                                 主题

                

                Hi Hadriel,

                
                
                OR

                Regards,
                
                Christer

                -----Original Message-----

                
                
                -hadriel

---

From: [email-masked]
Date: Mon, 2 Mar 2009 15:09:20 +0800

"Sanjay Sinha (sanjsinh)" <[email-masked]> 
发件人:  [email-masked]
2009-03-02 15:00

收件人
"Christer Holmberg" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>, "sipping" <[email-masked]>
抄送

主题

[Gao] Yes.

IMO:

Modification triggered by Re-INVITE MUST rollback as the failure of 
Re-INVITE.  --That is the original concept of RFC3261

Any committed new modification during Re-INVITE with other SIP 
transaction, would have nothing to do with the Re-INVITE's failure or 
success.  --That is the original concept of RFC3311.

Do you think so?

Sanjay

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 09:17:34 +0100

Hi,
 
Regarding "committed new modification during Re-INVITE", I don't think there is a difference between yours and Gonzalo's proposal, right?
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 2. maaliskuuta 2009 9:09
	To: Sanjay Sinha (sanjsinh)
	Cc: Christer Holmberg; Gonzalo Camarillo; Hadriel Kaplan; sipping; [email-masked]
	Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

2009-03-02 15:00 

收件人
"Christer Holmberg" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Gonzalo Camarillo" <[email-masked]>, "sipping" <[email-masked]> 
抄送
主题
Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	

	[Gao] Yes. 
	
	IMO: 
	
	Modification triggered by Re-INVITE MUST rollback as the failure of Re-INVITE.  --That is the original concept of RFC3261 
	
	Any committed new modification during Re-INVITE with other SIP transaction, would have nothing to do with the Re-INVITE's failure or success.  --That is the original concept of RFC3311. 
	
	Do you think so? 

	Sanjay

---

From: [email-masked]
Date: Mon, 2 Mar 2009 16:36:41 +0800

2009-03-02 16:17

收件人
<[email-masked]>, "Sanjay Sinha (sanjsinh)" <[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]>
主题
RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

Hi,
 
Regarding "committed new modification during Re-INVITE", I don't think 
there is a difference between yours and Gonzalo's proposal, right?

[Gao] Yes. But the deducing process is not same:

By my proposal, it is committed because it is a new modification. And it 
can not be rollback by the unsuccess of original pending modification. So, 
it is commited.

By Gonzalo's, any "in use" modification can not be rollback. So, it is 
committed.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: 2. maaliskuuta 2009 9:09
To: Sanjay Sinha (sanjsinh)
Cc: Christer Holmberg; Gonzalo Camarillo; Hadriel Kaplan; sipping; 
[email-masked]
Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback 
issue?

收件人

主题

[Gao] Yes. 

IMO: 

Do you think so? 

Sanjay

--------------------------------------------------------
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, 2 Mar 2009 09:37:35 +0100

Hi, 

>I think so now. And you can ask Gonzalo if he think it is the only branching. 
>	
>But I want to know that if I or someone else find new branching, can it be talked? 

I am not sure what you mean by "be talked", but I think we need a full picture of the alternatives, and the difference between them.

Regards,

Christer

	

	2009-03-02 15:00 

		收件人
		<[email-masked]> 
		抄送
		"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "sipping" <[email-masked]>, <[email-masked]> 
		主题
		RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	

	
	Regards,
	
	Christer

	               

	               2009-03-02 14:21 

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

	
	               Hi, 

	                 
	               Regards, 
	                 
	               Christer 

	               

	               

	               2009-03-02 05:30 

	                                收件人
	                                
	                                主题

	               

	               Hi Hadriel,

	               
	               
	               OR

	               Regards,
	               
	               Christer

	               -----Original Message-----

	               
	               
	               -hadriel

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 02 Mar 2009 18:43:49 +0900

Hi,

The following table describes my understanding.
Is this right?

signaling            | O/A state                      | media in use
---------------------+--------------------------------+--------------
init-INVITE/200/ACK  | audio1(met)                    | audio1
re-INVITE/183-rel    | audio2(notmet)                 | audio1
(PRACK/200OK)        | audio2(met)    +video1(notmet) | audio2
UPDATE/200OK         | audio2(met)    +video1(met)    | audio2+video1
UPDATE/200OK         | audio2(met)    +video2(notmet) | audio2+video1
4xx/ACK              |                                |
  Gonzalo's proposal | audio2         +video1         |
  Gao's proposal     | audio1         +video1(?)      |

Regards,
Shinji

---

From: [email-masked]
Date: Mon, 2 Mar 2009 18:21:20 +0800

UPDATE/200OK         | audio2(met)    +video2(notmet) | 

This is a new modification request with precondition, not a precondition 
notification. And as RFC3311, if the other side can not accept it at once, 
it should reject the modification request by 504. So, I think it(the 
UPDATE) should be rejected here.

Then, let's taklk if the other side accept it, what will happen.

IMO, commitment of UPDATE/200OK with a new modification MUST be rollback, 
as the new modification has nothing to do with the original modification 
triggered by Re-INVITE. Accepting the new modification request by UPDATE 
is a radical behaviour, but it should be responsible for it.

And this modification committed all its media type, audio2 and vedio2.

And it should be pointed out that UPDATE/200OK with new modification 
during or outside Re-INVITE should have the same effect.

Question:

If the same UPDATE/200OK is outside Re-INVITE. My proposal's state is 
audio2 and vedio2.

And what is Gonzalo Camarillo's proposal's state.

OKUMURA Shinji <[email-masked]> 
2009-03-02 17:43

收件人
sipping <[email-masked]>
抄送
"Christer Holmberg" <[email-masked]>, 
[email-masked], Gonzalo Camarillo <[email-masked]>
主题
Re: [Sipping] Summary of Closing the offer/answer rollback issue?

Hi,

Regards,
Shinji

---

From: [email-masked]
Date: Mon, 2 Mar 2009 18:27:02 +0800

Explanation for Precondition notification

Precondition notification can be treated as part of the original 
modification triggered by Re-INVITE.

And only SDP with Precondition notification and without any other 
modification of session, during suspending state of session
modification, is called precondition notification.

收件人

Hi,

Regards,
Shinji

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 2 Mar 2009 11:56:28 +0100

Shinji,

The summary that you have given provides a simple view of the issues.

It does however highlight some other issues which need to be clarified.

If I assume that your use of met/notmet refers to precondition
negotiation then the sequence you have described highlights some
specific issues.

Here is a numbered copy of your sequence:

   signaling            | O/A state                      | media in use
   ---------------------+--------------------------------+--------------
1. init-INVITE/200/ACK  | audio1(met)                    | audio1
2. re-INVITE/183-rel    | audio2(notmet)                 | audio1
3. (PRACK/200OK)        | audio2(met)    +video1(notmet) | audio2
4. UPDATE/200OK         | audio2(met)    +video1(met)    | audio2+video1
5. UPDATE/200OK         | audio2(met)    +video2(notmet) | audio2+video1
   4xx/ACK              |                                |
     Gonzalo's proposal | audio2         +video1         |
     Gao's proposal     | audio1         +video1(?)      |

1. This is OK. The original SDP offer/answer is agreed.

2. In the re-INVITE the audio stream is being modified in some way. How
this is being modified will result in whether preconditions are
required.

3. This creates an issue. The PRACK has made a new SDP offer as part of
the precondition notification AND has also added a new media stream.

I am unsure if this should be allowed during a precondition negotiation.
Technically it is allowed but is does cloud the issue. Gao has stated in
a separate response that the UPDATE (5.) should be rejected 504, and I
agree with this, but as 3. is a PRACK I am unsure how this modified
offer can be rejected. I would think that the receiving UA should reject
the re-INVITE at this point.

A simpler scenario would be:

signaling            | O/A state                      | media in use
---------------------+--------------------------------+--------------
init-INVITE/200/ACK  | audio1(met)                    | audio1
re-INVITE/183-rel    | audio1(met)    +video1(notmet) | audio1
(PRACK/200OK)        | [no sdp]                       | audio1
UPDATE/200OK         | audio1(met)    +video1(met)    | audio1+video1
4xx/ACK              |                                |
Gonzalo's proposal(?)| audio1         +video1         |
Gao's proposal(?)    | audio1                         |

I think that the end state should be to return the media back to state
in which it was prior to the re-INVITE. 

The question is how.

The other issue that you have raised concerning new modification of the
SDP during the precondition modification also needs to be addressed. My
belief is that this modification should be rejected. If the UPDATE with
this modification crosses with the 4xx to the re-INVITE then we are back
to the original issue from section 6.2 of the offeranswer draft. How
does the UAS determine that this transaction is associated with the
original re-INVITE or is a separate standalone transaction?

Offer/answer 5 in your original sequence is a modification to an agreed
media stream and requires new precondition negotiation. While
technically this is possible using UPDATE transactions I do not believe
that this should be allowed. Any SDP modification using preconditions
should require use of a re-INVITE.

Ian Elz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of OKUMURA Shinji
Sent: 02 March 2009 09:44
To: sipping
Cc: Gonzalo Camarillo; Christer Holmberg
Subject: Re: [Sipping] Summary of Closing the offer/answer rollback
issue?

Hi,

Regards,
Shinji

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 12:02:54 +0100

Hi, 

>Precondition notification can be treated as part of the original modification triggered by Re-INVITE. 
>	
>And only SDP with Precondition notification and without any other modification of session, during suspending state of session 

So, what if I e.g. Also do a "codec refine" inside a precondition notficiation?

Regards,

Christer

	2009-03-02 17:43 

		收件人
		sipping <[email-masked]> 
		抄送
		"Christer Holmberg" <[email-masked]>, [email-masked], Gonzalo Camarillo <[email-masked]> 
		主题
		Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Hi,

	Regards,
	Shinji

---

From: gaoyang <[email-masked]>
Date: Mon, 2 Mar 2009 13:31:51 +0000

1.

The question is same as asking whether "refine codec" is a new modification or just part of the original modification.

By RFCs, it is a new modification. But I can not stop other people to treat as part of the original modification.

If "refine codec" is a new modification by UPDATE/200OK, its commitment will go on and without rollback.

If "refine codec" is part of the original modification, it will rollback for the faillure the original modification.

Not matter by which point of view, the session state is all clear. 

2.

I have no right to decide it("refine codec") alone.

If people want to reach a consensus to this point, we can talk further. 

If ask my personal view, I can accept:

2.1 treat it as new modification. or

2.2 treat it as part of the original modification, but "protected" by precondition.

Why "protected" by precondition?

By RFCs it is new modification at all, and as to make it part of the original modification, we should have semantics of suspending/resuming modification.

How "protected" by precondition?

We can define that only use "refine codec" in suspending state of QoS precondition.

IMO, it is better to define a new precondition type for "refine codec".

> Date: Mon, 2 Mar 2009 12:02:54 +0100
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Summary of Closing the offer/answer rollback issue?
> 
> 
> Hi, 
> 
> 

_________________________________________________________________
上Windows Live 中国首页，下载最新版 MSN！
http://im.live.cn/

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 14:45:10 +0100

Hi,
 
As we know, sometimes when you use preconditions you may do some modifications for a stream, in ADDITION to simply change the precondition status. I guess the most typical example is codec refine, ie you reduce the sets of codecs when it's know what both ends support.
 
Wouldn't it be possible to say that whatever change is done for a stream, if the the re-INVITE fails before the preconditions have been met everything will be rolled back for that stream?
 
So, if I send an UPDATE and remove a codec, while preconditions still haven't been met, that codec change would also be rolled back if the re-INVITE fails.

SDP before re-INVITE  audio-codec = 4

----- re-INVITE       audio-codec = 1,2,3       precon = not_met   --- >
<---- 18x             audio-codec = 1,2,3   	precon = not_met   -----
----- UPDATE          audio-codec = 1           precon = not_met   ---->       //codec refine
<---- 200             audio-codec = 1           precon = not_met   -----

<---- 4xx --------------------------------------------------------------

SDP after re-INVITE	 audio-codec = 4

Regards,
 
Christer

	From: gaoyang [mailto:[email-masked]] 
	Sent: 2. maaliskuuta 2009 15:32
	To: Christer Holmberg; [email-masked]; [email-masked]
	Cc: [email-masked]; Gonzalo Camarillo
	Subject: RE: [Sipping] Summary of Closing the offer/answer rollback issue?

	1.

	 
	2.

	 

	> UPDATE/200OK | audio2(met) +video2(notm et) | audio2+video1
	> 4xx/ACK | |
	> < BR>> 

	微软地图实时路况，为您节省的不仅仅是时间！ 立即查看！ <http://ditu.live.com/default.aspx?v=2&form=MICHAJ&cp=qcbgzzsz1gzz&style=r&lvl=4&tilt=-90&dir=0&alt=-1000&phx=0&phy=0&phscl=1&trfc=1&encType=1>

---

From: gaoyang <[email-masked]>
Date: Mon, 2 Mar 2009 14:15:25 +0000

Comments inline.

> Date: Mon, 2 Mar 2009 14:45:10 +0100
> To: [email-masked]; [email-masked]; [email-masked]

[Gao] If all the Offer/Answer pairs during the suspending state are part of the original modification, it is.

But if there is a new modification, it is not.

> SDP after re-INVITE audio-codec = 4

[Gao] If treat "refine codec" as part of the original modification, it is.

_________________________________________________________________
Live Search视频搜索，快速检索视频的利器！
http://www.live.com/?scope=video

---

From: [email-masked]
Date: Mon, 2 Mar 2009 15:12:53 +0800

I think so now. And you can ask Gonzalo if he think it is the only 
branching.

But I want to know that if I or someone else find new branching, can it be 
talked?

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]>
主题
RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback 
issue?

>But what I think important for "evolution and extension" is nested 
transaction. And if using something like "a= chain"(RFC3108) in 
Offer/Answer, nested transaction concept can be more 

>So, again: is the "late commitment" currently the ONLY difference between 
yours and Gonzalo's proposals, or is there something else? 

Regards,

Christer

 

                2009-03-02 14:21 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 "Gonzalo Camarillo" 
<[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]> 
                                 主题
                                 RE: Re: [Sipping] Summary of Closing the 
offer/answer rollback issue?

                Hi, 
 
                Again, I strongly do NOT think we should choose an 
"evolution and extension" approach, and let organizations decide what is a 
new modification, and what isn't. Again, you can have entities which 
belong to DIFFERENT organizations´communicating with each other, and those 
should have a common understanding of the rules. 
 
                If you have a closed network, where you know that every 
entity belongs to a single organization, you can of course do whatever you 
want. But, in that case you don't need to standardize it. 
 
                Regards, 
 
                Christer 

                From: [email-masked] [mailto:[email-masked]] 
                Sent: 2. maaliskuuta 2009 5:47
                To: Christer Holmberg
                Cc: Gonzalo Camarillo; Hadriel Kaplan; sipping; 
[email-masked]
                Subject: 答复: Re: [Sipping] Summary of Closing the 
offer/answer rollback issue?

                My draft is open for evolution and extension. My view is 
that: 
 
                Considering RFCs, "refine codecs" is "a new modification". 
And if some one(org/operator/internal usage) think "refine codecs" is part 
of the original modification. It still can assure its session state by 
nested transaction concept. 
 
                Some custom-built one really treated it as part of the 
original modification. 

 

                2009-03-02 05:30 

                                 收件人
                                 "Hadriel Kaplan" 
 
                                 主题
                                 Re: [Sipping] Summary of Closing the 
offer/answer rollback issue?

 

                Hi Hadriel,
 
                I guess Gonzalo will provide his summary soon, but I don't 
think there
                is currently a disagreement regarding pre-conditions. You 
call them
                "conditional offers", Gao calls them "notifications", but 
that's just
                wording... :)
 
                I think the one of the main issues at the moment is what 
happens after
                preconditions have been met on both sides:
 
                1) Is the change now commited/in-use, and a re-INVITE 
failure would not
                change that?                                       <----- 
"in-use"
                alternative
 
                OR
 
                2) Would a re-INVITE failure cause a fallback (this is 
what is meant by
                "late commitment")?                                <---- 
"late
                commitment" alternative

                If preconditions have NOT been met, and the re-INVITE 
fails, I think
                most agree that there will be a rollback to the "last 
committed state".

                Gao's draft also talk about other changes which would not 
be considered
                as "real" SDP offers, for example if you reduce codecs. 
But, at least I
                strongly prefer NOT to go into such details, because that 
would for sure
                cause interop issues. I am not sure what Gao's view on 
that is at the
                moment, though?

                Regarding the race condition, I think we can avoid that 
with some BCP-
                and guidance text.

                Regards,
 
                Christer

                -----Original Message-----
                From: Hadriel Kaplan [mailto:[email-masked]] 
                Sent: Saturday, February 28, 2009 5:26 PM
                To: Christer Holmberg; Gonzalo Camarillo; sipping
                Subject: Summary of Closing the offer/answer rollback 
issue?

                Is there an email in this long thread that summarizes the 
issues?
                It's impossible to follow this thread. :)
 
                I'm not clear on what the issues are with pre-conditions 
that make
                failed offers concept break.  To me, pre-conditions are 
basically not
                real SDP offers; they're conditional offers.  Until the 
*all* the
                conditions are met, it's not "committed".  You continue 
using the last
                committed state.  I know there are race conditions, but 
considering how
                rare pre-conditions are in the real world (especially in 
re-Invite's),
                that I'm having trouble imagining why we should care about 
corner cases
                of such.  Regardless, I vote for any fixing that needs to 
happen because
                of pre-conditions should be around changing pre-condition 
logic, even if
                it means completely re-writing how pre-conditions works - 
don't change
                normal SIP or SDP. (not that anyone is proposing it, I 
just can't tell
                form this thread)
 
                Re-Invites and SDP offer/answer have so many interop 
issues in the wild
                even without pre-conditions, that this whole thread scares 
me. :(
 
                -hadriel
 
                _______________________________________________
                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

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

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

                 --------------------------------------------------------
                 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: [email-masked]
Date: Mon, 2 Mar 2009 14:37:41 +0800

2009-03-02 14:30

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]>
主题
RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

>Not considering "evolution and extension", it is still a solution without 
any violation of RFCs. 

Yes, but that was not the point. I am trying to figure out what the 
differences between the proposals are.

[Gao] Yes.

But what I think important for "evolution and extension" is nested 
transaction. And if using something like "a= chain"(RFC3108) in 
Offer/Answer, nested transaction concept can be more effective.

[Gao] IMO, "Late commitment" is the most important branching for current 
SIP/SDP usage.

Regards,

Christer

 

                 2009-03-02 14:21 

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

                 Hi, 

 
                 Regards, 
 
                 Christer 

 
                 Considering RFCs, "refine codecs" is "a new 
modification". And if some one(org/operator/internal usage) think "refine 
codecs" is part of the original modification. It still can assure its 
session state by nested transaction concept. 

 

                 2009-03-02 05:30 

                                 收件人
                                 "Hadriel Kaplan" 
 
                                 主题

 

                 Hi Hadriel,
 
                 I guess Gonzalo will provide his summary soon, but I 
don't think there
                 is currently a disagreement regarding pre-conditions. You 
call them
                 "conditional offers", Gao calls them "notifications", but 
that's just
                 wording... :)

 
                 OR

                 Regards,
 
                 Christer

                 -----Original Message-----

                 that I'm having trouble imagining why we should care 
about corner cases
 
                 Re-Invites and SDP offer/answer have so many interop 
issues in the wild
                 even without pre-conditions, that this whole thread 
scares me. :(
 
                 -hadriel
 
                 This list is for NEW development of the application of 
SIP

---

From: [email-masked]
Date: Mon, 2 Mar 2009 15:41:29 +0800

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

SIP/SDP usage. 

Regards,

Christer

 

                2009-03-02 14:21 

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

                Hi, 

 
                Regards, 
 
                Christer 

 

 

                2009-03-02 05:30 

                                 收件人
                                 "Hadriel Kaplan" 
 
                                 主题

 

                Hi Hadriel,

 
 
                OR

                Regards,
 
                Christer

                -----Original Message-----

 
 
                -hadriel

---

From: [email-masked]
Date: Mon, 2 Mar 2009 16:43:38 +0800

Yes. I also think we need the full picture.

I just want to know can we still modify the "picture" after its first 
"painting".

2009-03-02 16:37

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]>
主题
RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback 
issue?

Hi, 

branching. 
>But I want to know that if I or someone else find new branching, can it 
be talked? 

I am not sure what you mean by "be talked", but I think we need a full 
picture of the alternatives, and the difference between them.

Regards,

Christer

 

                 2009-03-02 15:00 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 "Gonzalo Camarillo" 
<[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]> 
                                 主题
                                 RE: RE: RE: Re: [Sipping] Summary of 
Closing the offer/answer rollback issue?

                 >>Not considering "evolution and extension", it is still 
a solution without any violation of RFCs. 
                 >
                 >Yes, but that was not the point. I am trying to figure 
out what the differences between the proposals are. 
                 >
                 >[Gao] Yes. 
                 >
                 >But what I think important for "evolution and extension" 
is nested transaction. And if using something like "a= chain"(RFC3108) in 
Offer/Answer, nested transaction concept can be more 
                 >effective.
 
                 Yes, but we can have "something likes" - we need clear 
rules.
 
                 >So, again: is the "late commitment" currently the ONLY 
difference between yours and Gonzalo's proposals, or is there something 
else? 

                 Regards,
 
                 Christer

 

                                "Christer Holmberg" 
<[email-masked]> 
 
                                2009-03-02 14:21 

                                                 收件人
                                                 <[email-masked]> 
                                                 抄送
                                                 "Gonzalo Camarillo" 
<[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]> 
                                                 主题
                                                 RE: Re: [Sipping] Summary 
of Closing the offer/answer rollback issue?

 
                                Hi, 
 
                                Again, I strongly do NOT think we should 
choose an "evolution and extension" approach, and let organizations decide 
what is a new modification, and what isn't. Again, you can have entities 
which belong to DIFFERENT organizations´communicating with each other, and 
those should have a common understanding of the rules. 
 
                                If you have a closed network, where you 
know that every entity belongs to a single organization, you can of course 
do whatever you want. But, in that case you don't need to standardize it. 
 
                                Regards, 
 
                                Christer 

                                From: [email-masked] 
[mailto:[email-masked]] 
                                Sent: 2. maaliskuuta 2009 5:47
                                To: Christer Holmberg
                                Cc: Gonzalo Camarillo; Hadriel Kaplan; 
sipping; [email-masked]
                                Subject: 答复: Re: [Sipping] Summary of 
Closing the offer/answer rollback issue?

                                My draft is open for evolution and 
extension. My view is that: 
 
                                Considering RFCs, "refine codecs" is "a 
new modification". And if some one(org/operator/internal usage) think 
"refine codecs" is part of the original modification. It still can assure 
its session state by nested transaction concept. 
 
                                Some custom-built one really treated it as 
part of the original modification. 

 
                                "Christer Holmberg" 
<[email-masked]> 
                                发件人:  [email-masked] 
 
                                2009-03-02 05:30 

                                                 收件人
                                                 "Hadriel Kaplan" 
 
                                                 主题
                                                 Re: [Sipping] Summary of 
Closing the offer/answer rollback issue?

 

                                Hi Hadriel,
 
                                I guess Gonzalo will provide his summary 
soon, but I don't think there
                                is currently a disagreement regarding 
pre-conditions. You call them
                                "conditional offers", Gao calls them 
"notifications", but that's just
                                wording... :)
 
                                I think the one of the main issues at the 
moment is what happens after
                                preconditions have been met on both sides:
 
                                1) Is the change now commited/in-use, and 
a re-INVITE failure would not
                                change that?         <----- "in-use"
                                alternative
 
                                OR
 
                                2) Would a re-INVITE failure cause a 
fallback (this is what is meant by
                                "late commitment")?         <---- "late
                                commitment" alternative

                                If preconditions have NOT been met, and 
the re-INVITE fails, I think
                                most agree that there will be a rollback 
to the "last committed state".

                                Gao's draft also talk about other changes 
which would not be considered
                                as "real" SDP offers, for example if you 
reduce codecs. But, at least I
                                strongly prefer NOT to go into such 
details, because that would for sure
                                cause interop issues. I am not sure what 
Gao's view on that is at the
                                moment, though?

                                Regarding the race condition, I think we 
can avoid that with some BCP-
                                and guidance text.

                                Regards,
 
                                Christer

                                -----Original Message-----
                                From: Hadriel Kaplan 
[mailto:[email-masked]] 
                                Sent: Saturday, February 28, 2009 5:26 PM
                                To: Christer Holmberg; Gonzalo Camarillo; 
sipping
                                Subject: Summary of Closing the 
offer/answer rollback issue?

                                Is there an email in this long thread that 
summarizes the issues?
                                It's impossible to follow this thread. :)
 
                                I'm not clear on what the issues are with 
pre-conditions that make
                                failed offers concept break.  To me, 
pre-conditions are basically not
                                real SDP offers; they're conditional 
offers.  Until the *all* the
                                conditions are met, it's not "committed". 
You continue using the last
                                committed state.  I know there are race 
conditions, but considering how
                                rare pre-conditions are in the real world 
(especially in re-Invite's),
                                that I'm having trouble imagining why we 
should care about corner cases
                                of such.  Regardless, I vote for any 
fixing that needs to happen because
                                of pre-conditions should be around 
changing pre-condition logic, even if
                                it means completely re-writing how 
pre-conditions works - don't change
                                normal SIP or SDP. (not that anyone is 
proposing it, I just can't tell
                                form this thread)
 
                                Re-Invites and SDP offer/answer have so 
many interop issues in the wild
                                even without pre-conditions, that this 
whole thread scares me. :(
 
                                -hadriel
 
 _______________________________________________
                                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

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

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

 
 --------------------------------------------------------
                                 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, 2 Mar 2009 09:47:01 +0100

In IETF pictures are normally modified (even re-painted) MANY times before something is finally agreed :)
 
However, in this case we need clear proposals.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 2. maaliskuuta 2009 10:44
	To: Christer Holmberg
	Cc: Gonzalo Camarillo; Hadriel Kaplan; sipping; [email-masked]
	Subject: 答复: RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	I just want to know can we still modify the "picture" after its first "painting". 

	

2009-03-02 16:37 

收件人
<[email-masked]> 
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "sipping" <[email-masked]>, <[email-masked]> 
主题
RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Hi, 

	
	Regards,
	
	Christer

	                

	                2009-03-02 15:00 

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

	

	                

	                Regards,
	                
	                Christer

	                               

	                               2009-03-02 14:21 

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

	                
	                               Hi, 

	                                 
	                               Regards, 
	                                 
	                               Christer 

	                               

	                               

	                               2009-03-02 05:30 

	                                                收件人
	                                                
	                                                主题

	                               

	                               Hi Hadriel,

	                               
	                               
	                               OR

	                               Regards,
	                               
	                               Christer

	                               -----Original Message-----

	                               
	                               
	                               -hadriel

---

From: [email-masked]
Date: Mon, 2 Mar 2009 16:53:55 +0800

Yes.

Then, could you define clearly for "in use" for Camarillo in the 
"picture". Last time you give one, but Camarillo asked me to concentrate 
on his.

2009-03-02 16:47

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" 
<[email-masked]>, "sipping" <[email-masked]>, 
<[email-masked]>
主题
RE: RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer 
rollback issue?

In IETF pictures are normally modified (even re-painted) MANY times before 
something is finally agreed :)

Regards,
 
Christer

Subject: 答复: RE: RE: RE: RE: Re: [Sipping] Summary of Closing the 

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

Hi, 

branching. 

Regards,

Christer

 

                2009-03-02 15:00 

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

 

 
                Regards,
 
                Christer

 

                               "Christer Holmberg" 
 
                               2009-03-02 14:21 

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

 
                               Hi, 

 
                               Regards, 
 
                               Christer 

 

 
 
                               "Christer Holmberg" 
 
                               2009-03-02 05:30 

                                                收件人
                                                "Hadriel Kaplan" 
 
                                                主题
                                                Re: [Sipping] Summary of 

 

                               Hi Hadriel,

 
                               1) Is the change now commited/in-use, and a 
re-INVITE failure would not
                               change that?        <----- "in-use"
                               alternative
 
                               OR

                               If preconditions have NOT been met, and the 
re-INVITE fails, I think
                               most agree that there will be a rollback to 
the "last committed state".

                               Regards,
 
                               Christer

                               -----Original Message-----
                               From: Hadriel Kaplan 

                               of such.  Regardless, I vote for any fixing 
that needs to happen because
                               of pre-conditions should be around changing 
pre-condition logic, even if

                               -hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 09:59:44 +0100

I think Gonzalo is working on clarifying "in-use", so I DO think you should concentrate on YOUR proposal :)

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 2. maaliskuuta 2009 10:54
	To: Christer Holmberg
	Cc: Gonzalo Camarillo; Hadriel Kaplan; sipping; [email-masked]
	Subject: 答复: RE: RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	Yes. 
	
	Then, could you define clearly for "in use" for Camarillo in the "picture". Last time you give one, but Camarillo asked me to concentrate on his. 

	

2009-03-02 16:47 

收件人
<[email-masked]> 
抄送
"Gonzalo Camarillo" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "sipping" <[email-masked]>, <[email-masked]> 
主题
RE: RE: RE: RE: RE: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

	  
	Regards, 
	  
	Christer 

	

2009-03-02 16:37 

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

	

	Hi, 

	
	Regards,
	
	Christer

	               

	               2009-03-02 15:00 

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

	

	               

	               Regards,
	               
	               Christer

	                              

	                              2009-03-02 14:21 

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

	               
	                              Hi, 

	                                
	                              Regards, 
	                                
	                              Christer 

	                              

	                              

	                              2009-03-02 05:30 

	                                               收件人
	                                               
	                                               主题

	                              

	                              Hi Hadriel,

	                              
	                              
	                              OR

	                              Regards,
	                              
	                              Christer

	                              -----Original Message-----

	                              
	                              
	                              -hadriel

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 2 Mar 2009 08:24:24 -0600

Guys,
 
Can you please snip the thread as much as possible as you reply for a couple reasons?
1) The messages are getting held for being too big, so I'm having to release them thru the admin i/f for the mailing list.
2) It might force you to respond in a different manner that might make the threads easier to follow.
 
Thanks,
Mary.

From: [email-masked] [mailto:[email-masked]] On Behalf Of gaoyang
Sent: Monday, March 02, 2009 8:15 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Summary of Closing the offer/answer rollback issue?

Comments inline.

 

> ; Not matter by which point of view, the session state is all clear. 
> 
> 2.
& gt; > To: [email-masked]; [email-masked]
> > ; 
> > re-INVITE/183-rel | audio2(notmet) | au dio1
> > 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 addr essed. 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.

更多热辣资讯尽在新版MSN首页！ 立刻访问！ <http://cn.msn.com/>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 03 Mar 2009 01:31:22 +0900

Gao

I am confused about your explanation.

Does "the suspending state" mean "preconditions are not met" ?
What does "part of the original modification" mean ?

signaling            | O/A state (no precondition)
---------------------+----------------------------
init-INVITE/200/ACK  | audio1
re-INVITE/183-rel    | audio2
PRACK/200OK          | audio2    +video1
UPDATE/200OK         | audio3    +video1
UPDATE/200OK         | audio3    +video2
UPDATE/200OK         | audio4    +video2
UPDATE/200OK         | audio4    +video3
UPDATE/200OK         | audio5    +video3
UPDATE/200OK         | audio6    +video4

Which is a part of the original modification ?
Which is new modification ?
Is the decision depend on preconditions ?

Regards,
Shinji

>> As we know, sometimes when you use preconditions you may do some modifications for a 
>> stream, in ADDITION to simply change the precondition status. I guess the most typical 
>> example is codec refine, ie you reduce the sets of codecs when it's know what both 
>> ends support.
>> 
>> Wouldn't it be possible to say that whatever change is done for a stream, if the the 
>> re-INVITE fails before the preconditions have been met everything will be rolled back 
>> for that stream?
>
> 
>
>> So, if I send an UPDATE and remove a codec, while preconditions still haven't been met, 
>> that codec change would also be rolled back if the re-INVITE fails.
>> 
>> 
>> By RFCs it is new modification at all, and as to make it part of the original 
>> modification, we should have semantics of suspending/resuming modification.
>> 
>> > >And only SDP with Precondition notification and without any other modification of 
>> > >session, during suspending state of session 
>> > "Christer Holmberg" <[email-masked]>, [email-masked], Gonzalo 
>> > Camarillo <[email-masked]> 
>> > 主题

---

From: [email-masked]
Date: Tue, 3 Mar 2009 08:21:02 +0800

Thanks for your reminding.

And We will make response simple and small.

"Mary Barnes" <[email-masked]> 写于 2009-03-02 22:24:24:

> 1) The messages are getting held for being too big, so I'm having to
> release them thru the admin i/f for the mailing list.

---

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

---

From: [email-masked]
Date: Tue, 3 Mar 2009 08:53:05 +0800

Comments inline.

> Does "the suspending state" mean "preconditions are not met" ?

[Gao] Yes. It is defined in RFC3312.

> What does "part of the original modification" mean ?

[Gao] There is modification which using more than one Offer/Answer pairs. 
And 
the subsequent Offer/Answer pairs is called "part of the original 
modification".

Currently, only "Precondition notification" can be treated as "part of the 
original modification" by current RFCs.

And "refine codecs" can be "part of the original modification", but we 
need consensus and normative definition.

> signaling            | O/A state (no precondition)

[Gao] All UPDATE/200OK pairs and PRACK/200OK are new modification, they 
are not part of the original modification.

There is no restrict of sending new modification request in pending state 
of the original modification. But it is not recommendation.
And accepting the new modification means committing at once( and 
discarding of the original one).

> Which is new modification ?

[Gao] Any new version of SDP can be treated as new modification, if there 
is no specific definition to make it a part of the original one.

> Is the decision depend on preconditions ?

[Gao] "Precondition notification" is a kind of "part of the original 
modification". But it not means that every modification during suspending 
state can be treated as "part of the original modification"

---

From: [email-masked]
Date: Tue, 3 Mar 2009 11:12:00 +0800

> signaling            | O/A state (no precondition)

  The differents between original modification and new modification
is that whether the state committed by the negotiation should be
rollback.
  If UPDATE/200 is a new modification nested in re-INVITE,when re-INVITE
fails, the state committed by UPDATE/200 should be remained, but if 
UPDATE/200 is an origianl modification nested in re-INVITE,when re-INVITE
fails, the state committed by UPDATE/200 should rollback.

  And the definitions of the two should be defined clear further.
  IMO, pre-conditions is original modifications.
Others, if "refine codec", it should be discussed further whether it's 
an original modification, else, it's new modification.

Eric

[email-masked] 写于 2009-03-03 00:31:22:

> >[Gao] If all the Offer/Answer pairs during the suspending state are
> part of the original 
> >modification, it is.
> >
> > 
> >
> >> <---- 4xx 
--------------------------------------------------------------
> >> The question is same as asking whether "refine codec" is a new 
> modification or just 
> >> By RFCs, it is a new modification. But I can not stop other 
> people to treat as part of 
> >> the original modification.
> >> 
> >> If "refine codec" is a new modification by UPDATE/200OK, its 
> commitment will go on and 
> >> without rollback.
> >> If "refine codec" is part of the original modification, it will 
> rollback for the 
> >> faillure the original modification.
> >> > >Precondition notification can be treated as part of the 
> original modification 
> >> > >triggered by Re-INVITE. 
> >> > >

---

From: [email-masked]
Date: Tue, 3 Mar 2009 11:21:43 +0800

I arranged a Q/A list. And the questions are people usually asked. And it 
is the process of my thought, so I once asked myself too.

[Q1] Why we need rollback?
[A1] That is the original concept of RFC3261. And it is the intuitionistic 
requirement for rejecting modification from user's view.

[Q2] And I think other SIP transaction(such as UPDATE) is independent 
transaction from Re-INVITE.
[A2] Yes.

[Q3] If I think that Offer/Answer in UPDATE/200OK will be committed alone, 
and if the UPDATE/200OK pair is during the Re-INVITE, what will happen. 
Committment/Rollback? It seems antinomy. 
[A3] Yes. It seems that. 
But the 200OK of Re-INVITE is the "Late Commitment" of the modification 
triggered by Re-INVITE. The commitment of other "new modification" with 
other transaction is the duty of that transaction 's 200OK.

[Q5] It puzzled me more. How can we treat a new modification during 
Re-INVITE?
[A5]If UA can not accept it at once, it should be rejected by 504. If UA 
accepts it, it will be committed at once. And it will have nothing to do 
with the Re-INVITE's failure or success.

[Q4] But there are really some special Offer/Answer. How can we treat it?
[A4] Such as precondition, it has the semantics of suspending/resuming of 
modification. So, it can be treated as part of the original modification. 
Then it will rollback with Re-INVITE's failure.
Before user is hinted, there can be more than one Offer/Answer pairs. But 
when he/she rejected the modification, he rejected all as atomic.

[Q6] Your mean differentiate the UPDATE during Re-INVITE?
[A6] Yes. Because some are really parts of the original modification and 
some are really new modifications.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Mar 2009 10:05:38 -0500

gao,

You seem to place great importance on this concept of "original
modification". Where do you find this concept in the existing RFCs? I
don't find it in 3262, 3311, or 3312.

	Thanks,
	Paul

[email-masked] wrote:
> [Gao] There is modification which using more than one Offer/Answer 
> pairs. And
> Currently, only "Precondition notification" can be treated as "part of 
> the original modification" by current RFCs.
> 
> There is no restrict of sending new modification request in pending 
> state of the original modification. But it is not recommendation.
> [Gao] Any new version of SDP can be treated as new modification, if 
> there is no specific definition to make it a part of the original one.
> 
> modification". But it not means that every modification during 
> suspending state can be treated as "part of the original modification"
> 
>  >
>  > Regards,
>  > Shinji
> 
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Mar 2009 10:30:00 -0500

Snipping the conversation down...

> success.  --That is the original concept of RFC3311.

No. I think that makes no sense at all.

Each offer that is sent is dependent on the ones that went before. If
you accept a later one and then fail an earlier one the state is not
well defined.

For instance, suppose a reINVITE proposes addition of a codec to an
existing audio stream and also addition of a second media stream
(video). Then there is a subsequent UPDATE to modify the original audio
stream (e.g. to make it inactive). That UPDATE *must* contain two
m-lines, reflecting its understanding of the current state of both.
Hence it is dependent on the reINVITE. If there is a 200 response to it,
how can that be handled independently of the subsequent success or
failure of the reINVITE? The response to the UPDATE must address what
was in the offer in the UPDATE, about both streams.

	Thanks,
	Paul

---

From: [email-masked]
Date: Wed, 4 Mar 2009 09:02:05 +0800

"The UPDATE *must* contain two m-lines, reflecting its understanding of 
the current state of both."

Yes. But it is syntax restriction.

And I think that only with specific definition, we can say that the later 
offer's effect is dependent on the earlier one. Such as preconditon(the 
"Precondition notification's effect is dependent on the earlier one").

In your example, when the other side recv the UPDATE, it has two choice:

1. If the UA can not accept it(including the new modification part and the 
part triggered in Re-INVITE) at once, rejecting it with 504.

2. If the UA accept it, all the part in SDP committed(It is the newest 
share view of session).

Paul Kyzivat <[email-masked]> 
2009-03-03 23:30

收件人
[email-masked]
抄送
"Sanjay Sinha (sanjsinh)" <[email-masked]>, [email-masked], 
sipping <[email-masked]>, Gonzalo Camarillo 
<[email-masked]>, Christer Holmberg 
<[email-masked]>
主题
Re: [Sipping] 答复: Re:  Summary of Closing the offer/answer rollback 
issue?

                 Thanks,
                 Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 17:07:15 +0900

Hi,

comment inline.

"Ian Elz" <[email-masked]>
>   signaling            | O/A state                      | media in use

that is full-rollback, isn't it?
I like it, too.

>belief is that this modification should be rejected.

agree

> If the UPDATE with

it seems to impossible.

>should require use of a re-INVITE.

I think so too.