[OpenSIPS-Users] Dispatcher not probing

[Pete Kelly]

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 <bogdan at 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
> 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>
> 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
>> OpenSIPS Summit 2018
>>   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>
>> wrote:
>>
>>> Hi Pete,
>>>
>>> The DB schema is documented here:
>>>     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
>>> OpenSIPS Summit 2018
>>>   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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180130/978fd751/attachment-0001.html>