Outbound Calls Dropping after 15 minutes

1

I am new, so please show mercy.

All calls outbound drop after 15 minutes. I have checked connectivity with no packet drops and consistently return les than 3ms.

[2016-11-11 13:55:06] WARNING[10966]: chan_sip.c:4061 retrans_pkt: Retransmission timeout reached on transmission 97828c03c706740ada8318a36d8633cf for seqno 1 (Critical Response) – See h
Packet timed out after 32000ms with no response
Really destroying SIP dialog ‘97828c03c706740ada8318a36d8633cf’ Method: INVITE

My sip_general_additional.conf is here:

;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. ;
;--------------------------------------------------------------------------------;
; For information on adding additional paramaters to this file, please visit the ;
; FreePBX.org wiki page, or ask on IRC. This file was created by the new FreePBX ;
; BMO - Big Module Object. Any similarity in naming with BMO from Adventure Time ;
; is totally deliberate. ;
;--------------------------------------------------------------------------------;
accept_outofcall_message=yes
auth_message_requests=no
outofcall_message_context=dpma_message_context
faxdetect=no
vmexten=*97
useragent=FPBX-13.0.190.2(13.12.1)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g726
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
limitonpeers=yes
session-timers=originate
session-expires=10800
session-minse=300
session-refresher=uas
context=from-sip-external
rtpend=20000
rtpstart=10000
tcpenable=no
callevents=yes
bindport=5060
jbenable=no
tlsenable=no
registertimeout=20
tlsbindaddr=[::]:5161
tlsclientmethod=sslv2
allowguest=yes
srvlookup=no
g726nonstandard=no
defaultexpiry=120
rtptimeout=30
videosupport=no
maxcallbitrate=384
canreinvite=no
rtpholdtimeout=10800
rtpkeepalive=0
checkmwi=10
notifyringing=yes
notifyhold=yes
registerattempts=0
minexpiry=60
maxexpiry=3600
nat=no
ALLOW_SIP_ANON=no
callerid=Unknown
externip=xxx.xxx.xxx.xxx
localnet=10.10.1.0/24
language=en

If anyone can help, I would appreciate it.

2

try setting rtpkeepalive=20

3

Try setting session-timers=refuse.

Had an issue before with that causing calls to drop after X amount of time. That resolved it. Let us know if this helps.

1 Like
4

Focus on Asterisk, not FreePBX. Switch off the regular Asterisk log and check your SIP debug during the call. Don’t touch your configuration until you see the real disconnect reason.

5

I have attached debug for extension 42 and the SIP trunk. This is a snippet before the call drops outbound call at 15 minutes Does anything stand out? I appreciate all your help!

<--- SIP read from UDP:10.10.1.42:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK6c231a9a;rport=5060
From: <sip:[email protected]>;tag=as02c076f9
To: "IT Support" <sip:[email protected]>;tag=544860992
Call-ID: [email protected]
CSeq: 111 INVITE
Contact: <sip:[email protected]:5060>
Supported: replaces, path, timer
User-Agent: Grandstream GXP2140 1.0.5.28
Require: timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
<< [ TYPE: Control (4) SUBCLASS: Unknown control '33' (33) ] [SIP/42-000000af]

<--- SIP read from UDP:10.10.1.42:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK6c231a9a;rport=5060
From: <sip:[email protected]>;tag=as02c076f9
To: "IT Support" <sip:[email protected]>;tag=544860992
Call-ID: [email protected]
CSeq: 111 INVITE
Contact: <sip:[email protected]:5060>
Supported: replaces, path, timer
User-Agent: Grandstream GXP2140 1.0.5.28
Session-Expires: 180;refresher=uac
Require: timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length: 256

v=0
o=42 8000 8010 IN IP4 10.10.1.42
s=SIP Call
c=IN IP4 10.10.1.42
t=0 0
m=audio 5004 RTP/AVP 0 8 2 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
--- (14 headers 13 lines) ---
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 2
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G726-32 for ID 2
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw|gsm|g726), peer - audio=(ulaw|g726|alaw)/video=(nothing)/text=(nothing), combined - (ulaw|alaw|g726)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.10.1.42:5004
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 10.10.1.42:5060
Transmitting (no NAT) to 10.10.1.42:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK311281e9;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=as02c076f9
To: "IT Support" <sip:[email protected]>;tag=544860992
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 111 ACK
User-Agent: FPBX-13.0.190.2(13.12.1)
Content-Length: 0


