Initial Ping Plotter Results and Concerns

[Agrajag]

Okay, in another thread someone mentioned using Ping Plotter to identify issues.

I downloaded it and pointed it to my current VT server "newyork-2.vtnoc.net"

Here are the highlights:

There are 14 hops.

The first one is my router IP 192.168.1.1

The second one shows no information at all except that it is showing a 100% packet loss all the time. Any ideas what this is?

Hop 6 is problematic. It's a Comcast server 68.86.210.178 and is showing a steady 30% packet loss.

Hop 8 acts up here and there at 68.86.90.37 and is currently a 40% packet loss but this has gone in and out.

Except for my router every other hop shows Jitter in red. Jitter is at a low of 0.56 and a high in the 50's at times.

The round trip shows 13, 12, 1.11 (avg, cur, jttr)

What does this tell me?

[connervt]

Comcast, or former Adelphia customer? Either way, you may be going through some of Adelphia's former equipment, which filters/drops ICPM packets. You may want to look over this FAQ entry for some info of what may be going on:

http://www.dslreports.com/faq/8766

[Agrajag]

Comcast in South Jersey. Adelphia was never here. We are close though and as per the link you sent, Ping doesn't show any lost packets.

[DracoFelis]

The second one shows no information at all except that it is showing a 100% packet loss all the time. Any ideas what this is?
This happens all the time at some internet locations, and is nothing to worry about.

What is going on, is that some firewalls (that you ISP may be using) block the ICMP packets that tracert (and ping plotter) depends upon. As a result, it looks to tracert (or ping plotter) as if all the packets are being dropped (when in fact some packets are going through, but the info of that fact isn't being sent back to you). So as long as you can get to the next hop (which apparently you can), this is nothing to worrry about. It's a minor inconvenience (as the ISP is blocking you from diagnosing that specific internet node), but it doesn't necessarily mean anything is "wrong".

Hop 6 is problematic. It's a Comcast server 68.86.210.178 and is showing a steady 30% packet loss.
Ouch! That's where your problem is!!!

Your options now are to either:

1) You could try to submit a "trouble ticket" to Comcast, letting them know that router is dropping a lot of packets. That may work to get them to "fix" the problem, or it may be a "lots of luck" type situation (since I don't have Comcast as an ISP, I don't know how responsive they are to such "internet problem" requests).

The "good news", is that DNS shows 68.86.210.178 as a Comcast owned router (specifically: po-20-ar01.audubon.nj.panjde.comcast.net ), so Comcast would at least be in a position to do something about the problem. If they will do anything (vs "blowing you off") I don't know, but it is their router that has the problem, so they at least could "fix the problem" if they wanted to!

or 2) Try to tracert (or ping plotter) to the other ViaTalk servers, and see if any of them avoid the problem router/node. If you can find a ViaTalk server that is reachable from you without going through any problem nodes" (such as the 68.86.210.178 node that has the 30% packet loss) than you could just change your ViaTalk service over to using that other server (thereby "routing around the problem"). Personally, I think the "use a different VT server" (that avoids the problem Comcast router) may very well be "the path of least resistance" (as you just make the changes yourself, instead of trying to convince your ISP that there is a problem they should fix)!

Of course, due to the variable nature of the internet, there is no guarantee that you won't go through a "bad node" on the internet even if/when you manage to "fix things" for now. But the point is, that you now have the tools to test if that's what's causing the problem. Because if/when "ping plotter" (or other similar internet diagnostic tools) show the internet path isn't smooth and reliable, than you will notice the problems with your VoIP!


Hop 8 acts up here and there at 68.86.90.37 and is currently a 40% packet loss but this has gone in and out.
Routers that have packet loss going "in and out" are frequently ones that are overworked "some of the time" (depending upon what other traffic that router is dealing with at the time). Again, you will want to avoid that router hop if you can manage it (for example, by picking a different VT server to use).


