Because this is a bug where the fix hasn't been formally fixed, I don't
think it is safe to assume *either* that it has been fixed or it hasn't.
So I think a BCP should allow both, with an explanation.
Paul
Venkatesh wrote:
> I am not sure if that is a reasonable argument. This behavior has been
> acknowledged as a bug in the RFC 3261. The bug detailes what the fix for the
> same is going to be. I assume that this change in behavior will make it into
> a RFC sometime in future. Not sure an example draft that contradicts this
> behavior is a good idea.
>
> For this specific scenario under consideration the far end is going to get a
> 200 OK for the CANCEL (instead of a 481 response). It is still going to have
> to complete the INVITE transaction and tear down the call with a BYE.
>
> Venkatesh
>
>
> On 5/18/06, Frank Shearar <[EMAIL PROTECTED]> wrote:
>> Sure, I agree that there's an open bug. Nonetheless, if you write a stack
>> to
>> fix the bug, then your stack isn't quite RFC 3261 compliant anymore. UACs
>> that expect you to follow the RFC will then be surprised. (Caveat: I've
>> not
>> thought through what cases might lead to unexpected behaviour.)
>>
>> frank
>>
>> ----- Original Message -----
>> From: "Venkatesh" <[EMAIL PROTECTED]>
>> To: "Frank Shearar" <[EMAIL PROTECTED]>
>> Cc: <[email protected]>
>> Sent: Thursday, May 18, 2006 4:26 PM
>> Subject: Re: [Sip-implementors] Question
>> regardingdraft-hasebe-sipping-exceptional-procedure-examples-02.
>>
>>
>> I meant the UAS is not supposed to terminate the INVITE transaction on
>> sending a 200 OK response for the INVITE.
>>
>> On 5/18/06, Venkatesh <[EMAIL PROTECTED]> wrote:
>>> Please refer to the bug I referred to in my previous email that is open
>>> against RFC 3261. It clearly indicates that the UAS is not supposed to
>>> terminate the INVITE transaction on sending a 200 OK response for the
>>> response. If this were indeed to be the case, the UAS will still find
>> the
>>> INVITE transaction and that is my point.
>>>
>>> Venkatesh
>>>
>>>
>>> On 5/18/06, Frank Shearar <[EMAIL PROTECTED]> wrote:
>>>> "Venkatesh" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>> Section 2.1 of this draft illustrates a scenario where by a CANCEL
>> and
>>>> a
>>>> 200
>>>>> OK for the INVITE cross the wire. The draft suggests rejecting the
>>>> CANCEL
>>>>> with a 481 final response. I am not sure this is correct behavior.
>> The
>>>> UAS
>>>>> must send a 200 OK for the CANCEL request (as it would find the
>> INVITE
>>>>> transaction). INVITE transacations are not supposed to be destroyed
>>>> when a
>>>>> 200 OK response for the INVITE is sent by the UAS. I believe there
>> is
>>>> a
>>>> bug
>>>>> open against RFC 3261 for the same (
>>>>> http://bugs.sipit.net/show_bug.cgi?id=769)
>>>> RFC section 9.2 says regarding a UAS processing a CANCEL request
>>>>
>>>> If the UAS did not find a matching transaction for the CANCEL
>>>> according to the procedure above, it SHOULD respond to the CANCEL
>>>> with a 481 (Call Leg/Transaction Does Not Exist).
>>>>
>>>> In Hasebe et al's draft(*), Bob's 200 OK terminates his INVITE
>>>> transaction.
>>>> As a result, when Alice's CANCEL arrives, Bob cannot match the CANCEL
>>>> against a transaction, so must return a 481.
>>>>
>>>> (*) The draft's name has changed to
>> draft-hasebe-sipping-race-examples,
>>>> and
>>>> in the new draft this scenario is in section 3.1.2.
>>>>
>>>> frank
>>>>
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> [email protected]
>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
