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

[Timo Reimann]

On 29.09.2011 17:30, Jason Penton wrote:
> 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 ;)

You simply need to push your changes to a new, non-existing remote
branch. This should do the trick:

  git push origin <your local branch name>:<your git user name>/<new
remote branch name>

For instance,

  git push origin master_dialog2:jpenton/dialog2

When I did it for the first time I got weird permission errors; this was
because I didn't use my correct git user name, so watch out for that.


Cheers,

--Timo



> On Thu, Sep 29, 2011 at 5:05 PM, Timo Reimann <timo.reimann at 1und1.de
> <mailto: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>
>     > <mailto: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