Subject: [Sipping] Rollback issue: a proposal

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Mar 2009 15:32:50 +0200

Hi,

I have put together the following draft. It contains a proposal for the 
rollback issue that has been discussed on the list:

http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt

I have also written another short draft on an issue related to 
preconditions that was also discussed on the list in one of the 
rollback-related threads:

http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt

Comments are welcome.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Mar 2009 09:50:33 -0500

Gonzalo,

Very concise documents!

In terms of best practice I think they are good.

In terms of what to do if one finds oneself in a position where these 
procedures aren't used, I think it is still not entirely clear. Even so, 
I think we might be able to structure guidance around that. I think we 
also must still decide if we need to make a *normative* change here or not.

A key part of the doc is the guideline: don't send an error response to 
the reinvite unless no changes have been made since the reinvite was 
sent. As long as that guidance is followed I think most things are good.

Having the UAS send another o/a when the above wasn't followed seems 
like a good idea. Of course there is a window in there until that o/a is 
completed, and the state during that time (and offered in that offer) 
should still be defined if possible.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> _______________________________________________
> 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: gaoyang <[email-masked]>
Date: Tue, 3 Mar 2009 15:54:15 +0000

Comments for http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt

1. I think that it is BCP level. And the solution can be effective by restricting Non-2xx when Offer/Answer pair has been exchanged.

2. Your proposal considered legacy UAS. But currently, the situation is legacy UAC with legacy UAS. And it is the original issue.

3. "In order to undo changes that were already executed, the UAS uses a new
   offer/answer exchange or a target refresh request."

If the new offer/answer exchange need precondition, the other side can reject it with 504. then the modification(undo changes) may not be done by UPDATE/200OK. And Re-INVITE can not be used here(for the pending original Re-INVITE).

Comments for http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt

1. "However, the fact that the UAs can start using the new media parameters does not mean that they need to start using them immediately." Yes.

More than one Offer/Answer pais before Precondition Ok, and Caller can be answerer for some and Callee for the others. Then the two sides may waiting peer using new parameters

after Precondition OK. It may be deadlock.

 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt

_________________________________________________________________
MSN安全保护中心，免费修复系统漏洞，保护MSN安全！
http://im.live.cn/safe/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Mar 2009 18:16:33 +0200

Hi,

> Comments for 
> 1. I think that it is BCP level. And the solution can be effective by 
> restricting Non-2xx when Offer/Answer pair has been exchanged.

yes, we will need to decide on the status (BCP vs. PS vs. Informational)
at some point.

> 2. Your proposal considered legacy UAS. But currently, the situation is 
> legacy UAC with legacy UAS. And it is the original issue.

the draft describes the behavior of a new UAC that faces a legacy UAS,
which is the interesting situation. Other situations are not interesting
because a legacy UAC will be able to do the right thing when facing a
new UAS and if we have a legacy UAC against a legacy UAS, there is
nothing we can do because they were implemented some time ago and are
already out there.

> If the new offer/answer exchange need precondition, the other side can 
> reject it with 504. then the modification(undo changes) may not be done 
> by UPDATE/200OK. And Re-INVITE can not be used here(for the pending 
> original Re-INVITE).

The whole point is that the UAS should not send an error response. It
should send a 200 (OK) to the re-INVITE and then use traditional
mechanisms (i.e., UPDATEs or re-INVITEs) to modify the session if needed.

> Comments for 
> 1. "However, the fact that the UAs can start using the new media 
> parameters does not mean that they need to start using them 
> immediately." Yes.

we agree on this one, then.

> More than one Offer/Answer pais before Precondition Ok, and Caller can 
> be answerer for some and Callee for the others. Then the two sides may 
> waiting peer using new parameters

No, they will not be a deadlock because the UAS is in charge of starting
using the new parameters and of initiating a new offer/answer exchange.

Thanks for your comments,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 20:35:15 +0100

Hi,

If we decide to adopt the proposal in Gonzalo's draft, it will of course
have impact on the draft which tries to identify the essential
corrections based on the re-INVITE failure solution. I would say that
Gonzalo's proposal probably has less (if any) normative impacts than the
current solution. 3261 already says indicates that a full rollback
occurs in the case of re-INVITE failure, so I guess the question is we
need to add something extra.

But, we can discuss that once we have decided whether we are going to
adopt the new proposal.

In addition, we would also need to send a new LS reply to 3GPP.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gonzalo Camarillo
Sent: Tuesday, March 03, 2009 6:17 PM
To: gaoyang
Cc: [email-masked]
Subject: Re: [Sipping] Rollback issue: a proposal

Hi,

> 2. Your proposal considered legacy UAS. But currently, the situation 
> is legacy UAC with legacy UAS. And it is the original issue.

> reject it with 504. then the modification(undo changes) may not be 
> done by UPDATE/200OK. And Re-INVITE can not be used here(for the 
> pending original Re-INVITE).

The whole point is that the UAS should not send an error response. It
should send a 200 (OK) to the re-INVITE and then use traditional
mechanisms (i.e., UPDATEs or re-INVITEs) to modify the session if
needed.

> waiting peer using new parameters after Precondition OK. It may be 
> deadlock.

Gonzalo
_______________________________________________
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, 4 Mar 2009 08:36:13 +0800

Comments inline.

Gonzalo Camarillo <[email-masked]> 
发件人:  [email-masked]
2009-03-04 00:16

收件人
gaoyang <[email-masked]>
抄送
[email-masked]
主题
Re: [Sipping] Rollback issue: a proposal

Hi,

[Gao] "Legacy UAC with legacy UAS" is the all, currently. And I think will 
be the most in near future.
It is not practical to talk "new UAC that faces a legacy UAS" without 
talking "Legacy UAC with legacy UAS". Because use the legacy UAS to call 
the same type UA, it is the situation of  "Legacy UAC with legacy UAS".

[Gao] I don't think so. 
When one side using Re-INVITE to removing a media stream, perhaps with 
other modification. Offer/Answer has been exchanged before user's 
rejection.
Then the UPDATE(for undo) will reopen the removed media stream. 
Precondition may be need here. Then the other side can reject it.

But you can restrict UA MUST response 200OK to the undo UPDATE.

