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

Tue Oct 25 22:09:58 CEST 2011

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111025/28629c4d/attachment-0001.htm>