<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
On 10/25/11 4:11 PM, Asgaroth wrote:
<blockquote cite="mid:4EA6C37A.7010907@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi All,<br>
<br>
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.<br>
<br>
Just checking if anyone else is seeing this behaviour as well.<br>
<br>
Thanks<br>
<br>
<br>
On 24/10/2011 16:30, Asgaroth wrote:
<blockquote cite="mid:4EA58479.7090609@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
OK, did a few more tests but have come accross something, which
I am not sure is intended behaviour.<br>
<br>
When setting a destingation as probing in failure route (due to
timeout), the destination still gets used in destination
selection.<br>
<br>
# ./kamailio -V<br>
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc<br>
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<br>
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144,
MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
PKG_SIZE 4MB<br>
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.<br>
id: 25bedc <br>
compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2<br>
<br>
Dispatcher module parameters (in testing) are as follows
(SBC_PING_FROM is #defined previously):<br>
<br>
modparam("dispatcher", "flags", 2)<br>
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")<br>
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")<br>
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")<br>
modparam("dispatcher", "ds_ping_method", "OPTIONS")<br>
modparam("dispatcher", "ds_ping_from", SBC_PING_FROM)<br>
modparam("dispatcher", "ds_ping_interval", 10)<br>
modparam("dispatcher", "ds_probing_threshhold", 1)<br>
modparam("dispatcher", "ds_probing_mode", 0)<br>
<br>
Main routing logic has following snippet to select destination
(hash table selects dispatcher setid based on request domain):<br>
<br>
if(!ds_select_dst("$sht(which_sbc=>$rd)",
"0")) {<br>
sl_send_reply("500", "No destination
available");<br>
xlog("route[MAIN] : $rm : No
destinations available for $rd");<br>
exit;<br>
}<br>
<br>
Failure route has following logic to select next destination
based on timout/failure of destination:<br>
<br>
if (t_branch_timeout() && !t_branch_replied())<br>
{<br>
xlog("route[TO_SBC] : $rm : timeout and no reply
($si:$sp->$Ri:$Rp->$du)\n");<br>
xlog("route[TO_SBC] : $rm : setting $du to
probing state");<br>
ds_mark_dst("p");<br>
if(ds_next_dst())<br>
{<br>
xlog("route[TO_SBC] : $rm : next
destination select ($du)\n");<br>
t_on_failure("TO_SBC");<br>
t_relay();<br>
exit;<br>
} else {<br>
send_reply("500", "No destination
available");<br>
xlog("route[TO_SBC] : $rm : No
destinations available for $rd");<br>
exit;<br>
}<br>
}<br>
<br>
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:<br>
----<br>
<h3 class="title">4.6. <code class="function">ds_mark_dst("s")</code>
</h3>
<p> 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'. </p>
<p>possible parameters:</p>
<div class="itemizedlist">
<ul>
<li>
<p><span class="emphasis"><em>"i", "I" or "0"</em></span>
- the last destination should be set to inactive and
will be ignored in future requests.</p>
</li>
<li>
<p><span class="emphasis"><em>"a", "A" or "1"</em></span>
- the last destination should be set to active and the
error-counter should set to "0".</p>
</li>
<li>
<p><span class="emphasis"><em>"p", "P" or "2"</em></span>
- 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.</p>
</li>
</ul>
</div>
<p> This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.
</p>
---<br>
<br>
What happens here, for me, is:<br>
<br>
[1] Gateway is in Active mode (state: AX).<br>
[2] Request comes in and times out, destination is set to
Active/Probing (state: AP)<br>
[3] Another request comes in and it selects gateway that is in
AP mode, times out, and then selects next dst in list.<br>
[4] Another request comes in and it selects gateway that is in
AP mode, times out, and then selects next dst in list.<br>
. <br>
.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Is this the intended behaviour or am I missing something in the
documentation, or is it a bug?<br>
<br>
Thanks<br>
<br>
[...]</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
</body>
</html>