[asterisk-dev] Refreshing rtp.conf stunaddr IP address

[Joshua C. Colp]

On Wed, Feb 17, 2021 at 2:45 PM sduthil at wazo.io <sduthil at wazo.io> wrote:

<snip>

I'm willing to propose a patch in Asterisk to avoid the delay when the
> STUN server changes its IP address. I'm wondering what is the best
> strategy to make Asterisk resolve the stunaddr again. Here are the
> solutions that I've come up with:
>
> 1. Resolve the stunaddr hostname at every call
>
> This is the strategy used for turnaddr.
> This adds another chance of timeout when placing a call, e.g. if the DNS
> resolver is unavailable.
> This also adds a delay for every call, i.e. the time for the stunaddr to
> be resolved to an IP address.
>
> 2. Keep the stunaddr cache in memory, and refresh it after the first
> timeout
>
> This strategy is used in res_stun_monitor.
>
> 3. Keep the stunaddr cache in memory, and refresh it periodically
>
> What would be an acceptable default refresh frequency?
>
> 4. Keep the stunaddr cache in memory, and refresh it after the DNS
> response TTL
>
> AFAIK, this requires making an explicit DNS query, instead of relying on
> the OS name-resolving facilites like getaddrinfo. Maybe
> res_resolver_unbound could be used there? Is it a good idea to add a
> dependency from res_rtp_asterisk to res_resolver_unbound? Make the
> dependency optional with a configuration flag e.g.
> "stunaddr_resolve_frequency=auto" (default="once")?
>
> 5. Some program (either an Asterisk module thread or some external
> process) continuously checks the IP address of the STUN server and runs
>  "module reload res_rtp_asterisk.so" when the IP address changes.
>
> This is more of a crutch than a real solution.
>
> My preference goes to solution 4, and if not possible, then solution 2.
>
> My questions, then:
>
> Do you know of any discussion about this topic?
> What are your preferences regarding a solution?
> Do you have better strategies to propose?
> Does solution 4 go in the right direction?
> Would it be better to have the same strategy for stunaddr and turnaddr
> (currently solution 1)?
>

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].

[1]
https://github.com/asterisk/asterisk/blob/master/include/asterisk/dns_core.h
[2]
https://github.com/asterisk/asterisk/blob/master/include/asterisk/dnsmgr.h

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210217/ac930012/attachment.html>