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] <mailto:[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.


    On Wed, May 16, 2012 at 5:34 AM, Razvan Crainea
    <[email protected] <mailto:[email protected]>> 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([email protected]
        <mailto:[email protected]>) 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([email protected]
        <mailto:[email protected]>) 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:[email protected]
        <mailto:sip%[email protected]>\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:\[email protected] <mailto:[email protected]>\3>\5/ig')) {
                    xlog("L_DBG","CONTACT was modified");
                }
        }
        ...



        _______________________________________________
        Users mailing list
        [email protected]  <mailto:[email protected]>
        http://lists.opensips.org/cgi-bin/mailman/listinfo/users

        _______________________________________________
        Users mailing list
        [email protected] <mailto:[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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to