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

[Scott Godin]

If you abandon the Dialog state, then all future in-dialog requests from the
far-end will fail.  ie.  remote Hold/unhold, refer, Bye, session-timers,
etc. - these failures will likely cause the caller to tear the call down
eventually regardless.  Eitherway - as long it's clearly documented in the
code, that the new API your adding will have bad side effects (above), then
I think it's fine to contribute.  : )

Scott

On Fri, Sep 9, 2011 at 10:46 AM, Francis Joanis <francis.joanis at gmail.com>wrote:

> Hi,
>
> My application needs to support a state where it needs to "forget"
> about a call (i.e. delete the usages and dialogs) without tearing down
> the call at the SIP level. This is mainly because it doesn't terminate
> RTP (more like a B2BUA that relays SDP). In that case, I want the call
> to be removed from the application's memory, but I do not want to
> impact any ongoing RTP sessions: if a BYE were to go out, it would
> tear down the speech path (which would be bad).
>
> Mind you, this special case (in my app) is not part of its regular
> processing: it only applies when some things go wrong (as part of
> error recovery of an outside component). In this case, I'd like to
> cleanup the memory in the app but keep the ongoing audio between the
> end UAs.
>
> Thanks,
> Francis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110909/0a85dcd4/attachment.htm>