[SR-Users] Dispatcher Confusion Redeux

Bruce McAlister bruce.mcalister at blueface.ie
Thu Oct 20 13:13:21 CEST 2011


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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>





More information about the sr-users mailing list