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

[[e-mail]]

Hi,

Paul's words are alway constructive. And I just want to have a further 
talk about two parts of the Comments:

1. The feasibility of the way in the draft.

2. BCP and standard.

more inlines.

Thanks.

Gao

Paul Kyzivat <[e-mail]> 写于 2009-07-07 07:37:22:

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

[Gao] O/A exchange can not be processed in dialog/transaction(including 
INVITE and UPDATE) which is rejected 
due to authorization, overload. So, there are not the cases.

But for cautel, we need to demonstrate that there is no case/need to send 
error code(non-2xx) after O/A exchange. We can deduce as:
Three precondition(IMO, satisfied):
1. O/A exchange is in application level which is upon the sip level. And 
before the application level's processing, sip level should get ready. 
2. There are only two soure of error: application level itself and sip 
level. 
3. This draft talked about the way of avoiding sending error code(non-2xx) 
for application level's reason, such as rejecting media/media stream. 
Deduction:
Then the remaining part is demonstrating there is no case/need to send 
error semantics message(non-2xx/Cancel) for sip level's reason after O/A 
exchange.

If the deduction can be proved to be true, then the way in the draft is 
feasible.

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

[Gao] I am agreed that BCP(showing what is better) is needful, but not 
enough. For example, it is a hard work to make our IMS/AS system 
interworking with different UEs(SIP) which has different points of view 
for session state after un-successful Re-INVITE.

And absence of the standard(showing what is right) for session state would 
making equipment-interworking indeterminably.

>    Thanks,
>    Paul
> 
> 
> 



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