Hi,
I’m havig issues with dialing out. After dialing number # it takes 10 seconds to establish connection. As test I use *43. Anyone faced similar issue?
Asterisk version 15.7.2 - fresh install
log after pjsip set logger on
[2019-05-31 17:05:41] VERBOSE[19908] netsock2.c: Using SIP RTP Audio TOS bits 184
[2019-05-31 17:05:41] VERBOSE[19908] netsock2.c: Using SIP RTP Audio CoS mark 5
[2019-05-31 17:05:41] VERBOSE[22311][C-00000011] pbx.c: Executing [*43@from-internal:1] Set(“PJSIP/297-00000010”, “__COS_DEST=echotest”) in new stack
I’ve never seen anything like this and have no idea what may be wrong. However, a few comments and questions:
Asterisk 15 is no longer supported, near EOL and AFAIK not in any official distros. See https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
On the chance that it may fix your problem and you’ll want to do it anyhow, get or make a system with Asterisk 16. If you build it yourself, use --with-pjproject-bundled rather than building pjproject separately.
Also, I’m guessing that __COS_DEST is from the Class of Service module. Test before installing commercial modules, to see whether they are related to your issue.
See if a higher verbosity log shows anything interesting.
See if any processes are running continuously, you’re out of memory, etc.
Start a tcpdump capture (of everything), make test call, stop capture, copy to your PC and look at it with Wireshark. Possibly, there is a failing network operation between the incoming INVITE and the dial plan running, e.g. a DNS lookup, external logging attempt, etc.
If still no luck: FreePBX and Asterisk versions? Install script used? Cloud or on-site? If cloud, whose? If on-site, describe physical platform, virtualization used if any, etc.
Wow, I didn’t realize those settings existed. The OP can probably fix his trouble by leaving anything to do with STUN, TURN or ICE blank.
IMHO the Asterisk guys should have done better and at least allowed a list of several STUN servers to be entered. Otherwise (if your system really needs STUN to function), you would be depending on a single ‘public’ server for which you are not paying, makes no uptime guarantees and entitles you to no support. In most cases, you wouldn’t even know who’s running it or how responsible they are.
Another thought: The OP’s log shows the extension on the same subnet as the PBX, so I’d expect that a STUN server would not be interrogated. Either the OP’s NAT settings are wrong (check Local Networks in particular), or Asterisk was set up so a failing STUN server can cause trouble even when it’s not being used.