Except for my router every other hop shows Jitter in red. Jitter is at a low of 0.56 and a high in the 50's at times.
Ouch! Another ISP issue (and it wouldn't surprise me if the jitter was mostly from those two problem routers in your call path). Jitter (such as you are experiencing) that goes all over the place, is a death sentence for any sensitive "real time" internet traffic (including VoIP). :(

NOTE: There is a "jitter buffer" built into the VoIP adapters, that you can adjust the size of (to compensate for different levels of jitter by your ISP). Given your huge jitter, I suggest immediately setting your adapter's jitter buffer to the highest possible buffer setting (i.e. set "Network Jitter Level:" to "very high"). Given as much jitter as you sometimes get, this is likely still not enough to eliminate dropouts from your VoIP. But by setting your buffer to the highest possible value, you at least raise your chances of the jitter buffer dealing with the issue. Although, sadly, increasing your jitter buffer will also automatically increase the latency/delay in your voice. So raising the jitter buffer is clearly a trade-off, but IMHO the dropouts from having your buffer "too small" are more of a problem than dealing with a little voice latency/delay...

[Agrajag]

Thanks Draco... This is the sort of information and discussion I was looking to have. More information is better than guessing. <grin>

I have always been of the feeling that Comcast is a typical "brand" solution. They charge more and give you less.

BTW, I recall having a great experience while connected to Richmond. Is there a list of the actual VT servers? I did a search and couldn't come up with them.

[connervt]

newyork-1.vtnoc.net - 216.246.50.94
newyork-2.vtnoc.net - 64.118.82.164
houston-1.vtnoc.net - 209.85.6.12
houston-2.vtnoc.net - 67.15.74.4
sanjose-1.vtnoc.net = SF-1
sanfrancisco-1.vtnoc.net - 66.225.245.186
richmond-1.vtnoc.net - 216.246.37.202
chicago-1.vtnoc.net - 216.246.50.94

[badarac]

I'm probably the poster that turned you on to Ping Plotter. It's not unusual to see packet loss on the intermediate hops. I would only be concerned about packet loss if you see it beginning at a particular hop and continuing to the end point. Packets lost from one point to the end point would indicate that the packets really are being lost.

Your latency doesn't seem to be an issue to me. Latency on my DSL connection is typically 63ms. Most of that is due to my ISP turning on interleaving for the DSL connection. As a result my latency to the ISP is 36ms. Your problem seems to be related to jitter and setting the jitter buffer to a higher setting may help without having a huge impact on latency. You've got a lot of room in the latency department before it starts impacting call quality.

Try capturing the ping plotter data over extended periods of time and save the reports to disk. You can provide this to your ISP to help identify the problem. You'll need to get well past level one support to have an intelligent conversation with your ISP though.

Hope this all helps.

[DracoFelis]

I'm probably the poster that turned you on to Ping Plotter. It's not unusual to see packet loss on the intermediate hops. I would only be concerned about packet loss if you see it beginning at a particular hop and continuing to the end point. Packets lost from one point to the end point would indicate that the packets really are being lost.
Doh! I should have known that.

I guess I was just zeroing in on the 30%+ packet loss, and seeing that as "a bad thing", while forgetting that the real issue is how well do the packets get to/from one end to the other end. i.e. I was forgetting that there are things that can make these tools think that there is packet loss at one node/hop, but if that packet loss is real than it should also show up when reaching further along that path...

Your latency doesn't seem to be an issue to me. Latency on my DSL connection is typically 63ms.
And it seems like I totally misread that one too. Somewhere in the back of my mind I was thinking the 50 (presented without any scale mentioned) was the number in seconds, which would have been a HUGE amount (I know, what was I thinking?).

Yes, 50ms isn't overly long. However, the OP did mention 0.5 to 50 was the latency. And a 49.5ms "jitter" is moderately high (not extremely high, but on the higher end of acceptable). So it would still probably be useful for the OP to play with the size of the adapter's jitter buffer.

[GregM]

I figured I would do a tracert on my Comcast service just to see what you guys were talking about. What a mess. My PAP2T shows newyork-1.vtnoc.net. For some reason this address is being resolved by DNS to chicago-3.vtnoc.net [216.246.88.130]. My traffic went from Denver, to San Francisco, to San Jose, to Los Angeles, to Atlanta, and finally to Chicago. That's what I'd call the scenic route.:eek:

My best performance with the fewest hops is to San Francisco. Which server location in the control panel corresponds with San Francisco?

[connervt]

"North West US"

[badarac]

Ain't networking fun! :D

VoIP is either gonna make everybody crazy or spawn a whole generation of networking experts. I wonder if people needed to get this involved in the technology when regular telephone service was introduced. :eek: :rolleyes:

[connervt]

Comcast has some interesting routing --

For me in Vemont, newyork-2.vtnoc.net goes down to Boston, then to NYC.

newyork-1.vtnoc.net heads straight down to NYC, jumps on a Level 3 backbone to Chicago, then back to NYC.

chicago-1.vtnoc.net and richmond-1.vtnoc.net do the same (NYC to Chicago), but the number of hops and latency aren't any better than the newyork-2.vtnoc.net gives me.

As the latency for all four of these are around 40-50 each way, for me, the choice is the one that has the least number of hops, as each router has the potential of going 'bad'. Less is better.

Of course, each person's situation is different, and routing can always change. As with most things, YMMV...

[GregM]

"North West US"
I was originally setup with "North West US" and that is what is giving me the newyork-1 server. I'm now sitting with my computers in my home office next to the PAP2T and am trying the different control panel settings. Selecting "South West US" and resetting the PAP2T gives me the sanfrancisco-1 server.

I think I'll stick with this setting for now. The pre-provisioned newyork-1 was taking 22 hops and crossing the entire CONUS. sanfrancisco-1 is much quicker and only 15 hops. I agree with connervt, less is better.;)

[connervt]

Sorry, I didn't realize that they moved NYC to the north west coast of the USA. :D

I no longer use the "dynamic server" function, as now I'm BYOD. I would of though that San Fran was a little closer to the Pacific NW...

[GregM]

Now you know why I was asking the question.:D

[DracoFelis]

Comcast has some interesting routing --

For me in Vemont, newyork-2.vtnoc.net goes down to Boston, then to NYC.

newyork-1.vtnoc.net heads straight down to NYC, jumps on a Level 3 backbone to Chicago, then back to NYC.
Enough to make you ask "What were they thinking?", isn't it?

Actually what's going on, is that many internet connections involve 2 or more ISPs in the mix (i.e. it's frequently the case that the ISP you are using is not the one being used by the place you are trying to communicate with). And the handoff from one ISP to another can only occur in those locations where both ISPs are present (which are known as "peering points" in the industry). And while in theory you can have a "peering point" anywhere two ISPs agree to have them, in practice a lot of ISPs do most of their "peering" at just a few places scattered around the country (where many ISPs have agreed to provide equipment to do the "peering"). Which is why you often see traffic go "in the wrong direction" just to come back to where it is really headed. What's often happening in that case, is that one ISP realizes the traffic is really for a different ISP, and therefore is sending the traffic to a major peering point/hub that is "close to them", in order to hand the traffic over to the other ISP. And remember "close" is relative here, as there are not that many major peering hubs in the country, so "close" could still easily mean going a few states over in the wrong direction...

