Subject: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jan 2010 08:31:53 -0500

Gonzalo,

Over the holidays I had occasion to review the above document again, and 
I have a question about the criterion you propose for sending an error 
response or not:

    If any of the changes requested in a re-INVITE or in any transaction
    within it have already been executed (with the exception of target
    refreshes), the UAS MUST always return a 2xx response.

    A change to the session state is considered to have been executed
    when the new media parameters are being used.  Therefore, a change to
    a stream subject to preconditions [RFC4032] is considered to have
    been executed when the new media parameters start being used; not
    when the preconditions for the stream are met.  Connection
    establishment messages (e.g., TCP SYN) and connectivity checks (e.g.,
    when using ICE [I-D.ietf-mmusic-ice]) are not considered media
    either.  A UA considers the new parameters to be in use when it sends
    media using them, or when media that uses the new parameters is
    received, which should be interpreted as follows.  From Section 8.3.1
    of RFC 3264 [RFC3264]:

       "Received, in this case, means that the media is passed to a media
       sink.  This means that if there is a playout buffer, the agent
       would continue to listen on the old port until the media on the
       new port reached the top of the playout buffer.  At that time, it
       MAY cease listening for media on the old port."

Consider the case where the o/a has been performed, and the UAC has sent 
media according to the new session description, but the UAS has not yet 
sent or received that media according to the definition above. In that 
case, the UAS may choose to send an error response. But the UAC has 
already made the change to the new session, and so will need to switch 
again to the old one. This is the case you are attempting to avoid, and 
yet it has not been avoided. I don't see an easy answer to this - only 
messy ones.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 5 Jan 2010 15:29:24 +0800

Hi Paul,

I have had the same puzzle once. And I thought it as:

I'd like to talk the semantics of three different concept firstly:
1. O/A;
2. confirmation of session modification;
3. session usage in practice.

Without precondition, O/A means 1 & 2, but not 3.

With precondition, O/A just means 1, not 2 & 3.

And I think "confirmation of session modification" should be treated as 
signalling of changing of session state, while not "session usage in 
practice".

For O/A without precondition, finish of current O/A can be treated as 
signalling of "2". Further, offerer or answerer can decide to send("3") 
new session separately.　But for O/As with precondition, there is no such 
evident signalling for "2". While the answer with precondition can not be 
treated as the acceptance of current modification, the offerer should not 
use the new session firstly. So, it is rational(but not normatively 
defined) for the answerer to start to use the new session firstly.
If we obey this suggestion, UAC(if UAC sends Re-INVITE with offer) should 
not use new session firstly. And the case can be OK.
While the UAS is the offerer(UAC sends Re-INVITE without offer), UAC and 
UAS can rationalize its behavior according to this suggestion too.