[Gao] For UPDATE, the UAS can be different one of UAS of Re-INVITE.
And, RFC3264's restriction in media level is about answerer. So in 
suspending state, your proposal 
has the situation both Caller and Callee are answerers.

If your proposals restrict that it is UAS of Re-INVITE to do it, IMO, it 
is violation of RFC3264.

UAS of Re-INVITE can be offerer of some Offers before suspending state, I 
think by RFC3264, UAS of Re-INVITE should wait for the other side to start 
using the new parameters.

Gonzalo

--------------------------------------------------------
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: Wed, 4 Mar 2009 11:44:50 +0800

More comments for 

1. UA can send target refresh and session modification(limited for 
address\port) automatically. So, I think for BCP level, it is better to 
separate target refresh from session modification which need user's 
interaction. Because make something deniable together with something 
dis-deniable is not friendly.

2. As your proposal, UAS of Re-INVITE is in pending state of target 
refresh, then choices is that:
2.1 the UAS will never send any more UPDATE before the final response of 
Re-INVITE;
2.2 trying a new UPDATE. And after recv the peer's 200OK(with the target 
refresh as Re-INVITE), it commit the target refresh for this successful 
UPDATE/200OK.
    And then UAS can treat the session modification separately.

3. In "3.  Clarifications on the Target Refresh Procedure", your proposal 
means that Re-INVITE's "Target Refresh" can only be committed after the 
200OK, even if there are UPDATE during it.
I think if UAC of Re-INVITE send another UPDATE(with the target refresh), 
and the UAS of Re-INVITE accept it with 200OK. The target refresh MUST be 
committed.

4. I think we talk too much about target refresh. Your proposal base on 
the combination of "target refresh" and "session modification". But I 
think the case is not usual(My point 1). And the unusual case has 
solution(My point 2 and 3).

2009-03-03 21:32

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

主题
[Sipping] Rollback issue: a proposal

Hi,

Comments are welcome.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 09:04:33 +0200

Hi,

> dis-deniable is not friendly.

there are situations where you need to do both at the same time (e.g.,
you get a new IP address).

>     And then UAS can treat the session modification separately.

the draft explains what to do already...

> 3. In "3.  Clarifications on the Target Refresh Procedure", your 
> proposal means that Re-INVITE's "Target Refresh" can only be committed 
> after the 200OK, even if there are UPDATE during it.

I suggest you re-read that section to understand what it says.

> I think if UAC of Re-INVITE send another UPDATE(with the target 
> refresh), and the UAS of Re-INVITE accept it with 200OK. The target 
> refresh MUST be committed.

Same as above.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 4 Mar 2009 15:16:48 +0800

1. Using your pic, but UPDATE(6)/200OK(7) with no Offer/Answer:

                 UAC                                          UAS
                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<----(5) 183 Session Progress SDP4----------|
                  |                                            |
                  |                                            |
                  |<------------(6) UPDATE --------------------|
                  |                                            |
                  |-------------(7) 200 OK ------------------->|
                  |                                            |
                  |<---------------(8) 200 OK------------------|
                  |                                            |
                  |------------------(9) ACK------------------>|
                  |                                            |

Dialog state before Re-INVITE: dialog;

Re-INVITE(4) want to refresh to state: dialog';

UPDATE(6) is a newer refresh: dialog''

200OK(7) is the commitment of dialog''. And 200OK(8) is just using the 
committed state(dialog'') if UAS want to commit the session modification. 
And this is defined in RFC3311: 

If a UA
   uses an UPDATE request or response to modify the remote target while
   an INVITE transaction is in progress, and it is a UAS for that INVITE
   transaction, it MUST place the same value into the Contact header
   field of the 2xx to the INVITE that it placed into the UPDATE request
   or response.
 
2. I think the same is for session modification if UPDATE(6)/200OK(7) with 
Offer/Answer. That is, if the Offer/Answer in UPDATE(6)/200OK(7) is a new 
modification. Then the modification MUST be committed by 200OK(7). Then, 
it has nothing to do with (8).

Only with specific definition, the Offer/Answer in UPDATE(6)/200OK(7) can 
be treated as part of the modification triggered by Re-INVITE. 
Precondition is one case.

3. About racing condtion.
My proposal has no racing condition. And in later e-mail, I will explain 
it specificly.

收件人

主题

Hi,

Comments are welcome.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 4 Mar 2009 15:27:33 +0800

Comments inline.

2009-03-04 15:04

收件人
[email-masked]
抄送
sipping <[email-masked]>, [email-masked]
主题
Re: 答复: [Sipping] Rollback issue: a proposal

Hi,

[Gao] I am talking about do not send target refresh and session 
modification which need user's 
interaction together. Not about new IP.

[Gao] I wanted to say that your way is not the only one. So, I think it is 
a heavy restriction.

> refresh MUST be committed.

[Gao] I just wanted to say if UPDATE/200OK committed the target refresh, 
it should be free for 4xx of Re-INVITE.
You  want to make "target refresh"'s state pending, then form a big nested 
transaction. I do not think so.
I think the later UPDATE/200OK has committed it! 

Same as above.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 4 Mar 2009 15:46:03 +0800

I remember that Holmberg once said that the two proposal(your original one 
and mine) has one main branching about the importance of "Late 
commitment".

In your draft, there is "However, the fact that the UAs can start using 
the new media parameters does not mean that they need to start using them 
immediately." 

Is it means that you has agreed the importance of "Late commitment"?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 09:46:30 +0200

Hi,

> it should be free for 4xx of Re-INVITE.

I insist. You should re-read the draft. It explains why you should not
use 4xx response to cancel changes. The advantage of the approach in the
draft is that it does not require normative changes to already
implemented specs. It is more a BCP kind of spec. That is why its
backwards compatibility properties are good.

Cheers,

Gonzalo

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 04 Mar 2009 16:52:25 +0900

Hi,

>Very concise documents!

I think so, too :)

comment inline.

>3.  Clarifications on the Target Refresh Procedure
>   target again.  In this case, a 200 (OK) response to the re-INVITE
>   would accept the latest target refresh within the re-INVITE.  That
>   is, the target refresh performed by the UPDATE request.

