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 <[email protected]>wrote: > Hello, > > Is there any update on my question? > > Thanks, > Mariana > > > On Mon, May 21, 2012 at 10:06 AM, Mariana Arduini <[email protected] > > 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 <[email protected] >> > 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 <[email protected]> >>> 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 <[email protected]> >>> 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 < >>> [email protected]> 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 >>> > [email protected] >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > >>> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
