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

[Gonzalo Camarillo <[e-mail]>]

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


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