[OpenSIPS-Users] Dispatcher not probing

[Bogdan-Andrei Iancu]

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
OpenSIPS Summit 2018
   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 <bogdan at opensips.org 
> <mailto:bogdan at 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
>>     <bogdan at opensips.org <mailto:bogdan at 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 at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>         <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180126/a8fc68c5/attachment.html>