5 thoughts on - Asterisk Rtp.conf Stunaddr Setting – What Happens If There Is An Outage

• 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?

  Dan

  From: Dan Cropp Sent: Monday, February 6, 2023 2:06 PM
  To: Asterisk Users Mailing List – Non-Commercial Discussion
  Subject: Asterisk rtp.conf stunaddr setting – what happens if there is an outage

  Over the weekend, we had several customers running at AWS. AWS had an outage during this time.

  This customer is running Asterisk 16.23.0 (which has the STUN timeout crash fix). From what I have been told, other customers are running newer Asterisk 18.12.1 but encountered similar issues. (I haven’t had a chance to verify this)
  All these customers should be running PJSIP, but I haven’t had a chance to verify.

  The logs show Asterisk was reporting problems communicating with the STUN address in the rtp.conf

  [02/04 00:15:03.812] NOTICE[5943] stun.c: Attempt 1 to send STUN request to ‘x.x.x.x’ timed out.
  [02/04 00:15:06.812] NOTICE[5943] stun.c: Attempt 2 to send STUN request to ”x.x.x.x ‘ timed out.
  [02/04 00:15:09.813] WARNING[5943] stun.c: Attempt 3 to send STUN request to ‘x.x.x.x’ timed out. Check that the server address is correct and reachable.

  Until Asterisk was reset, the same pattern kept happening.

  Asterisk received INVITEs Immediately sends the 100 Trying
  7 seconds later, Asterisk receives a CANCEL from the SIP provider. Another half second later, Asterisk receives a second CANCEL
  A second later, Asterisk receives a third CANCEL
  After the third failed to send STUN request, Asterisk sends a 200 OK response for the CSeq CANCEL
  Followed by a 487 Request Terminated Then a second 200 OK response for the CANCEL CSeq Then a third 200 OK response for the CANCEL CSeq

  We have an AMI connection. At this point, we are seeing the Newchannel event for this channel. It immediately sends various events for the Channel, including the Event: Hangup indicating the channel is ended.

  63 ms later, it receives an ACK which completes the Call-ID processing.

  This went on for over 8 hours. When they restarted the Asterisk box, everything was fine. I have been told, they had to restart each Asterisk we had running at AWS to resolve the failed to send to STUN error. No calls/channels would work until that was resolved.

  I wonder if the STUN address lookup happens only one time and AWS DNS may have modified something during this outage/recovery?
  Is there a recommendation on how to prevent this from happening?
  Any thoughts?

  Dan

• 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.

