res_rtp_asterisk: Add option to control stun host resolution when TTL = 0

[gtjoseph]

If a hostname is specified for stunaddr in rtp.conf, periodic DNS resolution
is enabled based on the TTL returned in the DNS results. If the TTL returned
is 0, it means that the next time the IP address is needed, it must be
looked up again. I.E. Don't cache. Historically (and incorrectly) however,
res_rtp_asterisk stopped the periodic resolution and never re-resolved the
hostname again.

Besides what's mentioned in the user notes...

• Additional debugging was added in various STUN/DNS functions.
• The rtp show settings CLI command shows more detailed STUN info.
• Some debugging was added to dns_core.c and dns_recurring.c.

UserNote: A new stunaddr_reresolve_ttl_0 parameter has been added to rtp.conf
that allows control over what happens when a STUN server hostname lookup
returns a TTL of 0. The values can be set as follows:

• 'no': This is the historical (and current default) behavior of not doing
  any further lookups and continuing to use the last successful result until
  Asterisk is restarted or rtp.conf is reloaded.
• 'yes': Use the last cached result for the current call but trigger
  re-resolution in the background for the benefit of future calls.
  If the result of the background lookup is a ttl > 0, periodic resolution
  will be restarted otherwise the next call will use the new cached value
  and will trigger a background lookup again.

UserNote: A new CLI command rtp resolve stun hostname has been added
that will force a resolution of the STUN hostname and (re)start periodic
resolution if the result has a TTL > 0.

Resolves: #1858

[gtjoseph]

cherry-pick-to: 20
cherry-pick-to: 22
cherry-pick-to: 23

[github-actions]

Workflow Check failed
master-app_dial: FAILED TEST: apps/queues/transfer/caller_attended
master-ari1: FAILED TEST: rest_api/external_interaction/attended_transfer/stasis_bridge_to_non_stasis_app

[seanbright]

Can we make the default in master be the RFC compliant behavior?

[gtjoseph]

Can we make the default in master be the RFC compliant behavior?

Hmmm. It's a small enough tweak that it shouldn't cause cherry-pick issues later. Let me chat with @jcolp in the morning.

EDIT: I think it'd have to be "trigger_only" otherwise unexpected delays in call setup could occur.

[jcolp]

I think changing the default in master to something more reasonable is fine.

[gtjoseph]

I'm moving this back to draft. I need to think a bit more about the "trigger_only" option. If the TTL is always 0 and we keep triggering with a large call volume there's going to be a lot of churn going on and I'm not quite sure I like how locking is happening. Maybe I need to check if a resolution is already in-flight before scheduling another one.

[gtjoseph]

@seanbright @jcolp I'm wondering if we really need 3 options and can just do a simple boolean.

• false: current behavior
• true: if ttl == 0, call setup will use the cached result and trigger an async lookup. If the async lookup gets a new TTL > 0, future calls will use the cached result. This avoids having to do a synchronous lookup but it also means that a few calls might use a stale cached result. I can't imagine that to be an issue however.

Thoughts?

Oh, To keep things simple right now, I'm going to cherry-pick to all branches and once merged, submit a new master-only PR to change the default.

[jcolp]

I thinkkkk a boolean is fine, and same for using a stale entry.

[github-actions]

Workflow Check failed
master-pjs5: FAILED TEST: channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/batched

[github-actions]

Workflow Check completed successfully

[gtjoseph]

The last force-push fixed a bug where a failed lookup was never retried and added a rtp resolve stun hostname CLI command.

It also removed the re-resolution when a module reload (even via core reload) was done but no changes were detected to rtp.conf. I was kinda iffy on that in the first place because it could cause a change that wasn't expected.

[github-actions]

Workflow Check completed successfully