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

[Joshua C. Colp]

On Wed, Feb 17, 2021 at 3:10 PM Joshua C. Colp <jcolp at digium.com> wrote:

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

I forgot to mention that core DNS also has an API for doing recurring
resolution which takes into account the TTL[1].

[1]
https://github.com/asterisk/asterisk/blob/master/include/asterisk/dns_recurring.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/bf6eaf5c/attachment-0001.html>