Hi, is this expected behavior?
I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10).
When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP.
root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list
{
NRSETS: 1
RECORDS: {
SET: {
ID: 1
TARGETS: {
DEST: {
URI: sip:10.20.20.252:5060
FLAGS: IP
PRIORITY: 10
LATENCY: {
AVG: 0.000000
STD: 0.000000
EST: 0.000000
MAX: 0
TIMEOUT: 62
}
}
DEST: {
URI: sip:10.20.20.118:5060
FLAGS: AP
PRIORITY: 5
LATENCY: {
AVG: 3.876000
STD: 2.965000
EST: 5.058000
MAX: 14
TIMEOUT: 0
}
}
}
}
}
}
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar bazyar@gmail.com wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p...
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar bazyar@gmail.com Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Henning,
I've been over that section a number of times, but it is still not clear why Dispatcher would return from ds_select_dst a host that is in IP state. "I" is Inactive.
What does "Probing" mean? Does it imply something besides "we're trying to send OPTIONS packets"?
Regards,
Jawaid
On 3/13/23, 8:55 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com> wrote:
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt hw@gilawa.com Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p...
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar bazyar@gmail.com Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar bazyar@gmail.com wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi Alex,
I did try round-robin, but it has a different issue, which is that calls from a handset through the Kamailio to say asterisk1, trigger authentication challenge, then when the auth comes back from the client, Kam decides that's a failure, goes into the failover logic, and it round robins the client's auth to the -other- asterisk asterisk2, which then rejects the auth attempt as having a stale nonce (which is right, since it came from the other asterisk).
I haven't yet figured out how to keep affinity for the same asterisk except by routing based on CallID.
I guess the other option would be to tell Dispatcher that 401 Auth is not a 'failure'. If I can figure that out, then I can try with round robin.
Jawaid
--
On 3/13/23, 6:09 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
To your failure_route used for dispatcher rollover, add:
if(t_check_status(“407|401”)) exit;
This will allow the 401/407 challenge to be fed back to the original caller.
— Alex
On Mar 13, 2023, at 8:27 PM, Jawaid Bazyar bazyar@gmail.com wrote:
Hi Alex,
I did try round-robin, but it has a different issue, which is that calls from a handset through the Kamailio to say asterisk1, trigger authentication challenge, then when the auth comes back from the client, Kam decides that's a failure, goes into the failover logic, and it round robins the client's auth to the -other- asterisk asterisk2, which then rejects the auth attempt as having a stale nonce (which is right, since it came from the other asterisk).
I haven't yet figured out how to keep affinity for the same asterisk except by routing based on CallID.
I guess the other option would be to tell Dispatcher that 401 Auth is not a 'failure'. If I can figure that out, then I can try with round robin.
Jawaid
--
On 3/13/23, 6:09 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
That seems like it ought to have worked, but no..
Same issue,
Pic of trace attached.
The below config is largely cribbed from the default kamailio.cfg, and from the Dispatcher documentation example config..
In request_route
route(DISPATCH);
route[DISPATCH] { if (!ds_select_dst(1, 4)) { #Get a destination from dispatcher send_reply("404","No destination DS"); exit; } xlog("--- DISPATCH: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); #Route it exit; }
failure_route[DISPATCH_FAILURE] { if (t_is_canceled()) { exit; } # if an auth request, don't go to next entry in ds list.. if (t_check_status("(401)|(407)")) { xlog("401 or 407 status reply from dispatch"); exit; }
# next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { # on a timeout failure, 500, etc mark this dest as IP (as bad). ds_mark_dst("ip"); if(ds_next_dst()) { xlog("--- DISPATCH_FAILURE: retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); exit; } } }
On 3/13/23, 7:49 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
To your failure_route used for dispatcher rollover, add:
if(t_check_status(“407|401”)) exit;
This will allow the 401/407 challenge to be fed back to the original caller.
— Alex
On Mar 13, 2023, at 8:27 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi Alex,
I did try round-robin, but it has a different issue, which is that calls from a handset through the Kamailio to say asterisk1, trigger authentication challenge, then when the auth comes back from the client, Kam decides that's a failure, goes into the failover logic, and it round robins the client's auth to the -other- asterisk asterisk2, which then rejects the auth attempt as having a stale nonce (which is right, since it came from the other asterisk).
I haven't yet figured out how to keep affinity for the same asterisk except by routing based on CallID.
I guess the other option would be to tell Dispatcher that 401 Auth is not a 'failure'. If I can figure that out, then I can try with round robin.
Jawaid
--
On 3/13/23, 6:09 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>>
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com>> https://evaristesys.com&gt;>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
what about just hashing over a stable part, e.g. the from URI? Then the dispatcher would distribute the second INVITE with authorization information to the same asterisk again.
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar bazyar@gmail.com Sent: Dienstag, 14. März 2023 03:20 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dispatcher behavior
That seems like it ought to have worked, but no..
Same issue,
Pic of trace attached.
The below config is largely cribbed from the default kamailio.cfg, and from the Dispatcher documentation example config..
In request_route
route(DISPATCH);
route[DISPATCH] { if (!ds_select_dst(1, 4)) { #Get a destination from dispatcher send_reply("404","No destination DS"); exit; } xlog("--- DISPATCH: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); #Route it exit; }
failure_route[DISPATCH_FAILURE] { if (t_is_canceled()) { exit; } # if an auth request, don't go to next entry in ds list.. if (t_check_status("(401)|(407)")) { xlog("401 or 407 status reply from dispatch"); exit; }
# next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { # on a timeout failure, 500, etc mark this dest as IP (as bad). ds_mark_dst("ip"); if(ds_next_dst()) { xlog("--- DISPATCH_FAILURE: retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); exit; } } }
On 3/13/23, 7:49 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
To your failure_route used for dispatcher rollover, add:
if(t_check_status(“407|401”)) exit;
This will allow the 401/407 challenge to be fed back to the original caller.
— Alex
On Mar 13, 2023, at 8:27 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> wrote:
Hi Alex,
I did try round-robin, but it has a different issue, which is that calls from a handset through the Kamailio to say asterisk1, trigger authentication challenge, then when the auth comes back from the client, Kam decides that's a failure, goes into the failover logic, and it round robins the client's auth to the -other- asterisk asterisk2, which then rejects the auth attempt as having a stale nonce (which is right, since it came from the other asterisk).
I haven't yet figured out how to keep affinity for the same asterisk except by routing based on CallID.
I guess the other option would be to tell Dispatcher that 401 Auth is not a 'failure'. If I can figure that out, then I can try with round robin.
Jawaid
--
On 3/13/23, 6:09 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>>
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com>> https://evaristesys.com&gt;>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi, yes, that's the change I made which gets around the issue. I have the priorities of the hosts currently set to be the same, and, am using one of the URI hashes for REGISTER.
On 3/15/23, 3:09 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com> wrote:
Hello,
what about just hashing over a stable part, e.g. the from URI? Then the dispatcher would distribute the second INVITE with authorization information to the same asterisk again.
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> Sent: Dienstag, 14. März 2023 03:20 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
That seems like it ought to have worked, but no..
Same issue,
Pic of trace attached.
The below config is largely cribbed from the default kamailio.cfg, and from the Dispatcher documentation example config..
In request_route
route(DISPATCH);
route[DISPATCH] { if (!ds_select_dst(1, 4)) { #Get a destination from dispatcher send_reply("404","No destination DS"); exit; } xlog("--- DISPATCH: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); #Route it exit; }
failure_route[DISPATCH_FAILURE] { if (t_is_canceled()) { exit; } # if an auth request, don't go to next entry in ds list.. if (t_check_status("(401)|(407)")) { xlog("401 or 407 status reply from dispatch"); exit; }
# next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { # on a timeout failure, 500, etc mark this dest as IP (as bad). ds_mark_dst("ip"); if(ds_next_dst()) { xlog("--- DISPATCH_FAILURE: retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("DISPATCH_FAILURE"); route(RELAY); exit; } } }
On 3/13/23, 7:49 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> wrote:
To your failure_route used for dispatcher rollover, add:
if(t_check_status(“407|401”)) exit;
This will allow the 401/407 challenge to be fed back to the original caller.
— Alex
On Mar 13, 2023, at 8:27 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi Alex,
I did try round-robin, but it has a different issue, which is that calls from a handset through the Kamailio to say asterisk1, trigger authentication challenge, then when the auth comes back from the client, Kam decides that's a failure, goes into the failover logic, and it round robins the client's auth to the -other- asterisk asterisk2, which then rejects the auth attempt as having a stale nonce (which is right, since it came from the other asterisk).
I haven't yet figured out how to keep affinity for the same asterisk except by routing based on CallID.
I guess the other option would be to tell Dispatcher that 401 Auth is not a 'failure'. If I can figure that out, then I can try with round robin.
Jawaid
--
On 3/13/23, 6:09 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>> wrote:
I wonder if the distribution algorithm you have chosen behaves differently in this regard. Have you tried plain round-robin (i.e. #4)?
On Mar 13, 2023, at 6:59 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> wrote:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>>> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com> <mailto:hw@gilawa.com mailto:hw@gilawa.com <mailto:hw@gilawa.com mailto:hw@gilawa.com>>>> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>>> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode>> https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p.ds_probing_mode&gt;>>
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>>> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>>>> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com> <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto:abalashov@evaristesys.com>>>>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>>>>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com>> https://evaristesys.com&gt;>> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com>> https://evaristesys.com&gt;>> https://evaristesys.com> https://evaristesys.com>> https://evaristesys.com>> https://evaristesys.com&gt;>> https://evaristesys.com>> https://evaristesys.com&gt;>> https://evaristesys.com&gt;>> https://evaristesys.com&amp;gt;&gt;>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com https://evaristesys.com https://evaristesys.com> https://evaristesys.com https://evaristesys.com> https://evaristesys.com> https://evaristesys.com>> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org>> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hi,
You can configure Kamailio with dispatcher to an behavior like you want.
I personal would not set an destination to IP on 500 but that depends on your needs.
Kind regards
Jawaid Bazyar bazyar@gmail.com schrieb am Di., 14. März 2023, 00:41:
Hi,
Maybe it would be easier to explain my expectations on how it's supposed to work, and then you can tell me where I'm making a wrong assumption __
So, load balancers like haproxy etc perform "health checks" on the service being balanced. In this case, I have it setup for Kamailio to send OPTIONS and I do in fact see those packets and 200 OK responses. And if haproxy sees a host is down, it immediately stops trying to send client requests to that host.
In this case, after 10 successful OPTIONS pings, Kamailio marks the destination as AP and everything is fine, Kamailio correctly returns the destination in ds_select_dst.
I have the settings below, so that if the service misses 5 OPTIONS checks, Kamailio should mark that destination as "inactive". But, it should keep probing it, so Kamailio can detect when the destination comes back up. So as I understand it, that's the status "IP".
And, Kamailio should stop including that destination in the responses from ds_select_dst().
And all of that is behaving as expected, EXCEPT that last bit - ds_select_dst continues to include the IP (inactive) destination in responses.
I added
ds_mark_dst("ip");
in the event of a 500 or branch failure response, but I don't understand why this is needed, because the destination is already in "IP" mode.
So seemingly Kamailio knows the destination is inactive, but ds_select_dst isn't acting on it unless I manually mark the target also.
Perhaps I am overlooking an option?
Regards,
Jawaid
On 3/13/23, 9:51 AM, "Henning Westerholt" <hw@gilawa.com mailto: hw@gilawa.com> wrote:
Hello,
probing means in this context sending OPTIONS pings, yes.
In mode 1 you can disable the probing by setting flag 4 to the destination in the dispatcher file, according to the docs.
Cheers,
Henning
-----Original Message----- From: Henning Westerholt <hw@gilawa.com mailto:hw@gilawa.com> Sent: Montag, 13. März 2023 15:55 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hello,
not sure what the "auto-probing" mode is, but you can configure the dispatcher OPTIONS ping behaviour with that parameter:
https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p... < https://kamailio.org/docs/modules/5.5.x/modules/dispatcher.html#dispatcher.p...
Cheers,
Henning
-----Original Message----- From: Jawaid Bazyar <bazyar@gmail.com mailto:bazyar@gmail.com> Sent: Montag, 13. März 2023 14:33 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Re: Dispatcher behavior
Hi Alex,
I don't see "auto-probing" in the documentation.. here is my dispatcher config that I snatched from somewhere on the Internet.
modparam("dispatcher", "db_url", "mysql://xxxxxxx/kamailio") #Use DBURL variable for database parameters modparam("dispatcher", "flags", 2) # If flag 2 is set, then the failover support is enabled. modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 5) #How often to ping destinations to check status modparam("dispatcher", "ds_ping_method", "OPTIONS") #Send SIP Options ping modparam("dispatcher", "ds_probing_threshold", 5) #How many failed pings in a row do we need before we consider it down modparam("dispatcher", "ds_inactive_threshold", 10) #How many sucessful pings in a row do we need before considering it up modparam("dispatcher", "ds_ping_latency_stats", 1) #Enables stats on latency modparam("dispatcher", "ds_probing_mode", 1) #Keeps pinging gateways when state is known (to detect change in state)
On 3/12/23, 8:28 PM, "Alex Balashov" <abalashov@evaristesys.com mailto: abalashov@evaristesys.com <mailto:abalashov@evaristesys.com mailto: abalashov@evaristesys.com>> wrote:
Unless you have auto-probing enabled, yes.
On Mar 12, 2023, at 9:14 PM, Jawaid Bazyar <bazyar@gmail.com <mailto:
bazyar@gmail.com> <mailto:bazyar@gmail.com mailto:bazyar@gmail.com>> wrote:
Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and
10.20.20.252 (prio 10).
When I have 10.20.20.252 turned off, dispatcher still tries to send
packets to that host, even when the status flags are IP.
root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } } __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org <mailto:
sr-users-leave@lists.kamailio.org>
<mailto:sr-users-leave@lists.kamailio.org <mailto:
sr-users-leave@lists.kamailio.org>>
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com https://evaristesys.com < https://evaristesys.com%3E https://evaristesys.com> Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto: sr-users-leave@lists.kamailio.org <mailto: sr-users-leave@lists.kamailio.org mailto: sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto: sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto: sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
What type of packets? It should send OPTIONS to check whether it came back up. There’s params to disable this behavior.
On Mon, 13 Mar 2023 at 01:53, Jawaid Bazyar bazyar@gmail.com wrote:
Hi, is this expected behavior?
I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10).
When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP.
root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list
{
NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } }
}
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: