[OpenSIPS-Users] rtpproxy status health checking

[solarmon]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190820/defd7dfe/attachment-0001.html>