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

Re: [reSIProcate] Destroying a DialogUsage and its (App)Dialog(Set)s without actually "ending" it


I personally do not see a need for this functionality.  Can you explain more, what you would use this for?

Scott

On Fri, Sep 9, 2011 at 9:50 AM, Francis Joanis <francis.joanis@xxxxxxxxx> wrote:
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
>>
>

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel