[SR-Users] dispatcher & failover

[Mititelu Stefan]

Cool, I'm glad it works. :D

---
Stefan

On Wed, May 31, 2017 at 3:54 PM, Jean Cérien <cerien.jean at gmail.com> wrote:

>
> I've spent quite some time on tihs doc, and managed *not* to read this
> paragraph.....
>
> Many thanks for the help, it is indeed working as you said !
>
> J.
>
> On Wed, May 31, 2017 at 8:24 AM, Mititelu Stefan <
> stefan.mititelu92 at gmail.com> wrote:
>
>> Hi,
>>
>> In the documentation I read the following for "ds_ping_reply_codes":
>>
>> "Please note that the response codes the module accepts as valid reply to
>> the PING-Method are not only the ones generated from the remote servers,
>> but also those that are generated locally. E.g.: setting code=408 or
>> class=400 will never set a backend down even if it is, because internally
>> the Kamailio transaction layer generates a 408 in the case of no response
>> from the remote server, and this internal code 408 is accepted as valid
>> value"
>>
>> Then I can see you set class=4 which probably collides with the above
>> statement.
>>
>> Try removing the class=4 and give it a try. If it works, you can set
>> specific 4xx codes afterwards(if needed).
>>
>> ---
>> Stefan
>>
>> On Tue, May 30, 2017 at 4:49 PM, Jean Cérien <cerien.jean at gmail.com>
>> wrote:
>>
>>>
>>> Hello
>>>
>>> I am working with Kamailio 5.0 dispatcher module. I am aiming at having
>>> two or more gateways receiving the traffic with load balancing, and when
>>> one fails, that the traffic is distributed among others. Currently, testing
>>> with 2 gw.
>>>
>>> I see the options message going out (and not being answered). When I
>>> monitor with kamctl dispatcher dump, I never see the faulty gw going
>>> inactive (flags remain AP), and calls are still tried to the faulty gw.
>>>
>>> "Best" result so far is with ds_probing_mode=1, the flags start at AX
>>> with both gateway up, then AP once they've replied to an OPTIONS, and even
>>> if I stop one, and OPTIONS is no longer replied, it stays at AP. when a
>>> call comes through, it is tried on this GW (3 invites), and then fails onto
>>> the other one. I was expecting that the gw would not be tried if inactive.
>>>
>>> Am I missing something ?
>>>
>>> J.
>>>
>>> modparam("dispatcher", "db_url", DBURL)
>>> modparam("dispatcher", "table_name", "dispatcher")
>>> modparam("dispatcher", "flags", 2)
>>> modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
>>> modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
>>> modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
>>> modparam("dispatcher", "sock_avp", "$avp(AVP_SOCK)")
>>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>>> modparam("dispatcher", "ds_ping_from", "sip:probe at probe")
>>> modparam("dispatcher", "ds_ping_reply_codes",
>>> "class=2;class=3;class=4;class=5")
>>> modparam("dispatcher", "ds_ping_interval", 30)
>>> modparam("dispatcher", "ds_probing_mode", 1)
>>> modparam("dispatcher", "ds_probing_threshold", 3)
>>> modparam("dispatcher", "ds_timer_mode", 1)
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170531/d1be0b52/attachment.html>