Re: [reSIProcate] Destroying a DialogUsage and its (App)Dialog(Set)s without actually "ending" it
(Also replying to the list...)
Yes, you're right. In my case, there is little to no chance that a new
in-dialog request reaches the application (because of how the
application "manages" IP addresses the UAs won't be able to reach it
anymore).
In any case I like your comment: you should use this API only if you
know what you're doing and it should be clearly stated. I'll give it
some more thoughts and I'll get back to you :)
Thanks,
Francis
On Fri, Sep 9, 2011 at 10:59 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
> 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
>
>