no audio at 15 min with FreePBX and Ubiquiti

[mkaye]

i have been using freepbx for years
yesterday i had an outgoing call that the audio stopped at 15 min
i had to call back 4 times to continue the call
i haven't made any changes
2 weeks ago talked for 90 min to same #
my registration timers have always been 3600
i read the registration timers thread, but don't see anything i haven't done

outgoing:
username=<username>
type=peer
session-timers=refuse
secret=<secret>
qualify=yes
nat=yes
keepalive=20
insecure=invite
host=voip.freephoneline.ca
fromdomain=voip.freephoneline.ca
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=ulaw

incoming:
type=peer
secret=<secret>
insecure=invite
host=voip.freephoneline.ca
fromdomain=voip.freephoneline.ca
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
allow=ulaw&g729

[Liptonbrisk]

Freephoneline's switch vendor, PortaOne, implemented a 15 minute session timer at some point in 2020. If something has changed since then that affects Asterisk/FreePBX users I'm not going to notice because I'm not using it.

A Re-INVITE occurs at each 15 minute mark. I can reproduce the problem when FPL"s trunk isn't registered in some SIP apps, particularly when using cellular data only to non-SIP users. Ensure the FPL trunk is registered by logging in at https://www.freephoneline.ca/showSipSettings and that your FPL account isn't being registered using the same FPL proxy server (voip.freephoneline.ca) on any other device. Actually, for troubleshooting purposes, try switching to "voip4.freephoneline.ca:6060" without the quotation marks.If FreePBX is failing to respond to the Re-INVITE request or if responses aren't received, then the call will fail.

