Re: [reSIProcate] Destroying a DialogUsage and its (App)Dialog(Set)s without actually "ending" it
Hi,
What do you think of this? I'd like to commit it to the mainline but
you like to get feedback first.
Thanks,
Francis
On Fri, Sep 2, 2011 at 10:02 AM, Francis Joanis
<francis.joanis@xxxxxxxxx> wrote:
> Hi again,
>
> I think I found a more elegant solution that seems to work fine: add a
> new public method to BaseUsage:
>
> /// Abandon the usage and remove it from the DUM's memory without
> /// performing any SIP processing at the TU level
> virtual void abandon();
>
> void BaseUsage::abandon()
> {
> mDum.destroy(this);
> }
>
> If children usages need to perform additional cleanup they could do it
> by overriding the abandon() method. For example, a ServerInviteSession
> might want to tell the stack to abandon its transaction (through
> abandonServerTransaction) if ServerInviteSession::abandon is called
> while the call is still ringing.
>
> I'll be testing it more but so far it seems fine.
>
> Please let me know if you see value in this.
>
> Thanks,
> Francis
>
> On Thu, Sep 1, 2011 at 11:04 AM, Francis Joanis
> <francis.joanis@xxxxxxxxx> wrote:
>> Hi,
>>
>> I'd like to be able to destroy all traces of a dialog set (for
>> example, an InviteSession and its
>> AppDialogSet/AppDialog/DialogSet/Dialog) without having to call
>> DialogUsage::end().
>>
>> Here's my use case: cleanup everything related to a call (INVITE)
>> *without* having it send a BYE. This would be similar to doing a force
>> shutdown on the DUM instance, but on a per call basis.
>>
>> The current InviteSession::end() method seems to always send a BYE,
>> which is perfectly fine, but I'd like to have a way to bypass it.
>>
>> I started looking into DialogUsageManager::destroy(...) and also the
>> DestroyUsage class, but those APIs require access to either a
>> DialogSet/Dialog or a BaseUsageHandle (and those types are not
>> accessible from an AppDialogSet or children of BaseUsage).
>>
>> I will try to add a (public)
>> DialogUsageManager::destroy(AppDialogSetHandle ...) method and let you
>> know how it turns out.
>>
>> Any thoughts?
>>
>> Thanks,
>> Francis
>>
>