BTW:
You will often find traffic going through Chicago, as Chicago has a MAJOR peering point/hub for the internet (and Chicago also has several lessor peering hubs that interconnect with the main/big peering hub). As a result, it's actually pretty common for traffic to head to Chicago in order to be handed off to another ISP (before being routed to it's actual location).

In fact, I know (from doing various route tracing) that my ISP is one of many ISPs that likes using the Chicago peering point/hub. Which is why I found that I got the best possible results when I used ViaTalk's Chicago server (as ViaTalk's Chicago server seems to be only about 5ms off from the main Chicago peering point)! However, you really do have to trace the network path (with something like "ping plotter" or even the "tracert" command) to know how good a path any given VT server is from you. So this is clearly a YMMV thing. It's just that in my case, my ISP often sends me to the Chicago peering point first anyway, so going with the VT server in Chicago makes a lot of sense for me!

[Agrajag]

Is there anything out there that can give us an accurate picture of of the datapath as it will be experienced by the voice data? If Tracert and Ping Plotter are going to run into the Comcast ICMP issues, etc., what out there would show a clean view of it?

By the way, service continues to be solid this week so far, though nearly everyone I ask comments on echo, WHEN ASKED. Most haven't mentioned it and I'm starting to think they're trying to be nice. The problem there is obvious. I can't be telling everyone who calls to buy a better phone. I also wish I could re-route the data to my PC and have some sort of major echo canceling app on the PC that cleans up the data for the adapter (which I have to assume has limited ability to handle this.

Oh, I also found the default jitter settings to be pretty aggressive already! Network Jitter Level is set to "High". Jitter Adjustment Buffer is set to "Up and Down", whatever that means.

One other thing has occurred to me. It's a pity it's not easier to sample the various providers. I'd love to be able to call up say, Voice Pulse and say, "Look, let me try yours for a month or even a week. If it's better, I'll switch." I have two lines with VT so I don't have any extra adapter space. And I doubt these guys would send out free hardware but it would be nice to be able to do a REAL A/B/C comparison between each of them from the same location. That said, I'll go back to POTS before I pay one of the VoIP providers $25 a month for service. No way.

Of course VT should be letting people call their CSR's so that they know they're reaching useful people which is no small benefit in itself.

[DracoFelis]

Is there anything out there that can give us an accurate picture of of the datapath as it will be experienced by the voice data? If Tracert and Ping Plotter are going to run into the Comcast ICMP issues, etc., what out there would show a clean view of it?
I'm not sure what to suggest, as most network tracing tools use those ICMP packets to tell what is going on. So if those ICMP packets are are blocked (at the ISP level), you pretty much do have a blind spot in your view of the situation...

By the way, service continues to be solid this week so far,
Good! With luck it was just a temporary internet issue than causing some of the voice problems. If so, than with luck it will stay "fixed".


though nearly everyone I ask comments on echo, WHEN ASKED. Most haven't mentioned it and I'm starting to think they're trying to be nice. The problem there is obvious. I can't be telling everyone who calls to buy a better phone.
You got that backwards. While VoIP can make any echo worse (due to the higher latency inherent in the VoIP connection), it is almost always the case that the CAUSE of that echo is the phone equipment on the OTHER END OF THE CALL. i.e. since THEY are hearing the echo, it is YOUR EQUIPMENT that is actually causing that echo!

So the trick now, is to figure out what about your equipment is causing the echo. IMHO there are two likely candidates here, either the phone you are using, or the phone wiring between your phone and the ViaTalk adapter. Cheap phones can often cause echo, by not properly isolating the sound being listened to from the microphone used to send the voice back (thereby causing a little of what you are hearing to be sent back to the caller, hence an "echo"). And cheap phone wiring (especially the straight non-twisted phone wires that used to be used in days gone by) have also been know to cause echo due to not properly controlling the electromagnetic properties of the signal (and this is especially likely to cause a problem if/when the phone wire is many feet long, or worse yet built into the house walls).

So if you really want to "kill the echo", you need to figure out that echo's source, and fix that echo source (so you aren't producing echo anymore).

IMHO the easiest/cheapest place to check first, is the phone wiring. Try putting a short HIGH QUALITY (ideally cat-5 wiring) phone cable directly between your adapter and your phone (with no phone cabling going anywhere else, during that test), and see if the people you are talking to still notice echo on their end. If the echo goes away, than you have verified that your phone is OK and the echo is caused by your phone wiring. You can then decide what phone wiring needs to be replaced (with cat-5 or better phone cable), to use your phones without causing echo.

OTOH if the echo is still present with the short high quality phone cable, than the next thing to try is swapping phones to see if the echo goes away (continue to use the short phone cable for the test, as it's always possible that both your phone and the phone wiring are "at fault"). If you have multiple phones around the house, try them all (one by one) to see if any of them eliminate the echo (and if necessary, borrow a phone or two from a friend, to see if any phones they have are "good"). And if any phone you tested causes the echo to go away, you will then know which phones are causing the echo and which are "OK". At that point, you should again test the phone wiring you were previously using (with a phone that is known to be OK), to see if the phone wiring is OK, or you had problems with both the phones and the wiring.

Of course, if this quick "swap the wiring and swap the phones" type testing doesn't isolate the cause of your echo, I'm not sure what to suggest next. There is fancy phone test equipment that can track down echo sources, but that test equipment isn't exactly cheap (or necessarily easy for a non-telco person to use). Which is why the "swap things out" is usually the easiest "low tech" way to track down the source of such problems. And (as already mentioned), the most likely sources of that echo are your phone wiring and/or your phones.

I also wish I could re-route the data to my PC and have some sort of major echo canceling app on the PC that cleans up the data for the adapter (which I have to assume has limited ability to handle this.
Actually it is possible to do what you described. However, to do so, you would need to install (and configure) full VoIP software (such as this free download: http://www.asterisk.org ), and then leave that PC running 24/7.

And even if you went to the hassle to do all that, it may not eliminate the problem (but it likely wouldn't hurt). IMHO you are probably better off trying to find the actual source of the echo, and fixing the echo problem itself (vs trying to use a lot of computer power to digitally erase the echo, after the echo has already been added in on your phone lines).


Oh, I also found the default jitter settings to be pretty aggressive already! Network Jitter Level is set to "High". Jitter Adjustment Buffer is set to "Up and Down", whatever that means.
"Up and Down" means pretty much what the description implies. i.e. Your buffer will initially start at the "High" setting (or whatever other setting you set for jitter buffer size), but than the adapter itself can decide to either lower or raise the buffer size on it's own.

Considering the amount of jitter we know about, I'm guessing you will get more desirable results from setting this to "up only" (i.e. instead of allowing the adapter to adjust the jitter buffer size in both directions, only let the adapter increase the buffer size but never decrease it). However, since it's only an educated guess that "up only" will be slightly more desirable for your situation, it's really a "try it and see if it helps" type thing.

[Agrajag]

I love to keep getting the echo issue backwards. I'm on Uniden phones now that others have recommended (I wasn't a Uniden fan at all before getting to the VT forums on DSLR). It's an extension-based system and thus, nothing is now using wall wiring. The base is plugged into the adapter and that's it. My wife would flip out if I said we needed to buy new phones again after having just bought these.

[GregM]

I thought I might have had some echo today, but it was actually my wife and her friend having a conversation in the background while I was talking. I have Uniden 5.8GHz cordless phones, 6 of them, running from a single base station that is connected to the house phone wiring. They were fantastic with Vonage and still are with ViaTalk.

I got the admin password and upgraded the firmware to 5.1.3-LS and had them disable the DHCP provisioning so that I could use a static IP for the PAP2T and place it in the DMZ of my Linksys WRT54Gv5. I also use QOS for the MAC of the PAP2T device set to "highest" priority. QOS by port is set to high for all 4 network ports and bandwidth management is enabled only for the ports not used by the PAP2T.

I was doing this with my Vonage MT1005 adapter and it works just dandy with the ViaTalk PAP2T.

[DracoFelis]

It's an extension-based system and thus, nothing is now using wall wiring. The base is plugged into the adapter and that's it. My wife would flip out if I said we needed to buy new phones again after having just bought these.
I use the Uniden phones as well (I have a TRU-8866 system with 8 extensions), and so I know they are quality phones. So the problem likely isn't in your phones. And I have personal experience with being on the other end of the call without hearing echo (i.e. call my wife from the office, and she answers on a phone extension, and I don't hear any echo).

So that means that the echo source is most likely the phone cabling you have between your adapter and the Uniden phone system. If so, here is how to keep the problems with the phone line to a minimum:

1) Don't put your Uniden base station right next to either your router, or your VoIP adapter. Try to separate them by at least at least a foot or two distance, to avoid having RF interference between your VoIP and your Uniden base station. Even 2 feet is usually enough separation, but just don't put them right next to each other!

2) Use a high quality phone cable between the phone and the adapter, and use the shortest cable that will "do the job", as not all phone cables are created equal (there is a lot of "cheap junk" cables out there). In fact, I actually prefer to make my own cable from crimp-on ends and bulk cat-5e cable, as cat-5e cable is a lot more resistant to various phone line problems, than most of the "flat" patch cables you buy in the stores. However, cable length can sometimes be even more important than cable quality, so "keep it short" if you can. And remember, if you are careful where you place your Uniden base station (relative to where you have your router and VoIP located), you might even be able to get away with a 3 foot phone cable here!

3) When you run the cable between your VoIP adapter and the Uniden base station, make sure you aren't running it near other cables (including power cables). This will help to lower interference. If you absolutely must have your phone cable cross other cables (including the power cables for the adapter and/or Uniden base station), try to cross the cables at 90 degree angles (i.e. do a sharp/clean crossing, if a cable crossing is unavoidable). Otherwise, do your best to keep the other cables a couple feet (or more) away from your phone cable.

Try those things, and see if they help. Assuming that the echo is in your phone wiring (which is the most likely place, since the Uniden phones are usually pretty good at avoiding echo), those simple wiring changes may very well do the trick.

[Agrajag]

Interesting. Okay, the Uniden base right now is sitting about 6 inches from the adapter. I'll paint a mental picture of my workspace. I work in the corner of a room bedroom that serves as my office. It's an L-shaped corner desk. Fairly big. On the extreme left edge is the cable modem (Linksys). To the immediate right of that is my D-Link DGL-4300 which sits directly on top of a D-Link Gigabit switch. Right next to that is a Belkin 6-port USB 2.0 hub. Then there's a space before you get directly in front of me where my speakers, monitor and keyboard sit. On the right side, next to the right speaker is the PAP2T then a light stand (the mouse cradle just in front of it) and then the Uniden TRU-9466.

