Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

[Gonzalo Camarillo <[e-mail]>]

Hi Paul,

thanks for your comments. Answers inline:

On 21/07/2010 9:47 PM, Paul Kyzivat wrote:
> Gonzallo,
> 
> Sorry it took me so long, but I finally got time to read the new version 
> carefully.
> 
> This is looking good. I have a few nits, and a couple of things that 
> might be more than nits.
> 
> 3.1:
> 
> nit:
> s/The UAS is automatically configured to reject video streams/The UAS is 
> configured to automatically reject video streams/

Fixed.

> 
> 3.3:
> 
>     A change to the session state is considered to have been executed if
>     an offer/answer without preconditions [RFC4032] for the stream has
>     completed successfully or the UAs have exchanged media using the new
> 
> "exchanged" is a tricky word here, and could use some added definition.

I have done the following:

OLD:
...or the UAs have exchanged media using the new parameters

NEW:
...or the UA have sent or received media using the new parameters


> A UA can know if it has *sent* media, and it can know if it has 
> *received* media. If media has been received (and can be distinguished 
> from the media that would have been received had the change not 
> occurred) then that UA knows media has been exchanged. But it doesn't 
> know if the other UA knows media has been exchanged. We want both sides 
> to reach the same conclusion regarding the exchange of media, but I'm 
> not sure how to assure that.

You cannot do this in a simple way. For RTP over UDP media, you would
need to look at the RTCP information. For TCP media, you would need to
look into the TCP data (unless the media stream itself provided some
type of acks). So, I think this is the best we can do without adding a
level of complexity that nobody would really implement just to resolve
corner cases.

> So, from the perspective of one of the UAs, how do you propose that this 
> decision be made? Is it just "I have received media according to the new 
> sdp"?

I have received or sent media (or both) using the new sdp.

> What about cases where no media is expected to be exchanged as a result 
> of the new O/A?  E.g. Suppose the change was simply from "a=sendrecv" to 
> "a=inactive". Is the absence of packets for some period of time evidence 
> that this is in effect?

To cover all these cases, the UAs can perform a new offer/answer
exchange without preconditions, as described in that section. That is
the more general way to indicate that the session parameters are in use.

> 
> 3.4:
> 
> nit:
> 
>     and the session parameters in the offer/answer exchange SHOULD be as
>     close as those in the pre-re-INVITE state as possible.
> 
> s/close as those/close to those/

Fixed.

> 
> 4.4:
> 
>     If the UA receives a reliable provisional response or a 2xx response
>     to the target-refresh request, or the UA receives a request on the
>     new local target, the remote UA has updated its remote target.  The
>     UA can consider the target refresh operation completed.
> 
> It isn't sufficient to receive a request on the new target - it must be 
> a request *within the dialog. (It might receive an out of dialog request 
> from another source, or otherwise unrelated.) (This is covered in 4.6, 
> but good to catch it here too.) So I suggest:
> 
>     If the UAC receives a reliable provisional response or a 2xx response
>     to the target-refresh request, or the UAC receives an in-dialog
>     request on the new target, the UAS has updated its remote target.
>     The UAC can consider the target refresh operation completed.

Fixed.

> 
> 4.6:
> 
> nit:
> s/ n-dialog/ in-dialog/

Fixed.

> 
> In the note discussing reliable provisional responses, it might be good 
> to reference RFC 4320 that says they MUST NOT be used for non-invite 
> transactions.

I have added a reference to RFC 4320.

Thanks,

Gonzalo