[SR-Users] dispatcher & failover

Jean Cérien cerien.jean at gmail.com
Wed May 31 14:54:16 CEST 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170531/9692ac37/attachment.html>


More information about the sr-users mailing list