Re: [reSIProcate] problems with race condition between CANCEL andanegative response
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@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Hagai Sela (TA)
> Sent: Tuesday, October 24, 2006 8:59 AM
> To: Jinke Jiang
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxx]
> Sent: Tuesday, October 24, 2006 4:56 AM
> To: Hagai Sela (TA)
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Hagai Sela (TA)
> Sent: Monday, October 23, 2006 10:30 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel