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