Re: [reSIProcate] Treatment of CANCEL in UAS_Accepted or UAS_AcceptedWaitingAnswer
Yes I agree - that is a real issue in DUM, we need do something like
keep the DialogSet around (after destruction/cancel) for some period
of time (likely 32s) in order to correctly handle scenarios like this.
Scott
On Tue, Sep 1, 2009 at 5:45 PM, Boris Rozinov<borisrozinov@xxxxxxxx> wrote:
> Scott,
>
> I believe you are right and UAS behaves correctly by just responding 200OK to
> Cancel. It brings us to UAC side (in our case both UAC and UAS are
> implemented using resiprocate). UAC was supposed to wait for 200OK/INV and
> then respond by ACK and then send BYE. But DialogSet::end() sends CANCEL and
> in absence of created dialogs invokes mDum.destroy(this) and effectively
> destruct itself and as result delayed (or retransmitted) 200OK/INV are thrown
> away as stray response.
>
> Thanks,
> Boris
>
>
> --- On Tue, 9/1/09, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
>
>> From: Scott Godin <sgodin@xxxxxxxxxxxxxxx>
>> Subject: Re: [reSIProcate] Treatment of CANCEL in UAS_Accepted or
>> UAS_AcceptedWaitingAnswer
>> To: "Boris Rozinov" <borisrozinov@xxxxxxxx>
>> Cc: resiprocate-devel@xxxxxxxxxxxxxxx
>> Received: Tuesday, September 1, 2009, 1:22 PM
>> 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
>> >
>>
>
>
> __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
>