The two phone cables are likely standard fare. They could easily be replaced. I'll need two as I have two VT lines and the adapter doesn't support the single cable-double line option (that would be nice).

I have my own crimper and pieces here and obviously getting good cat-5 would be easy.

I also got a note from Christcorp on another issue today and he had me check the SPI setting on my router. I'd recently upgraded the firmware and had to start everything from scratch. Turns out it was On and he was certain that this would cause all sorts of trouble, including echo. I turned it off and had two of the best calls I've ever had on VT after that (though the second one ended with a dropped call and a third call, in from the caller, that was among the worst calls ever). One other one was a post from the D-Link forum saying that I need to uncheck (disable) the SIP setting under something called Application Level Gateway. Help says it could conflict with SIP devices if they're attached to the router. If these turn out to be important than this is yet another example of why details are a good thing and why we need some sort of major FAQ (like PortForward.com) to tell everyone what the right settings are for each device out there.

[connervt]

Glad to hear you are getting a handle on your situation there.

If these turn out to be important than this is yet another example of why details are a good thing and why we need some sort of major FAQ (like PortForward.com) to tell everyone what the right settings are for each device out there.

This may be more an endorsement for turn key only operations like *shudder* Comcast Digital Voice, where they supply, install, and configure all of the equipment (except for the telephone itself).