IMO, it is not correct that "a 200 (OK) response to the re-INVITE
would accept the latest target refresh". Because 200 response is
returned by not Contact but Via header, 200 is unrelated to the
Contact of the UPDATE request.

>5.  UAC Behavior
>   so that the session can continue.  This new offer/answer exchange
>   should contain the minimum set of changes needed to continue the
>   session in order to minimize the chances of the UAS rejecting it as
>   well.

"the minimum set" I think is, 
as if all o/a exchange had been done by UPDATE, UAC should
revert to the pre-INVITE state.

>   level, the UAS sends an UPDATE request (10) removing the
>   preconditions from the audio stream.  This indicates that the audio
>   stream is now in use.

RFC3312 restrick downgrading the desired strength.
IMO "removing the precondition" is equal to downgrading 
the desired strength, isn't it?

---

From: [email-masked]
Date: Wed, 4 Mar 2009 16:07:36 +0800

I think I explained why I can use 4xx of Re-INVITE, without making 
anything ambiguously.

The point is that do you agree that later UPDATE/200OK commit the target 
refresh.

2009-03-04 15:46

收件人
[email-masked]
抄送
[email-masked], sipping <[email-masked]>
主题
Re: [Sipping] 答复: Re: 答复:  Rollback issue: a proposal

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 09:15:27 +0100

Hi,

I don't think the draft forbids you from using 4xx to re-INVITE, but it explains the disadvantage of doing so if you have committed changes.

Regards,

Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 4. maaliskuuta 2009 10:08
	To: Gonzalo Camarillo
	Cc: [email-masked]; sipping
	Subject: [Sipping] 答复: Re: 答复: Re: 答复: Rollback issue: a proposal

	I think I explained why I can use 4xx of Re-INVITE, without making anything ambiguously. 
	
	The point is that do you agree that later UPDATE/200OK commit the target refresh. 

	

	2009-03-04 15:46 

		收件人
		[email-masked] 
		抄送

	Hi,

	
	Cheers,
	
	Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 10:18:10 +0200

Hi,

> Contact of the UPDATE request.

you should read the paragraph above. It explains that the change has 
already been implicitly accepted. All the 200 OK to the re-INVITE does 
is formally accept the change. That is, this paragraph just clarifies 
that the state after the 200 OK to the re-INVITE does not change. The 
target continues to be the one the UPDATE request updated before.

> revert to the pre-INVITE state.

That paragraph deals with the case where the UAC *cannot* revert to the 
pre-INVITE state for some reason.

> the desired strength, isn't it?

No, the semantics of an m line without preconditions are clear in SDP. 
It means that the stream is established. This is what all UAs without 
support for preconditions continuously do.

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 10:19:33 +0200

Hi,

well, if after reading the disadvantages of doing so you still want to
use it, then you probably like to have interoperability problems :o)

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 4 Mar 2009 16:25:44 +0800

I did not mean that.

My thought:

This draft treats "Target refresh" as the obstacle of 4xx. This is the 
precondition of the draft.

"Christer Holmberg" <[email-masked]> 
2009-03-04 16:15

收件人
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
抄送
<[email-masked]>, "sipping" <[email-masked]>
主题
RE: [Sipping] 答复: Re:  答复: Re: 答复:  Rollback issue: a proposal

Hi,

I don't think the draft forbids you from using 4xx to re-INVITE, but it 
explains the disadvantage of doing so if you have committed changes.

Regards,

Christer

                 From: [email-masked] 
[mailto:[email-masked]] On Behalf Of [email-masked]
                 Sent: 4. maaliskuuta 2009 10:08
                 To: Gonzalo Camarillo
                 Cc: [email-masked]; sipping
                 Subject: [Sipping] 答复: Re: 答复: Re: 答复: Rollback 
issue: a proposal

                 I think I explained why I can use 4xx of Re-INVITE, 
without making anything ambiguously. 
 
                 The point is that do you agree that later UPDATE/200OK 
commit the target refresh. 

 

                 2009-03-04 15:46 

                                 收件人
                                 [email-masked] 
                                 抄送
                                 [email-masked], sipping 
<[email-masked]> 
                                 主题
                                 Re: [Sipping] 答复: Re: 答复:  Rollback 
issue: a proposal

                 Hi,
 
                 > it should be free for 4xx of Re-INVITE.
 
                 I insist. You should re-read the draft. It explains why 
you should not
                 use 4xx response to cancel changes. The advantage of the 
approach in the
                 draft is that it does not require normative changes to 
already
                 implemented specs. It is more a BCP kind of spec. That is 
why its
                 backwards compatibility properties are good.
 
                 Cheers,
 
                 Gonzalo

                 --------------------------------------------------------
                 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: Wed, 4 Mar 2009 16:32:18 +0800

Let's talk the point:

Does 200OK of Re-INVITE is the "Late commitment" of everything during it?

I do not think so.

I insist that 200OK of Re-INVITE is the "Late commitment" of only the 
modification triggered by Re-INVITE, not everything during it.

The modification including "Target refresh" and Session.

Precondition notification is part of the modification triggered by 
Re-INVITE, so it obeys commitment/rollback of the original one.

And eveything is clear, I think there is no interoperability issue.  

2009-03-04 16:19

收件人
Christer Holmberg <[email-masked]>
抄送
[email-masked], [email-masked], sipping <[email-masked]>
主题
Re: [Sipping] 答复: Re:  答复: Re: 答复:  Rollback issue: a proposal

Hi,

Cheers,

Gonzalo

issue: a proposal
<[email-masked]> 
issue: a proposal
you should not
approach in the
already
why its
Anti-Spam system.

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 04 Mar 2009 18:47:43 +0900

>target continues to be the one the UPDATE request updated before.

I have understood that the target continues to be use.
the change has already been explicitly accepted by 200 to UPDATE.
If re-INVITE rejected, I think, it doesn't influence the remote
target. That is, in this case, 200 to re-INVITE is unrelated to
the remote target.
that's just wording.

>pre-INVITE state for some reason.

Sorry, it is the behavior of "the UAC *cannot* revert".
I said the behavior of "the UAC *can* revert".
But I think that "the UAC *can* revert" need to send an 
UPDATE request too.

