Delay between pbx_variables.c: and netsock2.c - 10 seconds delay between dialing and establising connection

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:32] VERBOSE[19908] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘10.101.100.2’
[2019-05-31 17:05:32] VERBOSE[19908] res_pjsip_logger.c: <— Transmitting SIP response (358 bytes) to UDP:10.101.100.8:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.101.100.8:5060;rport=5060;received=10.101.100.8;branch=z9hG4bK79a3bc7e
Call-ID: [email protected]
From: “297-297” <sip:[email protected]>;tag=0011bb4726f700043157518b-1d16ffbd
To: <sip:*[email protected];user=phone>
CSeq: 102 INVITE
Server: FPBX-15.0.16(15.7.2)
Content-Length: 0

[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 [*[email protected]: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.

I’ve seen symptoms like this if you have a flaky STUN server configured.

1 Like

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.

This was it! STUN. I’ve deleted it and it all works. I have no idea how STUN would affect internal traffic, but thats it!
SOLVED
Thank you

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.