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
>