Hello list, I would like your input on a STUN-related issue. The issue is not about the STUN response, but rather about contacting the STUN server. Here is the scenario:
Given Asterisk is configured with a STUN server * rtp.conf has icesupport=yes, stunaddr=stun.example.com Given there are (PJSIP) endpoints able to place calls using ICE When stun.example.com changes its IP address from X to Y (X being unresponsive, like a STUN server that was replaced) When an endpoint places a call Then the call is placed after a delay of about 10 seconds Expected: the call is placed without any noticeable delay. The delay disappears after running "module reload res_rtp_asterisk.so" As far as I understand, here's what happens: * At startup, Asterisk loads rtp.conf, resolves stun.example.com and caches the resulting address X in memory (static variable stunaddr in res_rtp_asterisk) * An endpoint places a call with ICE * Asterisk tries to get a STUN response from the address X * Asterisk gets no response and reaches timeout, creating the delay * Asterisk then continues the placing of the call from the endpoint. I've found a related Asterisk issue with similar symptoms, but a different cause (WAN unavailable): https://issues.asterisk.org/jira/browse/ASTERISK-22745 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)? -- Sébastien Duthil Wazo developer -- _____________________________________________________________________ -- 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
