29 Sep
2011
29 Sep
'11
4:06 p.m.
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-…),
- 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
29 Sep
29 Sep
4:28 p.m.
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(a)gmail.com>om>:
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-…),
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH i. Gr.
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
4:34 p.m.
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-…),
*
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
4:54 p.m.
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(a)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-…
),
*
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5:05 p.m.
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(a)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-…),
*
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
5:30 p.m.
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(a)1und1.de> wrote:
Hey Jason,
On 29.09.2011 16:54, Jason Penton wrote:
dialog
http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-…
),
CANCEL
via
not
given
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(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hi Jason,
On 29.09.2011 16:06, Jason Penton wrote:
dialog2
Ok Dialog2 progressing nicely. We now have
dialogs and their
associated
> out dialogs (branches / forking) stored and managed within the 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
termination, but we are concerned with the way it has been done.
Basically as mentioned in the wiki
( >
>
> *
> 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
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 > 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 > 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 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
30 Sep
30 Sep
11:38 a.m.
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(a)1und1.de
<mailto:timo.reimann@1und1.de>> wrote:
Hey Jason,
On 29.09.2011 16:54, Jason Penton wrote:
early dialog
(http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-…),
sending a
CANCEL
reply
via
at a given
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(a)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:
the
dialog2
Ok Dialog2 progressing nicely. We now have
dialogs and their
associated
> out dialogs (branches / forking) stored and managed within 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
termination, but we are concerned with the way it has been done.
Basically as mentioned in the wiki
>
>
> *
> 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
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 > 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
tm is
not
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 > 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 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
4823
days inactive
4824
days old
6 comments
3 participants
participants (3)
-
Carsten Bock -
Jason Penton -
Timo Reimann