[OpenSIPS-Users] rtpproxy status health checking
Callum Guy
callum.guy at x-on.co.uk
Tue Aug 20 05:42:46 EDT 2019
Hi Solarmon,
I can't comment on the exact behaviour internally regarding the ticks value
however I thought I could share it as I see it from a user perspective.
The relevant settings I use are as follows:
modparam("rtpproxy", "rtpproxy_disable_tout", 60)
modparam("rtpproxy", "rtpproxy_timeout", "0.2")
modparam("rtpproxy", "rtpproxy_retr", 4)
My understanding is that it causes the following behaviour:
1. OpenSIPs selects a RTPProxy instance from the pool and sends it the
request
2. RTPProxy instance does not respond within 0.2s
3. This is repeated up to 4 times (*I am not sure if the repeats happen
for the same dialogs or for other dialogs, I would assume that OpenSIPs
will just try another instance immediately and increment the failure count*
)
4. If 4 successive requests for a given instance time out the node is
flagged as disabled for 60 seconds and the other instances are used
5. After 60 seconds the unresponsive instance is re-added to the pool
So regarding health checks, I do not believe this is a separate "heartbeat
system" instead it is a matter of tracking communication failures and using
this to disable unresponsive instances as per your configuration.
I hope that helps,
Callum
On Tue, 20 Aug 2019 at 09:55, solarmon <solarmon at one-n.co.uk> wrote:
> Hi,
>
> Just an update/correction. I notice that when I make a call through
> opensips, the recheck_ticks value does reduce slightly to 928855, but it
> seems to stay at that for subsequent calls. In Control Panel. The memory
> state does turn to Green.
>
> # opensipsctl fifo rtpproxy_show
> Set:: 0
> node:: udp:<IP:port> index=0 disabled=0 weight=1
> recheck_ticks=928855
> node:: udp:<IP:port> index=1 disabled=0 weight=1 recheck_ticks=0
> node:: udp:<IP:port> index=2 disabled=0 weight=1 recheck_ticks=0
>
> Please can you explain what recheck_ticks is and does and how it relates
> to any timeouts and health checks.
>
> On Tue, 20 Aug 2019 at 09:16, solarmon <solarmon at one-n.co.uk> wrote:
>
>> Hi Razvan,
>>
>> I'm using opensips 2.4.6 (x86_64/linux) so I don't think opensips-cli is
>> available?
>>
>> I'm using opensipsctl to show the rtpproxy status.
>>
>> This is the output of the command after I have turned off rtpproxy with
>> index 0:
>>
>> # opensipsctl fifo rtpproxy_show
>> Set:: 0
>> node:: udp:<IP:port> index=0 disabled=0 weight=1 recheck_ticks=0
>> node:: udp: <IP:port> index=1 disabled=0 weight=1
>> recheck_ticks=0
>> node:: udp: <IP:port> index=2 disabled=0 weight=1
>> recheck_ticks=0
>>
>> OpenSIPS Control Panel shows the same - the status does not change.
>>
>> When it does change, based on my quick testing, is:
>>
>> 1. On Reload
>> 2. When the is a call setup goes through it.
>>
>> I'm expecting the health/status to be checked on a regular basis, so as
>> to provide for early detection of failure.
>>
>> After I perform a reload (of rtpproxy config):
>>
>> # opensipsctl fifo rtpproxy_show
>> Set:: 0
>> node:: udp: <IP:port> index=0 disabled=1 weight=1
>> recheck_ticks=926858
>> node:: udp: <IP:port> index=1 disabled=0 weight=1
>> recheck_ticks=0
>> node:: udp:1 <IP:port> index=2 disabled=0 weight=1
>> recheck_ticks=0
>>
>> The status of rtpproxy node with index 0 shows a value (926858) for
>> recheck_ticks. However this value never changes - it always shows 926858.
>>
>> On Mon, 19 Aug 2019 at 15:25, Răzvan Crainea <razvan at opensips.org> wrote:
>>
>>> Hi, Solarmon!
>>>
>>> The parameter you should use is exactly the one you are using,
>>> rtpproxy_disable_tout[1]. That parameter says that after OpenSIPS
>>> detects the node as being down, it re-tries to send them requests after
>>> 20 seconds (according to your configuration).
>>> Are you checking the rtpproxy status using the `opensips-cli mi`? Does
>>> the disable timeout change? If not, what's the output of the status
>>> command?
>>>
>>> [1]
>>>
>>> https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#param_rtpproxy_disable_tout
>>>
>>> Best regards,
>>> Răzvan
>>>
>>> On 8/13/19 4:14 PM, solarmon wrote:
>>> > Hi,
>>> >
>>> > Can somebody clarify when the rtpproxy status and health checks are
>>> done
>>> > and what configuration is required.
>>> >
>>> > I am finding that the status/health of an rtprpoxy node is only
>>> > done/checked during opensips startup or rtpproxy module config reload.
>>> > If the rtprpoxy node goes down or comes back up, the status indicated
>>> by
>>> > opensips for that rtpproxy does not change until another restart or
>>> > reload is done.
>>> >
>>> > My rtpproxy module config is as below:
>>> >
>>> > loadmodule "rtpproxy.so"
>>> > modparam("rtpproxy", "db_url",
>>> > "mysql://<username:password>@127.0.0.1:3306/opensips
>>> > <http://127.0.0.1:3306/opensips>")
>>> > modparam("rtpproxy", "rtpproxy_disable_tout", 20)
>>> >
>>> > Thank you in advance for any help provided.
>>> >
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>> --
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
*0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | **
<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel>
<https://twitter.com/xonuk> *
X-on
is a trading name of Storacall
Technology Ltd a limited company registered in
England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel
Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.
The
information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient, please notify X-on immediately
on +44(0)333 332 0000 and delete the
message from your computer. If you are
not a named addressee you must not use,
disclose, disseminate, distribute,
copy, print or reply to this email. Views
or opinions expressed by an
individual
within this email may not necessarily
reflect the views of X-on
or its associated companies. Although X-on routinely
screens for viruses,
addressees should scan this email and any attachments
for
viruses. X-on
makes no representation or warranty as to the absence of viruses
in this
email or any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190820/f6e53f2f/attachment.html>
More information about the Users
mailing list