Outgoing Calls drop after 15 minutes

FreePBX Providers
1

Hi,

I know this is a common issue and have done the following in an attempt to fix the problem.

  • Added ‘session-timers=refuse’ and ‘timers=no’ to SIP Legacy Settings.
  • Using pfSense as a firewall and set Firewall Optimization Options to ‘Conservative’ which is supposed to increase the udp timeout setting
  • No port forwarding.

This is a call log (unfortunately forgot to turn on debug, will attempt to grab another) https://paste.ubuntu.com/p/Csj88yV8Sq/

Outgoing SIP settings:

username=XXX
type=friend
secret=XXX
qualify=yes
nat=yes
insecure=port,invite
host=voip2.freephoneline.ca
fromdomain=voip2.freephoneline.ca
dtmfmode=auto
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw&g729
keepalive=yes
session-timers=refuse

Incoming SIP settings:

type=user
secret=XXX
insecure=port,invite
fromdomain=voip2.freephoneline.ca
context=from-trunk

Other Info:

  • SIP provider (freephoneline)
  • Hardware (Fresh install of Raspbx on a RPi3)

Any suggestions would be greatly appreciated.

2

From this log it seems like 201 terminated the call.

[2020-04-16 14:53:44] VERBOSE[22472][C-00000013] bridge_channel.c: Channel SIP/freephoneline-0000002a joined 'simple_bridge' basic-bridge <d5d18447-368e-4ebf-9736-f007bc807947>
[2020-04-16 14:53:44] VERBOSE[22470][C-00000013] bridge_channel.c: Channel SIP/201-00000029 joined 'simple_bridge' basic-bridge <d5d18447-368e-4ebf-9736-f007bc807947>
[2020-04-16 15:08:45] VERBOSE[22470][C-00000013] bridge_channel.c: Channel SIP/201-00000029 left 'simple_bridge' basic-bridge <d5d18447-368e-4ebf-9736-f007bc807947>
[2020-04-16 15:08:45] VERBOSE[22472][C-00000013] bridge_channel.c: Channel SIP/freephoneline-0000002a left 'simple_bridge' basic-bridge <d5d18447-368e-4ebf-9736-f007bc807947>

To take a deeper look, you’ll have to enable sip debug.
From asterisk cli:

sip set debug on

And post the log using a pastebin link.

What SIP client are you using? Could be that the network between the SIP client and the PBX isn’t stable?

3

There are 3 general causes of this issue:

  1. Contact header incorrect or contact response incorrectly handled.
  2. NAT association lost (unlikely given qualify), but let’s rule this out.
  3. Re-invite butchered by firewall or mishandled by Asterisk.

(1) also affects BYE. To rule it out, call your mobile, answer it, verify properly connected. Hang up the mobile but leave the calling extension off hook. Within a few seconds, the calling extension should show that the call has ended. If not, BYE was not received.

(2) also affects BYE. To rule it out, call your mobile, answer it, verify properly connected. Wait 14 minutes, then hang up the mobile but leave the calling extension off hook. Within a few seconds, the calling extension should show that the call has ended. If not, BYE was not received.

Knowing the results of these tests, we can do appropriate further debugging.

4

What you nead in Incoming SIP settings:
canreinvite=no

5

This has the feeling of a networking / NAT issue. Make sure to read and follow this guide to eliminate any NAT issues:

https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12

6

You can get rid of these. Your Outbound config is set up as “type=friend”, so all of these settings are redundant (“friend” is a short-cut that builds these for you). Adding the “canreinvite=no” to the outbound config will work the same as putting it in the incoming section (once again, because of the “friend” setting).

Other than that - what they said. It’s almost certainly a router/NAT setting problem.

7

Thanks for all the suggestions. I guess was never too keen on opening up ports and forwarding it to freepbx. Thought I could get away with it, as initially it looked like it was working fine.

8

First, do the suggested tests, so we can determine whether port forwarding is relevant.

If it is, unless you make a mistake setting it up, there is zero risk because you will be forwarding only the FPL server addresses to your PBX. Those paths would normally be open anyhow, as replies to the REGISTER and OPTIONS requests sent out.

9

Most of the time these settings are copied from cookbook examples and users generally don’t try to understand what they mean.

type=peer is usually the better choice. Matching incoming invites is then done on IP address/port, whereas with type=friend it’s done on the user portion in the from header.
You need friend only if you have different endpoints on the same IP address/port, because with peer Asterisk wouldn’t then be able to know what endpoint the invite is coming from.

Secret plus insecure=invite has also been replaced with remotesecret, and insecure port is rarely required.
But best to switch to pjsip anyway.

1 Like
10

@Stewart1
I called my mobile, answered, then hung up. The calling extension took around 10 secs before I finally got a off the hook (busy tone) signal. Not sure what that means.

@cynjut
As per your post, I got rid of the incoming settings.

@mbrooks
I pretty much followed that guide except for the port forwarding.

This could be provider specific as I’ve just been made aware of another user using the Asterisk/Freepbx / Freephoneline service and experiencing outgoing calls drop audio after 15 minutes. So they’ve made changes recently somewhere that’s likely causing this.

Also on a now retired version of IncrediblePBX which I’ve been using for quite some time and recently swapped out, I remember seeing this error:
Disconnecting call 'SIP/freephoneline-00000104' for lack of RTP activity in 31 seconds