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



_______________________________________________
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

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