< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Treatment of CANCEL in UAS_Accepted or UAS_AcceptedWaitingAnswer


I believe DUM is behaving according to RFC3261 - section 9.2:

If the transaction
   for the original request still exists, the behavior of the UAS on
   receiving a CANCEL request depends on whether it has already sent a
   final response for the original request.  If it has, the CANCEL
   request has no effect on the processing of the original request, no
   effect on any session state, and no effect on the responses generated
   for the original request.

Scott

On Mon, Aug 31, 2009 at 11:52 PM, Boris Rozinov<borisrozinov@xxxxxxxx> wrote:
> Hi all,
>
> Due to race condition UAS may receive CANCEL for the initial INVITE 
> transaction in Accepted or AcceptedWaitingAnswer state. As transition to 
> OnCancel state occurs, 200 OK response for Cancel is sent, but session is not 
> terminated and session handler is not notified.
> Does not it make more sense to send BYE (dialog is already established), 
> terminate session and notify session handler (or just dispatch Cancel 
> treatment to InviteSession)?
>
> Thanks,
> Boris
>
>
>      __________________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
> favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>