asterisk users - Feb 2023 - [External] Asterisk rtp.conf stunaddr setting - what happens if there is an outage

On Mon, Feb 6, 2023 at 6:05 PM Dan Cropp <dan at amtelco.com> wrote:
> A quick follow-up.
>
>
>
> Looking at other customers running 18.12.1 who reported problems at the
> exact same time with AWS issue described below.
>
>
>
> We are seeing similar behavior.
>
> For these systems, the third STUN failure occurs.  We were able to answer
> the call because the SIP provider didn’t CANCEL the call.
>
> However, upstream from the service provider the calls were terminated.
>
> Resulting in a call from the SIP provider to Asterisk that’s live, but
> there is no caller so it appears to be dead air.
>
>
>
> Does the res_rtp_asterisk stunaddr DNS TTL expiration mentioned in change
> ID I7955a046293f913ba121bbd82153b04439e3465f require the dnsmgr.conf to be
> enabled?
>
It doesn't use dnsmgr so it's not required to be enabled. If the TTL is
long, or it's cached locally then it could stick around longer.

Fundamentally though is there a reason you're using STUN in the first
place? Can you not just configure the public IP address and not rely on an
external STUN server? rtp.conf has ice_host_candidates specifically for
situations like AWS.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230206/679d9614/attachment.html>

Thank you Joshua.

I’m not very good at networking.  We have a couple people who manage that and
they were the ones who configured the boxes to use an external STUN server for
all 4 systems that experienced problems accessing this STUN server at the same
time.

When all the boxes encountered the problem, each one was stuck in the stun
timeout.
My understanding is 3 customers reported the problem and we rebooted the
Asterisk VM.  (They service engineer did not understand he could have forced an
rtp.conf reload and it should have fixed the STUN issue).  After each of these
VMs were reset, everything worked.

The fourth customer didn’t report an issue for 8 hours.  (Agents who would have
been busy apparently notified no one to the issue).
When this VM was reset, it also started working again.  If I understand
correctly, this is a good indication the DNS sent a TTL longer than 8 hours.

I was told they ran a test and the DNS server was indicating the TTL was 120
seconds (but this was 2 days after the issue).  I wonder if the AWS DNS had a
hiccup and sent a TTL of 24 hours, but then either self-corrected or was
manually corrected for the TTL we require.


Going back to your idea of the ice_host_candidates.  (Again, apologize for my
ignorance on networking).
Do I understand correctly? We could use this formula for systems that have no
one accessing the (where 192.168.1.10 is the internal IP) and 1.2.3.4 is the
NAT’s public IP for Asterisk?

192.168.1.10 => 1.2.3.4,include_local_address

Using this, would we no longer need the stunaddr configured?

Dan



From: asterisk-users <asterisk-users-bounces at lists.digium.com> On
Behalf Of Joshua C. Colp
Sent: Monday, February 6, 2023 4:39 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Subject: Re: [External] [asterisk-users] Asterisk rtp.conf stunaddr setting -
what happens if there is an outage

On Mon, Feb 6, 2023 at 6:05 PM Dan Cropp <dan at amtelco.com<mailto:dan at
amtelco.com>> wrote:
A quick follow-up.

Looking at other customers running 18.12.1 who reported problems at the exact
same time with AWS issue described below.

We are seeing similar behavior.
For these systems, the third STUN failure occurs.  We were able to answer the
call because the SIP provider didn’t CANCEL the call.
However, upstream from the service provider the calls were terminated.
Resulting in a call from the SIP provider to Asterisk that’s live, but there is
no caller so it appears to be dead air.

Does the res_rtp_asterisk stunaddr DNS TTL expiration mentioned in change ID
I7955a046293f913ba121bbd82153b04439e3465f require the dnsmgr.conf to be enabled?

It doesn't use dnsmgr so it's not required to be enabled. If the TTL is
long, or it's cached locally then it could stick around longer.

Fundamentally though is there a reason you're using STUN in the first place?
Can you not just configure the public IP address and not rely on an external
STUN server? rtp.conf has ice_host_candidates specifically for situations like
AWS.

--
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com<http://www.sangoma.com> and
www.asterisk.org<http://www.asterisk.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230207/9af311cc/attachment.html>