<div dir="ltr"><div dir="ltr">On Wed, Feb 17, 2021 at 2:45 PM <a href="mailto:sduthil@wazo.io">sduthil@wazo.io</a> <<a href="mailto:sduthil@wazo.io">sduthil@wazo.io</a>> wrote:</div><div dir="ltr"><br></div><div><snip></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm willing to propose a patch in Asterisk to avoid the delay when the<br>
STUN server changes its IP address. I'm wondering what is the best<br>
strategy to make Asterisk resolve the stunaddr again. Here are the<br>
solutions that I've come up with:<br>
<br>
1. Resolve the stunaddr hostname at every call<br>
<br>
This is the strategy used for turnaddr.<br>
This adds another chance of timeout when placing a call, e.g. if the DNS<br>
resolver is unavailable.<br>
This also adds a delay for every call, i.e. the time for the stunaddr to<br>
be resolved to an IP address.<br>
<br>
2. Keep the stunaddr cache in memory, and refresh it after the first timeout<br>
<br>
This strategy is used in res_stun_monitor.<br>
<br>
3. Keep the stunaddr cache in memory, and refresh it periodically<br>
<br>
What would be an acceptable default refresh frequency?<br>
<br>
4. Keep the stunaddr cache in memory, and refresh it after the DNS<br>
response TTL<br>
<br>
AFAIK, this requires making an explicit DNS query, instead of relying on<br>
the OS name-resolving facilites like getaddrinfo. Maybe<br>
res_resolver_unbound could be used there? Is it a good idea to add a<br>
dependency from res_rtp_asterisk to res_resolver_unbound? Make the<br>
dependency optional with a configuration flag e.g.<br>
"stunaddr_resolve_frequency=auto" (default="once")?<br>
<br>
5. Some program (either an Asterisk module thread or some external<br>
process) continuously checks the IP address of the STUN server and runs<br>
 "module reload res_rtp_asterisk.so" when the IP address changes.<br>
<br>
This is more of a crutch than a real solution.<br>
<br>
My preference goes to solution 4, and if not possible, then solution 2.<br>
<br>
My questions, then:<br>
<br>
Do you know of any discussion about this topic?<br>
What are your preferences regarding a solution?<br>
Do you have better strategies to propose?<br>
Does solution 4 go in the right direction?<br>
Would it be better to have the same strategy for stunaddr and turnaddr<br>
(currently solution 1)?<br></blockquote><div><br></div><div>In general you don't want to delay call setup, so 3 or 4. Adding a dependency of res_resolver_unbound is not suitable, and there exists a core DNS[1] API specifically for doing DNS which can gain insight into the TTL and such. As for 3 there exists an API already for doing that as well[2].</div><div><br></div><div>[1] <a href="https://github.com/asterisk/asterisk/blob/master/include/asterisk/dns_core.h">https://github.com/asterisk/asterisk/blob/master/include/asterisk/dns_core.h</a></div></div>[2] <a href="https://github.com/asterisk/asterisk/blob/master/include/asterisk/dnsmgr.h">https://github.com/asterisk/asterisk/blob/master/include/asterisk/dnsmgr.h</a><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><div><font color="#073763">Joshua C. Colp</font></div><div><font color="#073763">Asterisk Technical Lead</font></div><div><font color="#073763">Sangoma Technologies</font></div><div><font color="#073763">Check us out at <a href="http://www.sangoma.com/" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org/" target="_blank">www.asterisk.org</a></font></div></div></div></div></div></div></div></div></div></div></div></div>