[reSIProcate] problems with race condition between CANCEL andanegative response

[Scott Godin]

Yes - this is a real race condition problem in DUM.  We need to be able
to linger the DialogSet around for some period of time after sending a
CANCEL, so that if we get a subsequent final response to the INVITE it
can be handled properly.

Scott

> -----Original Message-----
> From: resiprocate-devel-bounces at list.sipfoundry.org
> [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
> Hagai Sela (TA)
> Sent: Tuesday, October 24, 2006 8:59 AM
> To: Jinke Jiang
> Cc: resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] problems with race condition between CANCEL
> andanegative response
> 
> I agree. I don't create the messages myself, I am using DUM. I just
> call
> AppDialogSet::end(), this should send the ACK to the negative response
> instead of sending a CANCEL.
> 
> Hagai.
> 
> -----Original Message-----
> From: Jinke Jiang [mailto:jiangjinke at 163.com]
> Sent: Tuesday, October 24, 2006 4:56 AM
> To: Hagai Sela (TA)
> Cc: resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] problems with race condition between CANCEL
> and anegative response
> 
> Hi Hagai,
> 
> In RFC3261 [Page 52]
> 9 Canceling a Request
>    ...
>    The CANCEL request, as the name implies, is used to cancel a
> previous
>    request sent by a client.  Specifically, it asks the UAS to cease
>    processing the request and to generate an error response to that
>    request.  CANCEL has no effect on a request to which a UAS has
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    already given a final response.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 9.1 Client Behavior
>    ...
>    If no provisional response has been received, the CANCEL request
> MUST
>    NOT be sent; rather, the client MUST wait for the arrival of a
>    provisional response before sending the request.  If the original
>                                                      ^^^^^^^^^^^^^^^^
>    request has generated a final response, the CANCEL SHOULD NOT be
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    sent, as it is an effective no-op, since CANCEL has no effect on
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    requests that have already generated a final response.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> As you can see, the server will just ignore the CANCEL request after
> generating a class 6xx(603 in this case) final response.
> 
> Instead of sending a CANCEL, the UAC should send an ACK to terminate
> the
> transaction on receiving a 6xx response.
> 
> Regards,
> Jinke Jiang
> 
> ________________________________________
> From: resiprocate-devel-bounces at list.sipfoundry.org
> [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
> Hagai Sela (TA)
> Sent: Monday, October 23, 2006 10:30 PM
> To: resiprocate-devel at list.sipfoundry.org
> Subject: [reSIProcate] problems with race condition between CANCEL and
> anegative response
> 
> Hi,
> I make a call from my resiprocate based client to a certain proxy. I
> have a problem if the client receives a negative response and tries to
> send CANCEL at approx. the same time (see attached capture file). The
> problem is that I receive the onTerminated() callback about 30 seconds
> after the call is terminated instead of receiving it immediatly. Does
> anybody know why this happens?
> 
> Hagai.
> 
> 
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel