Re: [sipcore] New revision of the re-INVITE handling draft

[Paul Kyzivat <[e-mail]>]

Gonzalo,

Thanks for doing this work! I do have some comments:

Section 3/Figure 1

The figure shows a 6xx response.
The text says that the UAS wants to reject the new offer.

A UAS would probably not use a 6xx response to reject media.
(I guess it might use 606, but 488 would be more appropriate.)
In fact, it probably would not reject the request at all, but rather 
would just refuse the added media stream.

The point being made doesn't require that the response be 6xx or that it 
be with the purpose of refusing the media. So I think what is needed 
here is to find a plausible example to make the point.

A good one for the purpose here might be a 488 to reject the media, or a 
  401 response as another sort of reason for rejecting the whole thing 
but wanting to preserve what there is.

Section 5:

>    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.  Unsurprisingly, the
>    UAS considers the new parameters to be in use when it actually starts
>    using them. 

I'm not entirely following this. I think there may be an assumption here 
that the UAC is the offerer and the UAS the answerer. I'm guessing you 
are saying that the answerer considers the new parameters to be in use 
when it actually starts using them.

Since this section is about the UAS (for the reinvite), this point is 
probably that when the UAS is also the answerer it can decide when the 
new media is in use based on when it starts using them.

But what happens when the UAS is the offerer? In that case I think it 
must assume the media is in use as soon as it is offered. But maybe that 
isn't always the case with preconditions. I don't think it can wait till 
it receives media, because media may be in flight when it makes its 
decision.

>    As described in Section 8.3.1 of RFC 3264 [RFC3264], the
>    UAC considers the new parameters to be in use when media is received
>    in the new port, which should be interpreted as follows:
> 
>       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.

I don't know what the above has to do with the behavior of the UAS.

> 9.  Clarifications on Target Refresh Requests
> 
>    On receiving a target refresh request with an updated remote target,
>    a UAS updates the remote target of the dialog immediately.  This
>    update represents the execution of a state change.  Therefore,
>    following the rules in Section 5, UASs always return 2xx responses to
>    target refresh requests that update the remote target.

This does not address cases where the UAS cannot accept the change with 
a 200. Some cases that fall into this category are:

- request includes a Require of an unsupported option (e.g. 100rel)
- request cannot be authorized
- server overload
- precondition failure

In any case, if no state changes have been made prior to the request 
with a target change, then there is no issue with rejecting the target 
refresh if need be.

The issue with target refresh is that the UA sending it may have an 
urgent need for it to be accepted, since it may not be able to 
communicate on its old address(es) any longer. And if that is the case 
it may also have an urgent need to change its media addresses as well 
for the same reason. That would be motivation for doing both at once.

If a reINVITE includes a target change, then its very difficult to know 
when the UAC must begin using it. So I think the UAS must assume it must 
be considered in use immediately. Hence it should *try* to avoid 
rejecting the request, even if it must reject all the media in the 
request. But there is still a possibility that it will have to reject 
due to authorization, overload, etc. If that is done right away its no 
different than any request rejected before any changes have been made.

A difficult case is where a reINVITE has been initiated, and has not 
completed. (Perhaps its ringing.) Then the UAC loses its IP address or 
IP connectivity and needs to make a target change. So it sends an UPDATE 
with the target change. What it should probably do in that case is *not* 
include an offer in the UPDATE. Then it can't be rejected for o/a 
reasons. Once that is done it can continue the o/a process, updating its 
media addresses when it has the chance. Once the UAC target has changed, 
the UAS should not fail the INVITE. If need be it should reject all the 
media in order to avoid that.

Another difficult case if if a reINVITE has been initiated and the UAS 
finds it needs to change its address. Similar considerations to above 
seem to apply.

Frankly, this is all very nasty, and those in this situation may have 
few options for what do do. It feels deserving of its own treatment. 
Namely a whole call flow document with various use cases where target 
change is required. Probably a BCP.

	Thanks,
	Paul