Hello,
On 10/20/11 1:13 PM, Bruce McAlister wrote:
Thanks Daniel, I will try 3.2.0 shortly.
Just another quick question, I have the following failure route defined
for dispatcher:
if (t_branch_timeout()&& !t_branch_replied())
{
xlog("route[TO_SBC] : $rm : timeout and no reply
($si:$sp->$Ri:$Rp->$du)\n");
xlog("route[TO_SBC] : $rm : setting $du to probing state");
ds_mark_dst("p");
if(ds_next_dst())
{
------> xlog("route[TO_SBC] : $rm : next destination select
($du)\n");<--------
t_on_failure("TO_SBC");
t_relay();
exit;
} else {
send_reply("500", "No destination available");
xlog("route[TO_SBC] : $rm : No destinations
available for $rd");
exit;
}
}
In the above snippet, the following line always logs the dispatcher dst
of the 1st listed:
xlog("route[TO_SBC] : $rm : next destination select ($du)\n");
So for example, say I have 2 destinations defined as:
1.1.1.1
1.1.1.2
I always see 1.1.1.1 listed as the destination, I never see 1.1.1.2 as
the next destination to send to. However a sip trace confirms that it is
sending it to the next destination (1.1.1.2) but $du has 1.1.1.1 defined.
Is there some pre-processing I need to do on the message before $du will
see the 1.1.1.2 as the next destination to send to?
interesting, I will have to check the source code -- it should be the
second address if the first was selected before and failed ... cannot
look at it right now, maybe you can open an issue in the tracker not to
forget about it, as I am just to start a trip for several days.
Thanks,
Daniel
Thanks
Bruce
On 20/10/2011 11:52, Daniel-Constantin Mierla wrote:
Hello,
I haven't read the archive, but you probably talk about what I am
thinking of. IIRC, at that time Carsten tried to explain how it works,
but overall looked confused indeed. As a result, dispatcher module in
3.2.0 has a different system for gateway states.
There are three of them:
- active
- inactive
- disabled
The active and inactive states can be set also in probing mode, so
then there will be keepalives sent to gateways to detect when they
become inactive/active. The disabled state is to put a gateway out of
order completely.
Maybe you can give a try to 3.2.0 dispatcher, now that it is out as a
stable release, and see if it is more meaningful behavior.
Cheers,
Daniel
On 10/19/11 10:47 PM, Asgaroth wrote:
Hi All,
I'd like to clear something up with the diapatcher module and it's
probing parameters:
First things first:
./kamailio -V
version: kamailio 3.1.5 (i386/linux) 76fff5
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, PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 76fff5
compiled on 16:21:02 Oct 19 2011 with gcc 4.1.2
I think I am suffering from the same confusion as Klaus in the following
archive message:
http://web.archiveorange.com/archive/v/jZFTG61DlcEr9LJbS8Gq
I have the following parameters set for the dispatcher module:
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 0)
When I first start kamailio all gateways are active, no probing occurs.
If I then set a gateway inactive (ds_set_state i 1 sip:...), no probing
occurs.
If I then set same gateway active (ds_set_state a 1 sip:...), no probing
occurs.
If I mark same gateway as probing (ds_mark_dst("p") after 1 attempt as
specified in module parameter), then probing starts.
If I then set same gateway inactive (ds_set_state i 1 sip:...) probing
still occurs.
According to the docs if I set the state of a gateway to inactive then
no probing should occur. From my understanding of the docs, if I set
ds_probing_mode to 0 then only gateways marked as probing will be
"pinged".
Can someone with more experienced than myself please clarify how this
method is supposed to work.
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
_______________________________________________
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
