Re: [SR-Users] Dispatcher Confusion (v3.2.0)

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