Incoming calls dropping

[marco99]

Incoming calls dropping after about 5 sec. Outgoing calls seem OK.
I noticed problem today but other issues happened yesterday ( calls not going to voicemail )
I see that there has been some major changes to Fongo Network starting Jan 23.
I rebooted my ATA and made a test call OK

Any other users experiencing issues?.

[Liptonbrisk]

The changes made were in reference to this: http://forum.fongo.com/viewtopic.php?f= ... 702#p76878. Anyone still registering using old server IP addresses is going to have problems.

I’m not currently experiencing issues with incoming calls, but until the “degraded performance” status clears, I would expect quirks to occur.
https://status.fongo.com/

[Cyber]

Since the migration starting january 23, a major bug is occuring for me, my friends and my parents.

Incoming calls and outgoing calls from my FPL line to other FPL numbers are not working. When I call, there is no ringtones and the voicemail start after 15-20 seconds.

Using my Koodo cellphone, I can call my FPL line or my friends FPL line without any issue. This occur on 514 and 438 area codes (we didn't test other area codes).


I own a SPA112 (v1.4.1 SR5). A device reboot did not fix the issue.

I opened an support ticket about that. To be continued...

[Liptonbrisk]

Incoming calls and outgoing calls from my FPL line to other FPL numbers are not working

SIP to SIP calls can be dependent on other people’s router and ATA configurations at the other end.
I'm not having problems with incoming or outgoing calls between FPL numbers located in the GTA so far. I did experience some voicemail issues earlier (with the voicemail system not answering at all), but they seem to have cleared. If I experience issues after the "degraded performance" status is removed from https://status.fongo.com/, I'll inquire at that point.

I haven't tested voicemail notifications yet.

I own a SPA112 (v1.4.1 SR5). A device reboot did not fix the issue

They're probably still working on stuff, making troubleshooting pointless in my opinion, but you can try rebooting your router. Wait for it to be fully up and running with Wi-Fi SSIDs populated first. Afterwards, reboot your ATA. That's always proper device reboot order. Get the people you're calling to do the same thing.
If the issue still persists, you can try the following, but this all seems pointless to me given that Fongo's status page currently indicates "degraded performance":

1. If you have a modem/router combo, gateway, or hub from your ISP, ensure that it's in bridge mode provided you're using your own router. Contact your ISP if you need more information about their device or need assistance with getting it into bridge mode.

2. Log into your ATA

3. Navigate to Voice-->Line (choose the one used for FPL) -->SIP settings.

Change SIP Port to a random number between 30000 and 60000. Do this for security reasons.

Submit settings.

4. Navigate to Voice-->SIP-->NAT Support Parameters

Make these changes:
a)Handle VIA received-->yes
b)Handle VIA rport-->yes
c)Substitute VIA Addr-->yes

Submit settings.

This helps to ensure RTP audio packets are being sent to your public WAN IP address as opposed to somewhere in space (LAN IP address). Not enabling these settings can cause 1-way audio problems when using Freephoneline.


5. Navigate to Voice-->SIP-->SIP Timer Values (sec)-->Reg Retry Intvl should be 120 seconds

Change to 120 seconds.

Submit settings. This setting won't help with a dropped call or 1-way issue, but a lot of people don't have this setting set properly in their ATAs due to older setup guides not including it.

6. Test again.

7. If the problem persists, in your SPA112, Navigate to Voice-->Line (FPL)-->Proxy and Registration-->change proxy to voip4.freephoneline.ca:6060
This is done to circumvent buggy SIP ALG features in routers. In some cases these features are forced on in routers and modem/router combos or gateways with no way for the customer to disable them.


If the problem is with Freephoneline (and it very well could be at this point) or on the end of the person you're calling, then changing your ATA settings won't help.

[Liptonbrisk]

I haven't tested voicemail notifications yet

I don't know if the incoming voicemail notification interval has changed, but after waiting 13 minutes, VMI still hasn't been triggered.

https://status.fongo.com/

"Jan 25, 2020

Investigating - Voicemail Notifications Not Coming
Investigating -
Jan 25, 2020 - 07:51 (EST)
Investigating - We are still investing voicemail notifications not arriving
Jan 24, 2020 - 04:40 (EST)"


Seems as though that's still an issue at the moment.

[Cyber]

@Liptonbrisk,

Me and my friends are using FPL since 8 years and we never had issue before the migration occurred on january 23.

Same issue using voip2.freephoneline.ca

(Voice... Line 1 ... SIP Settings)
I was using 5060 as SIP Port. I changed it per your recommendation. Same issue.

(Voice... Line 2 ... SIP Settings)
I was using 5061 as SIP Port. I changed it. Same issue.

I have two FPL lines on the same ATA. I can test locally. No ringtones between both of them.
Using my cellphone, no issue. My friends and I are all located in QC.


Do I need to modify these parameters :

Voice... SIP.... SIP Parameters :

SIP TCP Port Min: 5060
SIP TCP Port Max: 5080

[Liptonbrisk]

Me and my friends are using FPL since 8 years and we never had issue before the migration occurred on january 23.

