We have a freePBX system distro 13.0.191.11. We have had the system in place for about a year now, we have added about 15 phones to the system recently, and since that change, we have had issues with dropping to toll free numbers after 17:30 to 17:32. The problem is pretty consistent, we have updated the firmware on the phones Aastra/Mitel 6867i as well as increased the RTP timeout to 1500, which I don’t think even makes a difference because we have the session-timers=refuse in the trunk. We have troubleshot with wireshark and found that the call hangs up, I am completely baffled by this issue.
You added 15 extensions to your system and now your calls to toll-free numbers drop from half-past 5 in the afternoon for two minutes? Am I parsing that right?
Sorry, I wasn’t clear…
The calls drop after being active for 17:30 - 17:32 - that’s the length of the call, not the time of day.
I’m not sure the issue has to do with the adding of extensions. Also I think being toll free might be a coincidence but not positive. The client will be on hold waiting for a representative when it happens. I think they just call alot of insurance companies that have 800 numbers and they keep them on hold forever.
Have them call you, put them on hold and see what happens. The file /var/log/asterisk/full will tell you why the call is dropping.
Call dropped at 12:59:37 at duration of 17:40… was from extension 289 and to 18005238444, below is the output of /var/log/asterisk/full at 12:59:37…
[2017-07-25 12:59:37] VERBOSE[21303][C-00005ac3] bridge_channel.c: Channel SIP/sipwise-00013f0c left 'simple_bridge' basic-bridge <a8d6ed37-9a64-441b-9be3-c15ae07f98c2>
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] bridge_channel.c: Channel SIP/289-00013f0b left 'simple_bridge' basic-bridge <a8d6ed37-9a64-441b-9be3-c15ae07f98c2>
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] app_macro.c: Spawn extension (macro-dialout-trunk, s, 23) exited non-zero on 'SIP/289-00013f0b' in macro 'dialout-trunk'
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Spawn extension (from-internal, 18005238444, 6) exited non-zero on 'SIP/289-00013f0b'
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Executing [h@from-internal:1] Macro("SIP/289-00013f0b", "hangupcall") in new stack
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("SIP/289-00013f0b", "1?theend") in new stack
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Goto (macro-hangupcall,s,3)
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Executing [s@macro-hangupcall:3] ExecIf("SIP/289-00013f0b", "0?Set(CDR(recordingfile)=)") in new stack
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Executing [s@macro-hangupcall:4] Hangup("SIP/289-00013f0b", "") in new stack
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/289-00013f0b' in macro 'hangupcall'
[2017-07-25 12:59:37] VERBOSE[21268][C-00005ac3] pbx.c: Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/289-00013f0b'Do extension to extension, or extension to PBX dialing appear to work fine?
This kind of looks like a connectivity issue with your sip trunk, sipwise??, from the first two lines of the log?
Is your PBX on-premise or hosted?
Do you have another sip trunk to test with and does that experience the same issue?
If so, I’d look at firewall configs at the PBX and any parameter firewalls for that LAN.
If not, maybe contact your sip trunk provider.
Freepbx is on premise with dedicated T1 back to facility with provider. No firewall per say just t1 router. No direct internet access, freepbx only communicates with proxy. Don’t seem to have this issue with other customers with same setup, so I don’t assume that it is provider related. Can you for my own curiosity let me know why you think its connectivity issues? It does always seem to happen between 17 and 18 minutes.
UDP timeouts, NAT issues are common issues among incorrect firewall setups, that’s why I thought it was connectivity related. Since it’s on-prem, and no internet access… that kind of rules out what I was thinking.
I saw “SIP/sipwise” in your log and just assumed it was a SIP trunk over the net.
I thought it might be provider related since you mentioned it on 800 numbers.
That usually sounds like a LCR dialing plan going haywire.
Anything else odd happening on this PBX? Like bad caller ID, phones rebooting, call quality issues?
All I have is a piece of a memory - “timers=no” that might be part of it.
We’ve seen reports of calls terminating after 15 minutes and it has something to do with timers either in Asterisk or in the router. UDP Keep-alives maybe? Maybe the NAT timers for your calls failing after 15 minutes? It’s been a few months, so I don’t remember any of the details, but I recall it being a setting in the router and the way that NAT was being handled that ended up being the solution.
Sorry I can’t be more specific.