How prevalent are these issues?

[Agrajag]

I'm looking for objective feedback on the following issues I've experienced during my time with ViaTalk. I'm not looking to be told that these issues don't exist or that they're unheard of. I've seen several people post these and have had several people look to solve these but they continue to come and go from time to time. If they are just inherent parts of VoIP, I'd rather know that and factor it into the equation instead of suggesting to the wife, family and friends that what some of us are experiencing are anomalies. I do believe these sorts of issues, if par for the course, will become historical issues left to the dawn of a young technology:

*Where possible I'd like to know the best guess or answer to what causes each of these. If the answer is entirely unknown, that's a concern I think we should be focusing on. Remember, I'm not saying these happen all the time but enough to be worth noting.

1. No outbound rings when calling people.

2. No inbound rings when people call me. (causing many typical callers to hang up before I answer)

3. Calls going direct to voiemail with no explanation. (Very bad as this means I can't rely on the service if it happens at key times. Several of us couldn't reach one another this past weekend for quite long periods.)

4. Mysterious phantom voicemail indicators.

5. Inability to dial out/fast busy. (Reliability again. Key issue.)

6. Dropped calls in mid-conversation.

7. Echo. Telling me that it's the other person's phone doesn't help. The other person's phone wasn't an issue with POTS. It shouldn't be an issue now with VoIP if it's truly a worthy substitute.

8. Scratchy, tinny sound.

[KLH]

I've had every single one of those issues with my cell phone.

It's just the way things are going to be. With a cell phone my singal may go down during the middle of a conservation, causing a droped call, or lost voice, or even an echo due to a low signal. Same thing with the internet and VoIP.

[Brian188]

Usually those type of issues are ISP related. Unfortunately, VoIP is NOT POTS. The quality is just not the same. For the time being anyway. I would like to think that someday it will be better than POTS, but we are by no means there yet.

[chas3]

I would also like to understand the causes of these things and what the fixes are. Hopefully someone can answer the numbered items with specific explanations as requested by Agragag. I have #1 and #2 happen at times, but not often enough to dupicate for testing. The problem is so small that I don't want to ask to get it fixed since everything else works so well.
I suspect that the problem for me might be my router dropping the first couple packets when a call is initiated.

[Agrajag]

I fully realize that VoIP is not POTS. The Bell's had more than 100 years of experience to get to where they are today. There's no way I can see that VoIP technology is just going to show up and, within a short time, catch up entirely with the experience gained by POTS providers.

That said, the service is being sold as stable and reliable. Thus, I would like to do everything possible to both facilitate evolving to that level and understanding what the issues are.

Someone has to be on top of all of these items to know what the main cause is. For example, my ISP is Comcast. I'm on a Premium service plan. Speed is not an issue at any time. I'm not on default SIP ports. All tests suggest I'm fine. Thus, what can my ISP be doing that causes this? My other friends, one on DSL, one on FiOS and one on a different Comcast plan (a bit slower) all have the same issues. That suggests to me that there's more to it than that.

I go back to my original request. I believe it would be beneficial to have a technical discussion on why VT engineers believe these things happen and if they are normal for VoIP, whether they are unsolvable, whether we just have to live with them if we suffer from it or not, etc. Ignorance here on our side isn't helping.

I believe this technology has a lot of POTENTIAL, but so far it's been limited to just that due to these issues. As a customer and a fan of the that potential, I want to be doing everything possible to help. Helping requires insight. Insight requires information.

[IronHelix]

issues 1, 2, 3, 5, 6 can be caused by ISP or connection related issues.

For your setup to work you will need (or at least i recommend) 1. sufficient bandwidth, 2. router configured to forward required ports to viatalk device, and 3. router configured with QoS controls to give priority to VoIP packets.
Also make sure that the device plugged into the modem is a generic router and not a viatalk device- many ISPs have been found to be causing funny issues when the MAC being used belongs to a competitor...

issue 4 could be caused by blocked ports, but that would make the indicator not go off, it wouldn't make the indicator randomly turn on.

You could try switching servers... that can be done from the website account manager.


issue 8 (scratchy sound) can be caused by analog phone wiring. If you are backfeeding your house wiring, make sure your NID (telco interface) is completely disconnected. Also try plugging a phone straight into the device.
Also, make sure the codec is set to be g.711 ulaw. Disable any bandwidth saver type things.

issue 7 (echo) could be related to issue 8. Make sure your device has echo cancellation turned on.

Both 7 and 8 could be due to a bad ATA. if the scratchyness occurs all the time, IE even when you have a dialtone, that's probably the case. Bad ATA could also explain the other things.


As for VoIP- VoIP as a technology works great, *BUT* its working is dependant on various pieces such as the Internet connection on all ends, what kind of PSTN connection there is, etc.

[Agrajag]

Iron,

The thing that bugs me is that resetting the adapter often will fix these "ISP-related" issues. That part suggests it's not just the ISP.

