Re: [reSIProcate] Destroying a DialogUsage and its (App)Dialog(Set)s without actually "ending" it
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@xxxxxxxxx> 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