<div dir="ltr"><div dir="ltr">On Wed, Nov 20, 2019 at 5:40 AM O. Hartmann <<a href="mailto:o.hartmann@walstatt.org">o.hartmann@walstatt.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Am Sat, 16 Nov 2019 07:39:08 -0400<br>
"Joshua C. Colp" <<a href="mailto:jcolp@sangoma.com" target="_blank">jcolp@sangoma.com</a>> schrieb:<br>
<br>
> On Sat, Nov 16, 2019 at 4:07 AM O. Hartmann <<a href="mailto:ohartmann@walstatt.org" target="_blank">ohartmann@walstatt.org</a>> wrote:<br>
> <br>
> > -----BEGIN PGP SIGNED MESSAGE-----<br>
> > Hash: SHA256<br>
> ><br>
> ><br>
> > Hello,<br>
> ><br>
> > we're running a small Asterisk appliance on a PCengine APU2C4. Base<br>
> > operating system is<br>
> > FreeBSD 12-STABLE, most recent incarnation as of today.<br>
> ><br>
> > Since update of port net/asterisk16 to the latest bug fix revision 16.6.1,<br>
> > we face a severe<br>
> > "slowdown" of everything that the Asterisk core performs, i.e. outgoing<br>
> > calls are delayed ~ 20<br>
> > seconds and I guess incoming calls suffer the same until they gett patched<br>
> > through to an<br>
> > endpoint/telephone. We also register a higher load on idle asterisk<br>
> > process since the last<br>
> > update.<br>
> ><br>
> > Here is an example when calling two attached physical phones directly,<br>
> > which performed prior<br>
> > to 16.6.1 almost immediately and now takes up to 30 seconds to make the<br>
> > called ednpoint ring.<br>
> ><br>
> > The calling phone/endpoint sinals by callsound that it is calling, and the<br>
> > sound changes then<br>
> > (some kind of different octave/tune, don't know) when the asterisk core<br>
> > reports<br>
> ><br>
> > [Nov 15 13:21:24]   == Using SIP RTP Audio TOS bits 184<br>
> ><br>
> > (see below). It is here approx 10 seconds, but there are situations were<br>
> > it might more (as<br>
> > observed). the host has no further load so far!<br>
> ><br>
> > Incoming testcalls we made from wireless/mobile show the same. It seems,<br>
> > asterisk is acting as<br>
> > a black hole delaying device for approx 10 seconds until it decides to<br>
> > pass the call through<br>
> > to an endpoint and then it takes another 10 seconds until the endpoint<br>
> > starts ringing (it is<br>
> > in fact a group of phones ringing alltogether).<br>
> ><br>
> > I can not see anything unusual with the underlying OS or some critical<br>
> > debug messages from<br>
> > asterisk itself.<br>
> ><br>
> > Any ideas?<br>
> >  <br>
> <br>
> Do you have a STUN server configured in rtp.conf? If you do, is it<br>
> reachable, does the problem go away if you remove it?<br>
> <br>
<br>
Is there anything wrong/buggy with the implementation of the STUN service in 16.6.1?<br></blockquote><div><br></div><div>In that specific version? No. That code itself hasn't been touched in years, so the problem applies to every version. Using the defined STUN server to get a server reflexive ICE candidate is a blocking process. If the server isn't reachable or is extremely slow then it has to wait until a timeout occurs, causing a delay.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Joshua C. Colp<br>Digium - A Sangoma Company | Senior Software Developer<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>Check us out at: <a href="http://www.sangoma.com/" target="_blank">www.sangoma.com</a> & <a href="http://www.asterisk.org/" target="_blank">www.asterisk.org</a><br></div></div></div>