[Resolved] Dead air calling out, or upon being put on hold

[Erft]

For the last couple of months, I've had trouble with, (I thought) just calls placed to Amazon, with the phone ringing and then hearing nothing but dead air. It was only happening with calls to Amazon, maybe about 40% of them.
As well, after being put on hold, the hold music is suddenly being replaced with dead air, and eventually the call disconnects.

Today I called a friend; the phone rang, then I got dead air. I called my friend again and got them; they said that the phone had rung and when they picked up there was nothing but dead air.

I have noticed that nearly 40% of the time, when I dial a number, regardless of what it is, that it won't even ring. I have to hang up and try again, and usually it goes fine the second try (except with Amazon where I only get through on the 5th try).

I have had to call Amazon several times today. Sometimes I get dead air after dialing. Sometimes after it rings, I get dead air. But most commonly I'm put on hold after speaking to an agent, and after a little while the hold music is replaced with dead air. This goes on for several minutes until the call disconnects. I assume at the other end someone has picked up and gotten dead air, so they hang up.

So it's maybe nearly four months that the dead-air-after-dialing issue has been going on, and about two months that the dead-air-while-on-hold has been going on. It wasn't until my friend shared their experience with my calling them that I realised it's happening on both ends.

Come to think of it, the being disconnected while on hold business might have been going on for nearly a year or more.
I wondered if it was the 15-minute problem I'd heard about, but the time that dead air sets in seems to be random.
It also seems like I'm making/getting more garbled calls, too.

This is possibly (probably?) an ATA problem (Cisco SPA122) but I haven't changed anything in the settings for a long time. I need help in figuring this out. Does anyone know what's going on?

[Liptonbrisk]

For the last couple of months, I've had trouble with, (I thought) just calls placed to Amazon, with the phone ringing and then hearing nothing but dead air. It was only happening with calls to Amazon, maybe about 40% of them.

I call Amazon relatively often. I've never had that issue.

Based on your description of the problem, I'm not sure that it's related to my experience, but today, I did have issues with calls involving Rogers carrier numbers. One call lasted over 2 hours and worked fine. With other calls, incoming audio dropped out after awhile, forcing me to call back, which was annoying. As you may be aware, Rogers' network isn't back to normal quite yet. Some Rogers customers are still experiencing intermittent issues, and some are still, inexplicably, without service, although they are in the minority. Anyway, all my call problems today involved Rogers numbers (Rogers, Fido, etc.).

However, I'm not 100% positive the issue I'm having is with Rogers. The problem could be with FPL's RTP servers during peak call periods. I simply haven't done enough testing yet, and I was very busy today and will probably be tomorrow as well. I can see in my call log stats that I'm not losing or dropping packets on my end.

I wondered if it was the 15-minute problem I'd heard about

FPL uses a 15 minute session timer. There's a RE-INVITE that occurs at the 15 minute mark, and if there's no ACK (acknowledgement) received, the call will drop/end.

It also seems like I'm making/getting more garbled calls, too.

If by garbled you mean it sounds as though audio packets are arriving out of order (or slowly garbled) and then suddenly working normally afterwards, that's usually caused by ping spikes (a problem with your ISP or a problem along the path it uses from you to FPL's servers) or a QoS issue (lack of it being configured in a router for the ATA).

1. I would try this WINMTR test:


The instructions below are for testing to FPL's proxy servers, but I would also test to 208.85.218.149 and 208.85.218.150, which are the RTP IPs at the moment for FPL.
That's where the RTP audio packets come from.


"Test pings and jitter (you want little to no variation between pings) to the specific Freephoneline SIP servers you plan on using.

Use winmtr: https://sourceforge.net/projects/winmtr/. Ping about 200 times to each server.

My pings to
-voip.freephoneline.ca average 11 ms.
-voip2.freephoneline.ca average 12 ms
-voip4.freephoneline.ca average 27 ms

If you're using a Macintosh, maybe this helps: https://www.reddit.com/r/TagPro/comment ... tr_on_mac/

When using WinMTR, look at the very last hop or line. Look at your average ping and then maximum ping. Although WINMTR doesn't provide a jitter value, you can get an idea of what yours is by subtracting maximum ping from your average. Jitter is the difference between each successive ping. The bigger the difference, the bigger the problem.

Same with ping, which represents lag or delay. The lower your ping and jitter, the better.

You do not want high pings and lots of jitter (you do not want a lot of variation between each ping). If you get horrible results (pings over 200ms), to any server, you probably don’t want to use that server. So you would want to give that server the lowest priority.

