Re: [reSIProcate-users] 200/CANCEL race

["Krister Jarl" <kj@xxxxxxxxxxx>]

It seems as if I was a little quick in my analysis. The scenario is not quite 
as I explained below. I've found the problem on our side.

Thanks for your help!

/KJ

>-----Ursprungligt meddelande-----
>Från: Jason Fischl [mailto:jason.fischl@xxxxxxxxx]
>Skickat: den 14 januari 2009 15:08
>Till: Krister Jarl
>Kopia: resiprocate-users@xxxxxxxxxxxxxxx
>Ämne: Re: [reSIProcate-users] 200/CANCEL race
>
>I think this is correct behavior. The UAC needs to send a BYE if it
>receives a 481 to the CANCEL in order to terminate the session.
>
>Coding a work-around in your application would require changes in the
>transaction state machine of resiprocate and would likely introduce
>unintended consequences. Is the UAC vendor not willing to budge on
>this one? What is the behavior at the UAC after receiving the 481 to
>the CANCEL?
>
>Jason
>
>
>On Wed, Jan 14, 2009 at 8:58 AM, Krister Jarl <kj@xxxxxxxxxxx> wrote:
>> Hi!
>>
>>
>>
>> I've got a question regarding a race condition. In this case our
>reciprocate
>> based application receives an INVITE from a slightly broken UA. The 200
>> response and CANCEL cross each other on the wire and we get the following
>> scenario.
>>
>>
>>
>> <-------INVITE------
>>
>> ----------100-------->
>>
>> ----------180-------->
>>
>> ----------200-------->
>>
>> <------CANCEL----
>>
>> ---------481--------->
>>
>> (resending of 200 is omitted)
>>
>>
>>
>> The behaviour in reciprocate is correct, after 200 is sent there's no
>> request to cancel, hence the 481 response. But is there any way to be
>able
>> to support this scenario other then fixing the broken UA? I understand
>that
>> this may be hard due to RFC 3261 bug id 769.
>>
>>
>>
>> Cheers
>>
>> KJ
>>
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users@xxxxxxxxxxxxxxx
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>