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

[Timo Reimann]

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