1. I get 18-20MB down. I get 740K up.
2. Ports are forwarded. In my case that means I forward UDP ports 5090-5096 (I've had reps move the ports within this range since signing on), and UDP 18384-18482 and then 19384-19482 (I have two VT lines). I've also been DMZ without any difference.
3. QOS on my D-Link DGL-4300 isn't as robust as some of the others but it's there and seems to work. I notice the issues regardless of my computing bandwidth.

I have my Linksys cable modem, then the router and the adapter is into that.

As far as #4, I've had this come and go. Recently I had a real major issue with this where every 30 minutes (or so) I'd get another one of these. I changed off of Chicago and over to NY and it went away (this time). But I've had it on an off for months. What's telling is that it happens more in the middle of the night than during the day suggesting some sort of housekeeping on the server side might be at play here. Almost never happens during normal US business hours. I find that VERY interesting. This also suggests that's why a lot of people might not know about it. It will often come on, trigger a voicemail, give you a stutter tone and then, 5 minutes later, clear itself. That's what it does 95% of the time I've seen it.

Scratchy sound for me mainly (but not entirely) cleared up when I went to the new handset-based phone and got off the wall wiring. Still want to go back to that but not until I run Cat5 all over the house.

Thanks for posting. I've told the support guys I don't envy them. I have to think that a huge percentage of their calls are for issues that are outside of their direct control and that has to be frustrating as hell.

[chas3]

I had a belkin router that worked ok with VT, but bricked it when playing with dd-wrt upgrades. So, I borrowed my son's DLINK that he got free on rebate last year. The DLINK was horrible/unusable. It was as if it rebooted every few minutes, especially if you tried to use VT, dropping calls. I replaced it with a Zyxel X-550 and everything became stable.

My view...Router and router settings can make/break the whole VOIP experience.

[connervt]

D-Link DGL-4300? As the router is optimized for gaming (ports opened and QoS), it may be placing less importance on your VOIP packets. Things I'd try are
-- making sure the router has the latest firmware;
-- testing without router; and
-- testing with a different make/model of router.

(BTW, I never have had a good experience with D-Link routers, and I've tried a few...)

[jepolito]

I haven't been a customer with Viatalk for long, but I had/have Vonage for over a year. The sad thing now that Vonage is getting hammered by Verizon, is that they improved their service tremendously over the past year(s) and is has become very realiable with very good quality.

It sounds like you have done a good deal of investigation already. I would also suggest running a voip test over your line (esp. when you notice problems). Try http://www.testyourvoip.com/

I initially had some problems with (1), but tech support changed my port range and that cleared up that problem. I experienced (7/8) recently, but so far only once. I have structured wiring/cat-5/6 in my house so I shouldn't have a problem there.

Coming from Vonage, what you are describing sounds like a lot of problems Vonage had when I first signed up. Judging from the reviews that I've seen, I had hoped that ViaTalk would be better than Vonage and certainly, I still hope since I am switching. As you've stated, VoIP is not POTS, is dependent on many downstream factors, but also is susceptible to service provider issues. If I were to *guess* you may have an ATA problem whether in HW or in provisioning since I am assuming there aren't a lot of people having the same problems as you. ViaTalk is supposed to allow you a free replacement ATA per year. You may wish to try that.




1. No outbound rings when calling people.

2. No inbound rings when people call me. (causing many typical callers to hang up before I answer)

3. Calls going direct to voiemail with no explanation. (Very bad as this means I can't rely on the service if it happens at key times. Several of us couldn't reach one another this past weekend for quite long periods.)

4. Mysterious phantom voicemail indicators.

5. Inability to dial out/fast busy. (Reliability again. Key issue.)

6. Dropped calls in mid-conversation.

7. Echo. Telling me that it's the other person's phone doesn't help. The other person's phone wasn't an issue with POTS. It shouldn't be an issue now with VoIP if it's truly a worthy substitute.

8. Scratchy, tinny sound.

[KC9FOI]

I too have had 7, 8 with VT and when I had Packet 8. Not been much of a problem with VT though. If all else fails open a ticket on it.

I have noticed 1 now and then too, but I started using the work around that I found in another post and it happens less frequently. That post suggested dialing 11 digits instead of 7.

I can't say I have experienced the others. I do notice a slight delay (2.) on some calls ringing though, but not enough to miss calls. Mostly I noticed this since I have simultaneous ring on and my cell phone sometimes goes off first.

[Agrajag]

On the router, I have several network admins in the family and have gotten all sorts of mixed responses on good/bad routers. Two of the family members swear by (not at) the newer, higher-end D-Link routers but not their cheapest stuff.

I've even seen bad stories about the Zyxel. With D-Link the DGL-4300 gets solid reviews almost everywhere (it was also $150 so it wasn't cheap crap). On the other hand I was a big Linksys fan and their stuff seems to be really suspect of late. I might pick up the Zyxel for myself to see how that goes. The issue is spending that money on a device that might make no difference what-so-ever.

On the 4300 specifically, while they call it a gaming router, they base the priority on whatever it is you tell it to base it on. It doesn't magically know what game traffic is. You give it the ports/IP and away it goes. It's a bit goofy setting up ViaTalk under what they call GameFuel but it's all the same. GameFuel isn't quite the same as QOS. With QOS you can generally say, "Give 110K to this traffic all the time". With this you tell it what IP or ports you want to monitor and you give it a priority (0 is top, 255 is least) and it will give 100% of that traffic that priority level.

I too was not a fan of D-Link prior to this one. I'd still be on my Linksys WRT54G but the wireless died and Linksys had no resolution to that.

The biggest issue that I keep pointing to that suggests this isn't my issue is that everything will be rock solid for a period, sometimes weeks at a time, and then suddenly these will materialize, sometimes alone, sometimes all at once. I also often notice other posts around this time from others having similar issues.

[chas3]

I agree, not to make a blanket statement about any brand. There are some settings that can interfere. Zyxel had one setting that before set was suspect to cause a reboot every 2 weeks. Perhaps the dlink forum can help...
http://www.dslreports.com/forum/dlink
Many threads on your router.

[Agrajag]

Thanks Chas, I am now the high bidder on a Zyxel X-550 on ebay with 2 hours to go. We'll see what happens. Another one is out there that finishes tomorrow so if I don't get this one I may try for that one too. Are you saying that the Zyxel issue is known and resolved now?

[IronHelix]

just to toss in- since Linksys started switching their products from Linux-based software to a VxWorks-based system I've heard a handful more complaints. I'm not a Linux fanboy, this is just what I hear.
Personally I recommend a Linksys WRT54GL and DD-WRT SP2 firmware, it seems to be a quite stable combo

[chas3]

The Zyxel issue was related to needing access rules set for all devices, even if the rule did nothing. This month, v1.6 firmware was released and that area of the menu has changed significantly. I am thinking it may be resolved. I just upgraded, so in a few weeks I should know.

While I am happy with the router, I still get "Blocked outgoing ICMP packet (ICMP type 3) from" my PAP2 IP to an external IP which I think is a VT related site. I have tried all sorts of changes to try to get rid of this, but have not been able. Everytime I initiate a call, I see a few log entries like this. Happy, but maybe even better if this is ever figured out. I have seen post about blocking like this for other brands as well.

[connervt]

just to toss in- since Linksys started switching their products from Linux-based software to a VxWorks-based system I've heard a handful more complaints. I'm not a Linux fanboy, this is just what I hear.
Personally I recommend a Linksys WRT54GL and DD-WRT SP2 firmware, it seems to be a quite stable combo

Linksys seems to want to compete in the D-Link and the Netgear low-level consumer market, where bottom line cost to produce per unit is more important than functionality. The V5 (and up) versions of the WRT54G just don't handle anything when there is any sort of load.

I've also had great luck with the WRT54GL (esentially a V4 version) running DD-WRT version 23 SP2. Even with a throttled back P2P client running, I've never had any problem with call quality, thanks to the QoS.

[Agrajag]

Well, here's hoping it's not a big issue as I won that auction for the Zyxel. heheh

[jepolito]

I can't say enough good things about the WRT54Gv5 running DD-WRT. It was a piece of junk with the stock vxworks and dropped connections all over the place, but once I loaded dd-wrt, the thing has been rock solid for over a year now.

[badarac]

I think that one thing you may be overlooking is that the quality of your internet connection extends beyond the size of the pipe. The amount of bandwidth required for voip is actually very small. With adequate bandwidth available you really need to look at latency, packet loss, and jitter, which will have a HUGE impact on voip call quality. Running a tool like Ping Plotter to the voip provider's server for an extended period of time may provide some insight to call quality problems. I had these same issues with my previous provider and discovered that while my latency and response time was great to the isp, it jumped substantially at certain times of the day where they connected to the backbone. Once it hops on the backbone the isp no longer has any control over it. Increased latency or packet loss at any one of the hops will cause call quality issues. In my case I was able to provide the source of the problems to my isp and they tweaked their connection to the backbone. I recommend that people perform this testing prior to signing up for voip.

As for Quality of service setting on home routers, they will generally only impact the upstream traffic. What comes in on the downstream side just gets pumped through the router.

[chas3]

Yes, agree, QoS is mainly upstream issue. When I still had POTS, I called my POTS line from my VT line. Then put the VT phone next to a radio and listened on the POTS. Ran some bandwidth tests and because I was listening on the POTS side, I would get broken audio during the upload part of the test. I tweaked my router's QoS and now get great audio both ways, even during bandwidth tests. Never had an audio problem on the download/VT side even before QoS.

[connervt]

As for Quality of service setting on home routers, they will generally only impact the upstream traffic. What comes in on the downstream side just gets pumped through the router.

Which is why people with asymmetrical connections (typically cable modem users) frequently believe that their connection is fine, as they don't hear any problem. Unfortunately, it is the person on the other side of the connection that hears all of the artifacts from low bandwidth, jitter, high latency, etc.

[Agrajag]

When I go to the testyourvoip.com I always get excellent scores. Everything is always over 4.

I'll have to try Ping Plotter and see what's up.

[gavmitchau]

7. Echo. >> def had this reported a few times since switching to VT.

[badarac]

When I go to the testyourvoip.com I always get excellent scores. Everything is always over 4.

I'll have to try Ping Plotter and see what's up.

Be sure to run Ping Plotter over an extended period of time. What you may see is that at particular times of day you start noticing problems with the connection. Ping Plotter will allow you to capture that and notice those trends over time. Usually latency and packet loss goes up right after school gets out in the afternoon and drops back off at around 11pm when people start hitting the hay for the night. My ping times to the VT servers run right around 63ms and the call quality is rock solid. In my experience when you start getting over 100ms you'll start seeing problems. YMMV

[Agrajag]

Just as an update, I spent the evening at the family member's house that I mentioned. She had just gotten her new Actiontec Gateway 704 modem/router from Verizon to replace the Westell 2200 that I was very suspect of.

We replaced the Westell and the Linksys WRT54G v6 and used just the Actiontec. Had some difficulty out of the gate but finally got it running, so far without QOS as I wasn't 100% sure about their QOS setup.

The results were dramatic. Echo on her line was evident on every single call. She heard it and the caller heard it. The first test calls came back with very little, if any, echo and that's a first. The only place I could reliably generate echo was for her to call my VT line. Doh!

So, not only was she happy to get better service, but she also managed to clear up the clutter that bugged her nearly as much as the echo.

The only impact was that now she has a symptom I had before and that's where every ring of the phone gets stuck on one distinctive ring tone regardless of who is calling.

[DracoFelis]

1. No outbound rings when calling people.
Not a problem for me, and I haven't heard of it being a problem for a lot of others. But than again, I don't work for VT, so I only hear about problems others are having, if I see a forum post on them.

2. No inbound rings when people call me. (causing many typical callers to hang up before I answer)
My guess is that most people don't have a problem with this one. However, when the problem occurs, it can often be traced back to which router the user has on their LAN and how they have that router configured. And this problem can occur with pretty much any VoIP service (not just ViaTalk's).[/quote]