• VGhhbmsgeW91IEpvc2h1YS4NCg0KSeKAmW0gbm90IHZlcnkgZ29vZCBhdCBuZXR3b3JraW5nLiAg V2UgaGF2ZSBhIGNvdXBsZSBwZW9wbGUgd2hvIG1hbmFnZSB0aGF0IGFuZCB0aGV5IHdlcmUgdGhl IG9uZXMgd2hvIGNvbmZpZ3VyZWQgdGhlIGJveGVzIHRvIHVzZSBhbiBleHRlcm5hbCBTVFVOIHNl cnZlciBmb3IgYWxsIDQgc3lzdGVtcyB0aGF0IGV4cGVyaWVuY2VkIHByb2JsZW1zIGFjY2Vzc2lu ZyB0aGlzIFNUVU4gc2VydmVyIGF0IHRoZSBzYW1lIHRpbWUuDQoNCldoZW4gYWxsIHRoZSBib3hl cyBlbmNvdW50ZXJlZCB0aGUgcHJvYmxlbSwgZWFjaCBvbmUgd2FzIHN0dWNrIGluIHRoZSBzdHVu IHRpbWVvdXQuDQpNeSB1bmRlcnN0YW5kaW5nIGlzIDMgY3VzdG9tZXJzIHJlcG9ydGVkIHRoZSBw cm9ibGVtIGFuZCB3ZSByZWJvb3RlZCB0aGUgQXN0ZXJpc2sgVk0uICAoVGhleSBzZXJ2aWNlIGVu Z2luZWVyIGRpZCBub3QgdW5kZXJzdGFuZCBoZSBjb3VsZCBoYXZlIGZvcmNlZCBhbiBydHAuY29u ZiByZWxvYWQgYW5kIGl0IHNob3VsZCBoYXZlIGZpeGVkIHRoZSBTVFVOIGlzc3VlKS4gIEFmdGVy IGVhY2ggb2YgdGhlc2UgVk1zIHdlcmUgcmVzZXQsIGV2ZXJ5dGhpbmcgd29ya2VkLg0KDQpUaGUg Zm91cnRoIGN1c3RvbWVyIGRpZG7igJl0IHJlcG9ydCBhbiBpc3N1ZSBmb3IgOCBob3Vycy4gIChB
  Z2VudHMgd2hvIHdvdWxkIGhhdmUgYmVlbiBidXN5IGFwcGFyZW50bHkgbm90aWZpZWQgbm8gb25l IHRvIHRoZSBpc3N1ZSkuDQpXaGVuIHRoaXMgVk0gd2FzIHJlc2V0LCBpdCBhbHNvIHN0YXJ0ZWQg d29ya2luZyBhZ2Fpbi4gIElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoaXMgaXMgYSBnb29k IGluZGljYXRpb24gdGhlIEROUyBzZW50IGEgVFRMIGxvbmdlciB0aGFuIDggaG91cnMuDQoNCkkg d2FzIHRvbGQgdGhleSByYW4gYSB0ZXN0IGFuZCB0aGUgRE5TIHNlcnZlciB3YXMgaW5kaWNhdGlu ZyB0aGUgVFRMIHdhcyAxMjAgc2Vjb25kcyAoYnV0IHRoaXMgd2FzIDIgZGF5cyBhZnRlciB0aGUg aXNzdWUpLiAgSSB3b25kZXIgaWYgdGhlIEFXUyBETlMgaGFkIGEgaGljY3VwIGFuZCBzZW50IGEg VFRMIG9mIDI0IGhvdXJzLCBidXQgdGhlbiBlaXRoZXIgc2VsZi1jb3JyZWN0ZWQgb3Igd2FzIG1h bnVhbGx5IGNvcnJlY3RlZCBmb3IgdGhlIFRUTCB3ZSByZXF1aXJlLg0KDQoNCkdvaW5nIGJhY2sg dG8geW91ciBpZGVhIG9mIHRoZSBpY2VfaG9zdF9jYW5kaWRhdGVzLiAgKEFnYWluLCBhcG9sb2dp emUgZm9yIG15IGlnbm9yYW5jZSBvbiBuZXR3b3JraW5nKS4NCkRvIEkgdW5kZXJzdGFuZCBjb3Jy ZWN0bHk/IFdlIGNvdWxkIHVzZSB0aGlzIGZvcm11bGEgZm9yIHN5c3RlbXMgdGhhdCBoYXZlIG5v IG9uZSBhY2Nlc3NpbmcgdGhlICh3aGVyZSAxOTIuMTY4LjEuMTAgaXMgdGhlIGludGVybmFsIElQ
  KSBhbmQgMS4yLjMuNCBpcyB0aGUgTkFU4oCZcyBwdWJsaWMgSVAgZm9yIEFzdGVyaXNrPw0KDQox OTIuMTY4LjEuMTAgPT4gMS4yLjMuNCxpbmNsdWRlX2xvY2FsX2FkZHJlc3MNCg0KVXNpbmcgdGhp cywgd291bGQgd2Ugbm8gbG9uZ2VyIG5lZWQgdGhlIHN0dW5hZGRyIGNvbmZpZ3VyZWQ/DQoNCkRh bg0KDQoNCg0KRnJvbTogYXN0ZXJpc2stdXNlcnMgPGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlz dHMuZGlnaXVtLmNvbT4gT24gQmVoYWxmIE9mIEpvc2h1YSBDLiBDb2xwDQpTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDYsIDIwMjMgNDozOSBQTQ0KVG86IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlz dCAtIE5vbi1Db21tZXJjaWFsIERpc2N1c3Npb24gPGFzdGVyaXNrLXVzZXJzQGxpc3RzLmRpZ2l1
  bS5jb20+DQpTdWJqZWN0OiBSZTogW0V4dGVybmFsXSBbYXN0ZXJpc2stdXNlcnNdIEFzdGVyaXNr IHJ0cC5jb25mIHN0dW5hZGRyIHNldHRpbmcgLSB3aGF0IGhhcHBlbnMgaWYgdGhlcmUgaXMgYW4g b3V0YWdlDQoNCk9uIE1vbiwgRmViIDYsIDIwMjMgYXQgNjowNSBQTSBEYW4gQ3JvcHAgPGRhbkBh bXRlbGNvLmNvbTxtYWlsdG86ZGFuQGFtdGVsY28uY29tPj4gd3JvdGU6DQpBIHF1aWNrIGZvbGxv dy11cC4NCg0KTG9va2luZyBhdCBvdGhlciBjdXN0b21lcnMgcnVubmluZyAxOC4xMi4xIHdobyBy ZXBvcnRlZCBwcm9ibGVtcyBhdCB0aGUgZXhhY3Qgc2FtZSB0aW1lIHdpdGggQVdTIGlzc3VlIGRl c2NyaWJlZCBiZWxvdy4NCg0KV2UgYXJlIHNlZWluZyBzaW1pbGFyIGJlaGF2aW9yLg0KRm9yIHRo ZXNlIHN5c3RlbXMsIHRoZSB0aGlyZCBTVFVOIGZhaWx1cmUgb2NjdXJzLiAgV2Ugd2VyZSBhYmxl IHRvIGFuc3dlciB0aGUgY2FsbCBiZWNhdXNlIHRoZSBTSVAgcHJvdmlkZXIgZGlkbuKAmXQgQ0FO
  Q0VMIHRoZSBjYWxsLg0KSG93ZXZlciwgdXBzdHJlYW0gZnJvbSB0aGUgc2VydmljZSBwcm92aWRl ciB0aGUgY2FsbHMgd2VyZSB0ZXJtaW5hdGVkLg0KUmVzdWx0aW5nIGluIGEgY2FsbCBmcm9tIHRo ZSBTSVAgcHJvdmlkZXIgdG8gQXN0ZXJpc2sgdGhhdOKAmXMgbGl2ZSwgYnV0IHRoZXJlIGlzIG5v IGNhbGxlciBzbyBpdCBhcHBlYXJzIHRvIGJlIGRlYWQgYWlyLg0KDQpEb2VzIHRoZSByZXNfcnRw X2FzdGVyaXNrIHN0dW5hZGRyIEROUyBUVEwgZXhwaXJhdGlvbiBtZW50aW9uZWQgaW4gY2hhbmdl IElEIEk3OTU1YTA0NjI5M2Y5MTNiYTEyMWJiZDgyMTUzYjA0NDM5ZTM0NjVmIHJlcXVpcmUgdGhl IGRuc21nci5jb25mIHRvIGJlIGVuYWJsZWQ/DQoNCkl0IGRvZXNuJ3QgdXNlIGRuc21nciBzbyBp dCdzIG5vdCByZXF1aXJlZCB0byBiZSBlbmFibGVkLiBJZiB0aGUgVFRMIGlzIGxvbmcsIG9yIGl0
  J3MgY2FjaGVkIGxvY2FsbHkgdGhlbiBpdCBjb3VsZCBzdGljayBhcm91bmQgbG9uZ2VyLg0KDQpG
  dW5kYW1lbnRhbGx5IHRob3VnaCBpcyB0aGVyZSBhIHJlYXNvbiB5b3UncmUgdXNpbmcgU1RVTiBp biB0aGUgZmlyc3QgcGxhY2U/IENhbiB5b3Ugbm90IGp1c3QgY29uZmlndXJlIHRoZSBwdWJsaWMg SVAgYWRkcmVzcyBhbmQgbm90IHJlbHkgb24gYW4gZXh0ZXJuYWwgU1RVTiBzZXJ2ZXI/IHJ0cC5j b25mIGhhcyBpY2VfaG9zdF9jYW5kaWRhdGVzIHNwZWNpZmljYWxseSBmb3Igc2l0dWF0aW9ucyBs aWtlIEFXUy4NCg0KLS0NCkpvc2h1YSBDLiBDb2xwDQpBc3RlcmlzayBQcm9qZWN0IExlYWQNClNh bmdvbWEgVGVjaG5vbG9naWVzDQpDaGVjayB1cyBvdXQgYXQgd3d3LnNhbmdvbWEuY29tPGh0dHA6
  Ly93d3cuc2FuZ29tYS5jb20+IGFuZCB3d3cuYXN0ZXJpc2sub3JnPGh0dHA6Ly93d3cuYXN0ZXJp c2sub3JnPg0K

