Sound Cuts Out for Half a Second Randomly

[samcro]

I noticed that the 1/2 second sound drop off is when I talk with others on FPL. I have some friends with ported numbers to FPL. It does not happen when I talk with others on regular phones (bell, cell etc.). It started after the last upgrade.
I am in Windsor

[andyha]

Is there any progress being made on this issue?

[andyha]

Believe me I am NO expert on voip, but after a weekend of trial and error I have found a way to eliminate the dropoffs. I can't say it will work for everyone but it's working great for me so far. I have been testing for the last 4 hours and haven't had one dropoff. Hopefully it will stay that way. I have also noticed that the lag seems to have improved quite noticeably. Do this at your own risk, I cannot be responsible if you brick your router! This is what I did:

First I downloaded and flashed my WRT54GL router with the Generic Voip firmware from the dd-WRT website. You can get that here
http://www.dd-wrt.com/site/support/router-database

logged into my router (WRT54GL) and under services>services> DHCP server I set the MAC address and IP of my PAP2T ATA as a static lease.

Then I did this:
http://wiki.milkfish.org/index.php?n=Mi ... figuration read the instructions VERY carefully.

Here is a good article on QoS settings. I followed this article pretty closely. Pretty well everything below is in this article.
http://bec-systems.com/site/264/implent ... sys-router

Next I did this:
Under QoS settings, I enabled QoS , and set 90% upload and download limits for WAN. You can get those here http://www.speedtest.net/index.php remember to convert them from megabits to kilobits. here is a calculator: http://www.easycalculation.com/bandwidth-calculator.php

Under Service Priority I added sip and made it premium. I also added bitorrent and made it bulk.
Under Netmask Priority I added my PAP2T's IP address in this format 192.168.1.***/32 and set that to premium.

I also forwarded UDP port 5060, 5061, 6060, 6061, 53 and 69 to the IP of my PAP2T ATA.

On my PAP2T ATA I logged in and changed to admin login, and switch to advanced view.

Under Line 1, Proxy and Registration I set proxy to 208.65.240.142
Outbound proxy to 192.168.1.1 [the address of my router] Register=yes, Register Expires=180 Use Outbound Proxy=yes

I set the codec to G711U.

I rebooted everything and voila. No more dropoffs! at least today so far!

[cp24isgoodnews]

when did it initially start working, meaning what exact setting then made your calls work correctly because to me it seems to be only on thing thats causing the issue

[cp24isgoodnews]

one more thing if possible, so you have no drop offs can you confirm via your voip's home page and view your lost packets, lets say make a call for 10min or so and refresh the page every so often and see if you have any dropped packets because at this point i have set it up your way and to no avil im still having issues

[andyha]

when did it initially start working, meaning what exact setting then made your calls work correctly because to me it seems to be only on thing thats causing the issue

Yeah that's a good question. I just was having some trouble with FPL registering with my PAP2T ATA, so I disabled the Milkfish setup and put my outgoing proxy setting to no. And I am still getting no dropoffs! So it could merely be the QoS settings. Or it could be none of any of it. It could be a light traffic day or FPL could have done something. I really don't know what is going on but I do know that my dropoffs are gone right now and as I stated before there seems to be less lag too.

[andyha]

I discovered that my PAP2 was not registering because I was using the IP address 208.65.240.142. When I changed it to voip.freephoneline.ca, it started registering again. Something to do with DNS I suppose. So I enabled the Milkfish settings and all is good again. I definitely think the Milkfish thing is helping the voice quality. I just had an 18 minute convo and there was only twice where the other person was a little garbled for half a second. other than that I didn't notice any of the classic dropoffs that I was having before doing all this configuration and the lag is definitely better than it was. Until FPL permanently fixes this issue, I am doing what I can to make it as good as possible for right now. Good luck to you all.

[laurent]

Well it's been said many times, QoS is a vital part of a good VoIP system.

The past week we've had phones calls for 70 minutes, 22 minutes, 37 minutes, all without a single hiccup in the voice.

There's much more than ticking "Enable" for proper QoS to work. Setting proper upstream and downstream real-life-calculated limits is very important, and proving that the proper data packets are flagged as high priority and moving in front of everything else is too.

Btw the bandwidth calculator is fine, but you must measure the actual capacity of the line with a few tests, not just take the ISP's word for it. Lines are often slower than advertised...

Who else in this thread is having *NO* problem with this? Do you have QoS implemented at the router?

[andyha]

Just a quick update. I must have had a lucky weekend!...and no I don't mean "that" kind of lucky! This morning I noticed that I am getting dropoffs once again. So although the overall quality of my calls is better and the latency is improved with thQoS and Milkfish settings, the dropoff problem is still there. Hopefully something is going to be done soon about this...as you can probably tell it's driving me CRAZY! as well as probably a lot of others too.

[magicray]

Everybody can jump up and down saying they think they fixed the problem from their end but thats not the case. The problem is from FREEPHONELINE itself "PERIOD".
I have other voip lines on my DSL and cable lines and no hiccups EVER but with freephoneline every few minutes or every few seconds a cut off of sound. DONE.

