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

Mariana Arduini marianarduini at gmail.com
Mon Jun 11 22:14:14 CEST 2012


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.

The files are attached in the previous messages.

Thanks for the help.


On Thu, May 17, 2012 at 6:06 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 Developerhttp://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 Developerhttp://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.
>>>
>>>
>>> On Wed, May 16, 2012 at 5:34 AM, Razvan Crainea <razvan at opensips.org>wrote:
>>>
>>>>  Hi, Mariana!
>>>>
>>>> Can you check if the variables are properly flushed into the DB after
>>>> 200OK?
>>>> Also, if you only want to check the direction of a sequential request,
>>>> you could use directly the $DLG_dir [1] pseudovariable from the dialog
>>>> module.
>>>>
>>>> [1]
>>>> http://www.opensips.org/html/docs/modules/1.8.x/dialog.html#id295750
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Răzvan Crainea
>>>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>>>
>>>>
>>>> On 05/15/2012 10:03 PM, Mariana Arduini wrote:
>>>>
>>>>  Hello all,
>>>>
>>>>  We need to perform some substitutions in the R-URI and Contact header
>>>> in order to have the following flow working as required:
>>>>
>>>>  caller > opensips1 > opensips2 > callee
>>>>
>>>>  Currently, opensips1 stores "call_id", "caller_tag" and
>>>> "caller_contact" Dialog variables  using function store_dlg_value() on new
>>>> INVITES, and "callee_contact" on 200 OK for the INVITES. Later, for
>>>> sequential requests, it compares the from_tag with the caller_tag, accessed
>>>> using fetch_dlg_value(), to find out whether it is a request from the
>>>> caller or from the callee, and it works. Then I started working on failover
>>>> for opensips1, and that's where I'm facing problems. I'm playing with
>>>> "db_flush_vals_profiles" new parameter and "dlg_db_sync" new fifo command,
>>>> both on Dialog module, in order to have a stand by opensips1 taking over
>>>> the dialogs going on in an active opensips1, in case it fails. This is the
>>>> test:
>>>>
>>>>  1) active opensips is running listening on virtual ip say 10.0.0.1
>>>> 2) caller sends INVITE to 10.0.0.1, which goes to active opensips
>>>> 3) active opensips is stopped and it's virtual ip set down; same
>>>> virtual ip is set up in stand by opensips and it is started; fifo command
>>>> dlg_db_sync is run on stand by opensips
>>>> 4) caller sends BYE to 10.0.0.1, which goes to stand by opensips
>>>>
>>>>  After loose_route(), stand by opensips cannot fetch_dlg_value for
>>>> "caller_tag" and the R-URI is set to 0. Then I tried the following, using
>>>> only one opensips:
>>>>
>>>>  1) caller sends INVITE to opensips
>>>> 2) fifo command dlg_list_ctx is run and shows all of the variables I
>>>> stored
>>>> 3) opensips is restarted and fifo command dlg_db_sync is run
>>>>  4) fifo command dlg_list_ctx is run again and shows only the dialog
>>>> info, not the variables in context
>>>>
>>>>  I also
>>>> tried get_dialog_info("caller_tag","$var(caller_tag)","call_id","$ci"); and
>>>> $dlg_val(), but yet the variables are not found:
>>>>
>>>>   22232: DBG:dialog:fetch_dlg_value: looking for <caller_tag>
>>>> 22232: DBG:dialog:fetch_dlg_value: var NOT found!
>>>> 22232: ERROR:core:do_assign: no value in right expression
>>>> 22232: ERROR:core:do_assign: error at line: 134
>>>> 22232: callid(1-5150 at 192.168.16.154) trying dlg_val(), caller_tag: 0
>>>> 22232: DBG:core:comp_scriptvar: str 20 : uac1192.168.16.154
>>>> 22232: DBG:dialog:fetch_dlg_value: looking for <caller_contact>
>>>> 22232: DBG:dialog:fetch_dlg_value: var NOT found!
>>>> 22232: ERROR:core:do_assign: no value in right expression
>>>> 22232: ERROR:core:do_assign: error at line: 146
>>>> 22232: callid(1-5150 at 192.168.16.154) trying dlg_val(), caller_contact:
>>>> 0
>>>> 22232: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff
>>>> 22232: DBG:core:parse_headers: flags=ffffffffffffffff
>>>> 22232: DBG:core:parse_headers: flags=78
>>>> 22232: DBG:tm:t_lookup_request: start searching: hash=5130, isACK=0
>>>> 22232: DBG:tm:matching_3261: RFC3261 transaction matching failed
>>>> 22232: DBG:tm:t_lookup_request: no transaction found
>>>> 22232: ERROR:core:parse_uri: uri too short: <0> (1)
>>>> 22232: ERROR:core:parse_sip_msg_uri: bad uri <0>
>>>> 22232: DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing r-uri'
>>>> 22232: ERROR:tm:new_t: uri invalid
>>>> 22232: ERROR:tm:t_newtran: new_t failed
>>>>
>>>>  There is no error logs when dlg_db_sync is run. I see in the dialog
>>>> table a column called from_tag, is there a way to get its content for a
>>>> certain dialog? It seems the functions get_dialog_info(), fetch_dlg_info()
>>>> and $dlg_val() only look for variables in the column vars.
>>>>
>>>>  Can anyone see other type of solution that does not involve
>>>> storing/fetching dialog variables? I could take on that.
>>>>
>>>>  I'd really appreciate any help on this.
>>>>
>>>>   This is my cfg file:
>>>>
>>>>  ...
>>>>  modparam("dialog", "db_url",
>>>> "postgres://opensips:opensips@opensips_db_host:5432/opensips")
>>>> modparam("dialog", "db_mode", 1)
>>>> modparam("dialog", "db_flush_vals_profiles", 1)
>>>>  ...
>>>>  route {
>>>> ...
>>>>  if(is_method("INVITE")) {
>>>>  create_dialog();
>>>>  store_dlg_value("caller_tag", "$ft");
>>>>  xlog("L_INFO","Storing caller_tag: $ft");
>>>>  store_dlg_value("caller_contact", "$ct.fields(uri)");
>>>>  xlog("L_INFO","Storing caller_contact: $ct.fields(uri)");
>>>>  store_dlg_value("call_id", "$ci");
>>>>  xlog("L_INFO","Storing call_id: $ci");
>>>>                 route(1);
>>>>         }
>>>>  ...
>>>>  if (has_totag()) {
>>>>  # sequential request withing a dialog should
>>>>  # take the path determined by record-routing
>>>>  if (loose_route()) {
>>>>
>>>>                      $var(caller_tag) = $dlg_val(caller_tag);
>>>>                     xlog("L_INFO","trying dlg_val(), caller_tag:
>>>> $var(caller_tag)\n");
>>>>
>>>>                      if ($ft == $var(caller_tag)) {
>>>>                         $var(callee_contact) = $dlg_val(callee_contact);
>>>>                         xlog("L_INFO"," trying dlg_val(),
>>>> callee_contact: $var(callee_contact)\n");
>>>>                         $ru = $var(callee_contact);
>>>>                     } else {
>>>>                         $var(caller_contact) = $dlg_val(caller_contact);
>>>>                         xlog("L_INFO"," trying dlg_val(),
>>>> caller_contact: $var(caller_contact)\n");
>>>>                         $ru = $var(caller_contact);
>>>>                     }
>>>>
>>>>  }
>>>>  }
>>>>         record_route();
>>>>         if (!t_relay()) {
>>>>                 send_reply("500","Internal Error");
>>>>         };
>>>>         exit;
>>>> }
>>>> ...
>>>> route[1] {
>>>>  # for INVITEs enable some additional helper routes
>>>>  if (is_method("INVITE")) {
>>>>       $rd="opensips2.domain.com";
>>>>             $rp="5060";
>>>>
>>>>              # Change Contact header
>>>>             if
>>>> (subst('/^Contact\s*:\s*("[^"]*")?\s*<?sip:(([^@]*)@)?([^;>]*)((;[^;>]*)*)>?(.*)/Contact:
>>>> <sip:plain at my.domain.com\5>\7/ig')) {
>>>>                 xlog("L_DBG","CONTACT was modified");
>>>>             }
>>>>
>>>>      t_on_reply("2");
>>>>  }
>>>>
>>>>  }
>>>> ...
>>>> onreply_route[2] {
>>>>
>>>>          if(is_present_hf("Contact")) {
>>>>              xlog("L_INFO"," Storing callee_contact: $ct.fields(uri)");
>>>>             store_dlg_value("callee_contact", "$ct.fields(uri)");
>>>>         }
>>>>
>>>>          if
>>>> (subst('/^Contact\s*:\s*("[^"]*")?\s*<?sip:([^@]*)@[^;>]*((;[^;>]*)*)>?(.*)/Contact:
>>>> <sip:\2 at my.domain.com\3>\5/ig')) {
>>>>             xlog("L_DBG","CONTACT was modified");
>>>>         }
>>>> }
>>>>  ...
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> 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/55defd2a/attachment-0001.htm>


More information about the Users mailing list