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@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

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

On 09/03/15 14:40, Alex Balashov wrote:

Daniel,

On 03/09/2015 07:09 AM, Daniel-Constantin Mierla wrote:

...

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.

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.

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

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