Hi All,
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-d...),
- 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. - 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?
Cheers Jason
Hi,
have you looked at the following: http://www.kamailio.org/docs/modules/devel/modules_k/tmx.html#id2534002 or http://www.kamailio.org/docs/modules/devel/modules_k/tmx.html#id2531610 ??
Regards, Carsten
2011/9/29 Jason Penton jason.penton@gmail.com:
Hi All,
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-d...),
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.
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?
Cheers Jason
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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-d...),
* 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
Carsten, Unfortunately tmx does not provide the appropriate functionality.
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).
Cheers Jason
On Thu, Sep 29, 2011 at 4:34 PM, Timo Reimann timo.reimann@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-d... ),
* 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@1und1.de mailto:timo.reimann@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
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@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@1und1.de mailto:timo.reimann@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 thedialog2
> 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 earlydialog
> 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-d... ),
> > > * > It should be possible to terminate dialogs in the “early”state,
> i.e., sending out BYE/CANCEL requests in order to terminateall
> branches appropriately. > o > ibc: IMHO it would be easier just to cancel the transaction > as when fr_inv_timer expires, this is, by sending aCANCEL
> 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 replyvia
> the TM module. We have therefore exposed the fake_reply functionfrom
> 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 isnot
> expert yet ;) ) > > So any thoughts/ideas. Is this the correct way to do it? Would itbe
> 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 agiven
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 definitelyneeded,
so IMHO you may go ahead and re-establish it in dialog2. Finding a cleaner implementation approach that doesn't involve TMCB_MAX ishighly
appreciated though. HTH, --Timo
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@1und1.de mailto:timo.reimann@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@1und1.de <mailto:timo.reimann@1und1.de> > <mailto:timo.reimann@1und1.de <mailto:timo.reimann@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
-
Carsten Bock -
Jason Penton -
Timo Reimann