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