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

[Jason Penton]

yeah, make sense. Ok, we will proceed exposing fake_reply in tm and start a
new branch for everyone to review. Any tips on how to create a branch using
GIT? ;) - I'm paranoid of doing something wrong to git master ;)

Cheers
Jason

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

> Hey Jason,
>
>
> On 29.09.2011 16:54, Jason Penton wrote:
> > 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).
>
> Dialogs aren't stored in transactions, they are stored (hackishly) in
> transaction callbacks (better: attached to them). But anyways, I think
> the uses-relationships are similar in both cases: The dialog module is
> called and needs to refer to its transaction. The current module's
> pseudo-code:
>
> "When INVITE on_create callback is called: create dialog structure, link
> and store pointer to transaction in tm callback.
> If we a response, fetch the transaction ptr from the tm callback to
> allow access to dialog variables."
>
> AFAICS, all that differs is the location of the transaction pointer
> which is currently stored in a tm callback (bad) while you use the
> dialog structure (good). Let me know if I get things wrong.
>
>
> Cheers,
>
> --Timo
>
>
>
> > On Thu, Sep 29, 2011 at 4:34 PM, Timo Reimann <timo.reimann at 1und1.de
> > <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110929/7c27d89e/attachment-0001.htm>