<div dir="ltr">Thanks Juha!! I have a perfect use case for this algorithm.<div><br></div><div>Is it tryable ? <br><div><br></div><div>Joel.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 13, 2020 at 5:57 AM David Villasmil <<a href="mailto:david.villasmil.work@gmail.com">david.villasmil.work@gmail.com</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="auto">Nice!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 12 Nov 2020 at 22:01, Julien Chavanton <<a href="mailto:jchavanton@gmail.com" target="_blank">jchavanton@gmail.com</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>About The Algorithm “13” - latency optimized dispatching,</div><div><br></div>Is now reviewed once and tested, it will most likely be ready to merge soon.<br><br>I want to share my thoughts on it one more time as it is not too late to get more feedback before we merge.<br><br><div>I think it is the best algorithm in most use cases, here is why :<br></div><br>It is providing round-robin and fail-over with automatic de-prioritization of slow/unresponsive gateways.<br><br>You probably asked yourself the following questions in the past :<br>"How do I set the thresholds to put a gateway out of service ?"<br><div><br></div><div><i>ds_probing_threshold</i>, <i>ds_inactive_threshold</i> and timers ...<br></div><br>- If your thresholds are too strict, you may end up running out of gateway.<br>- If your thresholds are too tolerant, you may end up adding excessive delays to call establishment and using degraded gateways.<br><div><br></div><div>The automatic de-prioritization can help to address this concern more efficiently by providing more flexibility.</div><div><br></div><div>- it can react faster than lets say 2 consecutive timeouts.<br></div><div>- it will not disable gateways but simply de-prioritize / reorder them if needed.<br></div><div><br></div><div>The only main drawback I can imagine is when you always need to evenly distribute calls using round-robin.<br>It may be needed sometimes but in this case it means  you are willing accept to send calls to a degraded gateway or trough degraded network paths.</div><div><br></div><div>Even if you may select to preset a mixture of round-robin sets, thanks to <i>ds_select_routes</i> however it will stay static, needs to be configured precisely, and will not react to degradation automatically.<br></div><div><br></div><div>I hope this will help use to protect QoS and lower latency of calls routed by Kamailio.<br></div><div><br></div><div>Feel free to let me know what you think<br></div><div>Julien<br><br></div><div><br></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>