I get between 11 (voip.freephoneline.ca and voip2.freephoneline.ca) and 24ms (voip4.freephonline.ca) on average, depending on the server I'm testing to. Preferably, you want pings below 100ms.
Anything over 200ms is unacceptable.
What you don't want to see is 40, 45, 50, 35, 500, 40, 30, 45, 700. That's bad jitter.
You want relatively consistent pings without a lot of variation.

One reason why jitter can occur is due to other devices on your LAN (local area network) using bandwidth. That’s why properly enabling QoS in your router for your ATA is always a good idea. Refer to point C from viewtopic.php?f=8&t=20199#p78976.

Bad jitter can produce broken-up audio or choppiness during phone calls. Severe jitter (or large ping spikes) can cause calls to drop. Ping affects delay.

I recommend testing pings/jitter between 8 p.m. and 11 p.m. to see if local congestion is a factor (this often is your ISP's fault). Sundays are the best days to test (because that's when most people in your area will be home). 8 p.m. - 11 p.m. is prime time. During prime time (between 8 p.m. and 11 p.m.) cable internet nodes may be oversubscribed in your area and face congestion issues (and congestion can also exist with DSL). So I suggest testing services between 8 p.m. and 11 p.m., particularly on Sundays, when everyone in your area will be home.

Ping is a measurement of data packet transmission, and ping does affect delay or lag. All gamers know, almost inherently, that lag affects them negatively. A PC gamer will pound his or her keyboard in hope that a character will respond on his or her monitor, quickly, but when there's a delay or lag, reality doesn't meet expectation. A gamer can see this problem visually. Over VoIP, anything over 200-210 ms, you will typically start to encounter crosstalk due to increased delay, even if the untrained ear doesn't notice. All VoIP services are subject to the same scientific principles including the fact that speed of transmission affects delay, and Freephoneline is not some magical service that is somehow exempt from issues arising from high pings and jitter. When pings and, especially, jitter are high, it's a pretty horrible experience, just as it would be with any other VoIP service. When pings and jitter are fine, Freephoneline is great.

Lastly, anyone using any communication service (or even when playing online games or using other online services) should understand that the longer the path to the server being used, the greater the potential exists for a problem to occur somewhere along that path. Freephoneline’s SIP servers are located in Ontario."

-- from download/file.php?id=2164 (pages 16 and 17)

This is possibly (probably?) an ATA problem (Cisco SPA122)

I'm skeptical. Your issue seems more likely to be ISP related (or a QoS problem), particularly with "garbled" audio.

Don't test using Rogers, Fido, or Chatr numbers. Right now, Rogers simply isn't reliable currently while they are continuing to resolve issues.

Another possibility, with respect to audio dropouts, is FPL's RTP servers (overloaded) during prime time, but I'm not sure yet. The problem I had today could be an FPL issue.

2. I suggest trying the echo and Music on Hold tests here:
http://thetestcall.blogspot.com/
Use the Toronto and B.C. test numbers

[Erft]

Thanks for replying, Liptonbrisk.
Before I try your suggestion, I'd like to clarify that what I meant by "garbled" would better be described as "choppy". So many words dropped and missed that I only hear one word out of 6 or so. Mostly silence for several seconds, with the occasional word sounding completely normal, then more silence.

[Liptonbrisk]

Thanks for replying, Liptonbrisk.
Before I try your suggestion, I'd like to clarify that what I meant by "garbled" would better be described as "choppy". So many words dropped and missed that I only hear one word out of 6 or so. Mostly silence for several seconds, with the occasional word sounding completely normal, then more silence.

Yeah, that's usually caused by jitter, which is either ISP or QoS related. Ping spikes cause a lot of problems.
Take a look at pages 42 and 43 from download/file.php?id=2164 ("I'm getting choppy audio, what should I do" section).

