Long Delay in Dialing

idacomp · June 13, 2018, 5:40pm

Okay - we’re having an weird issue when making outbound calls and to make things worse it’s sporadic.

FreePBX Distro - Asterisk 15

Twilio trunks (and I’ve got them helping troubleshoot).

When we make a call out there can be up to a 30 second delay before the call actually connects. Yes, we press # to initiate the call so it’s not a dial string issue. When looking at the logs, we get the error about retransmission issues and the system complains about congestion and rolls to the next trunk. Sometimes it will connect when rolling and sometimes it has to timeout and roll again, causing a longer delay.

The system sits behind a hardware firewall, the software firewall in FreePBX has been removed all together.

Inbound calls get routed fine and very quickly. Twilio is telling me they are not seeing timeouts - but I’m still questioning them on certain calls.

This one is really driving me crazy and we’re getting frequent complaints.

Any and all help would be greatly appreciated.

Excerpt of log (cleansed):

[2018-06-13 17:20:27] WARNING[23547] chan_sip.c: Retransmission timeout reached on transmission [email protected]:5060 for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[2018-06-13 17:20:27] WARNING[23547] chan_sip.c: Hanging up call [email protected]:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] app_dial.c: SIP/Twilio-Outbound-00001e6c is circuit-busy
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:33] NoOp("SIP/151-00001e6b", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 18") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:34] GotoIf("SIP/151-00001e6b", "1?continue,1:s-CONGESTION,1") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx_builtins.c: Goto (macro-dialout-trunk,continue,1)
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [continue@macro-dialout-trunk:1] NoOp("SIP/151-00001e6b", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 18 - failing through to other trunks") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [continue@macro-dialout-trunk:2] ExecIf("SIP/151-00001e6b", "1?Set(CALLERID(number)=151)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [xxxxxxxxxx@from-internal:7] Macro("SIP/151-00001e6b", "dialout-trunk,9,+xxxxxxxxxxx,,on") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:1] Set("SIP/151-00001e6b", "DIAL_TRUNK=9") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:2] ExecIf("SIP/151-00001e6b", "0?Set(DIAL_OPTIONS=Hhtr)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:3] GosubIf("SIP/151-00001e6b", "0?sub-pincheck,s,1()") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:4] ExecIf("SIP/151-00001e6b", "0?Set(CALLERID(num)=151)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:5] GotoIf("SIP/151-00001e6b", "0?disabletrunk,1") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:6] Set("SIP/151-00001e6b", "DIAL_NUMBER=+xxxxxxxxxx") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:7] Set("SIP/151-00001e6b", "DIAL_TRUNK_OPTIONS=HhTtr") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:8] Set("SIP/151-00001e6b", "OUTBOUND_GROUP=OUT_9") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:9] Set("SIP/151-00001e6b", "DIAL_TRUNK_OPTIONS=T") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:10] GotoIf("SIP/151-00001e6b", "1?nomax") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx_builtins.c: Goto (macro-dialout-trunk,s,12)
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:12] GotoIf("SIP/151-00001e6b", "0?skipoutcid") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:13] Macro("SIP/151-00001e6b", "outbound-callerid,9") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:1] NoOp("SIP/151-00001e6b", "151") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:2] NoOp("SIP/151-00001e6b", "") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:3] NoOp("SIP/151-00001e6b", "off") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:4] ExecIf("SIP/151-00001e6b", "0?Set(CALLERPRES(name-pres)=)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:5] ExecIf("SIP/151-00001e6b", "0?Set(CALLERPRES(num-pres)=)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:6] ExecIf("SIP/151-00001e6b", "0?Set(REALCALLERIDNUM=151)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:7] ExecIf("SIP/151-00001e6b", "0?Set(AMPUSER=151)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:8] GotoIf("SIP/151-00001e6b", "1?normcid") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx_builtins.c: Goto (macro-outbound-callerid,s,12)
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:12] Set("SIP/151-00001e6b", "USEROUTCID=") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:13] Set("SIP/151-00001e6b", "EMERGENCYCID=") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:14] Set("SIP/151-00001e6b", "TRUNKOUTCID=") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:15] GotoIf("SIP/151-00001e6b", "1?trunkcid") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx_builtins.c: Goto (macro-outbound-callerid,s,20)
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:20] ExecIf("SIP/151-00001e6b", "0?Set(CALLERID(all)=)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:21] ExecIf("SIP/151-00001e6b", "0?Set(CALLERID(all)=)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:22] ExecIf("SIP/151-00001e6b", "0?Set(CALLERID(all)=)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:23] ExecIf("SIP/151-00001e6b", "0?Set(CALLERPRES(name-pres)=prohib_passed_screen)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:24] ExecIf("SIP/151-00001e6b", "0?Set(CALLERPRES(num-pres)=prohib_passed_screen)") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:25] Set("SIP/151-00001e6b", "CDR(outbound_cnum)=151") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-outbound-callerid:26] Set("SIP/151-00001e6b", "CDR(outbound_cnam)=Caller ID") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:14] GosubIf("SIP/151-00001e6b", "0?sub-flp-9,s,1()") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:15] Set("SIP/151-00001e6b", "OUTNUM=+xxxxxxxxxxx") in new stack
[2018-06-13 17:20:27] VERBOSE[17372][C-000005b8] pbx.c: Executing [s@macro-dialout-trunk:16] Set("SIP/151-00001e6b", "custom=SIP/Twilio-Trunk-1-Oregon") in new stack

