20 Oct
2011
20 Oct
'11
8:52 p.m.
Hi All,
Just been doing some testing with Kamailio 3.2 and the dispatcher
module, and have some strange behaviour, can we confirm if it is
expected behaviour or a bug of some sort.
It appears that I can only set the dspatcher state via fifo command
once, and not reset it again, here is an example:
version: kamailio 3.2.0 (i386/linux) 94d3b8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 94d3b8
compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
Here we start with the dispatcher list as it was pulled from the
database and currently loaded in memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I try to set one gateway inactive:
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
All normal so far, now if I try to set the same gateway active again,
the state still stays inactive, i dont seem to be able to change the
state back to active. The same thing happens if I attempt to set this
state to disabled and then try to set it back to active afterwards. The
state does not change from what the first attempt was.
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I can try to set the state to inactive probing, that works.
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now if I try to disable the same destination:
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
State still stays in Inactive/Probing mode.
Now if I try to set the same gateway to active/probing mode, I cant:
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
The only way for me to get the state back to active after the above is
to do a reload on the dispatch table:
# kamctl dispatcher reload
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Is the dispatcher expected to behave as above?
I'm still trying to understand the different states assuming the
following options are set in the configuration file:
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
AX = Active/No Probing
(*) Gateway is used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages are sent to destination to check alive
state
This appears to be the normal operating state with no issues detected.
AP = Active/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination to check alive state
This appears to be the state taken when a gateway times out and
ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
down and set into AX mode once a response is recieved.
IX = Inactive/No Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages sent to destination
This appears to be the state taken when a gateway times out and if
ds_mark_dst("i") is set in failure route, this gateway is set inactive
and no "pinging" is performed.
IP = Inactive/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination
I'm not sure when this state would be reached unless it is set by
fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
the probing method would only become active is ds_probing_mode = 1. In
my case it is 0, so I'm not sure if I would ever reach this state unless
I forced it. What would happen here is the gateway came back alive once
in "IP" state, would it go back to "AX" state?
DX = Disabled/No Probing
(*) Gateway is administratively set to down
This is where manual intervention has occured and the destination
has been set to administrativly down, for example, work being carried
out on the destination gateway.
All these states make sense, for the most part, I'm a little unsure of
how IP/IX is meant to work unless you manually set it to "inactive" in
your failure route.
The main concern though is the the fifo commands dont appear to be
working as expected, I can only set the state for a destination manually
once, and not again after that, unless I perform a dispatcher reload.
Has anyone else experienced this behaviour?
Any comments/suggestions explanations are most welcome.
Thanks
21 Oct
21 Oct
12:54 a.m.
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your tests,
then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
Hi All,
Just been doing some testing with Kamailio 3.2 and the dispatcher
module, and have some strange behaviour, can we confirm if it is
expected behaviour or a bug of some sort.
It appears that I can only set the dspatcher state via fifo command
once, and not reset it again, here is an example:
version: kamailio 3.2.0 (i386/linux) 94d3b8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 94d3b8
compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
Here we start with the dispatcher list as it was pulled from the
database and currently loaded in memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I try to set one gateway inactive:
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
All normal so far, now if I try to set the same gateway active again,
the state still stays inactive, i dont seem to be able to change the
state back to active. The same thing happens if I attempt to set this
state to disabled and then try to set it back to active afterwards. The
state does not change from what the first attempt was.
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I can try to set the state to inactive probing, that works.
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now if I try to disable the same destination:
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
State still stays in Inactive/Probing mode.
Now if I try to set the same gateway to active/probing mode, I cant:
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
The only way for me to get the state back to active after the above is
to do a reload on the dispatch table:
# kamctl dispatcher reload
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Is the dispatcher expected to behave as above?
I'm still trying to understand the different states assuming the
following options are set in the configuration file:
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
AX = Active/No Probing
(*) Gateway is used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages are sent to destination to check alive
state
This appears to be the normal operating state with no issues detected.
AP = Active/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination to check alive state
This appears to be the state taken when a gateway times out and
ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
down and set into AX mode once a response is recieved.
IX = Inactive/No Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages sent to destination
This appears to be the state taken when a gateway times out and if
ds_mark_dst("i") is set in failure route, this gateway is set inactive
and no "pinging" is performed.
IP = Inactive/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination
I'm not sure when this state would be reached unless it is set by
fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
the probing method would only become active is ds_probing_mode = 1. In
my case it is 0, so I'm not sure if I would ever reach this state unless
I forced it. What would happen here is the gateway came back alive once
in "IP" state, would it go back to "AX" state?
DX = Disabled/No Probing
(*) Gateway is administratively set to down
This is where manual intervention has occured and the destination
has been set to administrativly down, for example, work being carried
out on the destination gateway.
All these states make sense, for the most part, I'm a little unsure of
how IP/IX is meant to work unless you manually set it to "inactive" in
your failure route.
The main concern though is the the fifo commands dont appear to be
working as expected, I can only set the state for a destination manually
once, and not again after that, unless I perform a dispatcher reload.
Has anyone else experienced this behaviour?
Any comments/suggestions explanations are most welcome.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
11:16 a.m.
Thanks Daniel, I will do some testing of the development version and get
back to you.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your
tests, then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
Hi All,
Just been doing some testing with Kamailio 3.2 and the dispatcher
module, and have some strange behaviour, can we confirm if it is
expected behaviour or a bug of some sort.
It appears that I can only set the dspatcher state via fifo command
once, and not reset it again, here is an example:
version: kamailio 3.2.0 (i386/linux) 94d3b8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 94d3b8
compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
Here we start with the dispatcher list as it was pulled from the
database and currently loaded in memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I try to set one gateway inactive:
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
All normal so far, now if I try to set the same gateway active again,
the state still stays inactive, i dont seem to be able to change the
state back to active. The same thing happens if I attempt to set this
state to disabled and then try to set it back to active afterwards. The
state does not change from what the first attempt was.
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I can try to set the state to inactive probing, that works.
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now if I try to disable the same destination:
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
State still stays in Inactive/Probing mode.
Now if I try to set the same gateway to active/probing mode, I cant:
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
The only way for me to get the state back to active after the above is
to do a reload on the dispatch table:
# kamctl dispatcher reload
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Is the dispatcher expected to behave as above?
I'm still trying to understand the different states assuming the
following options are set in the configuration file:
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
AX = Active/No Probing
(*) Gateway is used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages are sent to destination to check alive
state
This appears to be the normal operating state with no issues
detected.
AP = Active/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination to check alive
state
This appears to be the state taken when a gateway times out and
ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
down and set into AX mode once a response is recieved.
IX = Inactive/No Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages sent to destination
This appears to be the state taken when a gateway times out and if
ds_mark_dst("i") is set in failure route, this gateway is set inactive
and no "pinging" is performed.
IP = Inactive/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination
I'm not sure when this state would be reached unless it is set by
fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
the probing method would only become active is ds_probing_mode = 1. In
my case it is 0, so I'm not sure if I would ever reach this state unless
I forced it. What would happen here is the gateway came back alive once
in "IP" state, would it go back to "AX" state?
DX = Disabled/No Probing
(*) Gateway is administratively set to down
This is where manual intervention has occured and the destination
has been set to administrativly down, for example, work being carried
out on the destination gateway.
All these states make sense, for the most part, I'm a little unsure of
how IP/IX is meant to work unless you manually set it to "inactive" in
your failure route.
The main concern though is the the fifo commands dont appear to be
working as expected, I can only set the state for a destination manually
once, and not again after that, unless I perform a dispatcher reload.
Has anyone else experienced this behaviour?
Any comments/suggestions explanations are most welcome.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:53 p.m.
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Here we have the dispatcher state as loaded from db on startup in
kamailio memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive (Worked)
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to active (Worked)
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive-probing (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to active-probing (Worked)
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from AP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to disabled (Worked). At this point no pinging occured
as destination is admin down.
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to inactive-probing again, from disabled state (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Thanks.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your
tests, then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
Hi All,
Just been doing some testing with Kamailio 3.2 and the dispatcher
module, and have some strange behaviour, can we confirm if it is
expected behaviour or a bug of some sort.
It appears that I can only set the dspatcher state via fifo command
once, and not reset it again, here is an example:
version: kamailio 3.2.0 (i386/linux) 94d3b8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 94d3b8
compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
Here we start with the dispatcher list as it was pulled from the
database and currently loaded in memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I try to set one gateway inactive:
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
All normal so far, now if I try to set the same gateway active again,
the state still stays inactive, i dont seem to be able to change the
state back to active. The same thing happens if I attempt to set this
state to disabled and then try to set it back to active afterwards. The
state does not change from what the first attempt was.
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now I can try to set the state to inactive probing, that works.
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now if I try to disable the same destination:
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
State still stays in Inactive/Probing mode.
Now if I try to set the same gateway to active/probing mode, I cant:
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
The only way for me to get the state back to active after the above is
to do a reload on the dispatch table:
# kamctl dispatcher reload
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Is the dispatcher expected to behave as above?
I'm still trying to understand the different states assuming the
following options are set in the configuration file:
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
AX = Active/No Probing
(*) Gateway is used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages are sent to destination to check alive
state
This appears to be the normal operating state with no issues
detected.
AP = Active/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination to check alive
state
This appears to be the state taken when a gateway times out and
ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
down and set into AX mode once a response is recieved.
IX = Inactive/No Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) No OPTIONS/INFO messages sent to destination
This appears to be the state taken when a gateway times out and if
ds_mark_dst("i") is set in failure route, this gateway is set inactive
and no "pinging" is performed.
IP = Inactive/Probing
(*) Gateway is NOT used in ds_select_*, ds_next_*
(*) OPTIONS/INFO messages ARE sent to destination
I'm not sure when this state would be reached unless it is set by
fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
the probing method would only become active is ds_probing_mode = 1. In
my case it is 0, so I'm not sure if I would ever reach this state unless
I forced it. What would happen here is the gateway came back alive once
in "IP" state, would it go back to "AX" state?
DX = Disabled/No Probing
(*) Gateway is administratively set to down
This is where manual intervention has occured and the destination
has been set to administrativly down, for example, work being carried
out on the destination gateway.
All these states make sense, for the most part, I'm a little unsure of
how IP/IX is meant to work unless you manually set it to "inactive" in
your failure route.
The main concern though is the the fifo commands dont appear to be
working as expected, I can only set the state for a destination manually
once, and not again after that, unless I perform a dispatcher reload.
Has anyone else experienced this behaviour?
Any comments/suggestions explanations are most welcome.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
22 Oct
22 Oct
4:42 p.m.
Hi Daniel,
Just a reminder for this issue, to backport to 3.2.0 :)
Thanks
On 21/10/2011 10:53, Asgaroth wrote:
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Here we have the dispatcher state as loaded from db on startup in
kamailio memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive (Worked)
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to active (Worked)
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive-probing (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to active-probing (Worked)
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from AP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to disabled (Worked). At this point no pinging occured
as destination is admin down.
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to inactive-probing again, from disabled state (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Thanks.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your
tests, then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
> Hi All,
>
> Just been doing some testing with Kamailio 3.2 and the dispatcher
> module, and have some strange behaviour, can we confirm if it is
> expected behaviour or a bug of some sort.
>
> It appears that I can only set the dspatcher state via fifo command
> once, and not reset it again, here is an example:
>
> version: kamailio 3.2.0 (i386/linux) 94d3b8
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 94d3b8
> compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
>
>
> Here we start with the dispatcher list as it was pulled from the
> database and currently loaded in memory.
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I try to set one gateway inactive:
>
> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> All normal so far, now if I try to set the same gateway active again,
> the state still stays inactive, i dont seem to be able to change the
> state back to active. The same thing happens if I attempt to set this
> state to disabled and then try to set it back to active afterwards. The
> state does not change from what the first attempt was.
>
> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I can try to set the state to inactive probing, that works.
>
> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now if I try to disable the same destination:
>
> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> State still stays in Inactive/Probing mode.
>
> Now if I try to set the same gateway to active/probing mode, I cant:
>
> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> The only way for me to get the state back to active after the above is
> to do a reload on the dispatch table:
>
> # kamctl dispatcher reload
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Is the dispatcher expected to behave as above?
>
> I'm still trying to understand the different states assuming the
> following options are set in the configuration file:
>
> modparam("dispatcher", "ds_ping_interval", 10)
> modparam("dispatcher", "ds_probing_threshhold", 1)
> modparam("dispatcher", "ds_probing_mode", 0)
>
> AX = Active/No Probing
> (*) Gateway is used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages are sent to destination to check alive
> state
>
> This appears to be the normal operating state with no issues
> detected.
>
> AP = Active/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination to check alive
> state
>
> This appears to be the state taken when a gateway times out and
> ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
> down and set into AX mode once a response is recieved.
>
> IX = Inactive/No Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages sent to destination
>
> This appears to be the state taken when a gateway times out and if
> ds_mark_dst("i") is set in failure route, this gateway is set inactive
> and no "pinging" is performed.
>
> IP = Inactive/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination
>
> I'm not sure when this state would be reached unless it is set by
> fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
> the probing method would only become active is ds_probing_mode = 1. In
> my case it is 0, so I'm not sure if I would ever reach this state unless
> I forced it. What would happen here is the gateway came back alive once
> in "IP" state, would it go back to "AX" state?
>
> DX = Disabled/No Probing
> (*) Gateway is administratively set to down
>
> This is where manual intervention has occured and the destination
> has been set to administrativly down, for example, work being carried
> out on the destination gateway.
>
> All these states make sense, for the most part, I'm a little unsure of
> how IP/IX is meant to work unless you manually set it to "inactive" in
> your failure route.
>
> The main concern though is the the fifo commands dont appear to be
> working as expected, I can only set the state for a destination manually
> once, and not again after that, unless I perform a dispatcher reload.
>
> Has anyone else experienced this behaviour?
>
> Any comments/suggestions explanations are most welcome.
>
> Thanks
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:55 p.m.
Hello,
yes, I will do it. Just happens to travel these days, but when I get the
time for it, I will do it.
Btw, did you test also the load balancing functionality? Was it affected
or all is ok when you change the states? I mean when you disable/make
inactive a gateway, is no longer used for routing, right? Just double
checking, to be sure it was not affected by this change.
Thanks,
Daniel
On 10/22/11 3:42 PM, Asgaroth wrote:
Hi Daniel,
Just a reminder for this issue, to backport to 3.2.0 :)
Thanks
On 21/10/2011 10:53, Asgaroth wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Here we have the dispatcher state as loaded from db on startup in
kamailio memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive (Worked)
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to active (Worked)
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive-probing (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to active-probing (Worked)
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from AP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to disabled (Worked). At this point no pinging occured
as destination is admin down.
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to inactive-probing again, from disabled state (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Thanks.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your
tests, then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
> Hi All,
>
> Just been doing some testing with Kamailio 3.2 and the dispatcher
> module, and have some strange behaviour, can we confirm if it is
> expected behaviour or a bug of some sort.
>
> It appears that I can only set the dspatcher state via fifo command
> once, and not reset it again, here is an example:
>
> version: kamailio 3.2.0 (i386/linux) 94d3b8
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 94d3b8
> compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
>
>
> Here we start with the dispatcher list as it was pulled from the
> database and currently loaded in memory.
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I try to set one gateway inactive:
>
> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> All normal so far, now if I try to set the same gateway active again,
> the state still stays inactive, i dont seem to be able to change the
> state back to active. The same thing happens if I attempt to set this
> state to disabled and then try to set it back to active afterwards. The
> state does not change from what the first attempt was.
>
> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I can try to set the state to inactive probing, that works.
>
> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now if I try to disable the same destination:
>
> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> State still stays in Inactive/Probing mode.
>
> Now if I try to set the same gateway to active/probing mode, I cant:
>
> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> The only way for me to get the state back to active after the above is
> to do a reload on the dispatch table:
>
> # kamctl dispatcher reload
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Is the dispatcher expected to behave as above?
>
> I'm still trying to understand the different states assuming the
> following options are set in the configuration file:
>
> modparam("dispatcher", "ds_ping_interval", 10)
> modparam("dispatcher", "ds_probing_threshhold", 1)
> modparam("dispatcher", "ds_probing_mode", 0)
>
> AX = Active/No Probing
> (*) Gateway is used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages are sent to destination to check alive
> state
>
> This appears to be the normal operating state with no issues
> detected.
>
> AP = Active/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination to check alive
> state
>
> This appears to be the state taken when a gateway times out and
> ds_mark_dst("p") is set in failure route, the gateway is "pinged"
while
> down and set into AX mode once a response is recieved.
>
> IX = Inactive/No Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages sent to destination
>
> This appears to be the state taken when a gateway times out and if
> ds_mark_dst("i") is set in failure route, this gateway is set inactive
> and no "pinging" is performed.
>
> IP = Inactive/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination
>
> I'm not sure when this state would be reached unless it is set by
> fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
> the probing method would only become active is ds_probing_mode = 1. In
> my case it is 0, so I'm not sure if I would ever reach this state unless
> I forced it. What would happen here is the gateway came back alive once
> in "IP" state, would it go back to "AX" state?
>
> DX = Disabled/No Probing
> (*) Gateway is administratively set to down
>
> This is where manual intervention has occured and the destination
> has been set to administrativly down, for example, work being carried
> out on the destination gateway.
>
> All these states make sense, for the most part, I'm a little unsure of
> how IP/IX is meant to work unless you manually set it to "inactive" in
> your failure route.
>
> The main concern though is the the fifo commands dont appear to be
> working as expected, I can only set the state for a destination manually
> once, and not again after that, unless I perform a dispatcher reload.
>
> Has anyone else experienced this behaviour?
>
> Any comments/suggestions explanations are most welcome.
>
> Thanks
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
24 Oct
24 Oct
6:30 p.m.
OK, did a few more tests but have come accross something, which I am not
sure is intended behaviour.
When setting a destingation as probing in failure route (due to
timeout), the destination still gets used in destination selection.
# ./kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Dispatcher module parameters (in testing) are as follows (SBC_PING_FROM
is #defined previously):
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_from", SBC_PING_FROM)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
Main routing logic has following snippet to select destination (hash
table selects dispatcher setid based on request domain):
if(!ds_select_dst("$sht(which_sbc=>$rd)", "0")) {
sl_send_reply("500", "No destination
available");
xlog("route[MAIN] : $rm : No destinations
available for $rd");
exit;
}
Failure route has following logic to select next destination based on
timout/failure of destination:
if (t_branch_timeout() && !t_branch_replied())
{
xlog("route[TO_SBC] : $rm : timeout and no reply
($si:$sp->$Ri:$Rp->$du)\n");
xlog("route[TO_SBC] : $rm : setting $du to probing state");
ds_mark_dst("p");
if(ds_next_dst())
{
xlog("route[TO_SBC] : $rm : next destination
select ($du)\n");
t_on_failure("TO_SBC");
t_relay();
exit;
} else {
send_reply("500", "No destination
available");
xlog("route[TO_SBC] : $rm : No destinations
available for $rd");
exit;
}
}
According to 3.2 module docs for dispatcher, when a destination is set
into probing state, it will not be used by ds_select_dst:
----
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With this
function, an automatic detection of failed gateways can be implemented.
When an address is marked as inactive or probing, it will be ignored by
'ds_select_dst' and 'ds_select_domain'.
possible parameters:
*
/"i", "I" or "0"/ - the last destination should be set
to inactive
and will be ignored in future requests.
*
/"a", "A" or "1"/ - the last destination should be set
to active and
the error-counter should set to "0".
*
/"p", "P" or "2"/ - the last destination will be set to
probing.
Note: You will need to call this function "threshhold"-times, before
it will be actually set to probing.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.
---
What happens here, for me, is:
[1] Gateway is in Active mode (state: AX).
[2] Request comes in and times out, destination is set to Active/Probing
(state: AP)
[3] Another request comes in and it selects gateway that is in AP mode,
times out, and then selects next dst in list.
[4] Another request comes in and it selects gateway that is in AP mode,
times out, and then selects next dst in list.
.
.
NOTE: The requests selecting the AP mode gateway may not be right after
each other (algorythm used is hash over callid) but I have stripped
those out in above steps. If I'm not mistaked, if 2 destination in a
set, and 1 destination is marked as AP, then remaining destination
should always be selected as destination to send to. The destination
marked AP (active-probing) should not be selected while in probing state.
When the gateway is set into AP mode at step [2], then, according to
docs, any new request coming in should not have the gateway selected as
it is marked as being in probing state.
Is this the intended behaviour or am I missing something in the
documentation, or is it a bug?
Thanks
On 22/10/2011 15:55, Daniel-Constantin Mierla wrote:
Hello,
yes, I will do it. Just happens to travel these days, but when I get
the time for it, I will do it.
Btw, did you test also the load balancing functionality? Was it
affected or all is ok when you change the states? I mean when you
disable/make inactive a gateway, is no longer used for routing, right?
Just double checking, to be sure it was not affected by this change.
Thanks,
Daniel
On 10/22/11 3:42 PM, Asgaroth wrote:
Hi Daniel,
Just a reminder for this issue, to backport to 3.2.0 :)
Thanks
On 21/10/2011 10:53, Asgaroth wrote:
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Here we have the dispatcher state as loaded from db on startup in
kamailio memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive (Worked)
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to active (Worked)
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive-probing (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to active-probing (Worked)
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from AP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to disabled (Worked). At this point no pinging
occured
as destination is admin down.
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to inactive-probing again, from disabled state
(Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Thanks.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your
tests, then I will backport.
Guidelines to install master branch can be found at:
https://www.kamailio.org/wiki/install/devel/git
Cheers,
Daniel
On 10/20/11 7:52 PM, Asgaroth wrote:
> Hi All,
>
> Just been doing some testing with Kamailio 3.2 and the dispatcher
> module, and have some strange behaviour, can we confirm if it is
> expected behaviour or a bug of some sort.
>
> It appears that I can only set the dspatcher state via fifo command
> once, and not reset it again, here is an example:
>
> version: kamailio 3.2.0 (i386/linux) 94d3b8
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
> USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 94d3b8
> compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
>
>
> Here we start with the dispatcher list as it was pulled from the
> database and currently loaded in memory.
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I try to set one gateway inactive:
>
> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> All normal so far, now if I try to set the same gateway active again,
> the state still stays inactive, i dont seem to be able to change the
> state back to active. The same thing happens if I attempt to set this
> state to disabled and then try to set it back to active
> afterwards. The
> state does not change from what the first attempt was.
>
> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now I can try to set the state to inactive probing, that works.
>
> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now if I try to disable the same destination:
>
> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> State still stays in Inactive/Probing mode.
>
> Now if I try to set the same gateway to active/probing mode, I cant:
>
> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> The only way for me to get the state back to active after the
> above is
> to do a reload on the dispatch table:
>
> # kamctl dispatcher reload
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Is the dispatcher expected to behave as above?
>
> I'm still trying to understand the different states assuming the
> following options are set in the configuration file:
>
> modparam("dispatcher", "ds_ping_interval", 10)
> modparam("dispatcher", "ds_probing_threshhold", 1)
> modparam("dispatcher", "ds_probing_mode", 0)
>
> AX = Active/No Probing
> (*) Gateway is used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages are sent to destination to
> check alive
> state
>
> This appears to be the normal operating state with no issues
> detected.
>
> AP = Active/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination to check
> alive
> state
>
> This appears to be the state taken when a gateway times out and
> ds_mark_dst("p") is set in failure route, the gateway is
"pinged"
> while
> down and set into AX mode once a response is recieved.
>
> IX = Inactive/No Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) No OPTIONS/INFO messages sent to destination
>
> This appears to be the state taken when a gateway times out
> and if
> ds_mark_dst("i") is set in failure route, this gateway is set
> inactive
> and no "pinging" is performed.
>
> IP = Inactive/Probing
> (*) Gateway is NOT used in ds_select_*, ds_next_*
> (*) OPTIONS/INFO messages ARE sent to destination
>
> I'm not sure when this state would be reached unless it is
> set by
> fifo command. The ds_mark_dst function only allows "a","i" or
"p". So
> the probing method would only become active is ds_probing_mode =
> 1. In
> my case it is 0, so I'm not sure if I would ever reach this state
> unless
> I forced it. What would happen here is the gateway came back alive
> once
> in "IP" state, would it go back to "AX" state?
>
> DX = Disabled/No Probing
> (*) Gateway is administratively set to down
>
> This is where manual intervention has occured and the
> destination
> has been set to administrativly down, for example, work being carried
> out on the destination gateway.
>
> All these states make sense, for the most part, I'm a little
> unsure of
> how IP/IX is meant to work unless you manually set it to
> "inactive" in
> your failure route.
>
> The main concern though is the the fifo commands dont appear to be
> working as expected, I can only set the state for a destination
> manually
> once, and not again after that, unless I perform a dispatcher reload.
>
> Has anyone else experienced this behaviour?
>
> Any comments/suggestions explanations are most welcome.
>
> Thanks
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
25 Oct
25 Oct
5:11 p.m.
Hi All,
Just wondering, has anyone else experienced the behaviour described
below, where messages are still routed to a gateway that is in
Active-Probing state? From my understanding of the docs, when a
destination is in probing state, it should not be used in the
destination selection. I can see that Kamailio does set the state from
AX to AP (Active to Active-Probing) when a timeout occurs, and a "kamctl
dispatcher dump" does show that the state has changed to AP, however,
sip trace to the destination still shows messages being routed to the
destination that is in AP mode.
Just checking if anyone else is seeing this behaviour as well.
Thanks
On 24/10/2011 16:30, Asgaroth wrote:
OK, did a few more tests but have come accross
something, which I am
not sure is intended behaviour.
When setting a destingation as probing in failure route (due to
timeout), the destination still gets used in destination selection.
# ./kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Dispatcher module parameters (in testing) are as follows
(SBC_PING_FROM is #defined previously):
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_from", SBC_PING_FROM)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
Main routing logic has following snippet to select destination (hash
table selects dispatcher setid based on request domain):
if(!ds_select_dst("$sht(which_sbc=>$rd)", "0")) {
sl_send_reply("500", "No destination
available");
xlog("route[MAIN] : $rm : No destinations
available for $rd");
exit;
}
Failure route has following logic to select next destination based on
timout/failure of destination:
if (t_branch_timeout() && !t_branch_replied())
{
xlog("route[TO_SBC] : $rm : timeout and no reply
($si:$sp->$Ri:$Rp->$du)\n");
xlog("route[TO_SBC] : $rm : setting $du to probing
state");
ds_mark_dst("p");
if(ds_next_dst())
{
xlog("route[TO_SBC] : $rm : next destination
select ($du)\n");
t_on_failure("TO_SBC");
t_relay();
exit;
} else {
send_reply("500", "No destination
available");
xlog("route[TO_SBC] : $rm : No destinations
available for $rd");
exit;
}
}
According to 3.2 module docs for dispatcher, when a destination is set
into probing state, it will not be used by ds_select_dst:
----
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
this function, an automatic detection of failed gateways can be
implemented. When an address is marked as inactive or probing, it will
be ignored by 'ds_select_dst' and 'ds_select_domain'.
possible parameters:
*
/"i", "I" or "0"/ - the last destination should be set
to inactive
and will be ignored in future requests.
*
/"a", "A" or "1"/ - the last destination should be set
to active
and the error-counter should set to "0".
*
/"p", "P" or "2"/ - the last destination will be set to
probing.
Note: You will need to call this function "threshhold"-times,
before it will be actually set to probing.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.
---
What happens here, for me, is:
[1] Gateway is in Active mode (state: AX).
[2] Request comes in and times out, destination is set to
Active/Probing (state: AP)
[3] Another request comes in and it selects gateway that is in AP
mode, times out, and then selects next dst in list.
[4] Another request comes in and it selects gateway that is in AP
mode, times out, and then selects next dst in list.
.
.
NOTE: The requests selecting the AP mode gateway may not be right
after each other (algorythm used is hash over callid) but I have
stripped those out in above steps. If I'm not mistaked, if 2
destination in a set, and 1 destination is marked as AP, then
remaining destination should always be selected as destination to send
to. The destination marked AP (active-probing) should not be selected
while in probing state.
When the gateway is set into AP mode at step [2], then, according to
docs, any new request coming in should not have the gateway selected
as it is marked as being in probing state.
Is this the intended behaviour or am I missing something in the
documentation, or is it a bug?
Thanks
On 22/10/2011 15:55, Daniel-Constantin Mierla wrote:
Hello,
yes, I will do it. Just happens to travel these days, but when I get
the time for it, I will do it.
Btw, did you test also the load balancing functionality? Was it
affected or all is ok when you change the states? I mean when you
disable/make inactive a gateway, is no longer used for routing,
right? Just double checking, to be sure it was not affected by this
change.
Thanks,
Daniel
On 10/22/11 3:42 PM, Asgaroth wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hi Daniel,
Just a reminder for this issue, to backport to 3.2.0 :)
Thanks
On 21/10/2011 10:53, Asgaroth wrote:
Hi Daniel,
It appears the change you made has fixed the issue. Below are my
tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
Here we have the dispatcher state as loaded from db on startup in
kamailio memory.
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive (Worked)
# kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to active (Worked)
# kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state for destination to inactive-probing (Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to active-probing (Worked)
# kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from AP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to disabled (Worked). At this point no pinging
occured
as destination is admin down.
# kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Now try set state to inactive-probing again, from disabled state
(Worked)
# kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
I waited for OPTIONS/INFO message and checked state (Worked), changed
state from IP -> AX
# kamctl dispatcher dump
SET_NO:: 2
SET:: 1
URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
SET:: 2
URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
Thanks.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
> Hello,
>
> indeed the setting of active state via MI command was wrong.
> Should be
> fixed now in master branch. Can you test it and see if works ok
> now (I
> had no option to test it myself yet). If all goes fine with your
> tests, then I will backport.
>
> Guidelines to install master branch can be found at:
> https://www.kamailio.org/wiki/install/devel/git
>
> Cheers,
> Daniel
>
>
> On 10/20/11 7:52 PM, Asgaroth wrote:
>> Hi All,
>>
>> Just been doing some testing with Kamailio 3.2 and the dispatcher
>> module, and have some strange behaviour, can we confirm if it is
>> expected behaviour or a bug of some sort.
>>
>> It appears that I can only set the dspatcher state via fifo command
>> once, and not reset it again, here is an example:
>>
>> version: kamailio 3.2.0 (i386/linux) 94d3b8
>> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
>> USE_RAW_SOCKS,
>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
>> PKG_MALLOC,
>> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
>> 16,
>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: 94d3b8
>> compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
>>
>>
>> Here we start with the dispatcher list as it was pulled from the
>> database and currently loaded in memory.
>>
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> Now I try to set one gateway inactive:
>>
>> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> All normal so far, now if I try to set the same gateway active
>> again,
>> the state still stays inactive, i dont seem to be able to change the
>> state back to active. The same thing happens if I attempt to set
>> this
>> state to disabled and then try to set it back to active
>> afterwards. The
>> state does not change from what the first attempt was.
>>
>> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> Now I can try to set the state to inactive probing, that works.
>>
>> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> Now if I try to disable the same destination:
>>
>> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> State still stays in Inactive/Probing mode.
>>
>> Now if I try to set the same gateway to active/probing mode, I cant:
>>
>> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> The only way for me to get the state back to active after the
>> above is
>> to do a reload on the dispatch table:
>>
>> # kamctl dispatcher reload
>> # kamctl dispatcher dump
>> SET_NO:: 2
>> SET:: 1
>> URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>> SET:: 2
>> URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>> URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>
>> Is the dispatcher expected to behave as above?
>>
>> I'm still trying to understand the different states assuming the
>> following options are set in the configuration file:
>>
>> modparam("dispatcher", "ds_ping_interval", 10)
>> modparam("dispatcher", "ds_probing_threshhold", 1)
>> modparam("dispatcher", "ds_probing_mode", 0)
>>
>> AX = Active/No Probing
>> (*) Gateway is used in ds_select_*, ds_next_*
>> (*) No OPTIONS/INFO messages are sent to destination to
>> check alive
>> state
>>
>> This appears to be the normal operating state with no issues
>> detected.
>>
>> AP = Active/Probing
>> (*) Gateway is NOT used in ds_select_*, ds_next_*
>> (*) OPTIONS/INFO messages ARE sent to destination to check
>> alive
>> state
>>
>> This appears to be the state taken when a gateway times out
>> and
>> ds_mark_dst("p") is set in failure route, the gateway is
"pinged"
>> while
>> down and set into AX mode once a response is recieved.
>>
>> IX = Inactive/No Probing
>> (*) Gateway is NOT used in ds_select_*, ds_next_*
>> (*) No OPTIONS/INFO messages sent to destination
>>
>> This appears to be the state taken when a gateway times out
>> and if
>> ds_mark_dst("i") is set in failure route, this gateway is set
>> inactive
>> and no "pinging" is performed.
>>
>> IP = Inactive/Probing
>> (*) Gateway is NOT used in ds_select_*, ds_next_*
>> (*) OPTIONS/INFO messages ARE sent to destination
>>
>> I'm not sure when this state would be reached unless it is
>> set by
>> fifo command. The ds_mark_dst function only allows "a","i"
or
>> "p". So
>> the probing method would only become active is ds_probing_mode =
>> 1. In
>> my case it is 0, so I'm not sure if I would ever reach this state
>> unless
>> I forced it. What would happen here is the gateway came back
>> alive once
>> in "IP" state, would it go back to "AX" state?
>>
>> DX = Disabled/No Probing
>> (*) Gateway is administratively set to down
>>
>> This is where manual intervention has occured and the
>> destination
>> has been set to administrativly down, for example, work being
>> carried
>> out on the destination gateway.
>>
>> All these states make sense, for the most part, I'm a little
>> unsure of
>> how IP/IX is meant to work unless you manually set it to
>> "inactive" in
>> your failure route.
>>
>> The main concern though is the the fifo commands dont appear to be
>> working as expected, I can only set the state for a destination
>> manually
>> once, and not again after that, unless I perform a dispatcher
>> reload.
>>
>> Has anyone else experienced this behaviour?
>>
>> Any comments/suggestions explanations are most welcome.
>>
>> Thanks
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:30 p.m.
Hello,
the probing state is no longer related to selection of the gateways. It
is unclear in the previous version what is the role of it in selection
of an address, since some time, a gw in probing was wanted to be
selected and some time not.
So probing is a state related to whether to send or not keepalive to a
gw. If you don't want a gateways to be selected, it has to be inactive
or disabled. One may want active gateways to be in probing mode to
detect quickly when it is down with keepalives.
If the documentation has some old content in some places, has to be
updated -- maybe you can send the patch if you spotted the confusing parts.
Cheers,
Daniel
On 10/25/11 4:11 PM, Asgaroth wrote:
Hi All,
Just wondering, has anyone else experienced the behaviour described
below, where messages are still routed to a gateway that is in
Active-Probing state? From my understanding of the docs, when a
destination is in probing state, it should not be used in the
destination selection. I can see that Kamailio does set the state from
AX to AP (Active to Active-Probing) when a timeout occurs, and a
"kamctl dispatcher dump" does show that the state has changed to AP,
however, sip trace to the destination still shows messages being
routed to the destination that is in AP mode.
Just checking if anyone else is seeing this behaviour as well.
Thanks
On 24/10/2011 16:30, Asgaroth wrote:
> OK, did a few more tests but have come accross something, which I am
> not sure is intended behaviour.
>
> When setting a destingation as probing in failure route (due to
> timeout), the destination still gets used in destination selection.
>
> # ./kamailio -V
> version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
> SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
> USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 25bedc
> compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
>
> Dispatcher module parameters (in testing) are as follows
> (SBC_PING_FROM is #defined previously):
>
> modparam("dispatcher", "flags", 2)
> modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
> modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
> modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
> modparam("dispatcher", "ds_ping_method", "OPTIONS")
> modparam("dispatcher", "ds_ping_from", SBC_PING_FROM)
> modparam("dispatcher", "ds_ping_interval", 10)
> modparam("dispatcher", "ds_probing_threshhold", 1)
> modparam("dispatcher", "ds_probing_mode", 0)
>
> Main routing logic has following snippet to select destination (hash
> table selects dispatcher setid based on request domain):
>
> if(!ds_select_dst("$sht(which_sbc=>$rd)",
"0")) {
> sl_send_reply("500", "No destination
available");
> xlog("route[MAIN] : $rm : No destinations
> available for $rd");
> exit;
> }
>
> Failure route has following logic to select next destination based on
> timout/failure of destination:
>
> if (t_branch_timeout() && !t_branch_replied())
> {
> xlog("route[TO_SBC] : $rm : timeout and no reply
> ($si:$sp->$Ri:$Rp->$du)\n");
> xlog("route[TO_SBC] : $rm : setting $du to probing
> state");
> ds_mark_dst("p");
> if(ds_next_dst())
> {
> xlog("route[TO_SBC] : $rm : next destination
> select ($du)\n");
> t_on_failure("TO_SBC");
> t_relay();
> exit;
> } else {
> send_reply("500", "No destination
available");
> xlog("route[TO_SBC] : $rm : No destinations
> available for $rd");
> exit;
> }
> }
>
> According to 3.2 module docs for dispatcher, when a destination is
> set into probing state, it will not be used by ds_select_dst:
> ----
>
>
> 4.6. |ds_mark_dst("s")|
>
> Mark the last used address from destination set as inactive
> ("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
> this function, an automatic detection of failed gateways can be
> implemented. When an address is marked as inactive or probing, it
> will be ignored by 'ds_select_dst' and 'ds_select_domain'.
>
> possible parameters:
>
> *
>
> /"i", "I" or "0"/ - the last destination should be
set to
> inactive and will be ignored in future requests.
>
> *
>
> /"a", "A" or "1"/ - the last destination should be
set to active
> and the error-counter should set to "0".
>
> *
>
> /"p", "P" or "2"/ - the last destination will be
set to probing.
> Note: You will need to call this function "threshhold"-times,
> before it will be actually set to probing.
>
> This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.
>
> ---
>
> What happens here, for me, is:
>
> [1] Gateway is in Active mode (state: AX).
> [2] Request comes in and times out, destination is set to
> Active/Probing (state: AP)
> [3] Another request comes in and it selects gateway that is in AP
> mode, times out, and then selects next dst in list.
> [4] Another request comes in and it selects gateway that is in AP
> mode, times out, and then selects next dst in list.
> .
> .
>
> NOTE: The requests selecting the AP mode gateway may not be right
> after each other (algorythm used is hash over callid) but I have
> stripped those out in above steps. If I'm not mistaked, if 2
> destination in a set, and 1 destination is marked as AP, then
> remaining destination should always be selected as destination to
> send to. The destination marked AP (active-probing) should not be
> selected while in probing state.
>
> When the gateway is set into AP mode at step [2], then, according to
> docs, any new request coming in should not have the gateway selected
> as it is marked as being in probing state.
>
> Is this the intended behaviour or am I missing something in the
> documentation, or is it a bug?
>
> Thanks
>
> [...]
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
6:52 p.m.
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
this function, an automatic detection of failed gateways can be
implemented. When an address is marked as inactive or probing, it will
be ignored by 'ds_select_dst' and 'ds_select_domain'.
Above is the part that is a little misleading, it says that
"When an address is marked as inactive or probing, it will be ignored by
'ds_select_dst' and 'ds_select_domain'."
This, to me, means that if a gateway is in probing mode (Active-Probing)
then it wont be selected in the destination set because it is in probing
mode, if this is not the case then maybe the above line should read:
"When an address is marked as inactive or inactive-probing, it will be
ignored by 'ds_select_dst' and 'ds_select_domain'."
This brings me to my next question then, how would I set the state of a
destination to Inactive-Probing (state: IP) from the routing script. The
ds_mark_dst() function only allows one of "a", "i", "p".
If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive
with no probing to tell when gateway is back up.
If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log
is printed saying that you cannot put a destination into probing state
when it is marked as inactive.
Is it possible to set the state of a gateway to inactive-probing from
the routing script?
Thanks
11:09 p.m.
Hi Daniel,
I'm wondering if the change you made to the dev branch for setting the
state via fifo command is what could be causing this issues (just
guessing, I am more than likely worng :)), see my subsequent testing below:
Just a little further digging on this, seems to show that kamailio
v3.2.0 acts differently than 3.3.0 dev branch.
Below is the log output of my routing logic using v3.2.0:
at this point dispatcher is loaded with both destinations set in AX
(Active) state, I then shutdown the 2 destination port(s), then, request
comes in:
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This request responds as expected, however, both destinations are now
set in AP mode, then some more requests come in:
NOTE: $du seems to be causing issue here as well, but i think $du is
cosmetic (I have previously sent the routing logic that displays this).
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
This is behaiving as I understand it from the docs. Both destinations
are in Active-Probing state, and, because they are in probing state,
ds_select_dst will not use them in the selection process for subsequent
requests.
Now, when testing with 3.3.0 dev branch:
Below is log output of my routing script logic using 3.3.0 dev:
at this point dispatcher is loaded with both destinations set in AX
(Active) state, I then shutdown the 2 destination port(s), then, request
comes in:
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This request responds as expected, however, both destinations are now
set in AP mode, then some more requests come in:
NOTE: $du seems to be causing issue here as well, but i think $du is
cosmetic (I have previously sent the routing logic that displays this).
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10001
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10001
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This is not behaving as I understand the docs to explain. The only
difference between the 2 versions of the script logic is the version of
kamailio, the exact same routing script is used in both scenarios.
The "working as understood from docs" version is as follows:
# ./kamailio -V
version: kamailio 3.2.0 (i386/linux) e19bb8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e19bb8
compiled on 15:04:46 Oct 25 2011 with gcc 4.1.2
The "not working as understood from docs" version is as follows:
# /kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
I hope I'm not going crazy here :/
Thanks
On 25/10/2011 16:52, Asgaroth wrote:
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
this function, an automatic detection of failed gateways can be
implemented. When an address is marked as inactive or probing, it
will be ignored by 'ds_select_dst' and 'ds_select_domain'.
Above is the part that is a little misleading, it says that
"When an address is marked as inactive or probing, it will be ignored
by 'ds_select_dst' and 'ds_select_domain'."
This, to me, means that if a gateway is in probing mode
(Active-Probing) then it wont be selected in the destination set
because it is in probing mode, if this is not the case then maybe the
above line should read:
"When an address is marked as inactive or inactive-probing, it will be
ignored by 'ds_select_dst' and 'ds_select_domain'."
This brings me to my next question then, how would I set the state of
a destination to Inactive-Probing (state: IP) from the routing script.
The ds_mark_dst() function only allows one of "a", "i",
"p".
If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive
with no probing to tell when gateway is back up.
If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
Is it possible to set the state of a gateway to inactive-probing from
the routing script?
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
26 Oct
26 Oct
6:47 a.m.
Hello,
On 10/25/11 10:09 PM, Asgaroth wrote:
Hi Daniel,
I'm wondering if the change you made to the dev branch for setting the
state via fifo command is what could be causing this issues (just
guessing, I am more than likely worng :)), see my subsequent testing
below:
the purpose with three states (active, inactive and disabled) was not to
relate probing to selection of gateways, as one may want to have even
active gateways in probing mode to detect when they go down. So, in
other words, if probing mode is not checked when a gateways is selected,
but only if the gateway has the state active.
Cheers,
Daniel
Just a little further digging on this, seems to show that kamailio
v3.2.0 acts differently than 3.3.0 dev branch.
Below is the log output of my routing logic using v3.2.0:
at this point dispatcher is loaded with both destinations set in AX
(Active) state, I then shutdown the 2 destination port(s), then,
request comes in:
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select
(sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This request responds as expected, however, both destinations are now
set in AP mode, then some more requests come in:
NOTE: $du seems to be causing issue here as well, but i think $du is
cosmetic (I have previously sent the routing logic that displays this).
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@1…)
route[MAIN] : REGISTER : No destinations available for mydomain.com
This is behaiving as I understand it from the docs. Both destinations
are in Active-Probing state, and, because they are in probing state,
ds_select_dst will not use them in the selection process for
subsequent requests.
Now, when testing with 3.3.0 dev branch:
Below is log output of my routing script logic using 3.3.0 dev:
at this point dispatcher is loaded with both destinations set in AX
(Active) state, I then shutdown the 2 destination port(s), then,
request comes in:
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This request responds as expected, however, both destinations are now
set in AP mode, then some more requests come in:
NOTE: $du seems to be causing issue here as well, but i think $du is
cosmetic (I have previously sent the routing logic that displays this).
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10001
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10000
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
route[MAIN] : REGISTER : Initial route request
(if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>)
route[MAIN] : REGISTER : SBC selected for mydomain.com is
sip:10.10.10.11:10001
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000)
route[TO_SBC] : REGISTER : timeout and no reply
(10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001)
route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state
route[TO_SBC] : REGISTER : No destinations available for mydomain.com
This is not behaving as I understand the docs to explain. The only
difference between the 2 versions of the script logic is the version
of kamailio, the exact same routing script is used in both scenarios.
The "working as understood from docs" version is as follows:
# ./kamailio -V
version: kamailio 3.2.0 (i386/linux) e19bb8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e19bb8
compiled on 15:04:46 Oct 25 2011 with gcc 4.1.2
The "not working as understood from docs" version is as follows:
# /kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
I hope I'm not going crazy here :/
Thanks
On 25/10/2011 16:52, Asgaroth wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
this function, an automatic detection of failed gateways can be
implemented. When an address is marked as inactive or probing, it
will be ignored by 'ds_select_dst' and 'ds_select_domain'.
Above is the part that is a little misleading, it says that
"When an address is marked as inactive or probing, it will be ignored
by 'ds_select_dst' and 'ds_select_domain'."
This, to me, means that if a gateway is in probing mode
(Active-Probing) then it wont be selected in the destination set
because it is in probing mode, if this is not the case then maybe the
above line should read:
"When an address is marked as inactive or inactive-probing, it will
be ignored by 'ds_select_dst' and 'ds_select_domain'."
This brings me to my next question then, how would I set the state of
a destination to Inactive-Probing (state: IP) from the routing
script. The ds_mark_dst() function only allows one of "a", "i",
"p".
If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive
with no probing to tell when gateway is back up.
If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
Is it possible to set the state of a gateway to inactive-probing from
the routing script?
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:47 p.m.
Hi Daniel,
On 26/10/2011 04:47, Daniel-Constantin Mierla wrote:
the purpose with three states (active, inactive and
disabled) was not
to relate probing to selection of gateways, as one may want to have
even active gateways in probing mode to detect when they go down. So,
in other words, if probing mode is not checked when a gateways is
selected, but only if the gateway has the state active.
OK, so, before I continue on testeing between 3.2 and 3.3 dev branch,
can you confirm that my understanding of the states are correct:
Assuming ds_probing_mode = 0 (Only send "ping" requests when destination
is in probing state)
AX (Active)
[*] Used by ds_select_* in gateway selection
[*] No ping probes sent to destination
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
IX (Inactive)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
IP (Inactive-Probing)
[*] Not used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
DX (Disabled)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
Is the above true for both version 3.2.x and devel branch?
Just for ease of syntax in routing script, is it possible to do:
ds_mark_dst("ip") = Mark Inactive-Probing
ds_mark_dst("ap") = Mark Active-Probing
in both version 3.2.x and devel branch? Similar to fifo ds_set_state
command?
Once I understand these correctly, I can continue testing the 2 versions
and see the differences. I suspect v3.2.x does *not* use gateway in
ds_select_* when destination is in AP mode. But will confirm that with
testing if my above understanding is correct.
Thanks
8:06 p.m.
On 26/10/2011 10:47, Asgaroth wrote:
Assuming ds_probing_mode = 0 (Only send "ping" requests when
destination is in probing state)
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
Testing thus far shows that v 3.2.x does not select the destination when
the destination state is AP (active probing), therefor the above
assumption is wrong in v 3.2.x, I will test with dev branch shortly.
Kamailio version is as follows:
# sbin/kamailio -V
version: kamailio 3.2.0 (i386/linux) e19bb8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e19bb8
compiled on 15:04:46 Oct 25 2011 with gcc 4.1.2
8:15 p.m.
Hello,
On 10/26/11 7:06 PM, Bruce McAlister wrote:
On 26/10/2011 10:47, Asgaroth wrote:
I just backported to 3.2.x, so if you try again,
probing mode should not
have anything to do with selection of gateways. Just active, inactive
and disabled will influence that. Probing will be for keepalives and
automatic activation/inactivation of gateways.
Cheers,
Daniel
Assuming ds_probing_mode = 0 (Only send "ping" requests when
destination is in probing state)
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway
chages to AX (Active)
Testing thus far shows that v 3.2.x does not select the destination
when the destination state is AP (active probing), therefor the above
assumption is wrong in v 3.2.x, I will test with dev branch shortly.
Kamailio version is as follows:
# sbin/kamailio -V
version: kamailio 3.2.0 (i386/linux) e19bb8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e19bb8
compiled on 15:04:46 Oct 25 2011 with gcc 4.1.2
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
8:10 p.m.
Assuming ds_probing_mode = 0 (Only send
"ping" requests when
destination is in probing state)
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
Testing with dev branch, then the above is true. Dev branch will use
destination if it is in active-probing state. Kamailio version to test
this is:
# sbin/kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
8:23 p.m.
Hello,
On 10/26/11 11:47 AM, Asgaroth wrote:
Hi Daniel,
On 26/10/2011 04:47, Daniel-Constantin Mierla wrote:
The 3.2 branch got it
just few moment ago. I will have to look over the
code a bit more, since I saw some threshold for probing module, I guess
was added by Carsten, which should be for inactive at this moment. Might
be a need for new state, like 'trying' to mark a gateway in transition
from active to inactive for those that don't want to inactivate it
immediately, but just after a specific amount of failures.
the purpose with three states (active, inactive
and disabled) was not
to relate probing to selection of gateways, as one may want to have
even active gateways in probing mode to detect when they go down. So,
in other words, if probing mode is not checked when a gateways is
selected, but only if the gateway has the state active.
OK, so, before I continue on testeing between 3.2 and 3.3 dev branch,
can you confirm that my understanding of the states are correct:
Assuming ds_probing_mode = 0 (Only send "ping" requests when
destination is in probing state)
AX (Active)
[*] Used by ds_select_* in gateway selection
[*] No ping probes sent to destination
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
IX (Inactive)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
IP (Inactive-Probing)
[*] Not used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
DX (Disabled)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
Is the above true for both version 3.2.x and devel branch?
Just for ease of syntax in routing script, is it possible to do:
ds_mark_dst("ip") = Mark Inactive-Probing
ds_mark_dst("ap") = Mark Active-Probing
in both version 3.2.x and devel branch? Similar to fifo ds_set_state
command?
I will look into it (just that I am not in the office these days, so it
may take a bit, or not, depending on how I find time for it).
Once I understand these correctly, I can continue testing the 2
versions and see the differences. I suspect v3.2.x does *not* use
gateway in ds_select_* when destination is in AP mode. But will
confirm that with testing if my above understanding is correct.
The goal is not to relate probing mode to selection of gateways, but
only to the fact of sending keepalives. Selection of gateways should be
based on state: active, inactive, disabled.
Cheers,
Daniel
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
8:24 p.m.
On 26/10/2011 10:47, Asgaroth wrote:
Assuming ds_probing_mode = 0 (Only send "ping" requests when
destination is in probing state)
IX (Inactive)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
IP (Inactive-Probing)
[*] Not used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state for gateway chages
to AX (Active)
Testing with dev branch, the above assumption is true, however, I am
having the following issues:
[1] When using ds_mark_dst() in routing script, when timeout occurs, the
destination is marked as inactive (state: IX), this appears to be the
correct operation for this command.
[2] When using ds_mark_dst("ip") in routing script, when timeout ocurs,
the destination is marked as inactive (state: IX), this does *not*
appear to work properly, state should be IP
[3] When using:
ds_mark_dst("i");
ds_mark_dst("p");
In the routing script, the state changes to "IX" when
ds_mark_dst("i") is executed, which is correct, then, right after that,
when ds_mark_dst("p") is executed, the state is changed to AP
(active-probing).
Therefor, with the above testing, I am unable to set the state to
inactive-probing from within the routing script.
Kamailio version for the above tests is:
# sbin/kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 25bedc
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
6:44 a.m.
Hello,
On 10/25/11 5:52 PM, Asgaroth wrote:
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
are you sure you run the devel version? There
is no such case in the
sources -- send me exactly the log message you get. Only when the
destination is disabled the probing cannot be set, but not the same case
of inactive.
4.6. |ds_mark_dst("s")|
Mark the last used address from destination set as inactive
("i"/"I"/"0"), active
("a"/"A"/"1") or probing
("p"/"P"/"2"). With
this function, an automatic detection of failed gateways can be
implemented. When an address is marked as inactive or probing, it
will be ignored by 'ds_select_dst' and 'ds_select_domain'.
Above is the part that is a little misleading, it says that
"When an address is marked as inactive or probing, it will be ignored
by 'ds_select_dst' and 'ds_select_domain'."
This, to me, means that if a gateway is in probing mode
(Active-Probing) then it wont be selected in the destination set
because it is in probing mode, if this is not the case then maybe the
above line should read:
"When an address is marked as inactive or inactive-probing, it will be
ignored by 'ds_select_dst' and 'ds_select_domain'."
This brings me to my next question then, how would I set the state of
a destination to Inactive-Probing (state: IP) from the routing script.
The ds_mark_dst() function only allows one of "a", "i",
"p".
If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive
with no probing to tell when gateway is back up.
If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
Is it possible to set the state of a gateway to inactive-probing from
the routing script?
Yes, it should be, no constraint in master branch source code.
Daniel
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
12:59 p.m.
Hi Daniel,
On 26/10/2011 04:44, Daniel-Constantin Mierla wrote:
I think this may have been v3.2, I'm just looking through my log files
and here is the error line:
INFO: dispatcher [dispatch.c:2031]: Ignoring the request to set this
destination to probing: It is already inactive!
If I recall correctly, I first tried to do:
ds_mark_dst("ip");
in routeing script, but that did not work, it set state to IX and not IP.
Then I tried:
ds_mark_dst("i");
ds_mark_dst("p");
Thats when I got the following message:
INFO: dispatcher [dispatch.c:2031]: Ignoring the request to set this
destination to probing: It is already inactive!
I can see, from the docs, that if I just do ds_mark_dst(), then that
will set state to IX (Inactive), however, as described above, I cannot
set state to Inactive-Probing, from routing script using ds_mark_dst("ip").
Thanks
If I do a
ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
are you sure you run the devel version? There
is no such case in the
sources -- send me exactly the log message you get. Only when the
destination is disabled the probing cannot be set, but not the same
case of inactive.
Is it possible to set the state of a gateway to inactive-probing from
the routing script?
Yes, it should be, no constraint in master branch source code.
8:17 p.m.
Hello,
if you tried with 3.2.x, it was the case, since I just backported from
master branch the commit I did to sort out better the behaviour based on
probing state. Try again now with latest 3.2 branch.
Cheers,
Daniel
On 10/26/11 11:59 AM, Asgaroth wrote:
Hi Daniel,
On 26/10/2011 04:44, Daniel-Constantin Mierla wrote:
I think this may have been v3.2, I'm just looking through my
log files
and here is the error line:
INFO: dispatcher [dispatch.c:2031]: Ignoring the request to set this
destination to probing: It is already inactive!
If I recall correctly, I first tried to do:
ds_mark_dst("ip");
in routeing script, but that did not work, it set state to IX and not IP.
Then I tried:
ds_mark_dst("i");
ds_mark_dst("p");
Thats when I got the following message:
INFO: dispatcher [dispatch.c:2031]: Ignoring the request to set this
destination to probing: It is already inactive!
I can see, from the docs, that if I just do ds_mark_dst(), then that
will set state to IX (Inactive), however, as described above, I cannot
set state to Inactive-Probing, from routing script using ds_mark_dst("ip").
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
If I do a
ds_mark_dst("i") and then right after ds_mark_dst("p"), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
are you sure you run the devel version? There
is no such case in the
sources -- send me exactly the log message you get. Only when the
destination is disabled the probing cannot be set, but not the same
case of inactive. Is it
possible to set the state of a gateway to inactive-probing from
the routing script?
Yes, it should be, no constraint in master branch source code.
27 Oct
27 Oct
12:15 a.m.
Hi Daniel,
On 26/10/2011 18:17, Daniel-Constantin Mierla wrote:
if you tried with 3.2.x, it was the case, since I just backported from
master branch the commit I did to sort out better the behaviour based
on probing state. Try again now with latest 3.2 branch.
Thanks, the changes you made there for 3.2.x bring the behaviour into
the same operation as the devel branch. My findings so far are listed below:
Kamailio Version:
# sbin/kamailio -V
version: kamailio 3.2.0 (i386/linux) 7c241c
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 7c241c
compiled on 18:36:47 Oct 26 2011 with gcc 4.1.2
All the testing observations below is done with ds_probing_mode = 0 (A
gateway will only be "pinged" when it is set into probing mode). I
assume that the probing state needs to be manually set using fifo
command or ds_mark_dst()/ds_mark_dst("s") command.
Now I understand what you have been saying about the differentiation
between active/inactive/disabled state and probing enabled between the
states. However, I am still unable to set a destination into
inactive-probing state from within the routing script.
I understand that a gateway will only be selected when the state of the
destination gateway is in AX (Active) or AP (Active-Probing) state.
These states can be achieved by calling ds_mark_dst("a") for AX (Active)
state, or ds_mark_dst("p") for AP (Active-Probing) state from the
routing script.
I understand that a gateway will *not* be selected when the state of the
distination is in DX (Disabled), IX (Inactive) or IP (Inactive-Probing)
state. Only one of the three states in this case can be achieved via
routing script, IX (Inactive) can be achieved by calling ds_mark_dst()
or ds_mark_dst("i"). DX (Disabled) state can be achieved by calling
ds_set_state fifo command, this makes sense as it would be an
administrative down. However, IP (Inactive-Probing) cannot be called
from routing script, which, I think, is essential in some scenarios, for
example, say a destination crashes for some reason, and you want to
probe the gateway for when it becomes available again but you dont want
to use it while it is down, then you need to be able to set the state
from routing script to IP (Inactive-Probing).
To sum it all up, the states from fifo command all work as advertised,
the following states (AX/AP/IX) can be achieved from routing script, IP
state cannot be achieved from routing script (but can be achieved from
fifo command).
Disabled state is set manually using rpc/fifo command.
Is it intentional to not be able to set state to IP from routing script,
or is this also something that needs to be looked at?
Thanks for all the help thus far :)
Thanks
5:57 p.m.
Hello,
I just pushed to remote GIT repository in master branch a bit of
refactoring about the states and ds_mark_dst().
Since with 3.2 seemed that it was lost capability to go inactive after a
certain number of failures (ds_probing_threshold), there is a new state
'trying' that can be used for it. Means that you can set a destination
in trying state couple of times and then it becomes inactive. In 3.1 it
was using a confusing mechanism based on probing mode.
So right now there are states: active, inactive, trying and disabled,
plus modes: probing, not-probing. A destination can be selected only if
it is active or trying. It will not be selected in inactive and
disabled. Probing mode specifies whether keepalives should be sent to
destinations, can be done per address or globally with the module
parameter ds_probing_mode. If a keepalive is not replied, the address is
marked as trying first and later will become inactive if keeps being
non-responsive.
The parameter for ds_mark_dst() can be now a combination between states
and probing mode, like ds_mark_dst("ip").
Maybe you can give it a try and let me know if it works -- I was not
able to test in my side yet -- remember this id master branch (devel
version 3.3.0-devX). Once this is ok and the internal states are clear
and acting properly, I will look into backporting the fixes to 3.2 branch.
Cheers,
Daniel
On 10/26/11 11:15 PM, Asgaroth wrote:
Hi Daniel,
On 26/10/2011 18:17, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
if you tried with 3.2.x, it was the case, since I
just backported from
master branch the commit I did to sort out better the behaviour based
on probing state. Try again now with latest 3.2 branch.
Thanks, the changes you made there for 3.2.x bring the behaviour into
the same operation as the devel branch. My findings so far are listed below:
Kamailio Version:
# sbin/kamailio -V
version: kamailio 3.2.0 (i386/linux) 7c241c
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 7c241c
compiled on 18:36:47 Oct 26 2011 with gcc 4.1.2
All the testing observations below is done with ds_probing_mode = 0 (A
gateway will only be "pinged" when it is set into probing mode). I
assume that the probing state needs to be manually set using fifo
command or ds_mark_dst()/ds_mark_dst("s") command.
Now I understand what you have been saying about the differentiation
between active/inactive/disabled state and probing enabled between the
states. However, I am still unable to set a destination into
inactive-probing state from within the routing script.
I understand that a gateway will only be selected when the state of the
destination gateway is in AX (Active) or AP (Active-Probing) state.
These states can be achieved by calling ds_mark_dst("a") for AX (Active)
state, or ds_mark_dst("p") for AP (Active-Probing) state from the
routing script.
I understand that a gateway will *not* be selected when the state of the
distination is in DX (Disabled), IX (Inactive) or IP (Inactive-Probing)
state. Only one of the three states in this case can be achieved via
routing script, IX (Inactive) can be achieved by calling ds_mark_dst()
or ds_mark_dst("i"). DX (Disabled) state can be achieved by calling
ds_set_state fifo command, this makes sense as it would be an
administrative down. However, IP (Inactive-Probing) cannot be called
from routing script, which, I think, is essential in some scenarios, for
example, say a destination crashes for some reason, and you want to
probe the gateway for when it becomes available again but you dont want
to use it while it is down, then you need to be able to set the state
from routing script to IP (Inactive-Probing).
To sum it all up, the states from fifo command all work as advertised,
the following states (AX/AP/IX) can be achieved from routing script, IP
state cannot be achieved from routing script (but can be achieved from
fifo command).
Disabled state is set manually using rpc/fifo command.
Is it intentional to not be able to set state to IP from routing script,
or is this also something that needs to be looked at?
Thanks for all the help thus far :)
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:30 p.m.
Hi Daniel,
On 27/10/2011 15:57, Daniel-Constantin Mierla wrote:
Hello,
I just pushed to remote GIT repository in master branch a bit of
refactoring about the states and ds_mark_dst().
Thanks, I will test the dev branch in a short while and get back to you.
Since with 3.2 seemed that it was lost capability to go inactive after
a certain number of failures (ds_probing_threshold), there is a new
state 'trying' that can be used for it. Means that you can set a
destination in trying state couple of times and then it becomes
inactive. In 3.1 it was using a confusing mechanism based on probing mode.
Can you explain this trying state and "lost capability to go inactive
after certain number of failures" a little more please and how it
relates to the new trying->inactive states. I would like to understand
how these states relate so that I can test better.
So right now there are states: active, inactive, trying and disabled,
plus modes: probing, not-probing. A destination can be selected only
if it is active or trying. It will not be selected in inactive and
disabled. Probing mode specifies whether keepalives should be sent to
destinations, can be done per address or globally with the module
parameter ds_probing_mode. If a keepalive is not replied, the address
is marked as trying first and later will become inactive if keeps
being non-responsive.
OK, so if I understand this above paragraph correctly, if I have
ds_probing_mode = 0, then I need to set mode manually to probing for a
gateway that has failed "ds_probing_threshold" times? If a server times
out and I set state/mode to "ip", then I assume probing will commence.
In this case the server will not responde to probe requests (as it has
crashed), does this mean then that the state will change to "trying"
because there was no probe response recieved from destination?
The parameter for ds_mark_dst() can be now a combination between
states and probing mode, like ds_mark_dst("ip").
Excellent, thank you, that will help :)
Maybe you can give it a try and let me know if it works -- I was not
able to test in my side yet -- remember this id master branch (devel
version 3.3.0-devX). Once this is ok and the internal states are clear
and acting properly, I will look into backporting the fixes to 3.2
branch.
OK, I will try this in a short while and get back to you.
Thanks
7:49 p.m.
Hello,
On 10/27/11 5:30 PM, Asgaroth wrote:
Probing is no longer
a gw selection state, but a mode switch to send
keepalives or not to a gateway. So if you want these keepalives and
ds_probing_mode=0, you have to set 'p' in any of the states you want
keepalives. A matter of the reply code from keepalives, the state in
probing mode is changed to active if it is 200ok or a reply code
configured in module parameter, or to trying if it is a failure (which
may end up in inactive when failure threshold is met). ds_probing_mode
controls as well if a keepalive reply will maintain the probing mode or not.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
[...]
I was not using the feature in the past, but from the source code I
could see that there was a way not to go directly in probing mode (which
in the past meant not to select the gateway anymore), but just count
failure until a threshold is reached and then set probing.
So if threshold was 3 and there were (in 3.1.x-):
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state goes to probing (inactive, gateway not selected)
Now (3.3.x+), since probing can be always on, even for active
destinations (to detect when they go down), you can get previous like
behavior with trying state:
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state goes to inactive (gateway not selected)
Default failure counter threshold is 1, so goes to inactive as soon as
you set trying, but you can change it via ds_probing_threshold parameter.
Since with 3.2 seemed that it was lost capability
to go inactive after
a certain number of failures (ds_probing_threshold), there is a new
state 'trying' that can be used for it. Means that you can set a
destination in trying state couple of times and then it becomes
inactive. In 3.1 it was using a confusing mechanism based on probing mode.
Can you
explain this trying state and "lost capability to go inactive
after certain number of failures" a little more please and how it
relates to the new trying->inactive states. I would like to understand
how these states relate so that I can test better.
So right now there are states: active, inactive, trying and disabled,
plus modes: probing, not-probing. A destination can be selected only
if it is active or trying. It will not be selected in inactive and
disabled. Probing mode specifies whether keepalives should be sent to
destinations, can be done per address or globally with the module
parameter ds_probing_mode. If a keepalive is not replied, the address
is marked as trying first and later will become inactive if keeps
being non-responsive.
OK, so if I understand this above paragraph correctly, if I
have
ds_probing_mode = 0, then I need to set mode manually to probing for a
gateway that has failed "ds_probing_threshold" times? If a server times
out and I set state/mode to "ip", then I assume probing will commence.
In this case the server will not responde to probe requests (as it has
crashed), does this mean then that the state will change to "trying"
because there was no probe response recieved from destination?
28 Oct
28 Oct
1:33 p.m.
Hi Daniel,
Thanks for the explanation. I've been doing some testing and I've come
accross the following situation:
ds_probing_threshold = 1
ds_probing_mode = 0
in failure route (when timeout occurs) I do:
ds_mark_dst("ip")
State changes from active to inactive and mode set to probing is
correct, then dispatcher sends 3 ping messages to destination set in
probing state, it then recieves no response to the probe and then sets
the destination inactive. It looks like the probing for state inactive
also honours ds_probing_threshold.
If I wanted to keep pinging the destination, while its down, how would I
achieve that? So, for example, i have a destination in active state, the
destination goes down for some reason, I mark the destination as
inactive but want to keep probing it until it comes back. In this case I
will always be sending a probe to the destination, until it comes back,
in which case i recieve a 200 ok back and dispatcher sets state back to
active.
Currently, what happens is, the destination is active, it crashes, i set
state & mode to inactive probing, probe goes out to destination, it
times out, dispatcher sets state inactive, no probing. Therefor the
destination will never be selected unless manually set to active/trying
via fifo command when gateway is back alive.
The kamailio version I was testing with is:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 0b8f2e
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 0b8f2e
compiled on 10:24:56 Oct 28 2011 with gcc 4.1.2
On 27/10/2011 17:49, Daniel-Constantin Mierla wrote:
Hello,
On 10/27/11 5:30 PM, Asgaroth wrote:
Probing is no
longer a gw selection state, but a mode switch to send
keepalives or not to a gateway. So if you want these keepalives and
ds_probing_mode=0, you have to set 'p' in any of the states you want
keepalives. A matter of the reply code from keepalives, the state in
probing mode is changed to active if it is 200ok or a reply code
configured in module parameter, or to trying if it is a failure (which
may end up in inactive when failure threshold is met). ds_probing_mode
controls as well if a keepalive reply will maintain the probing mode
or not.
Cheers,
Daniel
Hi Daniel,
[...]
I was not using the feature in the past, but from the source code I
could see that there was a way not to go directly in probing mode
(which in the past meant not to select the gateway anymore), but just
count failure until a threshold is reached and then set probing.
So if threshold was 3 and there were (in 3.1.x-):
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state goes to probing (inactive, gateway not selected)
Now (3.3.x+), since probing can be always on, even for active
destinations (to detect when they go down), you can get previous like
behavior with trying state:
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state goes to inactive (gateway not selected)
Default failure counter threshold is 1, so goes to inactive as soon as
you set trying, but you can change it via ds_probing_threshold parameter.
Since with 3.2 seemed that it was lost capability
to go inactive after
a certain number of failures (ds_probing_threshold), there is a new
state 'trying' that can be used for it. Means that you can set a
destination in trying state couple of times and then it becomes
inactive. In 3.1 it was using a confusing mechanism based on probing
mode.
Can you explain this trying state and "lost capability to go inactive
after certain number of failures" a little more please and how it
relates to the new trying->inactive states. I would like to understand
how these states relate so that I can test better.
So right now there are states: active, inactive, trying and disabled,
plus modes: probing, not-probing. A destination can be selected only
if it is active or trying. It will not be selected in inactive and
disabled. Probing mode specifies whether keepalives should be sent to
destinations, can be done per address or globally with the module
parameter ds_probing_mode. If a keepalive is not replied, the address
is marked as trying first and later will become inactive if keeps
being non-responsive.
OK, so if I understand this above paragraph correctly, if I
have
ds_probing_mode = 0, then I need to set mode manually to probing for a
gateway that has failed "ds_probing_threshold" times? If a server times
out and I set state/mode to "ip", then I assume probing will commence.
In this case the server will not responde to probe requests (as it has
crashed), does this mean then that the state will change to "trying"
because there was no probe response recieved from destination?
2 Nov
2 Nov
12:06 p.m.
Hello,
can you fetch the latest master branch from git and try with:
ds_probing_mode = 2
This should keep inactive gateways in probing mode, if you set the
probing mode when switching in trying/inactive state, until it gets back
to active state.
Cheers,
Daniel
On 10/28/11 12:33 PM, Asgaroth wrote:
Hi Daniel,
Thanks for the explanation. I've been doing some testing and I've come
accross the following situation:
ds_probing_threshold = 1
ds_probing_mode = 0
in failure route (when timeout occurs) I do:
ds_mark_dst("ip")
State changes from active to inactive and mode set to probing is
correct, then dispatcher sends 3 ping messages to destination set in
probing state, it then recieves no response to the probe and then sets
the destination inactive. It looks like the probing for state inactive
also honours ds_probing_threshold.
If I wanted to keep pinging the destination, while its down, how would I
achieve that? So, for example, i have a destination in active state, the
destination goes down for some reason, I mark the destination as
inactive but want to keep probing it until it comes back. In this case I
will always be sending a probe to the destination, until it comes back,
in which case i recieve a 200 ok back and dispatcher sets state back to
active.
Currently, what happens is, the destination is active, it crashes, i set
state& mode to inactive probing, probe goes out to destination, it
times out, dispatcher sets state inactive, no probing. Therefor the
destination will never be selected unless manually set to active/trying
via fifo command when gateway is back alive.
The kamailio version I was testing with is:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 0b8f2e
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 0b8f2e
compiled on 10:24:56 Oct 28 2011 with gcc 4.1.2
On 27/10/2011 17:49, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
On 10/27/11 5:30 PM, Asgaroth wrote:
Probing is no
longer a gw selection state, but a mode switch to send
keepalives or not to a gateway. So if you want these keepalives and
ds_probing_mode=0, you have to set 'p' in any of the states you want
keepalives. A matter of the reply code from keepalives, the state in
probing mode is changed to active if it is 200ok or a reply code
configured in module parameter, or to trying if it is a failure (which
may end up in inactive when failure threshold is met). ds_probing_mode
controls as well if a keepalive reply will maintain the probing mode
or not.
Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hi Daniel,
[...]
I was not using the feature in
the past, but from the source code I
could see that there was a way not to go directly in probing mode
(which in the past meant not to select the gateway anymore), but just
count failure until a threshold is reached and then set probing.
So if threshold was 3 and there were (in 3.1.x-):
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state still active (no probing, gateway still selected)
ds_mark_dst(p) => state goes to probing (inactive, gateway not selected)
Now (3.3.x+), since probing can be always on, even for active
destinations (to detect when they go down), you can get previous like
behavior with trying state:
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state trying (gateway still selected)
ds_mark_dst(t) => state goes to inactive (gateway not selected)
Default failure counter threshold is 1, so goes to inactive as soon as
you set trying, but you can change it via ds_probing_threshold parameter.
Since with 3.2 seemed that it was lost capability
to go inactive after
a certain number of failures (ds_probing_threshold), there is a new
state 'trying' that can be used for it. Means that you can set a
destination in trying state couple of times and then it becomes
inactive. In 3.1 it was using a confusing mechanism based on probing
mode.
Can you explain this trying state and "lost capability to go inactive
after certain number of failures" a little more please and how it
relates to the new trying->inactive states. I would like to understand
how these states relate so that I can test better. So right
now there are states: active, inactive, trying and disabled,
plus modes: probing, not-probing. A destination can be selected only
if it is active or trying. It will not be selected in inactive and
disabled. Probing mode specifies whether keepalives should be sent to
destinations, can be done per address or globally with the module
parameter ds_probing_mode. If a keepalive is not replied, the address
is marked as trying first and later will become inactive if keeps
being non-responsive.
OK, so if I understand this above paragraph correctly, if I
have
ds_probing_mode = 0, then I need to set mode manually to probing for a
gateway that has failed "ds_probing_threshold" times? If a server times
out and I set state/mode to "ip", then I assume probing will commence.
In this case the server will not responde to probe requests (as it has
crashed), does this mean then that the state will change to "trying"
because there was no probe response recieved from destination?
3:51 p.m.
Hi
On 02/11/2011 10:06, Daniel-Constantin Mierla wrote:
Hello,
can you fetch the latest master branch from git and try with:
ds_probing_mode = 2
This should keep inactive gateways in probing mode, if you set the
probing mode when switching in trying/inactive state, until it gets
back to active state.
Thanks Daniel, I will give this a try in a short while and get back to
you on the testing.
Thanks
3 Nov
3 Nov
12:13 p.m.
Hi
can you fetch the latest master branch from git and
try with:
Trying with the following version:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 26364a
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 26364a
compiled on 13:56:27 Nov 2 2011 with gcc 4.1.2
ds_probing_mode = 2
I have ds_probing_mode = 2 in routing script, then in failure route I
have ds_mark_dst("ip")
This should keep inactive gateways in probing mode, if you set the
probing mode when switching in trying/inactive state, until it gets
back to active state.
This doesn't appear to be doing the above.
When the gateway is switched to inactive-probing using ds_mark_dst("ip")
in failure route, I see state change from active-no-probing to
inactive-probing, then ds_probe_threshold "pings" are sent to
destination (these time out as dst is down), then state changes to
inactive-no-probing. The state does not remain in inactive-probing
state/mode.
Thanks
12:53 p.m.
Hello,
I discovered a copy&paste typo in previous commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
Cheers,
Daniel
On 11/3/11 11:13 AM, Asgaroth wrote:
Hi
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
can you fetch the latest master branch from git
and try with:
Trying with the following version:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 26364a
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 26364a
compiled on 13:56:27 Nov 2 2011 with gcc 4.1.2
ds_probing_mode = 2
I have ds_probing_mode
= 2 in routing script, then in failure route I
have ds_mark_dst("ip")
This should keep inactive gateways in probing
mode, if you set the
probing mode when switching in trying/inactive state, until it gets
back to active state.
This doesn't appear to be doing the above.
When the gateway is switched to inactive-probing using ds_mark_dst("ip")
in failure route, I see state change from active-no-probing to
inactive-probing, then ds_probe_threshold "pings" are sent to
destination (these time out as dst is down), then state changes to
inactive-no-probing. The state does not remain in inactive-probing
state/mode.
Thanks
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:47 p.m.
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
I discovered a copy&paste typo in previous commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
That change works as expected now, thanks for all the work done to get
this going :)
Version tested with was:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 1f63d8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 1f63d8
compiled on 11:01:39 Nov 3 2011 with gcc 4.1.2
5:57 p.m.
Hello,
On 11/3/11 12:47 PM, Asgaroth wrote:
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
ok, thanks for testing!
I'll do the backporting to 3.2 branch soon.
Cheers,
Daniel
I discovered a copy&paste typo in previous
commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
That change works as expected now, thanks for all the work done to get
this going :)
Version tested with was:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 1f63d8
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 1f63d8
compiled on 11:01:39 Nov 3 2011 with gcc 4.1.2
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
4768
days inactive
4782
days old
32 comments
3 participants
participants (3)
-
Asgaroth -
Bruce McAlister -
Daniel-Constantin Mierla