<div dir="ltr">Hi Solarmon,<div><br></div><div>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.</div><div><br></div><div>The relevant settings I use are as follows:</div><div><br></div><div>modparam("rtpproxy", "rtpproxy_disable_tout", 60)<br>modparam("rtpproxy", "rtpproxy_timeout", "0.2")<br>modparam("rtpproxy", "rtpproxy_retr", 4)<br></div><div><br></div><div>My understanding is that it causes the following behaviour:</div><div><ol><li>OpenSIPs selects a RTPProxy instance from the pool and sends it the request</li><li>RTPProxy instance does not respond within 0.2s</li><li>This is repeated up to 4 times (<i>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</i>)</li><li>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</li><li>After 60 seconds the unresponsive instance is re-added to the pool<br></li></ol><div>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.</div></div><div><br></div><div>I hope that helps,</div><div><br></div><div>Callum</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Aug 2019 at 09:55, solarmon <<a href="mailto:solarmon@one-n.co.uk">solarmon@one-n.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div># opensipsctl fifo rtpproxy_show<br>Set:: 0<br> node:: udp:<IP:port> index=0 disabled=0 weight=1 recheck_ticks=928855<br> node:: udp:<IP:port> index=1 disabled=0 weight=1 recheck_ticks=0<br> node:: udp:<IP:port> index=2 disabled=0 weight=1 recheck_ticks=0<br></div><div><br></div><div>Please can you explain what recheck_ticks is and does and how it relates to any timeouts and health checks.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Aug 2019 at 09:16, solarmon <<a href="mailto:solarmon@one-n.co.uk" target="_blank">solarmon@one-n.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Razvan,<div><br></div><div>I'm using opensips 2.4.6 (x86_64/linux) so I don't think opensips-cli is available?</div><div><br></div><div>I'm using opensipsctl to show the rtpproxy status.</div><div><br></div><div>This is the output of the command after I have turned off rtpproxy with index 0:</div><div><br></div><div><font face="monospace"># opensipsctl fifo rtpproxy_show<br>Set:: 0<br> node:: udp:<IP:port> index=0 disabled=0 weight=1 recheck_ticks=0<br> node:: udp:
<IP:port> index=1 disabled=0 weight=1 recheck_ticks=0<br> node:: udp:
<IP:port> index=2 disabled=0 weight=1 recheck_ticks=0</font><br></div><div><br></div><div>OpenSIPS Control Panel shows the same - the status does not change.</div><div><br></div><div>When it does change, based on my quick testing, is:</div><div><br></div><div>1. On Reload</div><div>2. When the is a call setup goes through it.</div><div><br></div><div>I'm expecting the health/status to be checked on a regular basis, so as to provide for early detection of failure.</div><div><br></div><div>After I perform a reload (of rtpproxy config):</div><div><br></div><div><font face="monospace"># opensipsctl fifo rtpproxy_show<br>Set:: 0<br> node:: udp:
<IP:port> index=0 disabled=1 weight=1 recheck_ticks=926858<br> node:: udp:
<IP:port> index=1 disabled=0 weight=1 recheck_ticks=0<br> node:: udp:1
<IP:port> index=2 disabled=0 weight=1 recheck_ticks=0</font><br></div><div><br></div><div>The status of rtpproxy node with index 0 shows a value (926858) for recheck_ticks. However this value never changes - it always shows 926858.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 19 Aug 2019 at 15:25, Răzvan Crainea <<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, Solarmon!<br>
<br>
The parameter you should use is exactly the one you are using, <br>
rtpproxy_disable_tout[1]. That parameter says that after OpenSIPS <br>
detects the node as being down, it re-tries to send them requests after <br>
20 seconds (according to your configuration).<br>
Are you checking the rtpproxy status using the `opensips-cli mi`? Does <br>
the disable timeout change? If not, what's the output of the status command?<br>
<br>
[1] <br>
<a href="https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#param_rtpproxy_disable_tout" rel="noreferrer" target="_blank">https://opensips.org/html/docs/modules/3.0.x/rtpproxy.html#param_rtpproxy_disable_tout</a><br>
<br>
Best regards,<br>
Răzvan<br>
<br>
On 8/13/19 4:14 PM, solarmon wrote:<br>
> Hi,<br>
> <br>
> Can somebody clarify when the rtpproxy status and health checks are done <br>
> and what configuration is required.<br>
> <br>
> I am finding that the status/health of an rtprpoxy node is only <br>
> done/checked during opensips startup or rtpproxy module config reload. <br>
> If the rtprpoxy node goes down or comes back up, the status indicated by <br>
> opensips for that rtpproxy does not change until another restart or <br>
> reload is done.<br>
> <br>
> My rtpproxy module config is as below:<br>
> <br>
> loadmodule "rtpproxy.so"<br>
> modparam("rtpproxy", "db_url", <br>
> "mysql://<username:password>@<a href="http://127.0.0.1:3306/opensips" rel="noreferrer" target="_blank">127.0.0.1:3306/opensips</a> <br>
> <<a href="http://127.0.0.1:3306/opensips" rel="noreferrer" target="_blank">http://127.0.0.1:3306/opensips</a>>")<br>
> modparam("rtpproxy", "rtpproxy_disable_tout", 20)<br>
> <br>
> Thank you in advance for any help provided.<br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
> <br>
<br>
-- <br>
Răzvan Crainea<br>
OpenSIPS Core Developer<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">http://www.opensips-solutions.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div><img src="https://www.x-on.co.uk/email/footer/banner-surgeryconnect-sep-oct-19.jpg"></div><div><br></div><div><div><div><font size="4"><b><sup><font face="Verdana">0333 332 0000 | <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a> | <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font><br><p><span style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span> and delete the<br>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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>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<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>