Stewart1 · June 13, 2018, 11:17pm

IMO you should treat this as a networking problem unless you see evidence to the contrary.

At the Asterisk command prompt, do
sip set debug on
to cause SIP traffic to be included in the normal Asterisk log. Confirm that it’s the outgoing INVITE (rather than some other request) that’s not getting a response.

Just a guess: If the INVITE’s Via header does not have an rport tag, Twilio will send the responses to the address/port in the Via, which will fail if your router translated the source port number. Possibly, setting nat=yes for the trunk will cover this up. If your router/firewall permits, forward UDP port 5060 (or whatever you have Bind Port set to) to the PBX, but only allowing Twilio’s IP addresses. Of course, I may be way off base and the SIP trace will show something totally different.

If you still have trouble: What router/firewall do you have? Does it have a static public IP address on its WAN interface? If needed, can you capture traffic on the WAN interface? Or, can you get a SIP trace from Twilio for a failing call? Any port forwarding or other special settings in router? Do you have any other trunking providers on your PBX? If so, do they have the same issue?

idacomp · June 14, 2018, 2:07pm

Thanks for the info - it appears that there may be an issue with the rport being blank - is that what it looks like from the snippet of log?

[2018-06-14 13:49:42] VERBOSE[23547] chan_sip.c: Retransmitting #3 (NAT) to 54.172.60.0:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK146de029;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as2ce7d95d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Thu, 14 Jun 2018 13:49:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 351

idacomp · June 14, 2018, 2:11pm

Yet if I stay on the line long enough - sometimes 45 seconds it will go through. I can see in the logs after trying several times that an entry similar to above will be generated, but there will be an rport value.

Why would it not be generated every time?

Stewart1 · June 14, 2018, 9:13pm

In a SIP request (INVITE, OPTIONS, BYE, etc.), the rport tag (with no value) tells the server to send replies (100 Trying, 180 Ringing, 200 OK, etc.) to whatever address and port the request came from. It also instructs the server to include received= and rport= tags in the reply, so the client learns what IP address and port the server saw the request come from.

If you see rport with a value in a request, that’s wrong. If you see rport without a value in a reply, that’s also wrong.

In the replies that you did receive, you can look at the rport values to see whether your router modified the source port number. Of course, the received tag should show your correct public IP address (matching what you sent in the request’s Via header).

