[SR-Users] Dispatcher Confusion Redeux

[Daniel-Constantin Mierla]

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 at 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 at 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