• You don’t need the include_local_address option but otherwise yes. This will cause the ICE host candidates to be 1.2.3.4 instead of the local IP
  address 192.168.1.10 removing the need to use STUN to discover the public IP address.

• VGhhbmsgeW91IEpvc2h1YSEhISENCg0KVGhlIG5ldHdvcmtpbmcgZ3V5cyBkaWQgdGhpcyBjaGFu Z2Ugb24gYSB0ZXN0IGJveCBhbmQgdGhlaXIgamF3cyBkcm9wcGVkIHRvIHRoZSBmbG9vciB3aGVu IGl0IGRpZCBleGFjdGx5IGFzIHlvdSBleHBsYWluZWQuDQoNCg0KRnJvbTogYXN0ZXJpc2stdXNl cnMgPGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbT4gT24gQmVoYWxmIE9m IEpvc2h1YSBDLiBDb2xwDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA3LCAyMDIzIDk6MjIgQU0N
  ClRvOiBBc3RlcmlzayBVc2VycyBNYWlsaW5nIExpc3QgLSBOb24tQ29tbWVyY2lhbCBEaXNjdXNz aW9uIDxhc3Rlcmlzay11c2Vyc0BsaXN0cy5kaWdpdW0uY29tPg0KU3ViamVjdDogUmU6IFtFeHRl cm5hbF0gW2FzdGVyaXNrLXVzZXJzXSBbRXh0ZXJuYWxdIEFzdGVyaXNrIHJ0cC5jb25mIHN0dW5h ZGRyIHNldHRpbmcgLSB3aGF0IGhhcHBlbnMgaWYgdGhlcmUgaXMgYW4gb3V0YWdlDQoNCk9uIFR1
  ZSwgRmViIDcsIDIwMjMgYXQgMTE6MTggQU0gRGFuIENyb3BwIDxkYW5AYW10ZWxjby5jb208bWFp bHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IEpvc2h1YS4NCg0KPHNuaXA+
  DQoNCg0KR29pbmcgYmFjayB0byB5b3VyIGlkZWEgb2YgdGhlIGljZV9ob3N0X2NhbmRpZGF0ZXMu ICAoQWdhaW4sIGFwb2xvZ2l6ZSBmb3IgbXkgaWdub3JhbmNlIG9uIG5ldHdvcmtpbmcpLg0KRG8g SSB1bmRlcnN0YW5kIGNvcnJlY3RseT8gV2UgY291bGQgdXNlIHRoaXMgZm9ybXVsYSBmb3Igc3lz dGVtcyB0aGF0IGhhdmUgbm8gb25lIGFjY2Vzc2luZyB0aGUgKHdoZXJlIDE5Mi4xNjguMS4xMCBp cyB0aGUgaW50ZXJuYWwgSVApIGFuZCAxLjIuMy40IGlzIHRoZSBOQVTigJlzIHB1YmxpYyBJUCBm b3IgQXN0ZXJpc2s/DQoNCjE5Mi4xNjguMS4xMCA9PiAxLjIuMy40LGluY2x1ZGVfbG9jYWxfYWRk cmVzcw0KDQpVc2luZyB0aGlzLCB3b3VsZCB3ZSBubyBsb25nZXIgbmVlZCB0aGUgc3R1bmFkZHIg Y29uZmlndXJlZD8NCg0KWW91IGRvbid0IG5lZWQgdGhlIGluY2x1ZGVfbG9jYWxfYWRkcmVzcyBv cHRpb24gYnV0IG90aGVyd2lzZSB5ZXMuIFRoaXMgd2lsbCBjYXVzZSB0aGUgSUNFIGhvc3QgY2Fu ZGlkYXRlcyB0byBiZSAxLjIuMy40IGluc3RlYWQgb2YgdGhlIGxvY2FsIElQIGFkZHJlc3MgMTky LjE2OC4xLjEwIHJlbW92aW5nIHRoZSBuZWVkIHRvIHVzZSBTVFVOIHRvIGRpc2NvdmVyIHRoZSBw dWJsaWMgSVAgYWRkcmVzcy4NCg0KLS0NCkpvc2h1YSBDLiBDb2xwDQpBc3RlcmlzayBQcm9qZWN0
  IExlYWQNClNhbmdvbWEgVGVjaG5vbG9naWVzDQpDaGVjayB1cyBvdXQgYXQgd3d3LnNhbmdvbWEu Y29tPGh0dHA6Ly93d3cuc2FuZ29tYS5jb20+IGFuZCB3d3cuYXN0ZXJpc2sub3JnPGh0dHA6Ly93
  d3cuYXN0ZXJpc2sub3JnPg0K