As I said before the problem could very well be with FPL, which is why I feel troubleshooting at this point is a waste for as long as the status website indicates a problem exists.

But the length of time anyone has been with FPL with the service working properly doesn't matter, unless UDP timeouts in routers have been set properly. That's difficult to accomplish in many router's firmwares because the UDP timeout settings aren't made available. NAT associations in routers can become corrupted without users doing anything (it doesn't matter how long someone has been with FPL; I've been with them for around 10 years, and default UDP timeout settings in routers can cause problems even if everything was working fine at one point).

Same issue using voip2.freephoneline.ca

voip2 isn't going to make a difference for a potential buggy SIP ALG issue. SIP ALG features in routers monitor traffic on UDP port 5060. voip2.freephoneline.ca uses UDP 5060. Buggy SIP ALG features in gateways, router/modem combos, hubs, and in users routers can cause many problems: https://www.voip-info.org/routers-sip-alg/ (scroll down to SIP ALG problems). The reason voip4.freephoneline.ca:6060 exists is to circumvent buggy SIP ALG features in routers and gateways.

The two things to try that were listed previously that might make a difference are using voip4.freephoneline.ca:6060 (doesn't matter if you're not using a Rogers Hitron gateway; the server works for everyone)

and

in your ATA, Navigate to Voice-->SIP-->NAT Support Parameters

make these changes:
a)Handle VIA received-->yes
b)Handle VIA rport-->yes
c)Substitute VIA Addr-->yes

Submit settings.

The VIA settings should be applied, regardless, for everyone with SPA and PAP ATAs.

Then reboot router (wait for it to be fully up and running first) followed by your ATA. However, as I said before, the problem could very well be on Freephoneline's end, which would make troubleshooting pointless.

I have two FPL lines on the same ATA. I can test locally. No ringtones between both of them.
Using my cellphone, no issue. My friends and I are all located in QC.

Yes, I agree that the problem could be with FPL. "Degraded performance" is still listed at this time.

I have access to several FPL numbers. I have one configured on my smartphone. Calls over Wi-FI (LAN) and using cellular data (WAN) work fine between my FPL numbers for me. I also tested with Fongo Mobile, which is basically the same thing, and FPL. I have no issues between FPL numbers in the GTA. I don't have Quebec FPL numbers to test. It's entirely possible a problem exists.

Do I need to modify these parameters :

Voice... SIP.... SIP Parameters :

SIP TCP Port Min: 5060
SIP TCP Port Max: 5080

Nothing involving Freephoneline uses TCP ports. Everything with FPL is UDP.

[Cyber]

@Liptonbrisk,

Yes, I configured VIA settings as your said when I did my previous tests. Same issue on voip and voip2 proxy servers.

Issue solved on voip4.freephoneline.ca:6060

Since there is four SPA112 that stopped functionning normally on voip and voip2, I still continue to affirm that there is a bug since the migration.

Thanks for your help.

[Liptonbrisk]

@Liptonbrisk,

Since there is four SPA112 that stopped functionning normally on voip and voip2, I still continue to affirm that there is a bug since the migration.

Your findings would normally lend themselves towards a SIP ALG problem in either your router or a modem/router combo issued by your ISP, given voip4 works. But Fongo's status page says "degraded performance."
I'm not having issues with any server, but I'm not testing to Quebec numbers.

I just noticed you're using Asuswrt-Merlin. I use it and recommend it as well. Ensure SIP Passthrough (this is SIP ALG in Asus routers) is set to "Enabled + NAT Helper" under Advanced settings-->WAN-->NAT Passthrough in your router.


1) Are you using DSL? If so, do PPPoE login using your SPA112. Then try voip.freephoneline.ca:5060 again. If that works, the problem involved a router or modem/router combo on your end.
Using your ATA to do PPPoE login bypasses router (SIP ALG) features in your other devices.

2) If you're using cable,

a) ensure the modem/router combo you're using is in bridge mode (router features in it will be disabled in bridge mode; you'll be using it just as a modem only)--provided you're using your own router. And then
b) test using voip.freephoneline.ca:5060 with SIP Passthrough (in your RT-68U, under Advanced settings-->WAN-->NAT Passthrough) set to "Enabled + NAT Helper".




With respect to UDP timeouts I mentioned earlier, use values that adhere to the following:

UDP Unreplied Timeout (in your router) < NAT Keep-alive Interval (20 seconds) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (Reg Retry Intvl) (120 seconds)

“<“ means less than.

When a modem leases a new IP address, a problem can arise where prior associations using the old IP
address are maintained in the router. When the ATA attempts to communicate using the old IP address,
the response is unreplied, and then if the UDP Unreplied timeout is greater than the Keep Alive Interval
(and UDP Unreplied timeout is often set to 30 by default in consumer routers) a problem arises where
the corrupted connection persists. If UDP Unreplied timeout is, for example, 17, and the NAT Keep
Alive Interval is 20, then the corrupted connection will timeout or close. A new connection will be
created, and everything will work fine.