I suspect that this is a router issue. Make/model? If it has a SIP ALG, did you try disabling it? What special settings (related to the PBX) do you have? Does it get the public IP address on its WAN interface (or is there e.g. an ISP gateway also doing NAT)?

Are you actually sending 151 as outbound caller ID? If so, how does this work (e.g. Twilio sees that it’s invalid and substitutes your main company number)? Possibly, this is causing trouble on some of their routes (though I’d expect an error reply, rather than the lack of reply that you are seeing).

Your costlesscarpet.pstn.twilio.com domain maps to four Twilio servers (54.172.60.0 … 54.172.60.3). Do you see a pattern as to which server is selected for failing vs. successful calls?

idacomp · June 15, 2018, 3:13pm

It doesn’t look like there’s been any modification to the ports. I believe you at this point that it’s a router issue. It’s s SonicWALL TZ400 that the PBX sits behind and the phones are remote - they sit behind a SonicWALL TZ300.

SIP ALG is turned of and we’re doing 1 to 1 NAT with the PBX. the 151 as outbound Caller ID is just on a test extension and Twilio doesn’t care - it has no impact on this scenario. It also doesn’t matter which of the Twilio IP addresses we’re hitting - they all act the same. Here’s some more logs with SIP Debugging turned on.

[2018-06-15 14:54:58] VERBOSE[31233][C-000008e7] chan_sip.c: Reliably Transmitting (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:54:58] VERBOSE[31233][C-000008e7] app_dial.c: Called SIP/Twilio-Outbound/+xxxxxxxxxxx
[2018-06-15 14:54:58] VERBOSE[23547] chan_sip.c: Retransmitting #1 (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:54:59] VERBOSE[23547] chan_sip.c:
<— SIP read from UDP:63.147.164.210:15135 —>

<------------->
[2018-06-15 14:54:59] VERBOSE[23547] chan_sip.c: Retransmitting #2 (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:55:01] VERBOSE[23547] chan_sip.c: Retransmitting #3 (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:55:05] VERBOSE[23547] chan_sip.c: Retransmitting #4 (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:55:13] VERBOSE[23547] chan_sip.c: Retransmitting #5 (NAT) to 54.172.60.3:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 209.xxx.xxx.xxx:5060;branch=z9hG4bK2e338865;rport
Max-Forwards: 70
From: “Caller ID” sip:[email protected];tag=as212d563d
To: sip:[email protected]
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
User-Agent: FPBX-14.0.3.6(15.4.0)
Date: Fri, 15 Jun 2018 14:54:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 1192390112 1192390112 IN IP4 209.xxx.xxx.xxx
s=Asterisk PBX 15.4.0
c=IN IP4 209.xxx.xxx.xxx
t=0 0
m=audio 19834 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2018-06-15 14:55:26] VERBOSE[23547] chan_sip.c: Really destroying SIP dialog ‘[email protected]:5060’ Method: INVITE
[2018-06-15 14:55:29] VERBOSE[23547] chan_sip.c:

idacomp · June 15, 2018, 6:26pm

UPDATE:

Out of curiosity, I added an outbound trunk to Flowroute and without any changes to the firewalls, outbound calls connect immediately.

Maybe an issue with the carrier after all?

Just strange for it to be intermittent and to occur only after moving the PBX behind the firewall.

idacomp · June 15, 2018, 8:09pm

UPDATE:

After further testing, I think I found the issue with regards to Twilio. Under Settings -> Asterisk SIP Settings -> NAT Settings.

When behind the firewall and you let the system detect the network settings, it puts the public address correctly within the ‘External Address’ field, and it also correctly identifies the ‘Local Networks’ that includes the private address of the PBX behind the firewall.

It appears however, that with regard to Twilio, the ‘Local Networks’ field needs to be the network that includes the public IP.

Once I made that change, I haven’t been able to duplicate the problem.

Will continue to test next week and confirm - will leave an update whether I can confirm the finding.

system · June 15, 2019, 8:09pm

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