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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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:

...

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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

[...]

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@10.10.10.10:5060) 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@10.10.10.10:5060) 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@10.10.10.10:5060) 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@10.10.10.10:5060) 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@10.10.10.10:5060) 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

Hello,

On 10/26/11 7:06 PM, Bruce McAlister wrote:

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 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

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

Hello,

On 10/26/11 11:47 AM, Asgaroth wrote:

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?

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.

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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:

...

  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.

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.

Daniel

Thanks

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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:

...

...

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.

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!

...

...

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.

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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:

...

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

On 10/27/11 5:30 PM, Asgaroth wrote:

Hi Daniel,

[...]

...

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.

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.

...

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?

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

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:

...

Hello,

On 10/27/11 5:30 PM, Asgaroth wrote:

...

Hi Daniel,

[...]

...

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.

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.

...

...

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?

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

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

ok, thanks for testing!

No problemo, glad I could help in some way :)

I'll do the backporting to 3.2 branch soon.

Thanks, appreciated :)