If you want an easier (or more obvious) test and if you happen to have a friend or relative with Bell Fibe 500 Mbps or 1Gbps (or Telus 1Gbps, if you're out west) internet service, take your ATA over there. Try some test calls. If the problem disappears, the issue is either with your ISP or on your LAN (too many devices/apps fighting for bandwidth along with your ATA).


I suspect that your issue and mine are unrelated, but I was getting audio dropouts today on some calls involving Rogers carrier numbers. The incoming audio dropped out completely and did not return at all.
I was not dropping packets on my end.

[Erft]

I don't know anyone with a BellFibe or Telus internet. My friend, who got dead air the other day, uses Cogeco. And the problems seems to be getting worse. Today I was on the phone with someone when another call came through. I was expecting something important so I switched lines. It was the important call and the conversation suddenly went to dead air about 20 seconds in.
The problem is getting VERY bad with it being virtually impossible to have a conversation or get through, or hear from, anybody.

I am doing the test. I'm not sure how much time it takes to 200 iterations, but I'll let it run for a few minutes.
Something called ip.48.50.99.216.dsl-cust.ca.inter.net has an average of 228 (going up) and at worst is 3600 and rising. I don't know what this means as I can't see any way it's related to me. Is it?

The row of "Last" has gone over 100 but is usually between 8 and 30. I'll add another reply with the numbers when I have finished 200 pings for each server.

[Erft]

Here are the numbers. If I subtract maximum ("Wrst") from Average, I get a negative number, which would mean that jitter isn't the issue, correct?

I do apologise for the formatting: the text editor on this webpage keeps removing the spaces and justifying everything to the left. I've tried fiddling around with it and what it's at now is the best I can do. I haven't found a way to paste images into a reply. Sorry about that.

voip.freephoneline.ca
|-------------------------------------------------------------------------------------------------------------|
|--------------------------------------------------------WinMTR statistics-----------------------------|
|--------------------------------Host----------- - % | Sent | Recv | Best | Avrg | Wrst | Last |
|---------------------------------------------------------|--------|--------|--------|--------|--------|-------|
|192.168.0.1..............................................0 |..202 |...202 |.......0 |.......0 |......1 |.....0 |
|spa122.....................................................0 |..202 |...202 |.......0 |.......1 |......5 |.....1 |
|10.199.12.1 .............................................0 |..202 |...202 |.......7 |....10 |.....20 |...15 |
|No response from host........................100 |....41 |........0 |......0 |.......0 |.......0 |.....0 |
|xe-1-3-2-0-agg01-tor.teksavvy.com.........0 |..202 |...202 |.......8 |.....13 |....40 |...17 |
|ae2-0-bdr01-tor2.teksavvy.com...............0 |..202 |...202 |.....10 |.....16 |....34 |...13 |
|ae12-0-bdr01-tor.teksavvy.com...............0 |..202 |...202 |.....10 |.....14 |....38 |...18 |
|295ca.ip4.torontointernetxchange.net.....0 |..202 |...202 |.......9 |.....13 |....22 |...18 |
|ip-45.50.99.216.dsl-cust.ca.inter.net.......0 |..202 |...202 |.......9 |.....11 |....20 |....12 |
|ip-50.51.99.216.dsl-cust.ca.inter.net.......0 | 202 |...202 |.....15 |.....32 |..128 |....31 |
|ip-109.51.99.216.dsl-cust.ca.inter.net.....0 |..202 |...202 |.....10 |.....14 |...51 |.....18 |
|db.fongo.com..........................................0 |..202 |...202 |.......9 |.....13 |....20 |....17 |
|_________________________________|_____|_____|_____|_____|_____|____|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider




voip2.freephoneline.ca
|-----------------------------------------------------------------------------------------------------------------|
|..........................................................WinMTR statistics |
|..........................................-Host................ % | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------------------|--------|--------|--------|--------|--------|-------|
|.............................................192.168.0.1......0 |...201 |..201 |.......0 |......0 |.......1 |.....0 |
|....................................................spa122......0 |...201 |..201 |.......0 |......1 |.......4 |.....1 |
|.............................................10.199.12.1......0 |...201 |..201 |.......7 |......9 |.....20 |.....9 |
|..........................No response from host.....100 |.....41 |......0 |......0 | .....0 |.......0 |....0 |
|...........69-196-175-161.dsl.teksavvy.com......0 |....201 | 201 |.....9 |....13 |....47 |...12 |
|.............ae14-0-bdr01-tor2.teksavvy.com......0 |....201 | 201 |...10 |....14 |....48 |...14 |
|...............ae12-0-bdr01-tor.teksavvy.com .....0 |....201 | 201 |....11 |....15 |....52 |...14 |
|....295ca.ip4.torontointernetxchange.net .....0 |...201 | 201 |......10 |.....13 |....31 |...13 |
|.....ip-48.50.99.216.dsl-cust.ca.inter.net ......7 |....146 | 136 |.......0 |..270 | 4234 |...30 |
|......ip-47.50.99.216.dsl-cust.ca.inter.net .....0 |....201 | 201 |.....18 |....32 |...123 |...24 |
|....ip-109.51.99.216.dsl-cust.ca.inter.net .....0 |....201 | 201 |.....11 |....16 |...325 |...13 |
|.........host-162-213-111-22.static.295.ca .....0 |....201 | 201 |.....10 |....12 |....23 |....11 |
|____________________________________|_____|______|_____|____|___._|_____|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider



voip4.freephoneline.ca
|---------------------------------------------------------------------------------------------------------------------|
|.............................................................................WinMTR statistics |
|...............................................Host...................% | Sent | Recv | Best | Avrg | Wrst | Last |
|-----------------------------------------------------------------|--------|--------|--------|-------|--------|--------|
|....................................................92.168.0.1......0 |..200 |...200 |.......0 |.....0 |.......0 |......0 |
|.........................................................spa122 ......1 |.197 |...196 |.......0 |.....1 |.......3 |......1 |
|..................................................10.199.12.1.......0 |.200 |...200 |.......7 |...10 |.....18 |......8 |
|...............................No response from host....100 |....41 |.......0 |.......0 |.....0 |.......0 |......0 |
|.................69-196-175-81.dsl.teksavvy.com......0 |...200 |...200 |.......9 |...13 |.....90 |....11 |
|....................ae16-0-bdr01-tor.teksavvy.com......0 |..201 |...201 |.......9 |...13 |.....43 |....10 |
|..........295ca.ip4.torontointernetxchange.net .....0 |..200 |...200 |.......9 |...13 |.....20 |....15 |
|............ip-45.50.99.216.dsl-cust.ca.inter.net .....0 |..200 |...200 |.......9 |...12 |.....19 |....17 |
|............ip-50.51.99.216.dsl-cust.ca.inter.net .....0 ..200 |....200 |.....19 |...34 |...128 |....25 |
|..........ip-109.51.99.216.dsl-cust.ca.inter.net .....0 |..200 |...200 |.....10 |...17 |...201 |....16 |
|...............host-162-213-111-21.static.295.ca .....0 |..200 |...200 |.......9 |...12 |.....18 |....11 |
|_______________________________________|_____|_____|____|___._|_____|__.__|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider


--

[Liptonbrisk]

I don't know anyone with a BellFibe or Telus internet. My friend, who got dead air the other day, uses Cogeco.

Fibre to the house tends to me more consistent, but you could also try at your friend's place.

Something called ip.48.50.99.216.dsl-cust.ca.inter.net has an average of 228 (going up) and at worst is 3600 and rising. I don't know what this means as I can't see any way it's related to me. Is it?

This is the path or route data takes between you and FPL. Each step is a hop along the way from you down to the destination. While 3600 is horrible it is possible for a hop to simply not respond to ping requests (no response from host) or delay them. Regardless, the very last line is more important, and the results there aren't horrible. You've provided results to the proxy servers, which are responsible for SIP signalling.

However, the RTP audio stream is sent from either 208.85.218.149 or 208.85.218.150, which are the RTP IPs at the moment for FPL. I would test to those instead.

Also, you shouldn't see your second hop losing packets (results from voip4.freephoneline.ca), even if it's only 1%. That shouldn't be happening.
The proxy server that provided you with the least problems was voip.freephoneline.ca. You could try switching to it to see if it helps. I'm doubtful that it will.

I'd be more interested in your tests to 208.85.218.149 and 208.85.218.150.


I also had incoming audio become silent after 50 minutes to another Rogers number today. I think I'll inquire about this situation.

[Erft]

While I was setting up the ATA with VoIP.freephoneline.ca, and VoIP4.freephoneline.ca, when I clicked "Submit", I was immediately logged out. Second try went fine.
What is this dsl-cust.ca.inter.net? If it's an ISP, it doesn't look too reliable.

Here're the numbers you were wanting to see...


208.85.218.149
|------------------------------------------------------------------------------------------------------------------------|
|................................................................................WinMTR statistics...................................|
|......................................Host...............................% | Sent | Recv | Best | Avrg | Wrst | Last |
|--------------------------------------------------------------------|--------|--------|--------|-----.--|----.---|-------|
|192.168.0.1...........................................................0 |...201 |...201 |......0 |......0 |.......0 |.....0 |
|spa122 .................................................................0 |...201 |...201 |......0 |......1 |.......4 |.....1 |
|10.199.12.1...........................................................0 |...201 |...201 |......7 |....10 |.....19 |...10 |
|No response from host.....................................100 |.....41 |.......0 |.......0 |......0 |.......0 |.....0 |
|xe-1-3-2-0-agg01-tor.teksavvy.com......................0 |...201 |...201 |.......9 |...12 |......28 |...10 |
|ae4-0-bdr01-tor.teksavvy.com..............................0 |...201 |...201 |.....10 |...15 |......37 |...12 |
|295ca.ip4.torontointernetxchange.net..................0 |...201 |...201 |.......9 |...13 |......21 |...10 |
|ip-48.50.99.216.dsl-cust.ca.inter.net....................0 |...188 |....188 |....16 |..167 |.3576 |...22 |
|ip-3.50.99.216.dsl-cust.ca.inter.net......................0 |...194 |....194 |....16 |..109 |.3123 |...21 |
|208.85.218.149....................................................0 |...201 |....201 |....14 |....16 |.....32 |...21 |
|________________________________________|_____|____._|___._|___._|_____|____|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider


208.85.218.150
|--------------------------------------------------------------------------------------------------------------|
|....................................................................WinMTR statistics |
|.......................Host..................................% | Sent | Recv | Best | Avrg | Wrst | Last |
|----------------------------------------------------------|--------|------.--|-----.--|-------|--------|---.----|
|192.168.0.1.............................................. 0 |...200 |....200 |......0 |.....0 |.......0 |......0 |
|spa122......................................................0 |...200 |....200 |......0 |.....1 |.......5 |......1 |
|10.199.12.1...............................................0 |...200 |....200 |......7 |._10 |.....16 |....11 |
|No response from host.........................100 |......40 |.......0 | ..._.0 |....0 |.......0 |.......0 |
|69-196-175-81.dsl.teksavvy.com..............0 |...200 |....200 |....10 |...14 |.....39 |.....11 |
|ae14-0-bdr01-tor2.teksavvy.com..............0 |...200 |....200 |......9 |...14 |.....45 |.....11 |
|ae12-0-bdr01-tor.teksavvy.com................0 |...200 |....200 |....10 |...15 |...104 |.....11 |
|295ca.ip4.torontointernetxchange.net......0 |...200 |....200 |......9 |...13 |.....19 |.....10 |
|ip-48.50.99.216.dsl-cust.ca.inter.net.......11 |...137 |....122 |...14 |..120 |.4119 |.4119 |
|ip-3.50.99.216.dsl-cust.ca.inter.net...........1 |...137 |....123 |...17 |..130 |.4214 |.4214 |
|208.85.218.150.........................................0 |...200 |....200 |...13 |....14 |.....23 |.....14 |
|____________________________.______|_____|_____|___._|__.__|_____|_____|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[Liptonbrisk]

What is this dsl-cust.ca.inter.net?

https://whatismyipaddress.com/ip/216.99.50.48

Fibernetics, Freephoneline's parent company and CLEC. Calls are on Fibernetics' network.

Well, packet loss and the large ping spikes aren't good, but the last hop seems fine, which is what matters the most.

[Liptonbrisk]

While I was setting up the ATA with VoIP.freephoneline.ca, and VoIP4.freephoneline.ca

Do you have two VoIP unlock keys? Are you attempting to register the same VoIP unlock key on two separate ATA lines?

when I clicked "Submit", I was immediately logged out.

Have you tried a different ethernet cable on the back of the ATA?
You had 1 lost packet somewhere on your LAN:
|.........................................................spa122 ......1 |.197 |...196 |.......0 |.....1 |.......3 |......1 |
And then clicking "submit" shouldn't log you out.
I'm not sure why that would be happening.

[Erft]

Do you have two VoIP unlock keys? Are you attempting to register the same VoIP unlock key on two separate ATA lines?

I only have the one key.
voip.freephoneline.ca for line 1, and voip2.freephoneline.ca for line 2. "voip4.freephoneline,ca" was a typo.

Have you tried a different ethernet cable on the back of the ATA?
You had 1 lost packet somewhere on your LAN:
|.........................................................spa122 ......1 |.197 |...196 |.......0 |.....1 |.......3 |......1 |

Maybe lost packets is what's happening when I'm watching the number of pings go up and it skips a number. Like...182, 183, 184, 186...am I seeing packets getting lost? I saw that a few times each test.

I've put a different ethernet cable in.
The ethernet cable I had in there before had a broken clip (the plastic thingi that holds it in) and I had taped it onto the ATA. Seems to have worked just fine for years but I'll see what replacing it with a different cable does. This problem, though, started out small about six months ago, with getting dead air once in awhile when I called Amazon, then increased in frequency and severity until now it's a real interference in my ability to communicate. It's been really bad the last week, and really stepped up in just the last 36 hours. I've repeated the WinMTR test (up to 14 pings) with 208.85.218.149, and it skipped #12, if the skipped numbers is lost packets.

[Liptonbrisk]

Do you have two VoIP unlock keys? Are you attempting to register the same VoIP unlock key on two separate ATA lines?

I only have the one key.
voip.freephoneline.ca for line 1, and voip2.freephoneline.ca for line 2.

You can't attempt to register the same VoIP unlock key credentials on two ATA lines simultaneously and not expect problems.

When there are multiple devices/softphones/Lines (on an ATA) using the same FPL account, only the most recent registration is valid. The previously registered device (or Line, in this case) will lose registration, and, consequently, incoming calls will not ring on it. This is especially important to consider if someone else is using your SIP credentials (username and password) that are found after logging in at https://www.freephoneline.ca/showSipSettings or if you're trying to register your FPL account with a smartphone SIP app (or FPL desktop app), with another device, or more than one ATA line. Registration is required for incoming calls. It is not required for outgoing calls. Only one registration per FPL account is allowed at any time. A single line on an ATA is one registration. A SIP app is another.

Two lines on an ATA requires two VoIP unlock keys.
Either disable Line 1 or disable Line 2.
Navigate to Voice-->Line (the one you want to disable)-->General-->Line Enable
Toggle Line Enable to "no".

[Erft]

I think there has been a misunderstanding: I use voip.freephoneline.ca as proxy for line 1, and voip2.freephoneline.ca as proxy for line 2. This is how the instructions for setup say to do it so there's call waiting. At some point, I think last year, users were told they should use voip4.freephoneline.ca instead of vopip.freephoneline.ca, I forget why, so I did what the post or comment said. Now it looks like voip4 is giving me problems, so I've put it back to voip2.

[Liptonbrisk]

I think there has been a misunderstanding: I use voip.freephoneline.ca as proxy for line 1, and voip2.freephoneline.ca as proxy for line 2. This is how the instructions

What instructions?

You can't register the same VoIP unlock key credentials on two ATA lines simultaneously.

Only one registration is allowed per FPL account at any given time.
It doesn't matter how many different proxy servers are used; it won't work.

This is how the instructions for setup say to do it so there's call waiting.

No. Call waiting works with a single line registered.

By line, I mean log into your ATA and Navigate to Voice-->Line 1 and Line 2
Those are two separate lines.
Each one uses its own individual registration.

You can't use Line 1 with 15191234567 and Line 2 with 15191234567 at the same time, regardless of whether two different FPL proxy servers are used.
Only one Line will be registered at any moment.
When Line 2 makes a registration attempt and registers successfully, Line 1 will lose registration, and, consequently, incoming calls will not work on Line 1.
Eventually Line 1 will make a registration attempt (in approximately 3600 seconds), and, if successful, Line 2 will lose registration, and, consequently, incoming calls will not work on Line 2.

Also, too many registration attempts within a short period can cause you to be temporarily IP banned by FPL's proxy server.

Two ATA Lines requires 2 VoIP unlock keys.

Your ATA's setup guide is here: viewtopic.php?f=15&t=16340 (bottom of the first post). Look at page 5 of the PDF guide. Line 2 is (purposely) disabled in step 8.
If you own two VoIP unlock keys, then you can provision the second one on Line 2.

[Erft]

Line 2 is "Line Enable: No".

So I guess it didn't matter that I had voip4.freephoneline.ca as proxy...it wasn't enabled anyway.

I was referring to both the Cisco SPA122/Freephoneline set up guide and what I thought I was being told in various replies I've gotten to my posts over the years, as well as replies to other people's posts that I've read. I have no idea why I've repeatedly misunderstood. But I did. But since Line 2 is not enabled, having more than one address wouldn't have had an effect, would it?

Right now the set up is that I have replaced voip4.freephoneline.ca in Line 1 with voip.freephoneline.ca. I have replaced the ethernet cable in the back of the ATA. Line 2 was not, and is not, enabled.

Perhaps at this point I just wait and see if the problem(s) persist with the proxy and cable changes?

[Liptonbrisk]

Line 2 is "Line Enable: No".

So I guess it didn't matter that I had voip4.freephoneline.ca as proxy...it wasn't enabled anyway.

Correct

But since Line 2 is not enabled, having more than one address wouldn't have had an effect, would it?

Right

Perhaps at this point I just wait and see if the problem(s) persist with the proxy and cable changes?

Unfortunately, I don't have hope that the situation will improve. Regardless of the proxy used, the two RTP (audio stream) servers remain the same, and if there's an issue with one of them (overloaded possibly during peak call periods), then I could understand why audio dropouts occur. However, you mention "months". I haven't had a problem for months. Certainly, I've not had the problems you describe. I've had a problem this week, so I'm doubtful that the cause of our issues are the same. Possibly the ethernet cable was defective, but that seems like a long shot to me.

[Erft]

I seldom make or receive calls during peak times. These calls are usually between 12 and 5pm on weekdays.

Unfortunately, I don't have hope that the situation will improve. Regardless of the proxy used, the two RTP servers remain the same.

From what little I understand of RTP servers, that's the network protocol used by Freephoneline for transporting live data for audio. So are you saying that since Freephoneline's RTA remains the same, the situation's likely going to continue? In other words, there's nothing to be done?

If the issue has possibly been using voip4.freephoneline.ca, maybe going back to voip.freephoneline.ca will stop the problem? Do you think that's possible?

[Liptonbrisk]

I seldom make or receive calls during peak times. These calls are usually between 12 and 5pm on weekdays.

Apparently, due to the pandemic, more people are working from home now, and those can be (and sometimes often are) peak times.

In other words, there's nothing to be done?

I'd have to prove the servers are congested and then ask about it. I'm not sure I can prove that, and I'm uncertain that whatever causes your problem is similar to the one I'm experiencing because I haven't had audio dropouts for months. It just started happening recently. Another wrench in the works is that some people with Rogers numbers and services are still experiencing intermittent issues (from the huge Rogers outage that occurred recently), and I'm calling Rogers numbers when I have the audio dropouts.

If the issue has possibly been using voip4.freephoneline.ca, maybe going back to voip.freephoneline.ca will stop the problem? Do you think that's possible?

The proxy servers are used for SIP signalling. Commands are sent to communicate and initiate calls: INVITE, ACK, the registration process, etc. Those are done via the proxy servers (voip.freephoneline.ca). The proxy server understands if a call is in process, and one of FPL's RTP servers eventually sends audio packets to your ATA. We can't pick and choose the RTP servers as we can with proxy servers.

[Erft]

I wonder if anyone else has been experiencing these issues? The Rogers thing is only recent but my phoneline service has been deteriorating for months.

[Liptonbrisk]

I wonder if anyone else has been experiencing these issues? The Rogers thing is only recent but my phoneline service has been deteriorating for months.

I have access to several FPL accounts that are used somewhat regularly. I definitely have not experienced random blank incoming audio for months while I'm on calls (with Rogers numbers).
You could try connecting the ATA directly to your modem while all other devices are disconnected to see whether the issue improves (if it does you're dealing with a lack of QoS issue, or there's a problem with your router), and you could also test your ATA at friend's place.

[Erft]

Yesterday I was having terrible trouble with dead air, disconnected calls, and jitter while trying to communicate with a courier company. Then I found out that the trouble was at their end, not mine. They're still being affected by the Rogers fiasco.

After I had finished with them, I made other calls and only one had dead air after I dialed. No issues on the second try. I got a call from a friend last night and we talked for over three hours with no phone difficulties.

The problem may have been that I was using voip4. I hope it is as simple as that.

Looking back at my call logs, since the Rogers fiasco there have been quite a few calls from unknown numbers (directed to my number, registered as "Normal call clearing") that have been logged as 0:1:00 in length, but I have compared that with security footage at the time the call apparently connected, and the phone didn't ring.
Outbound calls where I get dead air are also being logged at 0:1:00 in length, when in reality they're only a few seconds. I suspect that when I am getting dead air, my outbound call has been actually directed to some "mystery" number that I have not dialed, and that that phone doesn't ring. I also think it's possible that the people with the numbers I don't recognise (that are in my call logs as "Normal call clearing") dialed and got dead air, and hung up.

[Liptonbrisk]

All call duration limits are now rounded in FPL call logs, which is a relatively recent change: viewtopic.php?f=8&t=20404&#p79878.
So, all calls will be listed as being at least 1 minute long no matter what.

[Liptonbrisk]

Yesterday I was having terrible trouble with dead air, disconnected calls, and jitter while trying to communicate with a courier company. Then I found out that the trouble was at their end, not mine. They're still being affected by the Rogers fiasco.

Yes, this is part of the reason why I’m having fits trying to figure out why I’m getting incoming dead air sometimes
(on Rogers carrier calls). I am unable to conclude, in each case, whether the problem is Rogers or FPL. Until Rogers completely fixes everything, I give up.

[Erft]

All call duration limits are now rounded in FPL call logs, which is a relatively recent change: viewtopic.php?f=8&t=20404&#p79878.
So, all calls will be listed as being at least 1 minute long no matter what.

Even the ones that don't actually reach you.

Until Rogers completely fixes everything, I give up.

I don't blame you.

[Liptonbrisk]

Even the ones that don't actually reach you.

Incoming calls either reach you or FPL's voicemail system in order for them to be listed in FPL's call logs.
Only calls that are answered in some manner are listed. You pick up, something on your phone line does, or FPL's voicemail system answers the incoming call.
FPL’s voicemail system counts as the call being answered.
If the caller hangs up before the call is answered by something, the incoming call is not listed in FPL's call logs. That's always been the case with FPL's call logs.

Call duration rounding to the nearest minute is new, but only calls that are answered being listed at https://www.freephoneline.ca/doGetCallLogs is not.
If a call is listed there you know that it has a) been answered by something, regardless of whether it’s been by FPL’s voicemail system and b) reached Fibernetics' network.
Reaching Fibernetics' network is a requirement for the call being able to reach your ATA.