---
<< [ TYPE: Control (4) SUBCLASS: Unknown control '33' (33) ] [SIP/42-000000af]
<< [ TYPE: Control (4) SUBCLASS: Unknown control '32' (32) ] [SIP/42-000000af]
[2016-11-14 12:46:42] DTMF[10160][C-0000008a]: channel.c:4058 __ast_read: DTMF begin '1' received on SIP/30-000000c1
[2016-11-14 12:46:42] DTMF[10160][C-0000008a]: channel.c:4069 __ast_read: DTMF begin passthrough '1' on SIP/30-000000c1
<< [ TYPE: DTMF Begin (12) SUBCLASS: 1 (49) ] [SIP/30-000000c1]
>> [ TYPE: DTMF Begin (12) SUBCLASS: 1 (49) ] [SIP/Fairpoint_SIP-000000c2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
[2016-11-14 12:46:43] DTMF[10160][C-0000008a]: channel.c:3972 __ast_read: DTMF end '1' received on SIP/30-000000c1, duration 160 ms
[2016-11-14 12:46:43] DTMF[10160][C-0000008a]: channel.c:4013 __ast_read: DTMF end accepted with begin '1' on SIP/30-000000c1
[2016-11-14 12:46:43] DTMF[10160][C-0000008a]: channel.c:4042 __ast_read: DTMF end passthrough '1' on SIP/30-000000c1
<< [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [SIP/30-000000c1]
>> [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [SIP/Fairpoint_SIP-000000c2]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/30-000000c1]
<< [ HANGUP (NULL) ] [SIP/30-000000c1]
[2016-11-14 12:47:03] SECURITY[29068]: res_security_log.c:116 security_event_stasis_cb: SecurityEvent="SuccessfulAuth",EventTV="2016-11-14T12:47:03.078-0500",Severity="Informational",Service="AMI",EventVersion="1",AccountID="admin",SessionID="0xb753691c",LocalAddress="IPV4/TCP/0.0.0.0/5038",RemoteAddress="IPV4/TCP/127.0.0.1/56392",UsingPassword="0",SessionTV="2016-11-14T12:47:03.078-0500"
[2016-11-14 12:47:03] SECURITY[29068]: res_security_log.c:116 security_event_stasis_cb: SecurityEvent="SuccessfulAuth",EventTV="2016-11-14T12:47:03.084-0500",Severity="Informational",Service="AMI",EventVersion="1",AccountID="admin",SessionID="0xb751956c",LocalAddress="IPV4/TCP/0.0.0.0/5038",RemoteAddress="IPV4/TCP/127.0.0.1/56396",UsingPassword="0",SessionTV="2016-11-14T12:47:03.084-0500"
[2016-11-14 12:47:03] SECURITY[29068]: res_security_log.c:116 security_event_stasis_cb: SecurityEvent="SuccessfulAuth",EventTV="2016-11-14T12:47:03.142-0500",Severity="Informational",Service="AMI",EventVersion="1",AccountID="admin",SessionID="0xb75261ac",LocalAddress="IPV4/TCP/0.0.0.0/5038",RemoteAddress="IPV4/TCP/127.0.0.1/56400",UsingPassword="0",SessionTV="2016-11-14T12:47:03.142-0500"

<--- SIP read from UDP:10.10.1.42:5060 --->
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.42:5060;branch=z9hG4bK848725973;rport
From: "IT Support" <sip:[email protected]>;tag=544860992
To: <sip:[email protected]>;tag=as02c076f9
Call-ID: [email protected]
CSeq: 3372 BYE
Contact: <sip:[email protected]:5060>
X-Grandstream-PBX: true
Max-Forwards: 70
Supported: replaces, path, timer
User-Agent: Grandstream GXP2140 1.0.5.28
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to 10.10.1.42:5060 (no NAT)
<< [ HANGUP (NULL) ] [SIP/42-000000af]
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: BYE)

<--- Transmitting (no NAT) to 10.10.1.42:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.1.42:5060;branch=z9hG4bK848725973;received=10.10.1.42;rport=5060
From: "IT Support" <sip:[email protected]>;tag=544860992
To: <sip:[email protected]>;tag=as02c076f9
Call-ID: [email protected]
CSeq: 3372 BYE
Server: FPBX-13.0.190.2(13.12.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>
Reliably Transmitting (no NAT) to 10.10.1.42:5060:
OPTIONS sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK68975fc7
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as515eb7a2
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.2(13.12.1)
Date: Mon, 14 Nov 2016 17:47:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from UDP:10.10.1.42:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK68975fc7
From: "Unknown" <sip:[email protected]>;tag=as515eb7a2
To: <sip:[email protected]:5060>;tag=1239664804
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream GXP2140 1.0.5.28
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS
Really destroying SIP dialog '[email protected]' Method: BYE
6

Please try to reformat the log using the appropriate forum tags - From, To, Contact headers are invalid. The initial INVITE is missing.

7

Whenever calls are interrupted at 15 minutes, it’s usually network. NAT, UDP which is usually based on TCP timers set on firewall are the cause. Are sip settings set for NAT? Ca you change NAT/TCP timer on Firewall?

8

Bill,

Here is the kicker. My predecessor built the FreePBX server and it was working. The hard disk failed and there were no backups or documentation of anything. I asked Fairpoint for the SIP provisioning info and built it from scratch. I suspect as well it is a NAT issue, but since it was working before I don’t believe it is something on the firewall but rather my config in FreePBX.

So all is working with the extensions, inbound calls, IVR and all. It only drops calls outbound after 15 minutes, inbound is fine.

I appreciate your help.

9

I have seen this issue with the timer field in the SIP messaging. Typically the Session-Expires field is set to 1800 seconds (30 mins) and if the timers are supported, the PBX will expect a refresh of the session at the 1/2 way mark or 15 mins. If it is not received, the call will get dropped. You might try setting session-timers=refuse in your trunk setting to see if that will resolve the issue. Good luck!

1 Like
10

I’m experiencing a similar issue with outbound calls dropping after exactly 15 minutes and 30 seconds. I never had this issue until I switched to running FreePBX Distro about a month ago.

I’ve tried adjusting the session timer settings on the PJSIP extensions, but that has not helped. I don’t see any obvious way to add the “session-timers=refuse” directly to the trunk through the FreePBX interface for trunks. How would I do that?

Thanks!
Rick

11

Go under Settings>Asterisk SIP Settings. Click on your PJSIP Settings. Near the bottom of the pjsip page i believe you should see Other SIP Settings with two fields separated by an equal sign. Enter session-timers in the first box, then refuse in the second box, submit and apply settings.

12

None of these fields exist for PJSIP.

13

Apologies @lgaetz I thought there were those options in PJSIP as well. Thanks for the clarification.

14

Although, and correct me if I’m wrong, but it could be added via CLI I believe under /etc/asterisk/pjsip.conf by setting the option:

timers=no

15

We have just been experiencing these problems. If the Freepbx server is behind a firewall make sure to turn off the SIP inspection.

16

Here’s what worked for me. We were able to solve the 15-minute hangup problem by using the pjsip.endpoint_custom_post.conf file. By adding “timers=no” to the trunk, the calls stopped timing out. I wish there had been a way to configure this in the pjsip trunk settings.

pjsip.endpoint_custom_post.conf

[mytrunk](+)
timers=no

Notice the (+) after the trunk name. It appears to need that to append to the other settings FreePBX manages.

18

This was exactly the problem. Note that I was using a yeastar myPBX.

Thank you!

19

i got a solution also! use SIP instead of PJSIP.

what happend to me:
I searched the whole web for a solution, timers=no were set everywhere, aswell as session-timers=refuse… no success, i also enabled ALG in the router (made it even worse, drop after 8 minutes), i doublechecked the NAT-Settings, i changed directmedia-settings, and so on…nothing helped. because nothing worked, i started a package-capture and checked what exactly was going on.
in my case the opposite of the FreePBX is the provider “Deutsche Telekom”.
They sent a INVITE-package after 15 minutes. In that INVITE they said: Supported: timers
Asterisk replied with a TRYING and saiid: supported: replaceds, and send a OK short afterwards. then the Deutsche Telekom replied with an “ACK” and after that, the RTP-Stream was broken, no packages more from Deutsche Telekom.
and than, i just thought, okay, let’s try with SIP instead PJSIP - and, bam! no drops anymore.
interesting is, that on the SAME machine (older freepbx-version) we had that exactly same problem in those days and the only solution was to enable PJSIP - now we needed to switch back to SIP to get rid of that calldrops within Deutsche Telekom.
Hope this helps someone else.

PS: before i found this solution i also upgraded from FreePBX13 to 14 and did a asterisk-version-switch to enable asterisk 15 core …but that didn’t changed anything!