>support for preconditions continuously do.

Does RFC3312 or 4566 says that ?
Give me the pointer of the semantics, please.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 12:42:11 +0200

Hi,

> target. 

see the reference to RFC 3261 in the draft regarding atomicity.

> But I think that "the UAC *can* revert" need to send an 

yes, it is probably a good idea to send an UPDATE anyway to make sure 
both ends are in synch. We may want to add that to the draft.

> Give me the pointer of the semantics, please.

Read the SDP spec and the offer/answer specs (nothing related to 
preconditions) and see what they way about m lines.

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 12:05:52 +0100

Hi,
 
If you have commited changes when the 200 OK sent, those changes are already used when the 200 is sent. So, it is not a late commitment in that sense.
 
It IS a late commitment in the sense that you DO have to possibilities to reject EVERYTHING (including modficiations triggered by UPDATE etc) by sending a 4xx response. But, again, the draft recommends you against doing that if changes have already been committed.
 
At the end of the day, it is the group that will decide which way we move forward.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 4. maaliskuuta 2009 10:32
	To: Gonzalo Camarillo
	Cc: Christer Holmberg; sipping; [email-masked]
	Subject: 答复: Re: [Sipping] 答复: Re: 答复: Re: 答复: Rollback issue: a proposal

	Let's talk the point: 

	I do not think so. 
	
	I insist that 200OK of Re-INVITE is the "Late commitment" of only the modification triggered by Re-INVITE, not everything during it. 

	Precondition notification is part of the modification triggered by Re-INVITE, so it obeys commitment/rollback of the original one. 

	

2009-03-04 16:19 

收件人

	Hi,

	Cheers,
	
	Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 12:07:14 +0100

>I remember that Holmberg once said that the two proposal(your original one and mine) has one main branching about the importance of "Late commitment". 

I had missunderstood Gonzalo's proposal, so I was wrong.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 04 Mar 2009 22:12:56 +0900

Gonzalo,

comment inline.

>see the reference to RFC 3261 in the draft regarding atomicity.

               A                 B
INVITE/200/ACK <----------------->
  Contact: A1
reINVITE/18x   <----------------->
  Contact: A2
UPDATE/200     <----------------->
  Contact: A3
4xx/ACK        <----------------->

You say that A's Contact(local target) is rolled back to A1.
Is this right?

>preconditions) and see what they way about m lines.

RFC3312
5.1 Generating an offer
   With the transaction status table, the user agent MUST generate the
   current-status and the desired status lines, following the syntax of
   Section 4 and the rules described below in Section 5.1.1.

5.2 Generating an Answer
   between two consecutive offer/answer exchanges.  Therefore, both user
   agents MUST keep their local status tables up to date, using local
   information throughout the duration of the session.

Therefore, I think that "removing the precondition" is not allowed.
Is this wrong?

Regards,
Shinji

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Mar 2009 16:09:19 +0200

Hi,

> You say that A's Contact(local target) is rolled back to A1.

yes.

> Therefore, I think that "removing the precondition" is not allowed.

the precondition phase is over. The preconditions were already met. All 
you are doing is indicating that the stream is in use in the most 
backwards compatible way we have.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 4 Mar 2009 21:55:24 +0800

To Holmberg:

The draft is a brand new one So, I think there is no misunderstanding at 
all.

To  Camarillo:

My question is that, as  your draft says that  "However, the fact that the 
UAs can start using the new media parameters does not mean that they need 
to start using them immediately." 

2009-03-04 19:07

�ռ���
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
����
<[email-masked]>, "sipping" <[email-masked]>
����
RE: [Sipping] ��: Re: ��:  Rollback issue: a proposal

 
>I remember that Holmberg once said that the two proposal(your original 
one and mine) has one main branching about the importance of "Late 
commitment". 

Regards,

Christer

�mz�ڶ+�

---

From: [email-masked]
Date: Wed, 4 Mar 2009 22:18:38 +0800

When later UPDATE/200OK commit the "Target Refresh", it is not associated 
with Re-INVITE.
So, it MUST NOT rollback.

In RFC3261 (about this point), there is only pending-committed semantics, 
no committed-rollback semantics.

While the pending state of "Target Refresh" is replace by a new 
modification of "Target Refresh".

The old one is discarded. Why the new one rollback?

2009-03-04 18:42

收件人
OKUMURA Shinji <[email-masked]>
抄送
sipping <[email-masked]>
主题
Re: [Sipping] Rollback issue: a proposal

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 15:50:25 +0100

>To Holmberg: 
>	
>The draft is a brand new one So, I think there is no misunderstanding at all. 

I did the comparision based on the e-mail discussions, before the draft was submitted, and I missunderstood when Gonzalo described his proposal.

Regards,

Christer

	To  Camarillo: 
	
	My question is that, as  your draft says that  "However, the fact that the UAs can start using the new media parameters does not mean that they need to start using them immediately." 

	

	2009-03-04 19:07 

		收件人
		<[email-masked]>, "Gonzalo Camarillo" <[email-masked]> 
		抄送
		<[email-masked]>, "sipping" <[email-masked]> 
		主题
		RE: [Sipping] 答复: Re: 答复:  Rollback issue: a proposal

	                

	Regards,
	
	Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 04 Mar 2009 23:57:21 +0900

Gonzalo,

>> You say that A's Contact(local target) is rolled back to A1.

I thought most had agreed that there will be a rollback to the
"last committed state".

Even if UPDATE had no offer, was A's Contact rolled back to A1 ?

>backwards compatible way we have.

But your interpretation is not written explicitly.
I think this is an another issue and cause new interoperability problems.

Do both Session Refresh Request and hold-SDP have no precondition attributes ?

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 5 Mar 2009 09:12:57 +0800

My proposal has no racing condition

1 UPDATE and 4xx/5xx/6xx of Re-INVITE

      UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   PRACK          |
       |-------------------->|
       | F4 2xx PRA          |
       |<--------------------|
       |                     |
       |F5 UPDATE F6 4xx INV |
       |---------\  /--------|
       |          \/         |
       |          /\         |
       |<--------/  \------->| 
       |                     |

Currently, there are only two cases for the Offer in UPDATE:

   o part of the original modification;

   o a new modification request.
 
