26 Feb
2015
26 Feb
'15
9:49 p.m.
Hi,
The dialog module documentation remains unclear about the order of
operations with regard to when to call dlg_manage() or set the
transaction flag.
My impression is that dlg_manage() only registered TM callbacks, so it
doesn't matter when you call it, as long as it's before t_relay().
However, the documentation neither confirms nor denies this.
So, this raises the questions:
1) Is this okay?
set_dlg_profile("caller", "$fU");
dlg_manage();
...
t_relay();
Or do I need to do this?
dlg_manage();
set_dlg_profile("caller", "$fU");
...
t_relay();
2) What about setting dialog-persistent variables? Is this okay?
$dlg_var(account_id) = 49555;
dlg_manage();
If so, where does the variable go if I never call dlg_manage() because
the call is aborted beforehand, e.g.
$dlg_var(account_id) = 49555;
sl_send_reply("403", "Forbidden");
exit;
dlg_manage();
...
t_relay();
3) Any other gotchas or caveats in relation to the order of operations?
I suppose my preference would be to set the dialog profiles in various
places throughout call processing and call dlg_manage() at the very end,
right before t_relay(). Is this acceptable?
Thanks,
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
2 Mar
2 Mar
9:53 a.m.
Hello,
it should be ok to set a profile or a dlg variable before creating the
dialog. They are kept in the context of the process and destroyed if the
dialog is no longer created for the current sip message.
Cheers,
Daniel
On 26/02/15 20:49, Alex Balashov wrote:
Hi,
The dialog module documentation remains unclear about the order of
operations with regard to when to call dlg_manage() or set the
transaction flag.
My impression is that dlg_manage() only registered TM callbacks, so it
doesn't matter when you call it, as long as it's before t_relay().
However, the documentation neither confirms nor denies this.
So, this raises the questions:
1) Is this okay?
set_dlg_profile("caller", "$fU");
dlg_manage();
...
t_relay();
Or do I need to do this?
dlg_manage();
set_dlg_profile("caller", "$fU");
...
t_relay();
2) What about setting dialog-persistent variables? Is this okay?
$dlg_var(account_id) = 49555;
dlg_manage();
If so, where does the variable go if I never call dlg_manage() because
the call is aborted beforehand, e.g.
$dlg_var(account_id) = 49555;
sl_send_reply("403", "Forbidden");
exit;
dlg_manage();
...
t_relay();
3) Any other gotchas or caveats in relation to the order of operations?
I suppose my preference would be to set the dialog profiles in various
places throughout call processing and call dlg_manage() at the very
end, right before t_relay(). Is this acceptable?
Thanks,
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
5:45 p.m.
Daniel,
Thanks for that insight. Where exactly is the association between an initial invite and a
dialog profile kept, if no dialog structure has yet been malloc'd? Is it in shared or
package memory? How exactly is such an association destroyed? Is it garbage-collected, or
explicitly deleted if, for example, script processing of an initial invite is aborted with
'exit'?
--
Sent from my BlackBerry. Please excuse errors and brevity.
Original Message
From: Daniel-Constantin Mierla
Sent: Monday, March 2, 2015 2:53 AM
To: Kamailio (SER) - Users Mailing List
Reply To: miconda(a)gmail.com
Subject: Re: [SR-Users] Dialog order of operations
Hello,
it should be ok to set a profile or a dlg variable before creating the
dialog. They are kept in the context of the process and destroyed if the
dialog is no longer created for the current sip message.
Cheers,
Daniel
On 26/02/15 20:49, Alex Balashov wrote:
Hi,
The dialog module documentation remains unclear about the order of
operations with regard to when to call dlg_manage() or set the
transaction flag.
My impression is that dlg_manage() only registered TM callbacks, so it
doesn't matter when you call it, as long as it's before t_relay().
However, the documentation neither confirms nor denies this.
So, this raises the questions:
1) Is this okay?
set_dlg_profile("caller", "$fU");
dlg_manage();
...
t_relay();
Or do I need to do this?
dlg_manage();
set_dlg_profile("caller", "$fU");
...
t_relay();
2) What about setting dialog-persistent variables? Is this okay?
$dlg_var(account_id) = 49555;
dlg_manage();
If so, where does the variable go if I never call dlg_manage() because
the call is aborted beforehand, e.g.
$dlg_var(account_id) = 49555;
sl_send_reply("403", "Forbidden");
exit;
dlg_manage();
...
t_relay();
3) Any other gotchas or caveats in relation to the order of operations?
I suppose my preference would be to set the dialog profiles in various
places throughout call processing and call dlg_manage() at the very
end, right before t_relay(). Is this acceptable?
Thanks,
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9 Mar
9 Mar
2:42 a.m.
Well, I can say this: it seems that dlg_set_property("ka-{src,dst}")
must be set after dlg_manage(), or it has no effect.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/
1:09 p.m.
On 09/03/15 01:42, Alex Balashov wrote:
Well, I can say this: it seems that
dlg_set_property("ka-{src,dst}")
must be set after dlg_manage(), or it has no effect.
I checked the code and the flags from the local context that are set
before the dialog creation are stored in dialog structure at the moment
of creation.
Can you get the value for iflags and sflags from dialog structure
(should be available in dialog table inside db)?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
3:40 p.m.
Daniel,
On 03/09/2015 07:09 AM, Daniel-Constantin Mierla wrote:
On 09/03/15 01:42, Alex Balashov wrote:
I seem to have overlooked an important detail:
dlg_set_property() was called in a normal SIP worker, then the
transaction was t_suspended(), and it was t_continued() in an rtimer
thread. I imagine that in such a case all local context from these
"lists" that you referred to in the previous response is lost.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/
Well, I can say this: it seems that
dlg_set_property("ka-{src,dst}")
must be set after dlg_manage(), or it has no effect.
I checked the code and the flags from the local context that are set
before the dialog creation are stored in dialog structure at the moment
of creation.
3:51 p.m.
On 09/03/15 14:40, Alex Balashov wrote:
Daniel,
On 03/09/2015 07:09 AM, Daniel-Constantin Mierla wrote:
That could
explain it.
In this case I think it is better to create the dialog before
suspending, because the transaction is created at that moment. Cleanup
of the dialog will be done if the transaction is not forwarded.
Feel free to add a note in dialog docs for this case.
I will think about and see if it is any easy way to propagate the
context in this situation, but doesn't look something trivial to have it
done quickly.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
On 09/03/15 01:42, Alex Balashov wrote:
I seem to have overlooked an important detail:
dlg_set_property() was called in a normal SIP worker, then the
transaction was t_suspended(), and it was t_continued() in an rtimer
thread. I imagine that in such a case all local context from these
"lists" that you referred to in the previous response is lost. Well, I can say this: it seems that
dlg_set_property("ka-{src,dst}")
must be set after dlg_manage(), or it has no effect.
I checked the code and the flags from the local context that are set
before the dialog creation are stored in dialog structure at the moment
of creation.
11:40 p.m.
Daniel,
Thanks for that insight. This does make me wonder if there are other
unforeseen implications in suspending/continue TM transactions, in terms
of "baggage" associated with the transaction or message, but not part of
the core TM structure, not making it across the suspend/continue gap.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/
10 Mar
10 Mar
10:36 a.m.
On 09/03/15 22:40, Alex Balashov wrote:
Daniel,
Thanks for that insight. This does make me wonder if there are other
unforeseen implications in suspending/continue TM transactions, in
terms of "baggage" associated with the transaction or message, but not
part of the core TM structure, not making it across the
suspend/continue gap.
X/AVPs and flags are taken over, being the attributes associated with
transaction/message. Anything else that is in the context of the local
process (e.g., $var(xyz)) are lost.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
9 Mar
9 Mar
12:59 p.m.
On 02/03/15 16:45, Alex Balashov wrote:
Daniel,
Thanks for that insight. Where exactly is the association between an initial invite and
a dialog profile kept, if no dialog structure has yet been malloc'd? Is it in shared
or package memory? How exactly is such an association destroyed? Is it garbage-collected,
or explicitly deleted if, for example, script processing of an initial invite is aborted
with 'exit'?
There are some lists per processes associated with the message id. When
the dialog is created, then it checks if the message id is the one for
current invite and if yes, it uses the lists, otherwise the lists are
discarded. There are also some callbacks for the end of config execution
for cleanup, but I don't remember by heart if does something with these
lists -- code has to be checked.
Cheers,
Daniel
--
Sent from my BlackBerry. Please excuse errors and brevity.
Original Message
From: Daniel-Constantin Mierla
Sent: Monday, March 2, 2015 2:53 AM
To: Kamailio (SER) - Users Mailing List
Reply To: miconda(a)gmail.com
Subject: Re: [SR-Users] Dialog order of operations
Hello,
it should be ok to set a profile or a dlg variable before creating the
dialog. They are kept in the context of the process and destroyed if the
dialog is no longer created for the current sip message.
Cheers,
Daniel
On 26/02/15 20:49, Alex Balashov wrote:
> Hi,
>
> The dialog module documentation remains unclear about the order of
> operations with regard to when to call dlg_manage() or set the
> transaction flag.
>
> My impression is that dlg_manage() only registered TM callbacks, so it
> doesn't matter when you call it, as long as it's before t_relay().
> However, the documentation neither confirms nor denies this.
>
> So, this raises the questions:
>
> 1) Is this okay?
>
> set_dlg_profile("caller", "$fU");
> dlg_manage();
> ...
> t_relay();
>
> Or do I need to do this?
>
> dlg_manage();
> set_dlg_profile("caller", "$fU");
> ...
> t_relay();
>
> 2) What about setting dialog-persistent variables? Is this okay?
>
> $dlg_var(account_id) = 49555;
> dlg_manage();
>
> If so, where does the variable go if I never call dlg_manage() because
> the call is aborted beforehand, e.g.
>
> $dlg_var(account_id) = 49555;
>
> sl_send_reply("403", "Forbidden");
> exit;
>
> dlg_manage();
>
> ...
>
> t_relay();
>
> 3) Any other gotchas or caveats in relation to the order of operations?
>
> I suppose my preference would be to set the dialog profiles in various
> places throughout call processing and call dlg_manage() at the very
> end, right before t_relay(). Is this acceptable?
>
> Thanks,
>
> -- Alex
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
3545
days inactive
3557
days old
9 comments
2 participants
participants (2)
-
Alex Balashov -
Daniel-Constantin Mierla