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