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