Carsten, Unfortunately tmx does not provide the appropriate functionality.<br><br>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:<br>
<br>when INVITE req_forwarded callback is called, create dialog_in 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 transaction ptr from dlg_cell and traverse through branches, sending fake_reply (480/408/x).<br>
<br>Cheers<br>Jason<br><br><div class="gmail_quote">On Thu, Sep 29, 2011 at 4:34 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;">
Hi Jason,<br>
<div><div></div><div class="h5"><br>
<br>
On 29.09.2011 16:06, Jason Penton wrote:<br>
> Ok Dialog2 progressing nicely. We now have dialogs and their 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 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>
> (<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 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 (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 in the<br>
> test scenarios we have performed, but the main drawback we can see here<br>
> is that the dialog module needs to hold a pointer to the 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>
</div></div>I cannot comment on how good or bad it is to expose the fake_reply 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>
<font color="#888888"><br>
--Timo<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br>