Hi Pete,

That is weird - If I do a patch for extra logging, would you be able to run it ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 03/01/2018 04:31 PM, Pete Kelly wrote:
Hi Bogdan
Yes this issue seems to still persist.

I have a gw which is initially active, and is then set to probing with ds_mark_dst("p")... The output of ds_list confirms it is in probing also.

The module parameter ds_probing_mode is not defined at all (so it should be 0 as per default).

However the gateway is not being probed!

This is with 2.3.3 now.

Pete




On 31 January 2018 at 11:53, Bogdan-Andrei Iancu <bog...@opensips.org <mailto:bog...@opensips.org>> wrote:

    Pete,

    There may be a bit of a confusion here. I was talking about the
    ds_probing_list parameter (which is default UNSET). The
    ds_probing_mode is indeed 0 as default, meaning to ping only
    destinations in state PROBING.

    Again, do you have this pinging issue for all the destinations in
    your set ?

    Regards,

    Bogdan-Andrei Iancu

    OpenSIPS Founder and Developer
       http://www.opensips-solutions.com <http://www.opensips-solutions.com>
    OpenSIPS Summit 2018
       http://www.opensips.org/events/Summit-2018Amsterdam
    <http://www.opensips.org/events/Summit-2018Amsterdam>

    On 01/30/2018 03:41 PM, Pete Kelly wrote:
    Bogdan

    The docs say the default is "0".... so actually the default is UNSET?

    Which I think means I need to set it to 0 in order to make the
    Probing gw's be probed?




    On 26 January 2018 at 15:55, Bogdan-Andrei Iancu
    <bog...@opensips.org <mailto:bog...@opensips.org>> wrote:

        Pete, yes, you are right - if not set at all (which is
        different than setting it to "0") it means probing for all.
        And default is "unset"/

        Regards,

        Bogdan-Andrei Iancu

        OpenSIPS Founder and Developer
           http://www.opensips-solutions.com
        <http://www.opensips-solutions.com>
        OpenSIPS Summit 2018
           http://www.opensips.org/events/Summit-2018Amsterdam
        <http://www.opensips.org/events/Summit-2018Amsterdam>

        On 01/26/2018 05:37 PM, Pete Kelly wrote:
        Hi Bogdan

        ds_probing_mode is set to the default (0).

        The docs say this "If set to 0, only the gateways with state
        PROBING are tested"

        So I would assume this means that anything in PROBING should
        be pinged?

        On 26 January 2018 at 14:15, Bogdan-Andrei Iancu
        <bog...@opensips.org <mailto:bog...@opensips.org>> wrote:

            Hi Pete,

            The primary storage (during runtime) is memory (the
            in-mem status is only flushed to DB, not read).

            Now, do you use "ds_probing_list" parameter ? Also, are
            you sure "ds_probing_mode" parameter is set to 1 ?

            More questions - this issue happens only for a
            particular destination ? or none of the "probing"
            destinations is pinged ?

            Regards,

            Bogdan-Andrei Iancu

            OpenSIPS Founder and Developer
               http://www.opensips-solutions.com
            <http://www.opensips-solutions.com>
            OpenSIPS Summit 2018
               http://www.opensips.org/events/Summit-2018Amsterdam
            <http://www.opensips.org/events/Summit-2018Amsterdam>

            On 01/26/2018 11:58 AM, Pete Kelly wrote:
            The gw should be being probed (this is the desired
            behaviour!).

            Is OpenSIPS using the DB column instead of the
            in-memory state?

            On 22 January 2018 at 16:33, Bogdan-Andrei Iancu
            <bog...@opensips.org <mailto:bog...@opensips.org>> wrote:

                Hi Pete,

                The DB schema is documented here:
                
http://www.opensips.org/Documentation/Install-DBSchema-2-3#AEN4379
                
<http://www.opensips.org/Documentation/Install-DBSchema-2-3#AEN4379>

                State "1" means disabled and this explains the
                no-probing behavior. Still, you claim that the
                in-memory state is Probing, according to the MI
                ds_list command....So, which is the right state of
                the GW ?? :)

                Regards,

                Bogdan-Andrei Iancu

                OpenSIPS Founder and Developer
                   http://www.opensips-solutions.com
                <http://www.opensips-solutions.com>
                OpenSIPS Summit 2018
                   http://www.opensips.org/events/Summit-2018Amsterdam
                <http://www.opensips.org/events/Summit-2018Amsterdam>

                On 01/18/2018 12:53 PM, Pete Kelly wrote:
                Hi

                I am using OpenSIPS 2.3.2 and have the dispatcher
                module configured thusly:


                # ----- dispatcher params -----
                modparam("dispatcher", "db_url",
                "mysql://DB_USER:DB_PASSWD@DB_HOST/DB_NAME")
                modparam("dispatcher", "ds_probing_threshhold", 10)
                modparam("dispatcher", "table_name", "dispatcher_2_3")
                modparam("dispatcher", "persistent_state", 0)
#modparam("dispatcher", "ds_probing_mode", 0) #Not setting this explicitly as the default is 0

                My understanding of this is that any gateway that
                is in the state of "Probing" will now be probed
                with OPTIONS until it becomes active by means of a
                200OK response (or a configured +ve response)

                However I have a gateway which has been set into
                probing using ds_set_state("p"). This is verified
                using the MI command ds_list:

                host:~/tees#
                /usr/local/opensips_2_3/sbin/opensipsctl fifo
                ds_list | grep "Probing"
                      URI:: sip:192.168.0.15 state=Probing
                first_hit_counter=0


                Yet OpenSIPS is not probing the gateway at all and
                I can't logically fathom why this is. The state
                column in the dispatcher table is set to 1, but
                the documentation is not clear on what this means.

                I am sure I am overlooking something silly, would
                you be able to offer any advice please?

                Thanks
                Pete





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









_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to