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 ;)<br>
<br>Cheers<br>Jason<br><br><div class="gmail_quote">On Thu, Sep 29, 2011 at 5:05 PM, Timo Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey Jason,<br>
<div class="im"><br>
<br>
On 29.09.2011 16:54, Jason Penton wrote:<br>
> Awesome, thanks Timo. However, The example you give here is to store<br>
> dlg_cell in transaction. Actually, we are using the reverse, se pseudo<br>
> code below:<br>
><br>
> when INVITE req_forwarded callback is called, create dialog_in<br>
> structure, link and store pointer to transaction in dlg_cell<br>
> if we get a request to terminate dialog that is unconfirmed we get the<br>
> transaction ptr from dlg_cell and traverse through branches, sending<br>
> fake_reply (480/408/x).<br>
<br>
</div>Dialogs aren't stored in transactions, they are stored (hackishly) in<br>
transaction callbacks (better: attached to them). But anyways, I think<br>
the uses-relationships are similar in both cases: The dialog module is<br>
called and needs to refer to its transaction. The current module's<br>
pseudo-code:<br>
<br>
"When INVITE on_create callback is called: create dialog structure, link<br>
and store pointer to transaction in tm callback.<br>
If we a response, fetch the transaction ptr from the tm callback to<br>
allow access to dialog variables."<br>
<br>
AFAICS, all that differs is the location of the transaction pointer<br>
which is currently stored in a tm callback (bad) while you use the<br>
dialog structure (good). Let me know if I get things wrong.<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
--Timo<br>
</font><div class="im"><br>
<br>
<br>
> On Thu, Sep 29, 2011 at 4:34 PM, Timo Reimann <<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>>> wrote:<br>
><br>
> Hi Jason,<br>
><br>
><br>
> On 29.09.2011 16:06, Jason Penton wrote:<br>
> > Ok Dialog2 progressing nicely. We now have dialogs and their<br>
> associated<br>
> > out dialogs (branches / forking) stored and managed within the dialog2<br>
> > module. For the moment, we have excluded DB support but will add<br>
> once we<br>
> > check in to git. One thing we need a little assistance with:<br>
> ><br>
> > We have just finished the prototype for proxy initiated early dialog<br>
> > termination, but we are concerned with the way it has been done.<br>
> > Basically as mentioned in the wiki<br>
> ><br>
> (<a href="http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design" target="_blank">http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design</a>),<br>
> ><br>
> ><br>
> > *<br>
> > It should be possible to terminate dialogs in the “early” state,<br>
> > i.e., sending out BYE/CANCEL requests in order to terminate all<br>
> > branches appropriately.<br>
> > o<br>
> > ibc: IMHO it would be easier just to cancel the<br>
> transaction<br>
> > as when fr_inv_timer expires, this is, by sending a CANCEL<br>
> > to all the pending branches and a 408 to the UAC<br>
> (perhaps in<br>
> > this case a 480 would be more appropriate).<br>
> ><br>
> > The only way we could think of doing this was to send a fake reply via<br>
> > the TM module. We have therefore exposed the fake_reply function from<br>
> > the TM module and using that to terminate early dialogs. It works<br>
> in the<br>
> > test scenarios we have performed, but the main drawback we can see<br>
> here<br>
> > is that the dialog module needs to hold a pointer to the<br>
> transaction for<br>
> > each dialog (not sure how bad this is as my experience with tm is not<br>
> > expert yet ;) )<br>
> ><br>
> > So any thoughts/ideas. Is this the correct way to do it? Would it be<br>
> > okay to expose a fake_reply function through TM API?<br>
><br>
> I cannot comment on how good or bad it is to expose the fake_reply<br>
> function.<br>
><br>
> Regarding pointing each dialog to its associated transaction at a given<br>
> time: This is already implemented in the current dialog(1) module. It<br>
> was needed for several reasons, one of them being to allow access to<br>
> dialog variables in responses. The way the link between dialogs and<br>
> transactions is done is by attaching a transaction pointer to the<br>
> TMCB_MAX callback which is fetched when required. Look at<br>
> store_dlg_in_tm() in dlg_handlers.c and get_dialog_from_tm() in<br>
> dlg_profile.c.<br>
><br>
> Yes, abusing TMCB_MAX to store additional data is kinda hackish. The<br>
> point here is that the dialog/transaction linkage is definitely needed,<br>
> so IMHO you may go ahead and re-establish it in dialog2. Finding a<br>
> cleaner implementation approach that doesn't involve TMCB_MAX is highly<br>
> appreciated though.<br>
><br>
><br>
> HTH,<br>
><br>
> --Timo<br>
</div></div></blockquote></div><br>