If it is part of the original modification, the session state is clear. 
That
is the state before F1.

If it is a new modification request, there are only two cases for the
   UPDATE:

   o accepted by 200OK;

   o rejected by 4xx/5xx/6xx, such as 504.

   If it is accepted by 200OK, the new modification is committed.  And
   the session state is committed state of the modification triggered by
   F5.

   If it is rejected, and the original modification failed, the session 
state is one before F1.

---

From: [email-masked]
Date: Thu, 5 Mar 2009 10:29:07 +0800

At the end of the day, it is the group that will decide which way we move 
forward.

What day is the day you mentioned?

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 11:47:30 +0900

Gao,

I feel your proposal is no bad for a summary.

BUT, The biggest drawback is which UPDATE is "part of the original 
modification" or "new modification". it is very very ambiguous.

the distinction seems to impossible.

It is no doubt that an UPDATE without SDP is "new modification".
UPDATE after ACk is "new modification" too.
but it has a racing condition.

new UAS behavior
	reject all UPDATEs received between 4xx and ACK

can the above rule solve the problem ?

Regards,
Shinji

[email-masked]

---

From: [email-masked]
Date: Thu, 5 Mar 2009 11:11:35 +0800

[Gao] Yes, it is summary. That's why I think we can solve the open issue 
without any change to current RFCs.

[Gao] It is clear. Because the distinction is according as modification 
itself(SDP).
And by current RFCs, only precondition notification can be treated as 
"part of the original modification". Others is just substitute of the 
orignal modification.
I think this concept itself is clear. 

People may want to treat some type of SDP as "part of the original 
modification", without specific definition as precondition. The concept 
itself(as framework) is open for this.

One example is "refine codec".
If we want to make "refine codec" as "part of the original modification" 
normative. I have a suggestion: 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".

new UAS behavior

[Gao] It can solve it. Because which is "part of the original 
modification" is decided by the modification's property while sequence(or 
order) of the signal(message), so it can solve it. (or say that it is 
unrelated tosequence(or order) of the signal(message)) . I think it is a 
merit.

---

From: [email-masked]
Date: Thu, 5 Mar 2009 14:39:51 +0800

Hi Gonzalo Camarillo， 

  I just read your two drafts,and at this moment I think it is a solution, 

but also, it's a complex one.

  In your draft:
   If changes requested by a re-INVITE or any transaction within it have
   already been performed, the UAS should always return a 200 (OK)
   response.  Even if the UAS would like to revert to the pre-INVITE
   state, it would still return a 200 (OK) to the INVITE request.

  I think it should be discussed more about this solution.
  If re-INVITE can't be rejected, then re-INVITEs are no better than 
UPDATEs,I think.
 
  There are two reasons listed in the draft to illustrate it.
 
  First one:
-  However, the UAC has no means to reject those changes
   if it is unable to execute them.  That is, if the UAC is unable to
   revert to the pre-re-INVITE state, it will not be able to communicate
   this fact to the UAS. 
  IMO, the best solution for the case is also in the draft.
--- This new offer/answer exchange
   should contain the minimum set of changes needed to continue the
   session in order to minimize the chances of the UAS rejecting it as
   well.
  If UAC raises an unrejectable request,it should contain minimum set
of changes.If it is rejected just because it contains unacceptable changes 

by UAS, it deserves the rejection.

  Second,
-- Since both the UPDATE request and the error response would
   request changes, it would not be clear which changes would need to be
   executed first.  This is yet another reason why UASs should not use
   error responses to undo already executed changes.
  As we can make restrictions not to reject re-INVITE,why not restrict 
  UPDATEs in re-INVITEs.
  Also, unlimited UPDATEs increase the collision.Such as the step (6) and 
  step (8)  in figure 4 of your draft.

               UAC                                          UAS
 
                  |                                            |
                  |-------------(1) INVITE SDP1--------------->|
                  |                                            |
                  |<------------(2) 200 OK SDP2----------------|
                  |                                            |
                  |------------------(3) ACK------------------>|
                  |                                            |
                  |                                            |
                  |-------------(4) INVITE SDP3--------------->|
                  |                                            |
                  |<----(5) 183 Session Progress SDP4----------|
                  |                                            |
                  |-------------(6) UPDATE SDP5--------------->|
                  |                                            |
                  |<------------(7) 200 OK SDP6----------------|
                  |                                            |
                  |                                            |
                  |<------------(8) UPDATE SDP7----------------|
                  |                                            |
                  |-------------(9) 200 OK SDP8--------------->|
                  |                                            |
                  |<--------------(10) 200 OK------------------|
                  |                                            |
                  |-----------------(11) ACK------------------>|
                  |                                            |

             Figure 4: Rejection of a video stream by the user

Wishes,
Eric.wang

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Mar 2009 09:04:10 +0200

Hi,

> but also, it's a complex one.

everything that has been discussed on the list is much more complex.
Note that my proposal does not involve normative changes to the specs.
It clarifies when and when not to use the existing tools we have.

>   If re-INVITE can't be rejected, then re-INVITEs are no better than 

sure, you can use UPDATEs instead of re-INVITEs for a lot of things.
Nobody keeps you from using UPDATEs. The draft is clarifying how to use
re-INVITEs if you decide to use them. There are a few reasons why some
implementations out there use re-INVITEs instead of UPDATEs in some cases.

> by UAS, it deserves the rejection.

You missed the whole point of that discussion. Please, re-read that section.

>   step (8)  in figure 4 of your draft.

again, there are reasons why some implementations use UPDATEs within a
re-INVITE. Preconditions is the typical example. There are many
implementations that use them.

Always keep in mind backwards compatibility. Designing mechanisms
without keeping this in mind is not a very productive exercise in this
context.

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 08:23:00 +0100

I hope we will make a decission on the way forward no later than at the upcoming IETF meeting, so that we also can send a new LS reply to 3GPP if needed.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 05, 2009 4:29 AM
To: Christer Holmberg
Cc: Gonzalo Camarillo; sipping; [email-masked]
Subject: 答复: RE: Re: [Sipping] 答复: Re: 答复: Re: 答复: Rollback issue: a proposal

---

