20 Oct
2011
20 Oct
'11
2:13 p.m.
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?
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users