[OpenSIPS-Users] Dialog vars not being sync'ed from DB to memory
Mariana Arduini
marianarduini at gmail.com
Wed May 16 19:46:49 CEST 2012
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120516/def3462a/attachment-0001.htm>
More information about the Users
mailing list