From: [email-masked]
Date: Thu, 5 Mar 2009 15:20:08 +0800

I think "UPDATE during Re-INVITE" is clear.

1. In RFC311
In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), 
the change of states is committed and effort at once. If the other side 
can not accept it at once, it can reject it by 504.
The semantics is clear. And, the states including "dialog state" and 
"session state".

2. Considering Precondition
Some people may ask is "Precondition" the violation of the semantics 
mentioned above? There is no violation at all.

UPDATE/200OK committed and effort the Offer/Answer at once. But we must 
make sure the effect of the Offer/Answer.
In RFC3312, there is specific semantics of suspending/resuming session 
modification. And Offer/Answer using as sharing precondition view(as I 
called "Precondition notification") do not determine the session 
modification commitment.

So, this obeys RFC3311:
If the session description has changed, the UAS MUST adjust the session 
parameters accordingly and generate an answer in the 2xx response.
The UA adjust the session parameters accordingly(refresh the precondtion 
state table), but it has no impact on the commitment of the modification.
It is quite clear.

3. Considering part of SDP with Precondition
If the UPDATE/200OK just refresh the precondtion state table, it is the 
same as "2. Considering Precondition".

If the UPDATE adding more than "refresh the precondtion state table":

o Precondition not satisfied. UA should reject it with 504.

o Precondition satisfied, but need user's acknowledgement. UA should 
reject it 504.

o Precondition satisfied, without needing user's acknowledgement. UA can 
accept it. And the modification is committed at once.

All the above is clear.

---

From: [email-masked]
Date: Thu, 5 Mar 2009 15:27:41 +0800

[Gao] I asked you how will happen when "legacy" UAC with "legacy" UAS. You 
answered:

" there is nothing we can do because they were implemented some time ago 
and are
already out there."

I think it might be "backwards disregarding".

2009-03-05 15:04

收件人
[email-masked]
抄送

Hi,

> by UAS, it deserves the rejection.

You missed the whole point of that discussion. Please, re-read that 
section.

Thanks,

Gonzalo

---

From: [email-masked]
Date: Thu, 5 Mar 2009 15:59:09 +0800

Hi,

> It clarifies when and when not to use the existing tools we have.

  I have no doubt that the problem is comlex,but I think we should find as 
easy 
a solution as possible to solve this problem.
  For most equipment such as UAs and service servers,some updates must be 
done in 
order to solve this problem. I think little updates would be 
better,although we 
may have to changes some specs.Specs are instructions, i think, of course, 
we 
should think carefully if we have to do so.

section.

I catch most of that discussion, but I can't receive all letters from 
gao.yang.

> implementations that use them.

Yes, preconditions surely can be implemented in re-INVITE,and both the UAs 
can foresee
these UPDATEs, and there is no puzzle if there are only precondition 
UPDATEs.

> without keeping this in mind is not a very productive exercise in this

I agree, if new solution has no backwards compatibility,it's not a 
solution.

Wishes,
Eri.wang

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 5 Mar 2009 11:00:21 +0100

Shinji,

I don't believe that your proposal to reject all UPDATEs received
between the 4xx and the ACK will solve the problem. It won't harm but
there are situations where the UPDATE may arrive after the ACK has been
received by the UAS.

This may occur when another node exists between the UAC and the UAS.
RFC3261 requires that the ACK for a non-2xx response be sent by the
transaction and hence the ACK in this case is hop-by-hop. Only an ACK to
a 2xx response is end-to-end.

This may lead to the following scenario:

      UAC                   P1                    UAS
       |          session established              |
       |<====================|====================>|
       |                     |                     |
       |            F1  re-INVITE (SDP)            |
       |-------------------->|-------------------->|
       |            F2 1xx-rel (SDP)               |
       |<--------------------|<--------------------|
       |                F3   PRACK                 |
       |-------------------->|-------------------->|
       |                 F4 2xx PRA                |
       |<--------------------|<--------------------|
       |                     |                     |
       |F5 UPDATE F6       4xx INV                 |
       |---------\  /--------|<--------------------|
       |          \/         |        ACK          |
       |          /\         |-------------------->|
       |<--------/  \        |    UPDATE F6        |
       |             \------>|-------------------->|
       |                     |                     |
       |         ACK         |                     |
       |-------------------->|                     |

The more intervening nodes the greater the probability that this
situation will occur.

Ian Elz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of OKUMURA Shinji
Sent: 05 March 2009 02:48
To: sipping
Cc: Gonzalo Camarillo
Subject: Re: [Sipping] My proposal has no racing condition

Gao,

new UAS behavior

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 19:20:23 +0900

Ian,

yes, you are right.
ACK is sent hop-by-hop.
This is the problem associated with full-rollback.

Do you have an idea to solve it ?

Regards,
Shinji

"Ian Elz" <[email-masked]>

---

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