[FONGO_kris]

magicray, the issue is not so much something broken on our end, our server simply isn't handling NAT and RTP proxy the way it should; this can be solved on the users end, yes. However that is for that user only while we are trying to get a global, permanent fix in place that a) works, and b) makes everyone happy!

[magicray]

Thanks for replying back with some hint of what's going on. This case of NAT and RTP proxy can probably be the cause, but do you have a solution or any thoughts we can implement from our end to remedy the problem?
i'm going to connect freephoneline to webbased pbx (e.g. voxalot) and see if I get any different results.

magicray, the issue is not so much something broken on our end, our server simply isn't handling NAT and RTP proxy the way it should; this can be solved on the users end, yes. However that is for that user only while we are trying to get a global, permanent fix in place that a) works, and b) makes everyone happy!

[magicray]

oright setup freephoneline as a trunk with pbxes.com and my ata connected as an extension. Lets see if the test passes tomorrow (wife test).

cheers.

[andyha]

Well, I am starting to get very agitated at this dropoff issue. I paid for my config file 8 days ago, and I see this thread started on the 2nd of November. What is happening here? Do you guys know what you are doing over there at FPL?? Surely it couldn't be THAT hard to figure this thing out?? I mean I realize that FPL is good deal and all, but really. COME ON!! We have all paid our money and the service is not happening. I am waiting to port over my number but won't do that until this problem is fixed. Steve, can you please tell us where you are at with this. I mean you posted that you won't sleep until this problem is fixed, that was 8 days ago! You must be pretty tired by now! But seriously I am extremely frustrated at how long this is taking. Maybe you should get a voip expert in there and pay him to solve this thing.

Big time annoyed

Andy

[FONGO_steve]

Andy
We are working as hard as we can on this and running several tests with several users here in the forum who are helping us.

As I've already explained earlier in this thread, the fact that this problem isn't happening for everyone does make it increasingly difficult to isolate what the problem is.

I've run into a case where two different users are on the same ISP, both have the same D-Link router and the same Linksys ATA - both can call the same destination - one has drops, the other does not. This does not appear to be a problem at all with our VOIP server, but a problem downstream from us. It could be a carrier used to connect the calls, or it could be something with the bandwidth carriers along the way. We are trying our absolute hardest to solve this, but when it may not be a problem that even falls on our own network, we have to identify where it does fall in order to get the appropriate parties involved. Until we can present justifiable evidence of where the problem is, we can't get the appropriate parties involved to fix it.

We are doing more testing again this afternoon, and will update here as this progresses.

[cp24isgoodnews]

Andy
We are working as hard as we can on this and running several tests with several users here in the forum who are helping us.

As I've already explained earlier in this thread, the fact that this problem isn't happening for everyone does make it increasingly difficult to isolate what the problem is.

I've run into a case where two different users are on the same ISP, both have the same D-Link router and the same Linksys ATA - both can call the same destination - one has drops, the other does not. This does not appear to be a problem at all with our VOIP server, but a problem downstream from us. It could be a carrier used to connect the calls, or it could be something with the bandwidth carriers along the way. We are trying our absolute hardest to solve this, but when it may not be a problem that even falls on our own network, we have to identify where it does fall in order to get the appropriate parties involved. Until we can present justifiable evidence of where the problem is, we can't get the appropriate parties involved to fix it.

We are doing more testing again this afternoon, and will update here as this progresses.

Again everyone has to understand that the solution isn't just a click of a button from Steve's end, if where then he would have defiantly pushed it by now, but like Steve said there are multiple factors here, that can't be "All" tested

[laurent]

Unfortunately for us, a VoIP provider isn't like "the phone company". When your phone doesn't work, you call the phone company. They send a phone technician that checks the phone wire from your house all the way to the phone central. He might have to drive there with his phone truck. Everything is owned and controlled by the same company, it's clean, simple, takes little time to diagnose and fix.

With VoIP, the company (FPL) controls only a teeny-tiny part of the whole system, which is their phone server. Everything else, from the internet link (many companies), the link (dsl, cable, whatnot?), the consumer's router equipment, the consumer's ATA, the phones themselves, the link to other phone companies systems, it's all OUT of the reach of FreePhoneLine.

So we must really take a cup of chamomile tea and relax a bit. There is a problem, the company ackowledged it and are stating that they're working on it. It's a tough, intermittent, hard to track one so it'S not like they can just order a new cisco router and presto, problem solved.

[cp24isgoodnews]

Unfortunately for us, a VoIP provider isn't like "the phone company". When your phone doesn't work, you call the phone company. They send a phone technician that checks the phone wire from your house all the way to the phone central. He might have to drive there with his phone truck. Everything is owned and controlled by the same company, it's clean, simple, takes little time to diagnose and fix.

With VoIP, the company (FPL) controls only a teeny-tiny part of the whole system, which is their phone server. Everything else, from the internet link (many companies), the link (dsl, cable, whatnot?), the consumer's router equipment, the consumer's ATA, the phones themselves, the link to other phone companies systems, it's all OUT of the reach of FreePhoneLine.

