Re: [reSIProcate] Question about scenario where DUM callbacks are not called for client INVITE

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

The reason that the call backs work that way is related to forking.  You can have multiple dialogs / invite sessions created for each outbound invite, if the call is forked by a proxy.  I typically use an application defined subclass of AppDialogSet to track call state.  You can know when the call is "terminated" after a cancel (with 100 resp only), by placing code in your AppDialogSet's destructor.   The recon and ichat-gw projects are a good example implementations of this.

Scott

On Mon, Oct 18, 2010 at 8:52 AM, Francis Joanis <francis.joanis@xxxxxxxxx> wrote:

Hi guys,

(this is using resip 1.6)

Consider the following scenario:

- Alice INVITEs Bob

- Bob replies 100 Trying

- Alice CANCELs the call to Bob

- ...

The InviteSessionHandler onNewSession and onTerminated callbacks are never called on Alice's side because Bob never replied anything greater than a 100 Trying. Note that onNewSession (and friends) are properly called for Bob.

This might not be a huge issue in an application that simply implements Alice's side: since onNewSession is never called, it is "safe" to assume that no application logic was really called (i.e. no application state created, ...). This is because the call never actually happened as far as the application is concerned, yet it is the application that created the INVITE message and instructed DUM to send it.

However, suppose this is implemented into a B2BUA which implements both UAS and UAC. If that B2BUA is driven by an application-level FSM, then the above scenario might confuse it since it would have been expecting an onNewSession/onTerminated for its UAC leg...

I haven't researched any "nice" solutions yet, I wanted to get your opinions first.

Thanks :)

Francis

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