If the UPDATE is "only refresh the precondtion state table"(I once using "
a part of the original modification"), it is discarded by UAS as the 
failure of Re-INVITE.

Other kind of UPDATE should be treated as a normal UPDATE.(accept/reject)

Then, the key point is the property of UPDATE itself, not its order in the 
sequence. Then, I say it has no racing condition.

2009-03-05 18:00

收件人
"OKUMURA Shinji" <[email-masked]>, "sipping" <[email-masked]>
抄送
Gonzalo Camarillo <[email-masked]>
主题
Re: [Sipping] My proposal has no racing condition

Shinji,

      UAC                   P1                    UAS
       |          session established              |

Ian Elz

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

Gao,

new UAS behavior

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 20:01:32 +0900

Hi,

New rule.

UAC Behavior
	After receiving 4xx, if UAC receive 200 response with answer
	to UPDATE that sent before receiving 4xx, UAC MUST treat it as if
	UAC sent the UPDATE after sending ACK.

      UAC                   P1                    UAS
       |          session established              |
       |<====================|====================>|
       |                     |                     |
       |            F1  re-INVITE (SDP)            |
       |-------------------->|-------------------->|
       |            F2 1xx-rel (SDP)               |
       |<--------------------|<--------------------|
       |                F3   PRACK                 |
       |-------------------->|-------------------->|
       |                 F4 2xx PRA                |
       |<--------------------|<--------------------|
       |                     |                     |
       |F5 UPDATE(offer)  F6 4xx INV               |
       |---------\  /--------|<--------------------|
       |          \/         |     F7 ACK          |
       |          /\         |-------------------->|
       |<--------/  \        |     F5 UPDATE       |
       |             \------>|-------------------->|
       |                     |                     |
       |                 F8 2xx UPDATE(answer)     |
       |<--------------------|<--------------------|
       |         ACK         |                     |
       |-------------------->|                     |

What do you think of this idea ?

Regards,

Shinji

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 12:45:26 +0100

Hi,

Please be aware that there may also be offer/answer state aware
intermediates, of which some may have received the 4xx (F6) BEFORE they
received the UPDATE (F5), and they must all end up having the same SDP
state. Otherwise you have a mess.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of OKUMURA Shinji
> Sent: 5. maaliskuuta 2009 13:02
> To: Ian Elz; sipping
> >transaction and hence the ACK in this case is hop-by-hop. 
> Only an ACK 
> >to a 2xx response is end-to-end.
> >
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

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

Christer,

Are you talking about B2BUA ?
It will go without saying B2BUA is an endpoint, terminate both dialog.
It should handle both O/A state adequately.

If you know a concrete problem, pl show me it's sequence flow.

Regards,

Shinji

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 14:44:56 +0100

Hi,

There are also "B2BUAs acting as proxies", that do not terminate the
dialogs.

There are even proxies which need to keep SDP state.

Regards,

Christer 

> From: OKUMURA Shinji [mailto:[email-masked]] 
> Sent: 5. maaliskuuta 2009 15:32
> To: Christer Holmberg; sipping
> Subject: RE: [Sipping] My proposal has no racing condition
> 
> Christer,
>

---

From: gaoyang <[email-masked]>
Date: Thu, 5 Mar 2009 13:46:51 +0000

In IMS system, P-CSCF(PDF) is such one. It is stateful proxy.

But it control the bear(GPRS). That is a kind of inter-box.

By the way, what do you think of  "analyse atomicity's semantics"?

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Thu, 5 Mar 2009 22:32:15 +0900

_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 22:52:44 +0900

Christer,

>There are also "B2BUAs acting as proxies", that do not terminate the

"B2BUAs acting as proxies" is a terrible entities !
It should behave as B2BUA.

Regards,

Shinji

>--------------------------"AVG certification"--------------------------
>
>No virus found in this incoming message.
>Checked by AVG - www.grisoft.jp 
>Version: 8.0.237 / Virus Database: 270.11.7/1983 - Release Date: 03/04/09 07:41:00

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 15:04:24 +0100

Hi, 

>"B2BUAs acting as proxies" is a terrible entities !

I would call them useful entities, but that's just me...

I would also say that many (most?) of the B2BUAs out there probably act
that way, but I am sure there are people who has better information on
that.

>It should behave as B2BUA.

Well, it doesn't :)

Anyway, even if they do I don't think it would solve the issue. The
point is that some entities may bet the 4xx from the UAS before they get
the UPDATE from the UAC, while other entities get the UPDATE from the
UAC before they get the 4xx from the UAS.

But, as indicated in Gonzalo's draft, that can be avoided by the UAS
sending an UPDATE instead of 4xx.

Regards.

Christer

> >> >> >>   If it is rejected, and the original modification 
> failed, the 
> >> >> >> session
> >> >> >
> >> >> >>state is one before F1.
> >> 
> >

---

From: gaoyang <[email-masked]>
Date: Thu, 5 Mar 2009 14:14:20 +0000

Yes. I agree with you.

But I tried to give you one example(P-CSCF).

The order of signals in P-CSCF's view can be different with UAC's view.

For example, UPDATE and 200OK before 4xx. Then P-CSCF can have different session state.

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 05 Mar 2009 23:40:35 +0900

Hi,

>that way, but I am sure there are people who has better information on

Where is the behavior of "useful entities" defined ?

>UAC before they get the 4xx from the UAS.

1.IT receive 4xx from UAS
2.IT send ACK to UAS
3.IT send 4xx to UAC
4.IT receive UPDATE from UAC
5.IT send UPDATE to UAS
6.IT receive 2xx to UPDATE from UAS
7.IT send 2xx to UPDATE to UAC

      UAC                   IT                    UAS
       |          session established              |
       |<====================|====================>|
 state1|              state1 | state1              | state1
       |                     |                     |
       |            F1  re-INVITE (SDP)            |
       |-------------------->|-------------------->|
       |            F2 1xx-rel (SDP)               |
       |<--------------------|<--------------------|
 state2|              state2 | state2              | state2
       |                     |                     |
       |                F3   PRACK                 |
       |-------------------->|-------------------->|
       |                 F4 2xx PRA                |
       |<--------------------|<--------------------|
       |                     |                     |
       |F5 UPDATE(offer)  F6 4xx INV               |
 offer3|---------\  /--------|<--------------------| rollback state1
       |              state1 | state1              |
       |                     |                     |
       |                     |                     |
       |          \/         |     F7 ACK          |
       |          /\         |-------------------->|
 state1|<--------/  \        |     F5 UPDATE       |
       |             \------>|-------------------->| offer3
       |              offer3 | offer3              |
       |                     |                     |
       |                 F8 2xx UPDATE(answer)     |
       |<--------------------|<--------------------| answer3 = state3
 state3|              state3 | state3              |
       |         ACK         |                     |
       |-------------------->|                     |

It is no problem, isn't it?

Regards,

Shinji

---

From: gaoyang <[email-masked]>
Date: Thu, 5 Mar 2009 14:49:10 +0000

> sending an UPDATE instead of 4xx.

I showed a example that UAC can not accept the UPDATE. But he did not give further explanation. 

session before Re-INVITE has two m-line, as m1 and m2

UAC send Re-INVITE to add m3 and remove m2, m3 with precondition.

Then UAS can not alert the user.

After m3's precondition OK, m2 has removed(because Offer/Answer pairs has exchanged).

Then user rejected the modification.

Then the undo UPDATE re-open m2 and remove m3. Re-open m2 can need precondition.

Then the UAC can not accept it at once.

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 16:02:24 +0100

Hi, 

>Where is the behavior of "useful entities" defined ?

draft-real-world and draft-customer-requirements

At the end of the day, those drafts are what really matters to many
people :)