For integrality, we should talk about the case which has susequent O/A 
with new modification during suspending state of previous modification.
If the answerer accepts the new modification and send the answer, the UAS 
should not sends 3xx-6xx(something has been changed).
If the answerer can not accept the new modification(such as needing user's 
confirmation), the answerer should reject the offer(if the reason is 
needing user's confirmation, the proper response can be 504). As the 
rejection, the original modification would process as if there's no 
subsequent O/A.

Thanks.

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-01-04 21:31

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

主题
[sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

Gonzalo,

                 Thanks,
                 Paul
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Jan 2010 13:49:06 -0500

[email-masked] wrote:
> 1. *O/A*;
> 2. *confirmation of session modification*;
> 3. *session usage in practice*.
> 
> And I think *"confirmation of session modification*" should be treated 
> as signalling of changing of session state, while not "*session usage in 
> practice*".

First, I want to hear what Gonzalo has to say, since it is his draft,
and he had in mind how it would work.

Second, lets see if things are clear without use of preconditions before
discussing how use of preconditions might change things.

	Thanks,
	Paul

> new session separately.　But for O/As with precondition, there is no 
> such evident signalling for "2". While the answer with precondition can 
> not be treated as the acceptance of current modification, the offerer 
> should not use the new session firstly. So, it is *rational(but not 
> normatively defined) *for the answerer to start to use the new session 
> firstly.
> If we obey this suggestion, UAC(if UAC sends Re-INVITE with offer) 
> should not use new session firstly. And the case can be OK.
> If the answerer accepts the new modification and send the answer, the 
> UAS should not sends 3xx-6xx(something has been changed).
> If the answerer can not accept the new modification(such as needing 
> user's confirmation), the answerer should reject the offer(if the reason 
> is needing user's confirmation, the proper response can be 504). As the 
> *Paul Kyzivat <[email-masked]>*

---

From: [email-masked]
Date: Thu, 7 Jan 2010 08:53:36 +0800

> and he had in mind how it would work.

Sure. And I look forward to Gonzalo's point too.

Thank,

Gao

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 13 Jan 2010 11:12:53 +0200

Hi Paul,

yes, that section of the draft includes a 'TODO' part because it does 
not provide an acceptable solution yet. What we need to decide, as you 
suggest in your email, is the point where the new session parameters are 
considered to be in use.

Without preconditions, this should be easy. When the new offer/answer 
completes, the new parameters are in use.

With preconditions, it is a bit more complex. The new parameters should 
be considered to be in use when the preconditions are met. The issue 
here is that, in some cases, it is the UAS the one that figures out when 
the preconditions are met and starts sending media using the new 
parameters, sometimes without issuing any SIP signalling. I wrote a 
draft a while ago describing this issue and explaining how the UAS can 
use SIP to signal the fact that the new parameters are now in use:

http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt

Using SIP signalling instead of having the UAC discover that the new 
parameters are in use at the media level is useful when the stream does 
not carry media continuously.

Therefore, I would propose to consider that the new parameters are in 
use when the following happens:

o an offer/answer without preconditions for the stream completes 
successfully, or
o an offer/answer where all the preconditions for the stream are met 
completes successfully, or
o media is received using the new parameters

Additionally, we may want to resurrect the draft above about 
preconditions so that the issue is described in more detail. However, 
last time I asked people were not that interested in the draft. If we 
want to resurrect it now, I would be OK with doing so.

Thanks,

Gonzalo

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 13 Jan 2010 07:53:55 -0600

> o media is received using the new parameters

I've never been a fan of implicit behavior, so this gets my vote. I'd
even vote for not allowing the endpoints to use the new parameters at
all until the offer/answer is complete, but I can understand the
motivation for allowing it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jan 2010 09:45:30 -0500

inline

> completes, the new parameters are in use.

Hmm. That seems inconsistent with current text:

The above seems to imply that "in use" will happen later than the 
completion of the o/a exchange - potentially quite a bit later if there 
was already data in the playout buffer before the o/a exchange.

> o media is received using the new parameters

That might help, but I don't think it totally solves the problem of the 
two sides having different ideas of whether the parameters are in use.

The o/a exchange is presumably done for the offerer when it receives the 
answer. But when is the o/a exchange done for the answerer? Is it when 
it first sends the answer, or when it gets some signaling indication 
that the answer was received? To be safe, in the absence of 
preconditions, it seems that the answerer should consider the new o/a 
parameters to be in use as soon as the answer has been *sent*.

Also, if the UAS for the reinvite has sent an offer (in something other 
than a 2xx for the reinvite) and has not yet received the answer to that 
offer, it must not send a failure response to the reinvite, because it 
doesn't yet know if that o/a is complete in the eyes of the answerer.
(Exception: it can send an error response that terminates the complete 
call/dialog, such as a 408.)

> want to resurrect it now, I would be OK with doing so.

I don't know about that draft, but it seems we need *something* to 
clarify the behavior in that case.

	Thanks,
	Paul

> Thanks,
> 
> Gonzalo
> 
> 
> Paul Kyzivat wrote:
>> Gonzalo,
>>
>> Over the holidays I had occasion to review the above document again, 
>> and I have a question about the criterion you propose for sending an 
>> error response or not:
>>
>> Consider the case where the o/a has been performed, and the UAC has 
>> sent media according to the new session description, but the UAS has 
>> not yet sent or received that media according to the definition above. 
>> In that case, the UAS may choose to send an error response. But the 
>> UAC has already made the change to the new session, and so will need 
>> to switch again to the old one. This is the case you are attempting to 
>> avoid, and yet it has not been avoided. I don't see an easy answer to 
>> this - only messy ones.
>>
>>     Thanks,
>>     Paul
>>
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 13 Jan 2010 17:46:21 +0200

Hi Paul,

> Hmm. That seems inconsistent with current text:

[snip]

> was already data in the playout buffer before the o/a exchange.

yes, what I was proposing was to replace the current text with the rule 
I was proposing above.

> parameters to be in use as soon as the answer has been *sent*.

yes, that is also what I had in mind.

> call/dialog, such as a 408.)

this is just one of the race conditions we need to tackle (the draft has 
a second TODO section about that). I am working on defining procedures 
to avoid this and other race or glare situations.

> clarify the behavior in that case.

I will add explanations in this draft... if we are happy with them, we 
do not need the other draft. Otherwise, we could think about it.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jan 2010 10:33:50 +0200

Hi,

I have put together a new version of the draft:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt

Let me know if you have some comments before I submit it.

Regarding the decision about when a given change in the session state 
has been executed when preconditions are used, I have added a paragraph 
that summarizes our discussions and the following draft:

Please, read Section 5.

Sections 7 and 15 contain new rules to avoid glare situations and race 
conditions. These rules avoid nasty call flows that were able to get the 
UAs out of synch.

Some time ago, we discussed whether or not unreliable provisional 
responses could refresh the remote target. There are several problems 
with unreliable responses updating remote targets. First, we would need 
to define even more rules to avoid glare situations and race conditions. 
Second, SIP does not provide any ordering for unreliable provisional 
responses. Responses arriving out of order at the UAC could easily get 
both UAs out of synch. Therefore, only reliable responses can refresh 
remote targets, as was specified in RFC 3261 anyway.

We also discussed the applicability of the target refresh rules to 
initial INVITEs. The rules in the draft cover them as well so I do not 
think we need to add anything else to that end.

Thanks,

Gonzalo

---

From: [email-masked]
Date: Sat, 16 Jan 2010 10:45:44 +0800

Hi,

Maybe clarification of precons has something beyond Re-INVITE handling 
text. 

As Re-INVITE handling text aims for updating of RFC3261, we may need a 
detailed normative text for updating RFC3312 & RFC4032. And we can talk 
topics relating to precons but outside of the scope of Re-INVITE handling 
text, such as "resuming and suspending for session or for separate 
stream".

Two separate text means different maintenance process and lifecycle. If we 
can guarantee the consistency and integrality of the two text, I think two 
text would be clear for two (relating) topics.

Thanks,

Gao

Gonzalo Camarillo <[email-masked]> 
发件人:  [email-masked]
2010-01-14 16:33

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

主题
Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

Hi,

Please, read Section 5.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jan 2010 10:14:12 +0200

Hi Gao,

that is why I wrote the draft about preconditions. However, not many
people showed interest in it at that time.

Cheers,

Gonzalo

[email-masked] wrote:
> topics relating to precons but outside of the scope of Re-INVITE 
> handling text, such as "resuming and suspending for session or for 
> separate stream".
> 
> Two separate text means different maintenance process and lifecycle. If 
> we can guarantee the consistency and integrality of the two text, I 
> think two text would be clear for two (relating) topics.
> 
> Thanks,
> 
> Gao
> 
> *Gonzalo Camarillo <[email-masked]>*

---

From: [email-masked]
Date: Mon, 18 Jan 2010 18:25:17 +0800

Hi Gonzalo,

Yes, I also found that not many people showed interest in it.

By deeply discussion "Re-INVITE handling" draft these days, we find that 
we should clarify how modified media can/should be used. But how modified 
media can/should/may be used is a more basic topic.

This topic has influence on other higher level topics, such as "Re-INVITE 
handling" draft and etc. So, I hope more people could pay attention to it.

Thanks,

Gao

2010-01-18 16:14

收件人
"[email-masked]" <[email-masked]>
抄送
SIPCORE <[email-masked]>
主题
Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

Hi Gao,

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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jan 2010 13:49:44 +0200

Hi Gao,

let's proceed as follows. Let's focus our efforts in finishing the
re-INVITE draft for now. Once we are done with it, let's decide whether
or not we want to work on clarifying all the open issues related to
preconditions we have been talking about.

Thanks,

Gonzalo

[email-masked] wrote:
> we should clarify how modified media can/should be used. But how 
> modified media can/should/may be used is a more basic topic.
> 
> This topic has influence on other higher level topics, such as 
> "Re-INVITE handling" draft and etc. So, I hope more people could pay 
> attention to it.
> 
> Thanks,
> 
> Gao
> 
>  > 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.

---

From: [email-masked]
Date: Mon, 18 Jan 2010 20:03:18 +0800

Hi Gonzalo,

Yes, we can do it in different sequence.

Cheers,

Gao

2010-01-18 19:49

收件人

Hi Gao,

Thanks,

Gonzalo