Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

[OKUMURA Shinji <[e-mail]>]

Hi Gonzalo,

I arrange my comments to clarify the issues.

First, as a precondition for new rules, this text updates
RFC3261. And so it is necessary to minimize the change in
consideration of backward compatibility.
I think this principle should be given priority to over the
KISS principle. Therefore we should clarify not a sufficient
condition but a necessary and sufficient condition.

Second, you describe the rules about O/A and target-refresh
at once. But I prefer to describe the two issues separately
in order to clarify the reason why the rule is necessary.
As we discuss the rules, it is acceptable result that the rules
are unified accordingly. But it is premature at this moment in
time.

>>>>>   The rules in RFC 3261 [RFC3261] do not cover collisions between an
>>>>>   UPDATE request and a reliable response to a re-INVITE (non-2xx final
>>>>>   responses to the re-INVITE are also considered reliable responses).
>>>>>   Since both the UPDATE request and the reliable response could be
>>>>>   requesting changes to the dialog or session state, it would not be
>>>>>   clear which changes would need to be executed first.
>>>>>
>>>>>   If the UAS of a re-INVITE transaction receives and UPDATE request
>>>>>   after having sent a reliable response to the re-INVITE but before
>>>>>   having received the corresponding ACK or PRACK request, the UA SHOULD
>>>>>   return a 491 (Request Pending) response to the UPDATE request.
>>>> 
>>>> I think this rule is more restrictive.
>>>> IMO;
>>>> In case that the reliable response is 18x, the UA SHOULD return a "500" response.
>>>> In case that the reliable response is 2xx;
>>>>     If the 2xx carries an offer, the UA SHOULD return a "500" response.
>>>>     Otherwise, the UA MAY return a 2xx response.
>>>> In case that the reliable response is 4xx, the UA MAY return a 2xx response.
>>>
>>> No, these rules would not address the glare situation.

>From an offer-answer perspective, you should agree that
there is no problem.

>> I am very interested in this topic. Laying aside the
>> response code, I don't understand the reason why these rules
>> would not address the glare situation.
>> Please explain the reason.
>>
>> In below cases, if a UAS returns a 2xx to the UPDATE, IMO
>> no ploblem would be occured.
>
> as we discussed in the past, the collision of two given messages may or
> may not be a problem. For example, two UPDATEs colliding each of them
> updating a different parameter would not be a problem... but if they
> update the same parameter the collision would get both UAs out of synch.
> For the sake of simplicity, instead of having UAs implement complex
> rules to figure out if a particular collision would cause problems, we
> specify general rules that are (relatively) easy to implement by user
> agents.
>
> So, let's take your example below
>
>>                A                               B
>>                |                               |
>>              s0|re-INVITE (offer1)             |s0
>>                |------------------------------>|
>>                |               18x-rel(answer1)|
>>                |<------------------------------|
>>              s1|PRACK                          |s1
>>                |------------------------------>|
>>                |                        2xx-PRA|
>>                |<------------------------------|<-+
>>                |                            2xx|  |
>>                |                /--------------|  |
>>                |UPDATE(offer2) /               |  |
>>                |==============/===============>|  | accept PDATE
>>                |             / 2xx-UPD(answer2)|  |
>>                |<===========/==================|  |
>>              s2|           /                   |s2|
>>                |<---------/                    |  |
>>                |ACK                            |  |
>>                |------------------------------>|  |
>>                |                               |  v
>
>
> both the 2xx to the INVITE and the 2xx to the UPDATE can update the
> dialog's target. As you see, the UAC receives them in a different order
> than they were sent. So, for the UAC the latest target refresh was the
> 2xx to the INVITE but for the UAS the latest target refresh was the 2xx
> to the UPDATE.

Your rules force a UAS to return a 491 response to the UPDATE.
But if I understand a current RFCs correctly, a UAS may accept
the UPDATE.

Certainly, your rules are new normative definitions.
I understand it. However if the 2xx to an UPDATE and the 2xx
to a re-INVITE have the same Contact, there is no problem.
And it is unnecessary to make an O/A exchange fail.

In any cases, we can not deny the possibility that a legacy
UAS returns a 2xx to the UPDATE with a different Contact.
Therefore a UAC MUST be prepared to receive the 2xx.

In this case, IMO UAC behavior are;
 1. A UAC must treat the Contact in 2xx to an UPDATE as
    current remote target. 
 2. In below cases, a UAC should send new target refresh request.
   a. it has sent UPDATE, received 2xx to UPDATE, and then
      received 2xx to re-INVITE with a different Contact.
   b. it has received UPDATE, sent 2xx to UPDATE, and then
      received 2xx to re-INVITE with a different Contact.
   c. it has sent UPDATE, received 2xx to re-INVITE, and then
      received 2xx to UPDATE with a different Contact.

Regards,
Shinji

Gonzalo Camarillo <[e-mail]>
Wed, 30 Jun 2010 15:03:27 +0300
>Hi Shinji,
>
>thanks for your comments. I already responded to your first example in
>my previous email. In your second example, the ACK (which does not carry
>an answer) is not a problem because it is not a target refresh request.
>
>Thanks,
>
>Gonzalo