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

[Paul Kyzivat <[e-mail]>]

inline

Gonzalo Camarillo wrote:
> 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.

Hmm. That seems inconsistent with current text:

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

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.

> 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

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

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

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