[sr-dev] Dialog2 and proxy initiated early dialog termination

[Jason Penton]

Carsten, Unfortunately tmx does not provide the appropriate functionality.

Awesome, thanks Timo. However, The example you give here is to store
dlg_cell in transaction. Actually, we are using the reverse, se pseudo code
below:

when INVITE req_forwarded callback is called, create dialog_in structure,
link and store pointer to transaction in dlg_cell
if we get a request to terminate dialog that is unconfirmed we get the
transaction ptr from dlg_cell and traverse through branches, sending
fake_reply (480/408/x).

Cheers
Jason

On Thu, Sep 29, 2011 at 4:34 PM, Timo Reimann <timo.reimann at 1und1.de> wrote:

> Hi Jason,
>
>
> On 29.09.2011 16:06, Jason Penton wrote:
> > Ok Dialog2 progressing nicely. We now have dialogs and their associated
> > out dialogs (branches / forking) stored and managed within the dialog2
> > module. For the moment, we have excluded DB support but will add once we
> > check in to git. One thing we need a little assistance with:
> >
> > We have just finished the prototype for proxy initiated early dialog
> > termination, but we are concerned with the way it has been done.
> > Basically as mentioned in the wiki
> > (
> http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design
> ),
> >
> >
> >     *
> >       It should be possible to terminate dialogs in the “early” state,
> >       i.e., sending out BYE/CANCEL requests in order to terminate all
> >       branches appropriately.
> >           o
> >             ibc: IMHO it would be easier just to cancel the transaction
> >             as when fr_inv_timer expires, this is, by sending a CANCEL
> >             to all the pending branches and a 408 to the UAC (perhaps in
> >             this case a 480 would be more appropriate).
> >
> > The only way we could think of doing this was to send a fake reply via
> > the TM module. We have therefore exposed the fake_reply function from
> > the TM module and using that to terminate early dialogs. It works in the
> > test scenarios we have performed, but the main drawback we can see here
> > is that the dialog module needs to hold a pointer to the transaction for
> > each dialog (not sure how bad this is as my experience with tm is not
> > expert yet ;) )
> >
> > So any thoughts/ideas. Is this the correct way to do it? Would it be
> > okay to expose a fake_reply function through TM API?
>
> I cannot comment on how good or bad it is to expose the fake_reply
> function.
>
> Regarding pointing each dialog to its associated transaction at a given
> time: This is already implemented in the current dialog(1) module. It
> was needed for several reasons, one of them being to allow access to
> dialog variables in responses. The way the link between dialogs and
> transactions is done is by attaching a transaction pointer to the
> TMCB_MAX callback which is fetched when required. Look at
> store_dlg_in_tm() in dlg_handlers.c and get_dialog_from_tm() in
> dlg_profile.c.
>
> Yes, abusing TMCB_MAX to store additional data is kinda hackish. The
> point here is that the dialog/transaction linkage is definitely needed,
> so IMHO you may go ahead and re-establish it in dialog2. Finding a
> cleaner implementation approach that doesn't involve TMCB_MAX is highly
> appreciated though.
>
>
> HTH,
>
> --Timo
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110929/b9d44772/attachment.htm>