I'll look at the rest later.

Regards,

Christer

> >point is that some entities may bet the 4xx from the UAS before they 
> >get the UPDATE from the UAC, while other entities get the 
> UPDATE from 
> >the UAC before they get the 4xx from the UAS.
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 06 Mar 2009 00:15:54 +0900

Christer,

>draft-real-world and draft-customer-requirements

Of course there will be many problems in real-world.

>At the end of the day, those drafts are what really matters to many

I feel your explanation is lacking in concreteness.
Pl show your problem concretely.

Regards,

Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 06 Mar 2009 01:10:23 +0900

Gao,

AFAIK, providing aspecific service, P/S-CSCF and AS are defined as B2BUA.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 18:26:13 +0100

Hi, 

people :)
>Pl show your problem concretely.

It's not a problem, I just told you how many intermeidates out there are
acting.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 18:28:51 +0100

P/S-CSCFs are actually defined as proxies.

Regards,

Christer 

-----Original Message-----
From: OKUMURA Shinji [mailto:[email-masked]] 
Sent: Thursday, March 05, 2009 6:10 PM
To: gaoyang; Christer Holmberg; [email-masked]
Subject: Re: [Sipping] My proposal has no racing condition

Gao,

AFAIK, providing aspecific service, P/S-CSCF and AS are defined as
B2BUA.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 19:44:25 +0100

Hi,

>Then the UAC can not accept it at once. 
 
If something has been removed there can always be situations when it is
not possible to roll back.
 
So, if the UAS sends a "rollback UPDATE", and offers m1 and m2 to be put
back, and the UAC cannot accept it, the UAC should of course reject the
UPDATE. What happens after that is an implementation issue, I think.
 
You could end up in the same situations even without preconditions
intermediate UPDATEs. For example:
 
- Session before re-INVITE = m1 and m2
- Re-INVITE adds m3 and removes m1 and m2
- UAS rejects the re-INVITE
 
Now, m1 and m2 has been removed, and no matter if the UAS sends 4xx, or
a rollback UPDATE, the UAC may not be able to put m1 and m2 back.
 
The only way to solve this would be to say that any committed change (no
matter whether the change has been done using reINV/18x or UPD/200) is
never rolled back - which is the current solution.
 
Regards,
 
Christer

---

From: [email-masked]
Date: Fri, 6 Mar 2009 11:06:30 +0800

1. Chart
By your rule, in A/B's view, UPDATE/200OK is after 4xx(/failure of 
Re-INVITE).

But in P-CSCF's view, UPDATE/200OK is before 4xx.

2. My proposal has no such problem.
Because: even if A/B/P-CSCF has different view of the order, but the state 
is decided by the property of Offer/Answer in UPDATE/200OK.

If the Offer/Answer is just "refresh precondition state table", it has no 
influence on the final session state.
If the Offer/Answer has modification, it is committed.

2009-03-06 00:10

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

主题

Gao,

---

From: [email-masked]
Date: Fri, 6 Mar 2009 11:26:02 +0800

[Gao] But Gonzalo's draft using "should not", but this is a case "MUST".

 

[Gao] Without precondition, there is no such problem at all.
UAS can reject the Offer, without giving answer, such as 488. 

[Gao] We are talking session state in theory level. And
I think I have show in my draft that we have definitive session state 
obeying current RFCs.

How to get to the session state, is practical level thing. 
If you are interested in it. You can make a new thread, and I will share 
my ways(I think we have many ways to do so).

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Mar 2009 07:08:27 +0100

Hi, 

>[Gao] But Gonzalo's draft using "should not", but this is a case
"MUST".

I don't know what text you are referring to, but there is always a risk
that the UPDATE will be rejected. We can't assume, it won't.

>UAS can reject the Offer, without giving answer, such as 488. 

Yes, but in my example there was already an answer in 18x.

obeying current RFCs. 

And I think Gonzalo's draft says the same thing.

>If you are interested in it. You can make a new thread, and I will
share my ways(I think we have many ways to do so). 

I don't want a new thread - I want a solution.

Regards,

Christer

---

From: [email-masked]
Date: Fri, 6 Mar 2009 14:17:04 +0800

Modification with mandatory precondition can not prompt the user and be 
committed at once ---RFC3312.

If the session description has changed, the UAS MUST
   adjust the session parameters accordingly and generate an answer in
   the 2xx response.
If the UAS cannot change
   the session parameters without prompting the user, it SHOULD reject
   the request with a 504 response.   ---RFC3311

Then, that's why the UAC can not accept the UPDATE. 

2009-03-06 14:08

收件人
<[email-masked]>
抄送
"gaoyang" <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: Re: [Sipping] About Gonzalo's draft //RE: My proposal has no racing 
condition

Hi, 

 

 
obeying current RFCs. 

Regards,

Christer

---

From: [email-masked]
Date: Fri, 6 Mar 2009 20:11:28 +0800

Add the analysis of Re-INVITE's atomicity.

URL:
http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-criterion-03.txt

Thanks Gonzalo Camarillo, OKUMURA Shinji, Ian Elz and Christer
Holmberg for discussion.

---

From: [email-masked]
Date: Sat, 7 Mar 2009 13:04:57 +0800

About draft-camarillo-sipping-precons-00:

The draft suggests UAS first using the modification in media level when 
resume from suspending state.

But if Re-INVITE has no Offer, the Offer in 183 from UAS, the the answerer 
is UAC. And it is UAC needing user's confirmation.
If people restrict that it is UAS first using new modification after 
suspending state for all the situation, it can solve the deadlock problem. 

But it will be violation of RFC3264.

Deadlock problem:
If people restrict that any later modification during suspending state is 
part of the ini-Offer/Answer in Re-INVITE.
Then, both UAC and UAS can be answerer. 
For examle, during suspending state, UAC added vedio stream(UAS is the 
answerer), then UAS changed the codec(UAC is the answerer).
Then, the UAC wait UAS using new stream, but UAS wait UAC using the new 
codec. That is deadlock.