Another problem can occur when the Keep-Alive interval is greater than UDP Assured Timeout (often
180 by default in consumer routers): the NAT hole will close due to the ATA not communicating
frequently enough with the SIP server. In turn, incoming calls may, intermittently, not reach the ATA.
Again, NAT Keep Alive Intvl is supposed to be 20 with FPL.

Getting access to both UDP Unreplied Timeout and UDP Assured Timeout settings in consumer routers may be
difficult, if not impossible. Asuswrt-Merlin, third party firmware for Asus routers, does offer easy access to these two
settings, which are found under General–>Tools-->Other settings. .
The keep alive interval for FPL is 20. The SIP Registration Failure Retry Wait Time (Reg Retry Intvl setting in your ATA) is 120.



3) Login to your router. Navigate to General–>Tools-->Other settings. Try 17 for UDP Unreplied Timeout and 117 for UDP Assured Timeout.

Save settings. Reboot router (wait for it to be fully up and running). Then reboot ATA.


Then try voip and voip2 again in your ATA.

Anyway, at least voip4.freephoneline.ca:6060 is working for you.

Thanks for your help.

You're welcome!

[Cyber]

I just noticed you're using Asuswrt-Merlin. I use it and recommend it as well. Ensure SIP Passthrough (this is SIP ALG in Asus routers) is set to "Enabled + NAT Helper" under Advanced settings-->WAN-->NAT Passthrough in your router.

You're right. I'm using Asuswrt-Merlin (RT-AC68U_384.14_2.trx). SIP Passthrough was already set to "Enabled + NAT Helper".

Try 17 for UDP Unreplied Timeout and 117 for UDP Assured Timeout.

I changed the values per your recommendation. Default values was 30 and 180.

My friends and I will use voip4 until it stop working.



Which setting is the "Registration Interval" that must be set to 3600 seconds in the SPA112 ?

[Liptonbrisk]

Which setting is the "Registration Interval" that must be set to 3600 seconds in the SPA112 ?

1)Set Register Expires to 3600. Navigate to Voice-->LINE 1 (or whichever line you’re using for FPL)-->Proxy and Registration -->Register Expires should be 3600 seconds

That's the interval.

This setting is important and can't be lowered if you want FPL to work properly without being temporarily IP banned by FPL's registration server.

2) Navigate to Voice-->SIP-->SIP Timer Values (sec)-->Reg Retry Intvl should be 120 seconds
(That’s the failed registration retry timer/interval)

This setting can be increased if you wish without having FPL's server temporarily ban you. So, let's say you want to keep your UDP Assured Timeout in your router set to 180s (default). In that case, raise Reg Retry Intvl to 183 seconds. When your ATA fails a registration attempt, instead of waiting 120 seconds to try again, it will wait 183 seconds to make another registration attempt. A setting below 120 seconds might cause problems. Too many registration attempts within a short period can result in a temporary IP ban.


3) The other timer you need to look at is T1.
T1 is the estimated round trip time (RTT) of a packet between your ATA and FPL's server in this case (for registration, invite requests or SIP signalling).
I don't know whether this T1 bug has been fixed in the latest firmware for SPA112/SPA122 ATAs: https://community.cisco.com/t5/atas-gat ... -p/1930651.
Basically firmwares were using 10% of the value for T1 that was listed.

a) If that bug still exists, navigate to Voice-->SIP-->SIP Timer Values-->T1
Change SIP T1 to 10.

b) If that bug doesn't exist, change SIP T1 to 1.

For an explanation of this issue, visit http://www.dslreports.com/forum/r294151 ... SIP-T1-bug, and read Mango's posts, in particular http://www.dslreports.com/forum/r29451649-.

[Cyber]

1)Set Register Expires to 3600. Navigate to Voice-->LINE 1 (or whichever line you’re using for FPL)-->Proxy and Registration -->Register Expires should be 3600 seconds
That's the interval.

I was thinking that Register Expires and Registration Interval was two differents things because on the VoIP Unlock Key Credentials page (source), both of them are displayed :

Registration Interval : 3600 seconds (1 hour)
Registration Expiry : 3600 seconds (1 hour)


I suggest to update the web page to avoid confusion for others clients.

3) The other timer you need to look at is T1.

That bug seem to be fixed. Default setting is 0.5 in my current firmware.

Code: Select all

SIP T1
RFC 3261 T1 value (round-trip time estimate), which can range from 0 to 64 seconds.
Default setting: 0.5

Thanks again for your very detailed explanations. This is appreciated.

[Liptonbrisk]

Registration Interval : 3600 seconds (1 hour)

This is how long before an ATA, IP Phone, etc. makes another registration attempt.

The Register Expires setting in your SPA ATA defines how often it renews registration with Freephoneline.

Registration Expiry : 3600 seconds (1 hour)

This is how long the ATA, IP Phone, etc. is registered with Freephoneline before registration is lost.
Without a new, successful registration attempt, registration will expire after 3600 seconds.

I suggest to update the web page to avoid confusion for others clients.

I don't work for Fibernetics, Freephoneline, or Fongo. But I think the idea is that different devices have different settings.
They're not obliged to read forums, so if someone has a suggestion, a ticket probably needs to be submitted.