BTW: The main technical issue here, is that INBOUND calls (to you) are just that "inbound data traffic". And routers/firewalls are setup to block inbound traffic that they think you didn't ask for. And while the VoIP adapters (in their "default configuration") try to tell the routers that it's OK to accept inbound VoIP traffic (i.e. that you've "asked for" that inbound call) there really isn't any universal way to do this that all routers handle equally well. So with some routers/firewall, the router will just block your inbound phone call, because it (incorrectly) determined it was an attempt to "hack you" (vs a phone call you really wanted to receive). Now, with the vast majority of routers on the market, you can override this annoying behavior, but it sometimes requires you to manually tweak the advanced settings on your router...

3. Calls going direct to voiemail with no explanation. (Very bad as this means I can't rely on the service if it happens at key times. Several of us couldn't reach one another this past weekend for quite long periods.)
Do you have a "network forwarding" number setup in ViaTalk (so that VT can send the call to a POTS line, when it can't reach your VoIP adapter for some reason)? What about any other "forwarding" option? I know the only time my calls went to VM?

While I don't know how common the problem is, everytime it's happened to me, I could explain why. For example, I once had some key calls going to VM when I wanted them, only to later find out that I had goofed (and used an "AM", instead of a "PM") in one of the time ranges for ViaTalk "Do Not Disturb". As a result of this incorrect time (I accidentally entered), VT was activating my DND settings (and therefore sending the call to VoiceMail) during the middle of the day...

4. Mysterious phantom voicemail indicators.
This is sadly the default way the PAP2 is setup. If you have your "admin password" you can override this behavior by setting the "VMWI Ring Splash Len:" setting to 0 (from it's default of 0.5).


5. Inability to dial out/fast busy. (Reliability again. Key issue.)
IMHO the usual cause of this is when you've lost "registration" for some reason (which is usually a problem with the reliability of your ISP). People with reliable ISPs should almost never experience this problem (because the problem is with your ISP either going down temporarily, or even just changing your IP address, thereby causing your "registration" to be lost).

However, if this is a problem for you, and you are "stuck" with your existing ISP, than there are some advanced adapter settings you can tweak to speed up how often the "registration" process occurs. Such tweaks don't "cure the problem" (as the problem is really with the reliability of your internet connection), but they do help raise "reliability" by shortening the time that your phone is "down" until if "fixes itself".


6. Dropped calls in mid-conversation.
Again, this doesn't seem to a big problem for most people. But if you have an "unreliable" internet connection, than it WILL happen. Because if your internet drops mid-call OR your ISP changes you to a new IP address mid-call, that will drop your call...

BTW: I've had several hour long calls on my ViaTalk line, without the call being dropped mid-call. But I did take steps to configure my router for maximum uptime with "keep alive". This was necessary in my case, because my DSL is highly "dynamic". So if I didn't take steps to keep my DSL connection up 24/7, my ISP would happily drop that connection "when it wasn't in use" and then give me a new IP address the next time I connected. And having your IP address change is one thing that will cause problems for pretty much all VoIP (not just ViaTalk). While the problem will usually be "fixed" at the next attempt (by the adapter) to "register", it could be a while before that next "register" attempt occurs (especially with the default adapter settings).


7. Echo. Telling me that it's the other person's phone doesn't help. The other person's phone wasn't an issue with POTS. It shouldn't be an issue now with VoIP if it's truly a worthy substitute.
Echo is almost always the fault of the phone equipment ON THE OTHER END OF THE CALL. What "echo" really is, is hearing some of your voice bleed through the phone equipment on the other end of the call, and come back to you (after the intrinsic delay in the call). And in the vast majority of cases, that's really a problem with cheap and/or faulty phone equipment being used by the person you are talking with (i.e. because THEY have cheap phones, YOU are the one who hears the echo)!

Now, the reason you often don't hear the echo with POTS, is that the human brain will filter out an "echo" if/when the delay in that echo is "small enough". And one (undesirable) side-effect of VoIP, is that the delay is often longer, and therefore you may hear an echo that you wouldn't have heard with a POTS line. That doesn't mean that the echo wasn't present all along, only that it's more noticeable to your mind with VoIP. If you can't live with that, then go back to POTS.

Now, that said, there are some advanced settings of the adapter that can be adjusted to better suppress whatever echo is already present on the line. Sometimes these settings help, and sometimes they don't. And even when they do help, they may lower your sound quality some in a different way. For example, a common "trade off" is that if you want/need better "echo cancellation" (which is "a good thing"), you have to put up with a slightly longer delay after one person speaks before the other person hears them (which is "a bad thing"). So the "echo cancellation" settings are in some ways a "pick your poison" type thing...


8. Scratchy, tinny sound.
Not on my line, I don't. In fact, my ViaTalk line is frequently better than my POTS line.

However, that is yet one more expected behavior if you have marginal internet reliability. So, I would really suggest you check out your internet bandwidth/latency/etc very closely. Because a number of the problem you are mentioning, are classic symptoms of your internet not being "good enough" for reliable VoIP...

[Agrajag]

Draco,

#2 What settings are you tweaking? I have all the ports that should be forwarded set to forward. I've tried it in the DMZ. No go. I also have another router on the way that's supposedly a solid one for VoIP so we'll see how that does when it gets here later this week.

#3 No, I don't have network forwarding setup. I shouldn't need it unless the service is out. If the service was out as often as this has happened I think the boards would be flooded with complaints about the down time. I can be sitting at my phone, making calls and people will call and go direct to voicemail. This can go on for hours and then magically clear up. I also have never used DND so it's not that.

#4 is not what you refer to. My setting is at 0. What I will see from time to time is that the phone will register a voicemail. It will even generate a stutter tone. 9 times out of 10 if I just wait a minute or two, it'll just clear itself. If you call in during this notification you're told you don't have any voicemail. I had a major problem with this a week ago where it was generating one of these every hour or so, especially during the middle of the night and they'd hang around until I cleared them manually the next day. I have the logs showing them being generated from the server. I switched out from Chicago and this went away. However, while this was the worst instance of this one, it wasn't the only instance of it. I've seen this one at least two dozen times but I also work strange hours depending on the project I'm on at the time.

#5 What setting shortens this loop? I'm stuck with Comcast for the time being until FiOS is here and I make that switch (I really can't wait). Halving this might make the problem invisible to me.

#6 I've had the same IP address for about 2 years now. I'll be talking and the guy on the other side will say, "Can you hear me? Are you there?" If he hangs in I find out I just dropped out for 10 seconds or so. Often people will just hang up or the situation never resolves during the call. I can go a while without this happening and I'm pretty sure it's Comcast. However, my other online activities don't skip a beat when this happens, at least not that I can see.

#7 I have a hard time with. The phones were fine for POTS. Now they're suddenly a major problem with VoIP. If so, someone needs to fess up to this and admit that VoIP is LIKELY to bring echo issues with it. It's currently made out as if the adapter is good enough that you won't notice issues like this.

On #8 all I can say is that I'm with one of the largest ISP's in the country on their fastest service plan. If it's not reliable for me, it's not reliable for millions upon millions of customers. I do have my issues with Comcast and reliable service has been one of them here and there. Perhaps I just see it more now. Again, I'll have a more first-hand experience with this if Verizon ever finishes up wiring our neighborhood for FiOS (it's all around me but not here as our cabling is all underground and the others are above ground).

By the way, just for completeness, the service has been nearly 100% for a week now. Some light noise on some calls and that's it. Of course now that I said that I expect the Gods to rain down all sorts of maladies on me.

[DracoFelis]

#2 What settings are you tweaking? I have all the ports that should be forwarded set to forward. I've tried it in the DMZ. No go. I also have another router on the way that's supposedly a solid one for VoIP so we'll see how that does when it gets here later this week.
Actually, I was rereading the post, and I think I may have mis-read your point here the first time. Are you saying that some people don't hear a "ring tone" even though your adapter is "ringing"? If so, than I mis-read you the first time, and the problem is likely on the calling telco's end (i.e. they aren't sending a "ring back" to their own customers).

OTOH if you are saying that they call, and you aren't getting a ring (and they aren't getting through), than it might be an issue with how you have your router setup. Even routers that are very good for VoIP can sometimes have problems with their firewalls closing the VoIP ports (to those calling you from the outside). That's why I find it's often more reliable if you first configure your VoIP adapter to an unchanging static "private" address ON YOUR LAN, and then setup your router to port forward the UDP SIP and RTP ports (to your VoIP adapter). That way, you eleminate any chance that it's your router blocking the inbound traffic (as you are explicitly sending all ports used for calling to your adapter), while still keeping all other ports (including the web interface for configuring the adapter) behind your router's firewall.

#3 No, I don't have network forwarding setup. I shouldn't need it unless the service is out.
You have it backwards.

Network forwarding isn't for when the service is out, it's to make sure your router always has all the needed ports open to complete a call. While some routers are pretty good at listening to the signals coming from your VoIP adapter (and using those "clues" to keep the VoIP ports open and pointed at your VoIP adapter), some routers will "close those ports" on their own. And its the router closing the VoIP ports (not the other way around) that is one possible cause of the problems you are experiencing. Because if/when the router closes those VoIP ports, than you will lose a call in progress (if you are on the phone), or you will stop being able to receive calls (until the next time the adapter "registers").

So IMHO the reason to use "port forwarding", is as "insurance" that the ports your phone call depends upon are always "open". Depending upon your router, "port forwarding" may not be needed in this situation, but it never seems to hurt (so IMHO it's "cheap insurance"). And IMHO it's also not that big of a security risk either (as you are only exposing the VoIP ports of your adapter to the general internet, and everything else, including the adapter's web interface, remains safely behind your router/firewall).


#5 What setting shortens this loop? I'm stuck with Comcast for the time being until FiOS is here and I make that switch (I really can't wait). Halving this might make the problem invisible to me.
There are 5 settings you likely want to play with, to help with more rapid "registration" when you are down:

1 of them (the most commonly known one) is on the "Line" tab, and is the "Register Expires:" setting, and controls the "normal time" the adapter goes between attempts to "register". That setting is in seconds. Since there is a compromise between registering "too often" (and thereby hammering the remote proxy) and thing "resetting themselves", I recommend setting this to around 5 minutes (give or take). Since that setting is in seconds, that would mean a value of maybe 300 seconds would be a good choice (while still causing the adapter to "try again" every few minutes).

The next two settings are on the "SIP" tab, and control the faster rate at which the adapter "tries again" (to "register") when it knows the connection is down for some reason. Again, this is a compromise (if you try every second, you will generate a huge amount of internet bandwidth during a down period), but you generally want this shorter than the time above (say, maybe 1 to 3 minutes between retries). The settings you will want (and some recommended values for them) are:

Reg Retry Intvl: 70
Reg Retry Long Intvl: 150

Finally, the last two settings (which are also on the "SIP" tab) that effect this, control the range of what "registration intervals" are accepted by the adapter. My recommendation for them is:

Reg Min Expires: 50
Reg Max Expires: 1200


#6 I've had the same IP address for about 2 years now. I'll be talking and the guy on the other side will say, "Can you hear me? Are you there?" If he hangs in I find out I just dropped out for 10 seconds or so. Often people will just hang up or the situation never resolves during the call. I can go a while without this happening and I'm pretty sure it's Comcast.
You may be right.

Some ISPs are worse than others at just "dropping packets" (i.e. temporarily loosing bandwidth). And that "can you hear me" effect is one symptom that can occur when your ISP looses data packets in the middle of a call...


#7 I have a hard time with. The phones were fine for POTS. Now they're suddenly a major problem with VoIP. If so, someone needs to fess up to this and admit that VoIP is LIKELY to bring echo issues with it.
I know it's a subtle point, but the point here is that it isn't the VoIP making the echo. Yes, it's a side-effect of the VoIP making any echo that is already present more noticable), but the echo was already present with that phone equipment.

What's happening is that there is a slight (fraction of a second) delay while VoIP converts your voice to data, transmits it over the internet, and converts it back. As a result, it's common to have an extra fraction of a second "latency" (the time between when one person talks and the other person hears them) in the call path when VoIP is used. And since our minds will filter out echoes that are "short enough" (say under 1/5 of a second), that extra delay can sometimes be enough to make an existing echo that you don't pay attention to, into one that is very annoying!

And BTW there have been a lot of people that have mentioned this as an "issue" for VoIP, so it's not like people are pretending the issue isn't there.

It's currently made out as if the adapter is good enough that you won't notice issues like this.
The adapters do have logic to try to digitally detect and digitally erase any echoes that may be present. So even if the extra latency (due to VoIP) makes a previously unnoticeable echo a problem, the adapter still can sometimes erase the echo. The trouble is, echoes are not always simple, and are frequently "distorted" (making them hard for the adapter to detect). So there are times when the "echo cancellation" just breaks down.


On #8 all I can say is that I'm with one of the largest ISP's in the country on their fastest service plan. If it's not reliable for me, it's not reliable for millions upon millions of customers.
I know you have a lot of bandwidth, but (out of curiosity) have you tested your ISP for "latency" (delay in the data path), "dropouts" (lost packets in the data path), and "jitter" (variation in speed of getting the packets to their destination)? It's been my experience that those three "internet quality" issues are much more important than raw bandwidth (assuming you have at least enough raw bandwidth for the VoIP).

Simply put, you could have tons of "bandwidth" (the speed at which you can move raw data packets), but if you are having problems with the smoothness (latency/jitter/drop-outs) of your bandwidth, you may still get lousy VoIP. And if that is what's going on, you might never notice it if you were just "surfing the web", as most things you do with a browser aren't nearly as "real time" as VoIP is!

And it's also possible that the problem isn't with your ISP, but is instead with your LAN. There is always a possibility that other things on your LAN (even "background programs", such as your computer's anti-virus updating it's signatures) are using "too much bandwidth" while you are on the phone, than you will have problems with your calls. In that case, the solution is probably a router with QoS ("Quality of Service", i.e. the ability to put your VoIP phone "at the head of the line" for any internet bandwidth it needs).


By the way, just for completeness, the service has been nearly 100% for a week now. Some light noise on some calls and that's it. Of course now that I said that I expect the Gods to rain down all sorts of maladies on me.
Glad to hear it's working better. However, that too points to a possible intermittent problem with your ISP.

Remember, ISPs do have "bad days" where they are less reliable than average. For example, my ISP has been known to have real problems "keeping a connection" during some of the more vigilant "internet worm" attacks (presumably because of all the traffic caused by the "worm" stealing bandwidth that would otherwise be used to serve "real customers" such as myself). So ISP problems really do "come and go" depending upon what is happening on the internet.

[Agrajag]

First item. I get both issues and so do the other VT users in the area. I can call someone (a non-VT customer) and I don't hear a ring (this happens maybe 5% of the time) and then they just pick up and say hello. Then, other people can call me and they don't hear a ring and then they hear me say, "Hello?" In both cases the phone IS ringing on the receiving end. It's just not being heard by the caller on the phone.

Just to be clear, my setup is that the ATA is on a static IP (192.168.1.35) and all ports are forwarded.

#3 item, we just had a terminology breakdown. You said Network Forwarding and I didn't hear "Port Forwarding" so I assumed you meant the VT feature that forwards calls when the network is down.

On the connection and testing, I'm doing for of that now (see my other thread) but the testyourvoip site consistently gives me top scores. Also, just FYI, I am using the QOS that the router provides. It's not the greatest but it does prioritize the data.

On the ISP, that's why I'm even more interested in switching to FiOS just to see exactly how it impacts the phone situation.

[Chulo]

The issue that really kills me is the incomming calls going to voicemail at random. I have 2 VOIP lines on seperate adapters- one from viatalk the other is Lingo. Both share the same internet connection, but the Lingo line NEVER misses a call (Had it since 2005). I mean 100% of incomming calls ring through. VT thinks that the two routers I have tried so far weren't compatible (tried using DMZ ect), so I ordered a Linksys spa2102 that should be comming today. I'll actually put this in front of my Lingo adapter directly to the ISP. I hope to god this works because I'm already out $100 for the router that didnt work and $70 for the 2102. :(
PS: I also get the No-Ringback issue once in a while but who cares when I'm missing phone calls lol.

[Agrajag]

Chulo, that's key info. We need answers from VT on this sort of thing. It's clearly nothing on your side of the network causing this if Lingo can get through.

I have to believe that this has something to do with the way the calls are being processed. I just hope I don't have to find this out the hard way. I too am spending a small fortune on band-aids. I went from phones I liked to phones I'm accepting (but may like over the long run). My third router is on the way. I'll be switching ISP's as soon as possible. If none of that works, the only thing left to switch is the VoIP provider.

[Chulo]

I got the 2102 yesterday and now have my configuration:
Modem--> Viatalk adapter (2102)-->Lingo Adapter-->Network.
I upgraded the firmware on the 2102 just in case it can't handle the bandwith for my network (read that somewhere). Both lines seem to work this way and I'll update with my results. I agree with you that it's odd for my Lingo to work prefectly while viatalk wouldn't- but this is the last possible solution if the problem is on my end at all. I'm jealous of my brother who saw my problems and cancelled in his 14 days. He got a 2 year deal with sunrocket and actually paid less than for VT because they didnt have activation, fees ect. Plus he can cancel w/o penalty and their adapter went in front of the router. :(

Agrajag: My sister is having the same issues as me using the Fios Actiontec MI-424 router + PAP2T (VT). According to verizon, the router streams Video On Demand for TV (4-5mb/sec) so she cant put an adapter in front of it. Does your family member with improved results with the Actiontec 704 also have the Fios TV service or just internet?

[Agrajag]

Just DSL at that location. No FiOS anywhere is sight out that way.

[DracoFelis]

I know it's coming late in this thread. But since one issue in this thread was "echo", I thought I would mentioned this other thread on these forums:
http://forums.hostrocket.com/showthread.php?t=20793

It looks like if your adapter has the "More Echo Suppression" setting (and that setting is a more recent addition to the firmware, so you might need a firmware upgrade to get to that setting), it might help some for those having persistent echo problems. Now, the best solution to echo is still to find the echo cause and eliminate it. But if that's not possible, telling your adapter to try harder to digitally erase echo, might be the next best option...

[bubbanc]

I'm having the same problems with my new Viatalk setup. Dropped calls mid-call (3 out of like 10 I've made), no dialtone (pap2 says Can't connect to login server, have to power cycle the unit to get things to work - It's done this like 4 times today, I've even tried moving the device to the DMZ and the same thing happens).

I have had Vonage for 3 years and never had a dropped call or had to physically reset the device in order to get it to register. My network is fine; I have a WRT54G w/ QoS enabled for this device. I have port triggering enabled on 5060-5062 & 10000-20000. My "testmyvoip" scores are great. I fail to see how any of this could be my or my setups fault since I have had 3 successful years with Vonage. Glad I'm still within my 14 days.

I am waiting to hear back from support regarding my issues, and to get the password to upgrade my firmware. Also, does anyone know a phone number that will just put me on-hold and play music? I need someone to call to test issues without bugging friends/family.

[Agrajag]

Call support. That's what they're there for and you'll likely be in the queue for a bit so you can use that too. If you drop off the line they won't mind. I call their number every time I want to verify that I actually have service.

[GregM]

I'm beginning to get annoyed at the echo from the outside phone. Nothing is different except that I have switched from the Motorola VT1005 and Vonage to the PAP2T and VT.

[Agrajag]

So what did Vonage do differently that's not happening here? Is it the codec? Is it the equipment?

[bubbanc]

I guess I'm going to have to call; The guy with my ticket didn't answer any of my questions (admin password for flashing, dropped calls, not registering w/ server). Instead he said I could setup a static IP if I wanted and didn't even elude that a static IP would fix any of my issues. I tried calling just now but phone support is not available now (You are first in line ... then I hear phone support is not available now and it's 8:05 here) and my account panel is not loading. This isn't looking so good.

...

I called back and got through and they changed my SIP ports since I'm on Earthlink/RR. I've also disabled dynamic routing and configured myself on newyork-2 rather than richmond. It may be closer physically, but there is definately more latency/hops to richmond than newyork - at least from my machine.

[bobfetten]

I have found over the years that VOIP quality is dependent on bandwidth (to a great extent) I just recently switched to ViaTalk from Vonage. Vonage allowed me to modify my dedicated bandwidth for VOIP. I run 2 desktops and a laptop on my Cablevision connection but really have no bandwidth issues.
I don't know how ViaTalk allows bandwidth modification (or if they do) but I find that sound quality increases with bandwidth allocation

[bubbanc]

I've had no issues in 3 days. After having my static IP configured for home, things have been as smooth as possible. I even enabled dynamic routing again and have had no issues since enabling it. I sort of think that the richmond-1 server that I was on might have been having issues (I saw a few posts about this earlier). Call quality has been excellent; Faxed my LOA from my Viatalk line with no issues (other than me getting 3 voicemails with the fax tones after sending the fax).

[GregM]

So what did Vonage do differently that's not happening here? Is it the codec? Is it the equipment?Could be. I do know that it's not me. I turned off provisioning and made some changes to my PAP2T and it seems to be working OK. I'll test some more tomorrow.

[bubbanc]

... forgot to mention that I also upgraded my firmware to 5.1.3(LS). Maybe it's all in my head, but this may have had something to do with it as well. I've heard this version is more stable than the default shipping firmware.

[Agrajag]

It's much improved. I started a while back with a PAP2T and at that point it was 2 major versions older and in such a bad state that ViaTalk support would tell you that they didn't totally feel comfortable with it. It was bad enough that I ended up getting a PAP2 from them. That worked for some time and then we found out about the PAP2T upgrades so I gave that a shot again.

In fact, I jumped through a bit of a hoop by having one VT line on the PAP2 while the other one was on the PAP2T. That way I could compare one with the other directly. It worked and shows the PAP2T to be very much as stable as the PAP2 and also more current so I've now gone back to PAP2T as my only device.

I can tell you that support had a bit of a trial with my having gone through all that which says even more about their willingness to work with customers. When most of their support people look at my account, the newer ones say, "Oh, wow, you've had a LOT of changes done to your account. Far more than most I've encountered." Such is the way of the quality assurance nutcase.

[gbpfan]

Here is my two cents worth, I am new to VT, my number just got ported from Comcast about a week ago. Before VT, I had Comcast digital voice. Never had a problem, my ISP speed were 8/2. The phone adapter was built right into the router. I have now switched to Verizon FIOS and will never return to Comcast (long Story) again. I now have 15/2 with FIOS using an Actiontec router and the linksys PAP for VT. I have not had any problems with dropped calls, scratchy tinny calls. Have not really noticed any echo. I do however have other issues:

1. I have the no ring back on many calls.
2. Long delays after dialing before ringback.
3. One day last week, I had to reset my PAP at least 8 times. Submitted a ticket and they told me to lower my router/firewall settings to none.

I have not given up on VT though, I still need to try alot of the tweaks that I am finding on this forum, just haven't had the time.

I do have to say this though, I never had to do any of this with comcast voice.

[Agrajag]

gbpfan, I feel your pain with Comcast. I cannot wait for FiOS to get here. I'm fairly certain that the HOUR I get the news that I can get it, I'll be signing up for the install. I've already starting preparing by moving to my own domain name for e-mail and web hosting.

As far as Comcast Digital Voice, I find it to be a rip-off in my view. Pay $33 for VoIP??? (and that's temporary pricing) No way. I'd rather pay Verizon $59 for POTS.

[gbpfan]

gbpfan, I feel your pain with Comcast. I cannot wait for FiOS to get here. I'm fairly certain that the HOUR I get the news that I can get it, I'll be signing up for the install. I've already starting preparing by moving to my own domain name for e-mail and web hosting.

As far as Comcast Digital Voice, I find it to be a rip-off in my view. Pay $33 for VoIP??? (and that's temporary pricing) No way. I'd rather pay Verizon $59 for POTS.

I feel the same way. I just wanted to note that when I did have it, I didn't have any of the issues I am now. I have now switched all of my services to 3 different providers, Phone is VT, ISP is Verizon, and cable tv is a local competitor of COMCRAP. I am thinking of making some bumper stickers that read "I am Comcast Free! Ask me how!" I will never be a customer of theirs again even if it means going without Television sometime in the future if I move. :)

[GregM]

That's how i feel about Qwest. Comcast has been good to me so far.

Echo is completely gone. I disabled provisioning and set the PAP2T to properly power the number of phones in my house and adjusted the input gain to -2 (having both output and input gain at -3 probably has a wierd symmetry that enhances echo).

[Agrajag]

In the, "strange things happen to VoIP" world, I have another one that just cropped up. I'm looking over at my adapter and one of my two lines (Line 2) is down. Now how does just one line go down? Both are on the same server.

Reset the adapter and they're both up again.

[Chulo]

Well it's been about a week with the 2102 using the default settings. I'm still missing calls and punching walls :eek: . What's interesting is that Lingo STILL has had no problems, even though it's behind the VT adapter now. I'm going to try changing the registration time to the settings that Dracofelis posted (I have road runner). And just for the hell of it I'm gonna get a new modem from TWC since I've had mine for a while. I'll give it another week and see how it goes before I throw in the towel.
What I can't understand is how Lingo works perfectly out of the box and VT has had nothing but problems. My sister and I have different ISP's (I have Road runner and she has Fios) but we have the same problems with calls not coming through on Viatalk. It sure looks like a VT problem to me but maybe I'm wrong and Draco's fix will work. Has anybody else had or solved these problems?

[DracoFelis]

In the, "strange things happen to VoIP" world, I have another one that just cropped up. I'm looking over at my adapter and one of my two lines (Line 2) is down. Now how does just one line go down? Both are on the same server.

Reset the adapter and they're both up again.
That is a classic problem with VoIP and the "registration" process (trust me when I say that this particular problem is not even close to being a VT only problem). Here's what's going on:

The lines may be both on the same server, but that doesn't mean that they attempt to "register" at the same time. And if/when there is a glitch in the internet during the short (a few seconds?) interval while the adapter is trying to "register", than the "registration" process will fail. And when that occurs, the line is usually "unusable" until you either reset the adapter (which forces another attempt to "register"), or until the adapter decides to try to register that line again on it's own (which can sometimes take HOURS).

Now, there is no way to perfectly get around this problem (at least none that I've found so far). And with glitches in your internet, it will be inevitable that it will happen some. But there is a treatment for this, if not a cure. With the proper set of VoIP adapter settings, you can make the adapter much more aggressive about auto-detecting when this has occurred, and trying the "register" again after a "short" interval. This won't cause the problem to go away, but the proper adapter settings can change a several hour outage into a few minute outage!

Here are the adapter settings needed to make that happen. I actually use very similar settings on my adapter, and I just love what it does for reliability (and btw I started those settings BEFORE I got VT, as that problem I describe is not just a VT problem). If you have your adapter's "admin password" (and if you don't have it by now with all your issues, I recommend you get it to help you with adjusting adapter settings), you can just make these adapter changes yourself, as long as you turn off "provisioning" (so that the VT settings push doesn't override your personal setting changes). Just be sure to save these changes and reboot the adapter once (to be sure that the adapter actually started using the new settings), and you should be "good to go" (as least on this particular issue):

Settings on each of your two "Line" tabs:

Make Call Without Reg: yes
Register Expires: 450

Settings on the SIP tab:

Reg Min Expires: 50
Reg Max Expires: 1200
Reg Retry Intvl: 66
Reg Retry Long Intvl: 150

[bubbanc]

are these settings you'd recommend for everyone, or just folks using both lines on their pap2t? Thanks for the info!

Brian

[connervt]

Use them on both lines, as each number registers independent of the other. Think of the PAP2/PAP2T as two separate devices, housed in one box...

[chas3]

Use them on both lines, as each number registers independent of the other. Think of the PAP2/PAP2T as two separate devices, housed in one box...

Would be nice if you could set different gain levels for each line. If you want to use a fax on line 2, I think a reduced gain helps the fax, but you may want voice calls on line 1 at a higher level.

[DracoFelis]

are these settings you'd recommend for everyone, or just folks using both lines on their pap2t?
My personal opinion is that they are good settings for almost everyone.

The only (minor IMHO) "down side" to those changes, is that these settings do allow the adapter to try registering more often than it otherwise would be able to do. And while the registration process (that happens when your phone is "on hook" btw, registration does NOT happen while you are talking on the phone) uses a small fraction of the bandwidth an actual call takes, it none-the-less does use a small amount of bandwidth. As a result, more frequent registration attempts could result in extra total bandwidth used (which could be an issue for someone who's ISP severely caps and/or meters their total monthly bandwidth). However, as already mentioned, the extra bandwidth from the more frequent "registration" process while measurable, is going to be a drop in the bucket compared to the bandwidth that you use everytime you are on the phone. So if you are going to be using VT service anyway, these setting will likely give you noticeably more "stable" service for very little extra bandwidth costs.

NOTE:
I haven't actually tested those settings on a VT supplied adapter, as I'm a BYOD customer. They should work fine, because tweaking those settings on my SPA-3000 works, and the majority of the adapter settings are common across the LinkSys line of adapters. So the changes I make on my SPA-3000, should in theory have the same effect on the VT supplied PAP2 (because both adapters were designed to have the same effect for identical settings). But since I'm a BYOD customer, I haven't actually tried this on a VT supplied adapter (as I never got such an adapter from VT, because I was always planning to use my own equipment with my VT phone service).

[DracoFelis]

Use them on both lines, as each number registers independent of the other. Think of the PAP2/PAP2T as two separate devices, housed in one box...
Yes and no. You will want to duplicate the two "Line" settings on both lines (as you are right that they are independent). However, don't forget the 4 settings on the SIP tab, as those 4 settings are what actually tells the adapter to "speed up when something is wrong". And there is only one set of SIP settings (that effect both lines equally).

Here's a more detailed description of how these settings work:

Settings on each of your two "Line" tabs:

Make Call Without Reg: yes
--> These two settings (one for each line), allow you to keep a "dial tone" (instead of getting a "fast busy") when the registration fails for some reason. If/when that happens, you can sometimes still make a call (if you have this setting set), even though inbound calls will not work until the next registration.

Register Expires: 450
--> Again this is a setting that is line specific (i.e. one setting for each of your two lines). It tells the adapter that your preferred registration interval is 7 1/2 minutes (i.e. 450 seconds). In my experience, this is a good compromise between setting the interval being too short (and thereby having problems resulting with too often of a registration attempt), and leaving it set too long (in which case the adapter might go for a very long period of time without realizing that the registration connection had gone down).

Settings on the SIP tab:

Reg Min Expires: 50
Reg Max Expires: 1200
--> These two settings control the range that your adapter can allow a "registration" to occur. In this case, we are telling the adapter to always wait at least 50 seconds between registration attempts (remember what I previously said about problems occurring if/when the adapter retries too quickly), but never wait more than 20 minutes (1200 seconds) even when things appear to be working well. Again, these number were carefully chosen to be IMHO a good compromise between saving bandwidth and overall stability.

Reg Retry Intvl: 66
Reg Retry Long Intvl: 150
--> And these two settings are very important. What they control, is the faster than normal registration interval that is used if/when the adapter detects that a registration failed. The values I have chosen mean that the adapter will often retry after a detected registration failure (and not all registration problems can be auto-detected by the adapter) in under 3 minutes time (which has the effect of limiting many "the line is out" problems to under 3 minutes each). However, these settings were also chosen to not be "too small", because there are bandwidth issues/problems (and in some cases even inadvertent DOS attacks) caused if you retry "too quickly". So I deliberately forced all retry attempt to be at least 66 seconds apart from each other, even if/when the proxy is down/unreachable for any reason.

Bottom line:
All of these settings (except for the "Make Call Without Reg:" setting) are a compromise between the problem of making the settings too small, and the problems of making them too big. If you make those values too small, you can actually make matters worse (as too frequent "registration" attempts can actually cause extra failures, not to mention chewing up extra bandwidth). But OTOH the default values for these settings are often too long to do a decent job of detecting and recovering from registration problems. So by carefully setting these values to a few minutes each, you get reasonably fast recovery, while still avoiding the vast majority of issues that occur from "too small" of settings!

[bubbanc]

Very nice analysis of the changes and why you changed them. I'll give them a shot as they don't really appear to have any negative impacts. Thanks again for the detail and explanations.

Brian

[chauzie]

Yes and no. You will want to duplicate the two "Line" settings on both lines (as you are right that they are independent). However, don't forget the 4 settings on the SIP tab, as those 4 settings are what actually tells the adapter to "speed up when something is wrong". And there is only one set of SIP settings (that effect both lines equally).

Here's a more detailed description of how these settings work:

Settings on each of your two "Line" tabs:

Make Call Without Reg: yes
--> These two settings (one for each line), allow you to keep a "dial tone" (instead of getting a "fast busy") when the registration fails for some reason. If/when that happens, you can sometimes still make a call (if you have this setting set), even though inbound calls will not work until the next registration.

Register Expires: 450
--> Again this is a setting that is line specific (i.e. one setting for each of your two lines). It tells the adapter that your preferred registration interval is 7 1/2 minutes (i.e. 450 seconds). In my experience, this is a good compromise between setting the interval being too short (and thereby having problems resulting with too often of a registration attempt), and leaving it set too long (in which case the adapter might go for a very long period of time without realizing that the registration connection had gone down).

Settings on the SIP tab:

Reg Min Expires: 50
Reg Max Expires: 1200
--> These two settings control the range that your adapter can allow a "registration" to occur. In this case, we are telling the adapter to always wait at least 50 seconds between registration attempts (remember what I previously said about problems occurring if/when the adapter retries too quickly), but never wait more than 20 minutes (1200 seconds) even when things appear to be working well. Again, these number were carefully chosen to be IMHO a good compromise between saving bandwidth and overall stability.

Reg Retry Intvl: 66
Reg Retry Long Intvl: 150
--> And these two settings are very important. What they control, is the faster than normal registration interval that is used if/when the adapter detects that a registration failed. The values I have chosen mean that the adapter will often retry after a detected registration failure (and not all registration problems can be auto-detected by the adapter) in under 3 minutes time (which has the effect of limiting many "the line is out" problems to under 3 minutes each). However, these settings were also chosen to not be "too small", because there are bandwidth issues/problems (and in some cases even inadvertent DOS attacks) caused if you retry "too quickly". So I deliberately forced all retry attempt to be at least 66 seconds apart from each other, even if/when the proxy is down/unreachable for any reason.

Bottom line:
All of these settings (except for the "Make Call Without Reg:" setting) are a compromise between the problem of making the settings too small, and the problems of making them too big. If you make those values too small, you can actually make matters worse (as too frequent "registration" attempts can actually cause extra failures, not to mention chewing up extra bandwidth). But OTOH the default values for these settings are often too long to do a decent job of detecting and recovering from registration problems. So by carefully setting these values to a few minutes each, you get reasonably fast recovery, while still avoiding the vast majority of issues that occur from "too small" of settings!


I'm in the US with stable net connection. My wife is in Vietnam with very shoddy connection. It's normal for her connection to drop +5 times a day. I used your suggested settings for her PAP2 and this did help A LOT. Before, her PAP2 would get dropped 3-4 times a day, drop calls were regular. Her PAP2 is behaving much better now.

However, there is a slight issue that these settings don't resolve. That is, when the PAP2 does get dropped, it is unable to re-register by itself, and power-cycling the PAP2 alone won't fix it either (strange!). Just about the only for her to get the PAP2 to re-register is to power-cycle the router-modem first (it's a one unit piece) and then power-cycle the PAP2 afterward. Do you know why this is? At this point, I don't care about the echo or dropped calls as I'm just glad to talk to her, but I was hoping that the PAP2 would be able to re-register all by itself if left alone after it has lost registration with voip proxy, but this doesn't look to be the case. Is there a way to force the PAP2 to re-register? As it stands, the "workaround" is to have my wife monitor the PAP2 whenever she walks by it and manually power-cycle it!

[connervt]

Just about the only for her to get the PAP2 to re-register is to power-cycle the router-modem first (it's a one unit piece) and then power-cycle the PAP2 afterward. Do you know why this is?

Does she have *any* Internet connectivity when this is necessary (PAP2 won't re-register with power cycle, but will when modem/router is power cycled)? My first thought is that she has no Internet connection at this point, and cycling the modem/router allows the PAP2 to communicate again to the outside world.

I feel for you, trying to troubleshoot from a few thousand miles away... :(

[DracoFelis]

Does she have *any* Internet connectivity when this is necessary (PAP2 won't re-register with power cycle, but will when modem/router is power cycled)? My first thought is that she has no Internet connection at this point, and cycling the modem/router allows the PAP2 to communicate again to the outside world.
FWIW: My guess is the same as Conner's.

The VoIP adapter settings I suggested changing can only help if/when the adapter still has internet. Now those settings can help to reestablish VoIP, if/when the internet drops for a short time (but comes back "on it's own"). And those settings can even help if/when your internet goes down but comes back with a different external/internet IP address (as might happen when your ISP uses dynamic IP addresses).

However, if someone has a modem/router with a glitch that causes the internet to go down and STAY DOWN (until the modem/router is reset), than there is really NOTHING that the VoIP adapter can do about it. Because if the VoIP adapter can't get to the internet, it really doesn't matter how much the adapter tries to reconnect, because if there isn't any internet there isn't any internet...

BTW:
Ever thought of a easy/cheap "low tech solution" to the modem/router problem? Specifically, plug the modem/router into a digital appliance timer, and set the timer to power down the modem/router for one minute/day (or maybe even one minute off several times a day).

The down side of this approach is you are actually forcing your internet down for that minute (when during the day that minute occurs, is settable by you in the appliance timer).

But the plus side, is that after that "forced down" minute, the modem/router will again get power (and therefore automatically "reset", without you having to do anything). And with any luck, the VoIP adapter should (do to the settings changes I recommended) also start to work within a few minutes of the modem/router again supplying internet service. So this is one way to force things to "reset on their own". It may not be quick or "pretty", but it does allow things to "fix themselves" without the user having to specifically do something...

[skimark]

What setting did you make to 'properly power the phones in your house'? I have looked for that setting and it isn't totally obvious to me.

Thanks

[connervt]

What setting did you make to 'properly power the phones in your house'? I have looked for that setting and it isn't totally obvious to me.


I'm not sure I understand your question, or even whom it was dirrected to...

[voxabox]

What setting did you make to 'properly power the phones in your house'? I have looked for that setting and it isn't totally obvious to me.

Thanks
FXS Port Power Limit, see http://forums.hostrocket.com/showpost.php?p=104165&postcount=3

[GregM]

Yep. I had a terrible echo when I called the house from work. I set the FXS port power limit to 5 and changed the FXS port output gain to -2 and I rarely hear any echo at all.

[gavmitchau]

interesting post. thanks for the information

[Todd D. Fuller]

Hi Guys,

I have been reading this thread and need a little help improving my upstream QoS. I have Sunrocket VoIp and have used it without many problems until just the last week.

In the last week, sometimes, and only from the 2 phones that are connected to phone jacks part of our inside phone wiring, the upstream is very choppy. And it comes and goes. The phone connected directly to the VoIP box always works well.

There are also 2 laptops in our home using the same router, one plugged in to port 2 of the Linksys WRT54G version 6, the Sunrocket gizmo is in port one, and the second laptop is used wirelessly.

I have tried changing the wireless channel in the router that hasn't help. I have upgraded the router firmware to the DD-WRT Linux based firmware.

But I have not turned on QoS or set the VoIP gizmo to a DMZ or port forwarded it.

Any suggestions to stabilize and improve upload call quality using the router will be appreciated? I am an advanced user so throw any details at me.

[firewall]

I have Sunrocket VoIp

Just a guess but maybe you should be in a Sunrocket forum?

[Agrajag]

I was thinking the same thing. What odds do I have of addressing a ViaTalk issue over on the Sunrocket forums?

[Todd D. Fuller]

I have already posted to Sunrocket forum... Same concepts apply.. Like flying a plane, there are different planes, but same stuff applies, in particular on router, QoS settings....

[chas3]

I was hours away from making the SR choice when a friend told me about VT. Maybe we can get Todd to switch and we can have a contest for the referral credit. :p

[jbo129]

Hi,
Seeing your title as Administrator, I jumped in with high expectations.
I could live with all other problems until No.3 hit me. All in-calls are going direct to voiemail with no explanation, no ringing.

"4. Mysterious phantom voicemail indicators" also happens when I transfer the line to another number.

Please read my post "BYOD Nightmare" in this forum and help us get out it.
Thanks a million.

[chas3]

4. Mysterious phantom voicemail indicators.


Agrajag, What do you mean by this? If I turn on VMWI I will get a ring splash even few hours when there is no VM, some what randomly. Did you have an issue like this? If I pick up the phone just after the ring, I will get the shutter tone, but a minute later it goes back to normal dial tone.

I would really like to use VMWI ring splash to remind me to check VM.

[Agrajag]

jbo and chas,

The phantoms have finally been put to rest. The engineers spent a day (like most of the day) looking at it and found out that my ATA was pretty strangely setup. It also appeared that my account had somehow become "crossed" with some guy in Virginia. My GUESS is that when he'd get a voicemail, I'd get a message indicator but calling VM would, of course, tell me I had none.

Once this got addressed I stopped seeing this one. It's been about two weeks since the fix. I wanted to be sure it was gone before saying anything.

Like most here I too had been having stability issues for the last two weeks or so. Things have been pretty steady of late.

I'm down to essentially three items:

1) Call quality issues from time to time

2) Fast busy on outbound calls (this happens enough that it's annoying)

3) I have an inbound caller that I am entirely unable to re-route. This is being looked at now. Their number has no "1" in it while all the others do. Seems to be the issue.

[chas3]

thanks for the update. It has been several weeks since I last tried VMWI. Given the upgrades, I will turn it on again and see what happens.

[wmmead]

#1 on your list is the only one I consistently notice, although all of them are happen occasionally. Here are a few additional things to note regarding service:

1. POTS = $50+/month, I am paying about $15/month for ViaTalk (2 years paid in advance) I guess to some extent, you get what you pay for. Since there are 3 cell phones in my house, having the reliability of POTS is just not worth the cost to me.

2. I have a friend who switched from ViaTalk to Comcast's digital voice, and although it lacks features he said the quality and consistency has been flawless. Comcast spin masters say this is because they own their own network and have more control of the service, blah blah blah. Sounds like bull to me, but really, there must be something going on to make it better. It is possible to have excellent quality VoIP service, but it is not easy. At least that is my conclusion.

3. The problem with these forums is that you have no idea how people's networks are set up etc. So complaints about quality come with no real way of getting to the bottom of the problem. I am guilty of posting messages here with issues too, but i think it is unlikely that I will get anything that will really help. There are just so many places, all along the line, starting with your handset and ending with the other person's handset, that can go wrong. It is truly amazing that it works at all.

4. My guess is that as bandwidth continues to grow, a lot of the various issues will lessen with time. Meanwhile we will all tweak our settings to try to get the best service we can.

-Bill

[taylor2767]

#1 on your list is the only one I consistently notice, although all of them are happen occasionally. Here are a few additional things to note regarding service:

1. POTS = $50+/month, I am paying about $15/month for ViaTalk (2 years paid in advance) I guess to some extent, you get what you pay for. Since there are 3 cell phones in my house, having the reliability of POTS is just not worth the cost to me.

2. I have a friend who switched from ViaTalk to Comcast's digital voice, and although it lacks features he said the quality and consistency has been flawless. Comcast spin masters say this is because they own their own network and have more control of the service, blah blah blah. Sounds like bull to me, but really, there must be something going on to make it better. It is possible to have excellent quality VoIP service, but it is not easy. At least that is my conclusion.

3. The problem with these forums is that you have no idea how people's networks are set up etc. So complaints about quality come with no real way of getting to the bottom of the problem. I am guilty of posting messages here with issues too, but i think it is unlikely that I will get anything that will really help. There are just so many places, all along the line, starting with your handset and ending with the other person's handset, that can go wrong. It is truly amazing that it works at all.

4. My guess is that as bandwidth continues to grow, a lot of the various issues will lessen with time. Meanwhile we will all tweak our settings to try to get the best service we can.

-Bill

The only issue I personally see is that if you have enough upload speed ideally around 300k or better you should in theory be able to plug the adapter in and the service should function just as POTS with very few issues. I personally don't buy the bandwidth issue. If thats the case move some of the bandwidth over from your hosting service.

[Agrajag]

Cable has been proven to be better due to the architecture of their network. I forget the acronym that's used but it provides for better, more reliable service. They also keep it all outside your personal network so they avoid all the router issues and such.

I'm just aghast that people would pay Comcast $57 a month for VoIP with LIMITED features when they can pay the phone company $59 a month for unlimited POTS with similar features. Makes NO sense to me. Even at the $33 temporary deal, it's still more than 3 times what I pay for ViaTalk. Stability for a POTS line is no longer worth that price to me.

The VT line is stable enough for >$10 a month. When VT starts pushing me to $15 a month then I need to start thinking about it again.

[Chulo]

From what I understand, TWC will give you a separate IP for VoIP so it doesn’t count towards bandwidth used. They also currently prioritize voip packets on their network (according to them it applies to competing VoIP also once it hits their network).

[Heat305]

From what I understand, TWC will give you a separate IP for VoIP so it doesn’t count towards bandwidth used. They also currently prioritize voip packets on their network (according to them it applies to competing VoIP also once it hits their network).

I hope this is how it's done in my case since I have TWC. Only reason I left TWC was because they don't give you some type of control over your features. The only thing you can do online is view your call logs. Nothing more. If they had something like VT I would of never left even with the price they charge.