If you want to check whether a most recent incoming call has reached your ATA, log into your ATA and navigate to Voice-->Information-->Last Caller Number.

If calls or ringing correspond with different numbers (that clearly aren't normal phone numbers) on your call display, such as 100, 1000, 1001, 999, (or "admin") etc., those aren't calls and won't ever be listed in FPL call logs. If you pick up, you won't hear anything. They're SIP scanners. SIP scanners are programs written by crackers (script kiddies). They look for ways to break into your home network by scanning for open ports. Typically, they'll scan for common service ports to see if they're open, such as UDP 5060, 5061 and a few others (some scan for a lot more than that). If a port is open, they can access your ATA (and, potentially, other devices on your LAN). Your phones will ring with caller IDs appearing as 1001, 999, something else that's clearly not a regular phone number, etc. These crackers will try to make free calls using your services (or much worse). That's why it's important to have a good NAT firewall in a router protecting your ATA, computers, and other devices on your LAN (local area network) and to never port forward or use DMZ. Port forwarding is a security risk. Enabling DMZ is even worse. In your SPA122 ATA, navigate to Voice-->Line 1 (or whatever Line you're using for FPL)-->SIP settings, and change SIP Port to a random number between 30000 and 60000. Do this for security reasons (to help avoid SIP Scanners/hackers). Also, this step may help to temporarily address a corrupted NAT association that's developed between a router and ATA (if you're having registration issues, try selecting a new random port number in this range, and then reboot the ATA. If that works, you were dealing with a corrupted/stale NAT association in your router). Also refer to Point A below (with respect to SIP Scanners).

And if the call happens to involve a Rogers, Fido, Chatr, or some other Rogers’ carrier number (or service, such as Zoomer, which uses Rogers’ wireless network), who knows what’s going on right now due to some Rogers’ customers still being intermittently affected by the Rogers problem that occurred earlier in July. Rogers' issues are supposed to be resolved for most of its customer base, but, clearly, they haven't been for every customer yet.



from viewtopic.php?f=8&t=20199#p78976

(Generic info)

Typically, for VoIP SIP services, especially for Freephoneline/Fongo, you want

A) a router that does not have a full cone NAT,

Visit https://dh2i.com/kbs/kbs-2961448-unders ... -punching/.
Mango from the Obitalk.com forums writes,
“Use a restricted cone NAT router, and do not use port forwarding or DMZ. Restricted cone NAT will only permit
inbound traffic from the service provider you're registered to. If you have a full cone NAT router, it will allow traffic
from any source. This is probably not what you intend.
If you have a Windows computer, you can test your router using the utility here:
http://www.dslreports.com/forum/remark,22292023. To run it, use stun stun.ekiga.net from a command prompt.”
Essentially, you download the stun-test.zip file; extract the stun.exe file from within the zip file to an easily
accessible location; use an elevated command prompt (visit
http://www.thewindowsclub.com/how-to-ru ... inistrator); change directory (cd) to the
directory or location where you extracted stun.exe (visit
http://www.digitalcitizen.life/command- ... c-commands); and type “stun stun.ekiga.net” without
the quotation marks followed by the enter/return button on your keyboard.
Asus routers, at the time of this writing, produce port restricted cone NAT routers, for example and are fine,
provided you’re using one with Asuswrt-Merlin, third party firmware installed.