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@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)
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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Cool, I'm glad it works. :D
--- Stefan
On Wed, May 31, 2017 at 3:54 PM, Jean Cérien cerien.jean@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@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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Jean Cérien -
Mititelu Stefan