The call should also drop after 15 minutes if BYE is processed properly (not just lost RTP audio). If the contact header that is required is wrong (after some change now) somehow, that might cause a problem. You can test by calling from another number (Fongo Mobile is free). After the call is established, hang up Fongo Mobile, in this example. Keep the other side of the call off hook or open (don't hang up the other end). The call should drop pretty quickly (wait 3 seconds or less). Otherwise, BYE isn't being received. A similar issue with BYE not being processed can occur due to a lost NAT association problem, but you're using keepalive and qualify. A NAT issue could also be affecting the Re-INVITE.

You appear to be using Ubiquiti Dream Machine pro. Visit viewtopic.php?f=8&t=20199#p80377 (point b). If rebooting your router fixes the problem, the issue is likely NAT related.

Possibly placing the call on hold, which forces a Re-INVITE, at 14 minutes intervals (and resuming the call before 15 minutes passes) will permit the call to last longer than 15 minutes, but that's not a good solution.

Generally, I've decided to stop trying to assist with FreePBX/Asterisk because I'm not using it and don't want to spend time setting it up again and troubleshooting. However, I didn't want to appear as though I was ignoring you. I'm not. I would suggest asking at https://community.freepbx.org, particularly if no one else responds here. I suspect someone will request a SIP log with debug enabled.

[mkaye]

thanks for getting back to me

yes, the 1st thing i did was look at SIP settings in my user panel
everything registered & OK

i will check the BYE stuff

i did check my unifi settings - i had already changed to those values

[mkaye]

called my # from my cell, hung up cell
call dropped immediately

called my cell from PBX, hung cell up - PBX call did not drop!

[Liptonbrisk]

called my cell from PBX, hung cell up - PBX call did not drop!

BYE was not either not received or processed. I would suspect a problem with NAT association, although I have no idea what caused it for you.
Does eliminating the router resolve the issue? Was router firmware updated recently?


Again, I suggest asking at https://community.freepbx.org/. I'm not using FreePBX at this time. Hopefully you don't need to port forward.

[mkaye]

i have a voip.ms # for my business - same Freepbx
i called my cell in each direction and both ends hung up instantly?
it does use IAX instead of SIP

[Liptonbrisk]

I use a lot of different (SIP) services and have no control over how PortaOne configures their switches for Freephoneline.
IAX uses UDP 4569 by default for both signalling and audio, and it's less likely to lose NAT association or encounter NAT issues than SIP.
SIP uses different ports for signalling and RTP audio, and Freephoneline uses UDP ports only, whereas other services don't necessarily require UDP transport.
Freephoneline also enforces a long 3600 second registration interval, so registrations can't be relied on to keep NAT associations active. Instead, keep-alive is used at 20 second intervals. And then the switch may be configured differently than how other SIP services configure their switches.

I made a request to remove the 15 minute session timer in 2020 and also in 2021, but the timer appears to exist for international tariff fraud prevention (I don't know the specifics of this).
I am sympathetic, but I have no control over anything concerning Freephoneline.

I made a 126 minute outbound call yesterday (helping someone fix an issue) using Freephoneline. The call worked fine and didn't drop, but I'm not using FreePBX or a Ubiquiti router (possibly the latest firmware version introduced an issue; it would be impossible for me to guess that enabling jumbo frames in certain firmware versions would cause some calls to not work, for example). I am aware people are excited about Unifi 8.0.7. I wouldn't be surprised if an issue were introduced. If removing the router from the setup works, then that at least provides a clue where to start looking. Having SIP ALG enabled can cause problems with SIP headers, but I'm pretty sure you have SIP ALG disabled (and I would have expected the call to drop after 32 seconds and not after the Re-INVITE). Another possibility is the Asterisk version used (if it was updated recently).

Lastly, (and again), if PortaOne changed something that affects Asterisk/FreePBX users I'm not going to notice because I'm not using it.

[mkaye]

i called my cell, call went past 15 min mark - not long distance like my other call
i called my cell again & hung up, FPL did not detect hangup
not sure where to look?

[Liptonbrisk]

i called my cell again & hung up

I'm not clear on what you're describing. Did you cancel (hang up) the call before answering it on the the cell phone side?
If so this is what should happen:


(example 1)

FPL did not detect hangup

Based on the cellphone continuing to ring after cancelling the call on the FPL phone side?

When I call my cellphone from FPL and cancel the call before it's answered, my cellphone stops ringing. I tested using all three FPL proxy servers.

Or did the cellphone side answer the call and then hang up from the cellphone end of the call?


(example 2)

In this example, the callee (cellphone) is hanging up after answering the call.

not sure where to look

In example 2, BYE is presumably being sent back to FPL's proxy server, and it, should be, in turn, sent back to you.
So you can check SIP logs to see whether BYE is being received/processed.
You can also check to see whether 200 OK is being sent from you to FPL after BYE is received.

If you are not receiving BYE, I would eliminate my router from the equation, briefly, and test without it to see whether its NAT firewall or some setting is causing a problem.
I would also check my Contact headers. BYE is sent to the IP address and port listed in the INVITE's Contact header; FPL's servers attempting to send packets over the internet to private LAN IP addresses (ex. 192.168.1.28) can cause problems, for example.

My response is the same: viewtopic.php?f=8&t=20678#p81154.

"BYE was not either not received or processed. I would suspect a problem with NAT association, although I have no idea what caused it for you.
Does eliminating the router resolve the issue? Was router firmware updated recently?


Again, I suggest asking at https://community.freepbx.org/. I'm not using FreePBX at this time. Hopefully you don't need to port forward."
You would need to enable/set debug to check whether the respective packets are arriving. If they are then you may need to change configuration settings if they're not being processed properly. I'm not going to support FreePBX. I'm not using it.


If the problem you're describing is example 1, where the cellphone continues to ring despite hanging up your FPL phone, then you need to see whether CANCEL is being sent from your side and also whether 487 is coming back to you. I would see whether my router is causing a problem by testing without it briefly.

[mkaye]

i call my cell, answer, then hang up
call on my end stays open
no message in log when i hang up the cell

[mkaye]

strange tho
i called my 519 # yesterday that lasted 15 min 2 weeks ago and now it worked past 15 min???

[Liptonbrisk]

i call my cell, answer, then hang up
call on my end stays open

That's this (up to the point where BYE is sent to proxy):


Source: https://thanhloi2603.wordpress.com/2017 ... -messages/

no message in log when i hang up the cell

After the cell phone is hung up, BYE should be sent towards the originating SIP client by FPL's proxy server.

If you are not receiving BYE, I would eliminate my router from the equation, briefly, and test without it to see whether its NAT firewall or some setting is causing a problem.
I would also check my Contact headers. BYE is sent to the IP address and port listed in the INVITE's Contact header; FPL's servers attempting to send packets over the internet to private LAN IP addresses (ex. 192.168.1.28) can cause problems, for example.



My response is the same: viewtopic.php?f=8&t=20678#p81154.

BYE was not either not received or processed. I would suspect a problem with NAT association, although I have no idea what caused it for you.
Does eliminating the router resolve the issue? Was router firmware updated recently? I am aware people are excited about Unifi 8.0.7. I wouldn't be surprised if an issue were introduced. If removing the router from the setup works, then that at least provides a clue where to start looking.

[Liptonbrisk]

strange tho
i called my 519 # yesterday that lasted 15 min 2 weeks ago and now it worked past 15 min???

For what it’s worth, with some SPA devices, trying to use or enable outbound caller ID block (anonymous calling) causes 15 minute call drops: viewtopic.php?f=8&t=20337&p=79706. You might want to see whether attempting to block outbound CID was the cause (or trying to spoof outbound CID).

Otherwise, nothing has changed on FPL's end. What you're describing suggests a NAT/router or VPN issue.

A Re-INVITE occurs at the 15 minute mark.

I suggest looking at the IP address and port that's being sent in the IP address in your Contact headers being sent with all instances of INVITE.


For example, Contact: "mkaye" <sip:12345678912@PUBLICWANIPADDRESS:44444>
Local sip UDP port 44444 should not be 5060. Don't use UDP 5060, and don't use the same UDP (44444) port for any other trunk.
These are FreePBX configurations. Ask at https://community.freepbx.org/

If you're using a VPN, test without it.

Regardless, BYE either isn't being received or being processed when you hang up your cellphone.

If BYE is being sent to private LAN IP address (ex. 192.168.2.28:44444) over the internet from voip4.freephoneline.ca:6060 (which you should be using while troubleshooting), then that's a problem.

Another potential cause is NAT firewall (or VPN) association suddenly closing (also check firewall log for dropped connections) or becoming corrupted.

Test using voip4.freephoneline.ca:6060. Test without router (briefly, just while testing). Ensure you're not running a VPN while testing.

If you're using Bell Gigahub, ensure you're doing PPPoE passthrough in Ubiquiti router (alternatively, you can enable Advanced DMZ in the Bell Hub and enter Ubiquiti router's MAC address).
It wouldn't hurt to disable SIP ALG in it, regardless:
For Bell Giga Hub
Open your web browser, and login at 192.168.2.1 with your administration password.
Navigate to "Advanced tools & settings"-->"Networking"
Disable "SIP ALG".

I have no further suggestions.