On Wed, Feb 17, 2021 at 3:10 PM Joshua C. Colp <jc...@digium.com> wrote:
> On Wed, Feb 17, 2021 at 2:45 PM sdut...@wazo.io <sdut...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