So we must really take a cup of chamomile tea and relax a bit. There is a problem, the company ackowledged it and are stating that they're working on it. It's a tough, intermittent, hard to track one so it'S not like they can just order a new cisco router and presto, problem solved.

I completely agree here

[andyha]

Well, right now the dropoffs are so bad for me that the phone is basically unusable. I was forwarding to FPL from my other voip provider to test this service and today I have reconfigured my router to use my original voip service. So I paid 56 bucks and am not getting anything for it. I am not ready to pull the plug just yet, I'll wait and see for the next little while what happens. But I think it's pretty bush league to advertise a service, no matter what the cost is, and it be second rate. I mean maybe FPL should change their advertising to something a little more truthful like:

"Only 50 dollars for your config file, and you will never pay another phone bill for the rest of your life! As long as you don't mind a phone that will constantly cutout and conversations that are full of "what was that?""could you say that again", "you keep cutting out".

Even the magicjack has better quality than FPL right now....very disappointing.

I get that this is voip and it gets complicated, but how do the VAST myriad of other voip companies manage, well the ones I have used in the past and presently too never had this dropoff problem. You know you just get sick of excuses and long winded descriptions of how complicated the problems are. Just get'er done man! If I ran my business like this....I wouldn't have a business!

Just checked the cupboard, and it looks like I'm flat out of Chamomile tea!

[yyzyyz]

magicray, the issue is not so much something broken on our end, our server simply isn't handling NAT and RTP proxy the way it should;

Doesn't it mean something *is* broken on your end?

this can be solved on the users end, yes. However that is for that user only while we are trying to get a global, permanent fix in place that a) works, and b) makes everyone happy!

How about sharing some technical details on the client-end fix? We could try that out to see if it helps alleviate the problem while a permanent solution is being worked out...

[FONGO_kris]

magicray, the issue is not so much something broken on our end, our server simply isn't handling NAT and RTP proxy the way it should;

Doesn't it mean something *is* broken on your end?

I do admit that was poorly worded; however, by broken I assume magicray is referring to something that cannot be fixed or needs to be replaced on our end, while in actuality it is an incompatibility _somewhere_. As Steve has said, this issue has not yet been 1500% determined to be with us, the carrier, it is simply the common factor here as are such things with many customers as their ISP, hardware, etc...

this can be solved on the users end, yes. However that is for that user only while we are trying to get a global, permanent fix in place that a) works, and b) makes everyone happy!

How about sharing some technical details on the client-end fix? We could try that out to see if it helps alleviate the problem while a permanent solution is being worked out...

These details of the client-end fix would of course have to be sought out via questioning those who have it working here on this board. Until a resolution is met (with open arms I might add...), you can understand the vast amount of variables that must be filtered out in order to isolate and troubleshoot properly. We ourselves at freephoneline have not been able to duplicate the issues experience, which may or may not be attributed to ourselves being the carrier which is why we're looking for outside input and testing - hence the 7 page thread

[tbrummell]

Rogers 10/1 service + WRT56G w/ Tomato & QoS configured + Asterisk + jitter buffer + IP hard phones = no drop outs.....*ever*.

Rogers 10/1 service + WRT56G w/ Tomato & QoS configured + Asterisk + jitter buffer + PAP2TNA = intermittent drop outs. No where close to what other people experience though. Maybe once, twice every few calls. It's usually very early in the call, I attribute it to the jitter buffer starting to kick in, because after 20 seconds in to a call it settles right down.


No matter how much I try and saturate my I'net link I'm not able to trip up my FPL connection. It's unfortunate that the problem can't be nailed easily because when the service works properly, it's awesome. Thanks FPL!

[cp24isgoodnews]

Ok question for users that having a working setup, besides hard ip phone users, is anyone using any other voip devices not having an issue whether it be from linksys or grand-stream who is not having issues ? the reason I ask is because everyone seems to be having issues only with the Linksys PAP-2 and im debating purchasing another voip-unit to test and to see if thats the issue itself (and yes i do have QoS and ports forwarded and a DMZ setup to ensure traffic goes out correctly) any input would be much appreciated

[brentw]

When this first started I ordered a GrandStream HT502 because I just wanted the issue solved.
It didn't help, the GrandStream actually appeared to be worse than my PAP2T....

I wish that was a fix...it would have been easy.

And yes I have done testing with both devices connected directly to the modem, same issue.
And also on 4 different types of connections, all behaved the same.
Even a 10meg business fibre line that runs 20 voip lines without issue...that was idle at the time of my test with FPL...and it still happened.

So really I don't know what we can do on our end at all.
Hopefully FPL can find the issues in the path to their connection and work to get them resolved.

[ekster]

Ok question for users that having a working setup, besides hard ip phone users, is anyone using any other voip devices not having an issue whether it be from linksys or grand-stream who is not having issues ? the reason I ask is because everyone seems to be having issues only with the Linksys PAP-2 and im debating purchasing another voip-unit to test and to see if thats the issue itself (and yes i do have QoS and ports forwarded and a DMZ setup to ensure traffic goes out correctly) any input would be much appreciated

I use the pap2t ATA and have no problems at all. I do not think it's the device.