[OpenSIPS-Users] Dialog vars not being sync'ed from DB to memory
Vlad Paiu
vladpaiu at opensips.org
Thu May 17 11:07:03 CEST 2012
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
> <mailto: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 <mailto: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 <mailto: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 Developer
>> http://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
>>> <mailto: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
>>> <mailto: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
>>> <http://opensips2.domain.com>";
>>> $rp="5060";
>>>
>>> # Change Contact header
>>> if
>>> (subst('/^Contact\s*:\s*("[^"]*")?\s*<?sip:(([^@]*)@)?([^;>]*)((;[^;>]*)*)>?(.*)/Contact:
>>> <sip:plain at my.domain.com
>>> <mailto:sip%3Aplain 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 <mailto:2 at my.domain.com>\3>\5/ig')) {
>>> xlog("L_DBG","CONTACT was modified");
>>> }
>>> }
>>> ...
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://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/20120517/3da08f51/attachment-0001.htm>
More information about the Users
mailing list