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

sduthil at wazo.io sduthil at wazo.io
Wed Feb 17 12:45:44 CST 2021


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




More information about the asterisk-dev mailing list