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

[[e-mail]]

Hi，

Please see inlines.

Thanks.

Gao

OKUMURA Shinji <[e-mail]> 写于 2009-07-07 18:15:08:

> Hi,
> 
> I have some comments.
> 
> RFC3261 describe about the atomic process.
> 
> 8 General User Agent Behavior
>  8.2 UAS Behavior
>    Note that request processing is atomic.  If a request is accepted,
>    all state changes associated with it MUST be performed.  If it is
>    rejected, all state changes MUST NOT be performed.
> 
> 12 Dialogs
>  12.2 Requests within a Dialog
>  12.2.2 UAS Behavior
>    Requests sent within a dialog, as any other requests, are atomic.  If
>    a particular request is accepted by the UAS, all the state changes
>    associated with it are performed.  If the request is rejected, none
>    of the state changes are performed.
> 
> 14 Modifying an Existing Session
>  14.1 UAC Behavior
>    If a UA receives a non-2xx final response to a re-INVITE, the session
>    parameters MUST remain unchanged, as if no re-INVITE had been issued.
> 
> above rule work fine for re-INVITE and PRACK. but I think that UPDATE
> and precondition procedure was considered insufficiently about an error
> response to a re-INVITE.
> 
> if all changes executed by UPDATE transactions are excluded from the
> rollback, are there any problems?
> 

[Gao] As media negotiation overlap more than one O/A pairs such as 
precondition, then it will use UPDATE/200OK as subsequent O/A pair after 
the first O/A pair(INVITE/183 or 183/PRACK). And in such case, we can not 
let UPDATE/200OK's O/A pair alone after un-successful Re-INVITE. So, IMO, 
making all changes executed by UPDATE transactions excluded from the 
rollback is not nice way.


> That is,
> 
>   |   INVITE     |                  |              |
>   |------------->|                  |              |
>   |   183        |                  |              |
>   |<-------------|                  |              |
>   |   PRACK      |                  |              |
>   |------------->|                  |              |
>   |   200(PRACK) |                  |              |
>   |<-------------| is identical to  |              |
>   |   UPDATE     |                  |   UPDATE     |
>   |------------->|                  |------------->|
>   |   200(UPDATE)|                  |   200(UPDATE)|
>   |<-------------|                  |<-------------|
>   |   488(INVITE)|                  |              |
>   |<-------------|                  |              |
>   |   ACK        |                  |              |
>   |------------->|                  |              |
> 
> 
> This updates RFC3311.
> 
> But at this point, I have one doubt.
> May precondition procedure be started by UPDATE?
> 

[Gao] As there is no specific restrict about precondition procedure 
started by UPDATE, then UAC can send a UPDATE as Offer(with precondition) 
outside of Re-INVITE.
But if the qos strength is mandatory, and the UAS can not reach the 
desired qos, it MUST reject the Offer with 504. So, at BCP level, we 
should trigger new session modification with precondition in Re-INVITE 
instead of UPDATE.

> >4.  Problems with Error Responses and Already-executed Changes
> >   Using an error response to undo already executed changes presents an
> >   additional problem.  Section 4 of [RFC3264] specifies rules to avoid
> >   glare situations (i.e., to avoid offer/answer collisions in race
> >   conditions).  Even when both UAs generate an offer at the same time,
> >   there are rules to determine which one should be processed first.
> >   However, there are no rules to avoid a collision between an offer in
> >   an UPDATE request and an error response for a re-INVITE.  Since both
> >   the UPDATE request and the error response would request changes, it
> >   would not be clear which changes would need to be executed first.
> >   This is yet another reason why UASs should not use error responses 
to
> >   undo already-executed changes.
> 
> I think glare situations occur in three cases.
> 
> 1.
>  | UPDATE       488(reINVITE) |
>  |---------\   /--------------|
>  |          \ /       ACK     |
>  |           X       -------->|
>  |          / \               |
>  |<--------/   \------------->|
>  |                            |
>  |                 200(UPDATE)|
>  |<---------------------------|
>  |                            |
> 
> 2.
>  | UPDATE                     |
>  |--------------------------->|
>  |                200(UPDATE) |
>  |<--------\   /--------------+
>  |          \ /               |
>  |           X                |
>  |          / \ 488(reINVITE) |
>  |<--------/   \--------------+
>  |                    ACK     |
>  |                   -------->|
>  |                            |
> 
> 3.
>  |               488(reINVITE)|
>  |<--------\   /--------------|
>  |          \ /      ACK      |
>  |           X      --------->|
>  |          / \        UPDATE |
>  |         /   \--------------|
>  |        /                   |
>  |       /  200(UPDATE)       |
>  |------/-------------------->|
>  |     /                      |
>  |<---/                       |
>  | 
> 
> 
> >6.  UAC Behavior
> >   In order to cope with this type of UAS, a UAC that receives an error
> >   response to a re-INVITE for which changes have been already executed
> >   SHOULD generate a new re-INVITE or UPDATE request in order to make
> >   sure that both UAs have a common view of the state of the session.
> 
> If all changes are the results of only re-INVITE and PRARK, I think
> new UPDATE(or re-INVITE) request is not necessary.
> 
> Regards,
> Shinji
> 
> 
> 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
> 



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