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

Daniel-Constantin Mierla miconda at gmail.com
Wed Oct 26 05:47:43 CEST 2011 

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

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

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

More information about the sr-users mailing list