Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.txt

From: [email-masked]
Date: Wed, 19 May 2010 10:32:16 +0800

Hi,

In the address line of your mail, there's the mail list's address. But 
your mail is not in the archive. I suggest you chech your internal mail 
server and request Oscar to check the mail list's server for your e-mail 
address.

Contents inlines.

Thanks,

Gao 

> In 4.5.  Race Conditions and Target Refreshes, 
>    Additionally, UAs MUST treat
>    the exchange of a 2xx response to an INVITE request and its
>    corresponding ACK request as an offer/answer exchange.
> 
> What do above descriptions require to UAS?

This requires UAC and UAS (UAs). And the specific demand is to treate such 
messages as if with O/A.

> 
> >In my understanding, it is crossing case, while not glare one.
> 
> The figure in the previous mail is a glare case of UPDATE.
> And the crossing case of UPDATE is shown as below.
> 
>     A                               B
>     |                               |
>     |re-INV (offer1)                |
>     |------------------------------>|
>     |                   18x(answer1)|
>     |<------------------------------|
>     |                        non-2xx|
>     |<------------------------------|
>     |                               |
>     |                   /---------->|*
>     |ACK               /            |
>     |-----------------/------------>|
>     |                /              |
>     |UPDATE (offer2)/               |
>     |--------------/                |
>     |                               |
> 
> UAS will not be able to recognize the difference between
> the glare case and the crossing case.
> 

Yes, UAS can not recognize the difference. So, this use case has 
ambiguity, and in UAS's view, this is a glare case.
And the UAS would send 491, the session state would be the same in UAC and 
UAS's view.

I'd like to put your glare case further:

UAC send UPDATE in scope of Re-INVITE in it's view(before non-2xx of this 
Re-INVITE). But UAS get the UPDATE after the non-2xx(Re-INVITE)'s ACK.
UAC's view: UPDATE is in scope of the Re-INVITE;
UAS's view: UPDATE is out scope of the Re-INVITE.
For this case, the text suggest UAC send a new Re-INVITE/UPDATE after the 
2xx of UPDATE. This is defined in 3.5:

If
   the UAC of a re-INVITE transaction sends an UPDATE request with an
   offer, receives a non-2xx response to the re-INVITE, and then a 2xx
   response to the UPDATE request, the UA 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, as described in Section 3.4.

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

---

From: [email-masked]
Date: Fri, 28 May 2010 19:07:28 +0800

//It seams that mail list doesn't dispatch this mail. To let other people 
catch up the thread, I re-send it.

> 
> I understand.
> 
> The text says that the UAC can not expect to receive a 487
> response to the INVITE. Right?

As UAC's old contact has been lost, UAC can not expect to receive any 
final response for the old Re-INVITE here.
So, the specific for final response is not important here. And the UAC's 
next Re-INVITE as synchronization can refresh the state here. 

> 
> And now, assuming that some of changes have already been
> executed, the UAS would send a new UPDATE to undo the changes.
> But the local target of the UAC has been changed, so I think UAC
> should an UPDATE to announce own new target before sending the
> CANCEL.
> 
> Do you think so?

I think the UAC should send a target refresh UPDATE before CANCEL. But the 
reason is not about UAS's rollback usage UPDATE.(the state would be 
synchronized by a next Re-INVITE).

To send a new request(the CANCEL) at new address, sending a target refresh 
UPDATE before the new request (the CANCEL) might be better.