PortForward.com does a good job at what they do. But the task of trying to accommodate the ever growing number of consumer grade routers (and firmware revisions, not including 3rd party) is daunting. especially considering that a larger percentage of people are in the class to never even bother to change their routers SSID than to be concerned with firewall/port forwarding/QoS issues.

[Agrajag]

Agreed. If you think about progression and what we know, the writing is on the wall there. As we know, Vonage had spent millions advertising their service to everyday users and they lose 650,000 customers a year. Why do they lose 650,000 customers a year? Is it because they're a lousy company?

My hunch is that most of that churn is due to marketing a highly-complicated technology to people who are not ready for the work involved in getting a lot of configurations to the point of full realization of the potential. These people, more than many of us, want to just pick up the phone and have it work 100% of the time and want to simply pay less for it than before. These customers want Ma Bell service for half the price and VoIP is not that.

I don't know how VoIP companies can possibly grow and keep the churn rate to an acceptable level as long as the complexity stays where it is especially if there's no way to even walk these users through changing settings of devices that are impeding acceptable performance.

My mother was a case in point of a typical scenario. She wanted to just save on her phone bill. She knew how much my wife and I saved on our phone bill. That appealed to her enough to have me help her through the process (I actually had to do 99% of it). We had to go through hell getting DSL set up correctly so that her number could be ported. That meant adding a temporary second line with Verizon, then moving the DSL over to it, then getting ViaTalk, then porting the number. Then turning off the second line to get DSL set as a dry-loop install. This all took weeks and costs mounted quickly.

Then we had to get her a router but the setup was a mess of noise and echos so we had to get her a new phone system. Better but still not right. Found out her Westell DSL modem was junk so $79 more dollars to Verizon to get the newer, better ActionTec modem/router. Now it's finally getting within range of workable.

Without my help she'd have never been able to attempt this. Plus in addition to the costs directly to ViaTalk she probably had to invest another $250-$300 to get it "right" while the whole idea was to save money. In the end she'll save but now that cross-over point will be down the line quite a bit instead of the immediate savings everyone anticipates due to the marketing.

It's not a pretty picture for players in this market.

[connervt]

VOIP isn't ready just yet for prime time, contrary to those who proclaim it as a 100% alternative to POTS.

For myself, I'm a computer/network/communications hobbyist. Since my land line was basically underutilized anyway, it was a natural progression for me to move toward VOIP. But for those expecting a plug-and-play operation, there still is a long path to go

Then there are different levels of service (and corresponding pricing), starting from those who offer turn key operation (as Comcast mentioned above), through the Vonages and Packet8s of the industry, to the PAYG (pay as you go) operations that are basically no more than low volume wholesalers picking up a few bucks.

Each has there own benefits, as well as their own short comings. Unfortunately, the consumer doesn't seem to figure out what each are until they've already committed themselves to a POTS-free lifestyle...

[DracoFelis]

On the right side, next to the right speaker is the PAP2T then a light stand (the mouse cradle just in front of it) and then the Uniden TRU-9466.

The two phone cables are likely standard fare. They could easily be replaced. I'll need two as I have two VT lines and the adapter doesn't support the single cable-double line option (that would be nice).

I have my own crimper and pieces here and obviously getting good cat-5 would be easy.

If you are just trying to cable up the two lines of your PAP2 to your Uniden base station, you can still do it with one cable. All you need to do, is crimp 2-ends (one for each "line") on one end of your cable, and a single 2-line end on the other end of the cable. You then plug each of those two lines into the individual phone plugs of the adapter, and plug the single (2-line) plug into the Uniden base station.

