[OpenSIPS-Users] Dialog vars not being sync'ed from DB to memory

[Mariana Arduini]

Hello,

I noticed that some weeks ago there was not much replying from OpenSIPS Dev
team in the Users team, but I saw Bogdan answering some questions now and I
would like to check on the updates on my issue.

Should I open a bug related to it?

Thanks a lot,
Mariana.

On Thu, May 24, 2012 at 9:35 AM, Mariana Arduini <marianarduini at gmail.com>wrote:

> Hello,
>
> Is there any update on my question?
>
> Thanks,
> Mariana
>
>
> On Mon, May 21, 2012 at 10:06 AM, Mariana Arduini <marianarduini at gmail.com
> > wrote:
>
>> Hello all,
>>
>> Is there any update on my question? Should I open a bug about this issue,
>> or is there any other test I can run to verify this feature?
>>
>> Thanks,
>> Mariana.
>>
>>
>> On Thu, May 17, 2012 at 2:22 PM, Mariana Arduini <marianarduini at gmail.com
>> > wrote:
>>
>>> Hello,
>>>
>>> >> The dlg_db_sync command is only useful when you have the second
>>> server online, and want to trigger a refresh of OpenSIPS memory based on
>>> what is in the DB.
>>>
>>> In fact I noticed it. I also tried this test with no success in
>>> fetching the dialog vars:
>>>
>>> 1) Server #2 is online listening on 10.0.0.1
>>> 2) interface 10.0.0.1 is set down on server #2, but server #2 is not
>>> stopped
>>> 3) interface 10.0.0.1 is set up on server #1 and server #1 is started
>>> 4) UAC sends INVITE to 10.0.0.1, which goes to server #1
>>> 5) interface 10.0.0.1 is set down on server #1, and server #1 is stopped
>>> 6) interface 10.0.0.1 is set up on server #2
>>> 7) dlg_db_sync is run on server #2, but dlg_list_ctx shows no vars
>>> 8) UAC sends BYE to 10.0.0.1, which goes to server #2
>>>
>>> >> If you just start the secondary server & do not issue dlg_db_sync, do
>>> you still have the same problem ?
>>>
>>> Yes, no dialogs vars in context.
>>>
>>> Attached is the log on server #2 you asked for. It includes the
>>> following, in this order:
>>>
>>> 1) opensipsctl start
>>> 2) opensipsctl fifo dlg_list_ctx: no vars shown in context
>>> 3) opensipsctl fifo dlg_db_sync
>>> 4) opensipsctl fifo dlg_list_ctx: no vars shown in context
>>> 5) BYE from UAC, server looks for dialog var "caller_tag"
>>>
>>> For this test, I tried to get the vars using fetch_dlg_value(), file
>>> name is log-server-2-from-start-fetch.txt.
>>>
>>> I collected another log for the same test, now using get_dialog_info()
>>> instead of fetch_dlg_value(), file name is.
>>>
>>> Thanks for the help.
>>> Mariana
>>>
>>> On Thu, May 17, 2012 at 6:08 AM, Vlad Paiu <vladpaiu at opensips.org>
>>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > Just to clear some things up, if you leave the second server offline
>>> and only start it after the active is down, then the ongoing dialogs will
>>> be automatically loaded by the secondary server at startup. The dlg_db_sync
>>> command is only useful when you have the second server online, and want to
>>> trigger a refresh of OpenSIPS memory based on what is in the DB.
>>> >
>>> > If you just start the secondary server & do not issue dlg_db_sync, do
>>> you still have the same problem ?
>>> > If you can, please send us ( privately or via pastebin ) a full debug
>>> OpenSIPS log of the secondary server ( from startup, until the moment you
>>> want to access a dlg_var ).
>>> >
>>> >
>>> > Regards,
>>> >
>>> > Vlad Paiu
>>> > OpenSIPS Developer
>>> > http://www.opensips-solutions.com
>>> >
>>> >
>>> > On 05/16/2012 08:46 PM, Mariana Arduini wrote:
>>> >>
>>> >> Hi Vlad,
>>> >>
>>> >> > Does this also happen if you leave the second server offline, and
>>> start it after the active OpenSIPS is shut down (...) ?
>>> >>
>>> >> Yes, that's exactly the test I've run.
>>> >>
>>> >> > At the moment that you run dlg_db_sync, do you see the variables in
>>> the dialog DB table ?
>>> >>
>>> >> Yes.
>>> >>
>>> >> After you run dlg_db_sync, you say you cannot access the variables
>>> from the script, but you see them in dlg_list_ctx ?
>>> >>
>>> >> No, I don't see them in dlg_list_ctx, neither I can access them from
>>> the script.
>>> >>
>>> >> Thanks.
>>> >> Mariana.
>>> >>
>>> >> On Wed, May 16, 2012 at 2:31 PM, Vlad Paiu <vladpaiu at opensips.org>
>>> wrote:
>>> >>>
>>> >>> Hi Mariana,
>>> >>>
>>> >>> Does this also happen if you leave the second server offline, and
>>> start it after the active OpenSIPS is shut down, instead of leaving the
>>> second server up and running 'dlg_db_sync' ?
>>> >>>
>>> >>> At the moment that you run dlg_db_sync, do you see the variables in
>>> the dialog DB table ?
>>> >>> After you run dlg_db_sync, you say you cannot access the variables
>>> from the script, but you see them in dlg_list_ctx ?
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Vlad Paiu
>>> >>> OpenSIPS Developer
>>> >>> http://www.opensips-solutions.com
>>> >>>
>>> >>>
>>> >>> On 05/16/2012 07:57 PM, Mariana Arduini wrote:
>>> >>>>
>>> >>>> Hi Razvan,
>>> >>>>
>>> >>>> Do I need to open a bug about this issue somewhere? I saw Bogdan's
>>> message about OpenSIPS 1.8 Stable being released tomorrow.
>>> >>>>
>>> >>>> I think the problem is the dialog variables are not being fetched
>>> from DB, either when OpenSIPS is restarded, either when we run the new fifo
>>> command dlg_db_sync.
>>> >>>>
>>> >>>> Thanks again!
>>> >>>> Mariana.
>>> >>>>
>>> >>>> On Wed, May 16, 2012 at 8:06 AM, Mariana Arduini <
>>> marianarduini at gmail.com> wrote:
>>> >>>>>
>>> >>>>> Hi, Razvan!
>>> >>>>>
>>> >>>>> Thank you for the $DLG_dir pseudovariable, it worked!
>>> >>>>>
>>> >>>>> The variables are properly flushed into the DB after 200 OK, and I
>>> can also see them using "opensipsctl fifo dlg_list_ctx", under context.
>>> >>>>>
>>> >>>>> Even using the $DLG_dir for the direction of a sequential request,
>>> I still need to access either the caller_contact or the callee_contact. Is
>>> there any other way to have those apart from the variables?
>>> >>>>>
>>> >>>>> Thanks again!
>>> >>>>> Mariana.
>>> >>>>>
>>> >
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120611/707a557a/attachment.htm>