[SR-Users] dispatcher problem

[Klaus Darilion]

I always set the fr_timer to a smaller value as I want to detect gone 
UASs much faster. This also solves the overlapping OPTIONS issue as tm 
gives up after 2 seconds.


# ----- tm params -----
/* we want fast failover in case a destination does not answer
    Note: fr_timer takes milliseconds */
modparam("tm", "fr_timer", 2000)


regards
Klaus

Am 10.09.2010 20:44, schrieb Klaus Feichtinger:
>   Carsten,
>
> thanks for your clarification. I guessed that it was influenced by the
> retransmission of the OPTIONS request. But I hoped this "check-health"
> mechanism would not be based on the standard mechanism. Because with
> this behaviour I do not understand what the former default interval of
> 10 seconds should bring? The default timeout for the request is 30
> seconds and the check-health interval is 10 seconds. So in every
> "period" the server has to handle 3 requests to one and the same target
> in parallel....... This does - from my point of view - not make sense.
>
> Therefore I have set the ping_interval to a value of 60 seconds and can
> now live with the retransmission (without interference).
>
> regards
>
> Klaus
>> Hi,
>>
>> what you are seeing here, are the retransmits for the OPTIONS-Requests.
>> The Dispatcher checks every 10 seconds for "dead" destinations and
>> then sends out the OTIONS-Request using TM (which is doing the
>> retransmits).
>>
>> This might be a little overlapping, e.g.
>> - OPTIONS-Request (initial request, 1st try)
>> - 0,5s (retransmit, 1st try)
>> - 1s (retransmit, 1st try)
>> - 2s (retransmit, 1st try) = 3,5 Seconds from initial request
>> - 4s (retransmit, 1st try) = 7,5 Seconds from initial request
>> - 10s OPTIONS-Request (initial request, 2nd try)
>> - 10,5s (retransmit, 2nd try)
>> - 11,5s (2x, retransmit, 2nd try + retransmit, 1st try)
>> - 13,5s (retransmit, 2nd try)
>> - 15,5s (retransmit, 1st try)
>> (and so on).
>>
>> That is the reason for this behaviour, and may look confusing....
>>
>> Carsten
>>
>> 2010/9/10<klaus.lists at inode.at>:
>>> Hello Daniel,
>>>
>>> these days I'm playing a lot with the dispatcher module and from my point
>>> of view I found a strange behaviour of the module, which is not according
>>> the description in the documentation and as you've explained in the list.
>>>
>>> I've learned that polling of failed gwys is only supported when the
>>> parameter "ds_ping_interval" is set to a value above '0' (the default
>>> value of '10' is no longer supported).
>>>
>>> However, when a gateway is in probing state the polling interval is never
>>> the value that is set in the modparam, it is - in dependent from this
>>> value - always a 'fix' period. E.g. the OPTIONS message is sent in
>>> following interval: 0.5-1-2-4-4-4-4 and afterwards it looks a little bit
>>> chaotic without a specified interval (= random).
>>>
>>> Is this as expected or do I miss another modparam that is mandatory? My
>>> config looks as follows:
>>> # ----- DISPATCHER -----
>>> modparam("dispatcher", "db_url",
>>> "mysql://openser:openserrw@localhost/openser")
>>> modparam("dispatcher", "table_name", "dispatcher")
>>> modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
>>> modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
>>> modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
>>> modparam("dispatcher", "ds_ping_from", "sip:proxy at 192.168.37.87")
>>> modparam("dispatcher", "ds_probing_mode", 0)
>>> modparam("dispatcher", "ds_ping_interval", 20)
>>> modparam("dispatcher", "flags", 2)
>>> modparam("dispatcher", "force_dst", 1)
>>>
>>> regards,
>>>
>>> Klaus Feichtinger
>>>
>>>
>>>>    Hello,
>>>>
>>>> I fixed, thanks for pointing out.
>>>>
>>>> We would need a documentation marshall that should update the docs as
>>>> something related is discussed on the lists. But none really volunteered
>>>>   to do it. For developers is not always obvious or easy (due to lack of
>>>> time) to track the doc changes.
>>>>
>>>> Anyone stepping forward?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 9/8/10 12:01 PM, klaus.lists at inode.at wrote:
>>>>> Klaus, Daniel-Constantin,
>>>>>
>>>>> I had the same "problem" and found the 'solution' in archived mails
>>>>> from diverse mailing lists only.
>>>>>
>>>>> In general the documentation is not really up-to-date. Because also
>>>>> the hint in modules documentation, chapter 3.16 "[...] if compiled
>>>>> with the probing of failed gateways enabled [...]" is no longer valid
>>>>> (as commented by Daniel-Constantin in another list).
>>>>>
>>>>> Please update the documentation for the next major release 3.1 to
>>>>> avoid any more confusions.
>>>>>
>>>>> THX
>>>>>
>>>>> regards,
>>>>> Klaus
>>>>>
>>>>>> Am 07.09.2010 20:58, schrieb Daniel-Constantin Mierla:
>>>>>>> Hello,
>>>>>>>
>>>>>>> you have to set the ping interval parameter:
>>>>>>> http://kamailio.org/docs/modules/stable/modules_k/dispatcher.html#id2590104
>>>>>>>
>>>>>>> I see that documentation says its default value is 10, but in
>>>>>>> sources is 0, which means this feature is disabled.
>>>>>> That was the reason I didn't configured it.
>>>>>>
>>>>>> Thanks
>>>>>> Klaus
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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