Yes, I know this cable will look a little "funny" (since you have to untwist and expose (from the wire sheath) about an inch or two of wire on the end with the 2 crimped on plugs, but if you are careful how you crimp the wires (and use quality cat5e cable) it should still work pretty well. Such a cable won't technically meet cat5 specs (due to the inch or two of untwisted wire on the one end where you have 2 plugs), but it should still be more than "good enough" for phone usage, and it will allow you to make do with only a single (cat5) cable between the two devices!

BTW:
Believe it or not, I actually have a cable around here that looks something like what I'm describing (i.e. two single line plugs on one end, and a single 2-line plug on the other). If I remember right, I used to use that custom built cable to combine my VoIP and my POTS line into a single plug for use on a 2-line phone device


I also got a note from Christcorp on another issue today and he had me check the SPI setting on my router. I'd recently upgraded the firmware and had to start everything from scratch. Turns out it was On and he was certain that this would cause all sorts of trouble, including echo. I turned it off and had two of the best calls I've ever had on VT after that (though the second one ended with a dropped call and a third call, in from the caller, that was among the worst calls ever).
He might be right.

SPI on your router is a YMMV thing with VoIP. My experience is that if your router has a good implementation of SPI filtering, it may not cause problems (or you may be able to get around those problems with other router settings such as "port forwarding" of the VoIP ports). But bad/cheap implementations of SPI, can often cause packet loss due to the router's SPI itself dropping those VoIP packets!

However, since SPI is a router "security tool" (i.e. SPI helps your router fend off attacks from the internet), I personally prefer to leave SPI on (and adjust other settings on my router, to get around the problems SPI is having for my VoIP). For example, with many routers, simply "port forwarding" both the SIP (call setup) and RTP (voice path) ports to your VoIP adapter, is enough to get around SPI issues with the VoIP (while still leaving SPI working for other internet traffic). And some routers will simply let you adjust the length of time that UDP ports stay "open" (in which case, increasing this timeout to 90 seconds or more does wonders for VoIP).

OTOH if you are trying to see if your router's SPI is what is getting in the way of the call, turning it off completely is clearly the easiest test!

[DracoFelis]

VOIP isn't ready just yet for prime time, contrary to those who proclaim it as a 100% alternative to POTS.
I hear you.

IMHO VoIP is no closer to being a 100% replacement for POTS, than a cell phone is. Both technologies (cell phones and VoIP) have a lot to offer, but both technologies have their problems. And pretending either one is a full POTS replacement, is expecting more reliability than is there. Things might work great most of the time, but VoIP (and cell phones) just have more things that can (and sometimes do) "go wrong" than POTS does...

For myself, I'm a computer/network/communications hobbyist. Since my land line was basically underutilized anyway, it was a natural progression for me to move toward VOIP.
You too? I have been a computer professional for many years now. So for me, the "challenges" of VoIP where similar to dealing with any other communication/networking challenges.

[Agrajag]

I'm willing to bet that a surprising number of us are in IT or related to it. I was a network admin long enough ago that the term then was "computer manager" (in the Lantastic and Token Ring days).

[connervt]

You too? I have been a computer professional for many years now. So for me, the "challenges" of VoIP where similar to dealing with any other communication/networking challenges.

Well, most of the time it is a bus driver's holiday (piling the kids into the SUV for a drive across country).

I'm more of a hardware guy. Out of college did hardware R&D for the developing personal computer graphics industry (http://en.wikipedia.org/wiki/Professional_Graphics_Controller); then the turnkey vertical software systems market; serviced PCs and Macintoshes (Mac Plus thru Quadra) back when there were still storefront computer stores. For the past 12 years, I've been fixing semiconductor manufacturing machines that probably made the chip in your cellular phone, your DVD player, wide screen TV, and most of the Cisco routers that make the Internet work. :p

So, in other words, I guess I'm just one of those sick geeks that enjoy trying to get my VOIP setup to work correctly... :eek:

[GregM]

I'm willing to bet that a surprising number of us are in IT or related to it. I was a network admin long enough ago that the term then was "computer manager" (in the Lantastic and Token Ring days).Guilty. You're really taking me back. I upgraded two branch offices from AT&T's StarLan to Artisoft Lantastic.:eek: