imacamper
join:2005-05-17
Elk Grove, CA
| ViaTalk - Latency Issues
I am a SunRocket refugee that signed up with ViaTalk's BYOD program after reading mostly good things about them in the forums. I finally got my confirmation email and followed the instructions at »gizmopasswords.blogspot.com/ to configure my Innomedia ATA for use with ViaTalk. First I followed the "Is Your Gizmo Bricked?" reset instructions and then the configuration instructions. I was happy to find that my phone appeared to be working!!!
But after several calls where the other party couldn't hear me or I couldn't hear him, I began to investigate the issue and tested with another phone where I could hear both sides of the conversation. There's about a 1/2 to 1 second delay between the two phones. For example, if I say "hello" on one phone, I hear it about 1 second later on the other phone.
I pinged the various proxies (I'm in Sacramento, CA) and all are around 120ms - 160ms with the exception of Houston at 80ms - 90ms so I set my proxy to Houston. No change. I played with jitter buffer settings and voice packet sizes but still no change.
Finally I call ViaTalk support and wait 3 1/2 hours to speak with someone. He confirms I have a latency issue as the latency is 1200 ms. I explain that I didn't have these issues with SunRocket and testing my line at several of the VoIP test sites indicates my Internet connection is well within acceptable quality. He says he's sorry by latency issues are something ViaTalk can do nothing about as they are caused by the various ISPs along the way. I understand that but when ViaTalk is the only carrier with which I have latency issues and with its recent influx of customers, I have to think the ViaTalk is having capacity issues.
So any advice or settings to try on my Innomedia before I cancel my service? Anyone else experiencing such issues? I only have about 7 days left before the 14 day trial period ends. As much as I'd like to keep ViaTalk for its price, reputation (I believe service will get better), and features, I'm going to have to cancel if I can't get this worked out.
Cheers,
Drew |
|
ptrowski
Got Helix?
Premium
join:2005-03-14
Putnam, CT
clubs: | Have you tried a traceroute to the servers? It sounds like it could be a routing issue. |
|
imacamper
join:2005-05-17
Elk Grove, CA
| Yes I have and it seems to be OK, other than there's 17 hops. 
traceroute to houston-1.vtnoc.net (209.85.6.12), 64 hops max, 40 byte packets
1 69.62.246.3 (69.62.246.3) 43.742 ms 41.011 ms 61.009 ms
2 172.21.2.53 (172.21.2.53) 67.914 ms 54.000 ms 43.257 ms
3 172.21.0.250 (172.21.0.250) 39.865 ms 44.428 ms 48.500 ms
4 245.98-30-64.ftth.swbr.surewest.net (64.30.98.245) 44.977 ms 47.451 ms 50.768 ms
5 ge-6-3.car1.Sacramento1.Level3.net (64.158.148.9) 43.510 ms 46.022 ms 61.372 ms
6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) 42.227 ms 43.099 ms 46.022 ms
7 ae-4-4.ebr1.SanJose1.Level3.net (4.69.132.158) 59.243 ms 52.143 ms 54.886 ms
8 ae-81-81.csw3.SanJose1.Level3.net (4.69.134.202) 49.969 ms 57.238 ms 71.874 ms
9 ae-3-89.edge6.SanJose1.Level3.net (4.68.18.138) 48.674 ms 50.509 ms
ae-4-99.edge6.SanJose1.Level3.net (4.68.18.202) 47.242 ms
10 abovenet-level3-oc48.SanJose1.Level3.net (4.68.127.34) 47.424 ms 134.490 ms 80.357 ms
11 so-1-0-0.mpr1.sjc2.us.above.net (64.125.30.174) 47.242 ms 43.309 ms 62.569 ms
12 so-0-0-0.mpr2.sjc2.us.above.net (64.125.27.246) 48.642 ms 48.637 ms 59.070 ms
13 so-1-0-0.mpr2.lax9.us.above.net (64.125.26.29) 53.684 ms 53.652 ms 116.422 ms
14 64.125.25.17.available.above.net (64.125.25.17) 92.076 ms 159.019 ms 122.763 ms
15 t289.216-200-251-166.iah1.us.above.net (216.200.251.166) 148.414 ms 89.531 ms 87.826 ms
16 gphou2-209-85-0-125.ev1servers.net (209.85.0.125) 98.661 ms 93.103 ms 98.369 ms
17 ev1s-209-85-6-12.ev1servers.net (209.85.6.12) 96.007 ms 109.051 ms 99.288 ms |
|
redshift
Premium
join:2004-03-23
Beverly Hills, CA
1 edit | reply to imacamper
Personally if you don't get this worked out in the next 7 days you should know that viatalk only refunds 50% of your yearly prepayment.
This could be a capacity issue, but it's not likely since Viatalk recently upgraded all their servers, and in that case many people were complaining in multiple forums. I would have to think that it's something to do between the routing of your ISP and viatalks servers. You may want to try signing up for someone like Net2phone - who will use your current Adaptor, has a pretty generous trial period and see if there are any issues there. If there are, then it's on your end, and if not then you know your settings and viatalks do not mix well together.
--
"So this is how liberty dies. With thunderous applause." |
|
dcurrey
Premium
join:2004-06-29
2 edits | reply to imacamper
Anyone know if the sanjose-1 server is back up or is going to be back up? Looks like he routes that way.
Edit: Never mind! It looks like the sanjose-1 server is pointing to the chicago-5 servers. |
|
ptrowski
Got Helix?
Premium
join:2005-03-14
Putnam, CT
clubs: | reply to imacamper
Those us.above.net servers I would imagine could be a sticky point for you. |
|
imacamper
join:2005-05-17
Elk Grove, CA
| reply to imacamper
Thanks for your replies. So basically I am a victim of "bad luck" in that my ISP and ViaTalk servers just happen to be a long way from each other?
I was wondering if there was some recommended ToS setting that might give the VoIP packets higher priority than other packets?
Thanks,
Drew |
|
B
Premium,MVM
join:2000-10-28
| reply to ptrowski
The above.net servers are on the EV side of things, so there's not much he or she can do about that.
Aren't the west coast VT servers a LOT closer to you, imacamper?
It doesn't matter that you can ping all the servers at the same rate; clearly those 17 hops are really adding up, and you should be able to shorten the path by trying closer boxes...
This is certainly one of those times when I wonder why VT doesn't have an option NOT to pass all traffic through their gateway.
-- B
--
In a realm outside causality and function |
|
Cogdis
join:2007-03-26
Floral Park, NY
 ·Verizon FIOS
 ·RoadRunner Cable
 ·Teleblend
| reply to imacamper
said by imacamper  :I was wondering if there was some recommended ToS setting that might give the VoIP packets higher priority than other packets? Thanks, Drew That's entirely up to your provider (and any other networks your traffic travels accross).
I have Time Warner Cable and they give VoIP the highest priority (even competing VoIP), but once they route traffic off their network they can't control it.
By the way for what it's worth I'm pinging 10 to my VT server. |
|
B
Premium,MVM
join:2000-10-28
| reply to dcurrey
said by dcurrey :Anyone know if the sanjose-1 server is back up or is going to be back up? Looks like he routes that way. Edit: Never mind! It looks like the sanjose-1 server is pointing to the chicago-5 servers. And NY-1 is going to Chicago-1, while NY-2 goes to HostRocket in (I guess) upstate NY. I thought these regional things had been shaked out?
-- B
--
In a realm outside causality and function |
|
imacamper
join:2005-05-17
Elk Grove, CA
| reply to B
said by B :Aren't the west coast VT servers a LOT closer to you, imacamper? It doesn't matter that you can ping all the servers at the same rate; clearly those 17 hops are really adding up, and you should be able to shorten the path by trying closer boxes... They are physically closer but no closer via the way the packets fly.
Here's a traceroute to sanfrancisco-1.vtnoc.net:
traceroute to sanfrancisco-1.vtnoc.net (216.246.105.146), 64 hops max, 40 byte packets
1 69.62.246.3 (69.62.246.3) 41.077 ms 43.560 ms 57.205 ms
2 172.21.2.53 (172.21.2.53) 48.647 ms 41.204 ms 41.210 ms
3 172.21.0.250 (172.21.0.250) 62.261 ms 41.741 ms 63.552 ms
4 245.98-30-64.ftth.swbr.surewest.net (64.30.98.245) 56.324 ms 42.140 ms 44.762 ms
5 ge-6-3.car1.Sacramento1.Level3.net (64.158.148.9) 40.484 ms 43.561 ms 39.503 ms
6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) 41.092 ms 58.327 ms 69.350 ms
7 ae-4-4.ebr1.SanJose1.Level3.net (4.69.132.158) 59.600 ms 52.254 ms 53.625 ms
8 ae-81-81.csw3.SanJose1.Level3.net (4.69.134.202) 46.242 ms 51.047 ms 58.776 ms
9 ae-82-82.ebr2.SanJose1.Level3.net (4.69.134.217) 72.825 ms 55.752 ms 56.082 ms
10 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 78.274 ms 79.017 ms 89.892 ms
11 ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 83.104 ms 79.217 ms 90.819 ms
12 ae-3.ebr3.Chicago1.Level3.net (4.69.132.62) 114.002 ms 109.403 ms 144.807 ms
13 ae-78.ebr2.Chicago1.Level3.net (4.69.134.61) 103.803 ms
ae-68.ebr1.Chicago1.Level3.net (4.69.134.57) 106.016 ms
ae-78.ebr2.Chicago1.Level3.net (4.69.134.61) 117.194 ms
14 ae-13-53.car3.Chicago1.Level3.net (4.68.101.71) 125.010 ms
ae-13-55.car3.Chicago1.Level3.net (4.68.101.135) 106.242 ms
ae-23-54.car3.Chicago1.Level3.net (4.68.101.103) 103.481 ms
15 xe-0-3-0.cr2.ord1.us.scnet.net (4.71.100.26) 149.551 ms 105.801 ms 124.009 ms
16 v55.ar2.ord1.us.scnet.net (216.246.95.146) 106.595 ms 104.841 ms 105.064 ms
17 v902.aggr902.ord1.us.scnet.net (216.246.94.174) 104.867 ms 103.624 ms 116.525 ms
18 unknown.scnet.net (216.246.105.146) 102.352 ms 103.775 ms 103.731 ms
And one to sanjose-1.vtnoc.net:
traceroute to sanjose-1.vtnoc.net (216.246.105.138), 64 hops max, 40 byte packets
1 69.62.246.3 (69.62.246.3) 48.776 ms 40.461 ms 41.067 ms
2 172.21.2.53 (172.21.2.53) 55.006 ms 43.460 ms 44.792 ms
3 172.21.0.250 (172.21.0.250) 131.990 ms 41.309 ms 62.103 ms
4 245.98-30-64.ftth.swbr.surewest.net (64.30.98.245) 43.742 ms 43.179 ms 51.153 ms
5 ge-6-3.car1.Sacramento1.Level3.net (64.158.148.9) 43.643 ms 48.522 ms 51.203 ms
6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) 44.677 ms 41.648 ms 62.844 ms
7 ae-4-4.ebr1.SanJose1.Level3.net (4.69.132.158) 44.441 ms 68.926 ms 55.071 ms
8 ae-61-61.csw1.SanJose1.Level3.net (4.69.134.194) 48.710 ms 49.437 ms 54.834 ms
9 ae-62-62.ebr2.SanJose1.Level3.net (4.69.134.209) 69.259 ms 56.133 ms 53.935 ms
10 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 91.708 ms 89.514 ms 90.828 ms
11 ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 83.295 ms 88.127 ms 90.560 ms
12 ae-3.ebr3.Chicago1.Level3.net (4.69.132.62) 112.770 ms 123.915 ms 144.791 ms
13 ae-68.ebr1.Chicago1.Level3.net (4.69.134.57) 107.624 ms
ae-78.ebr2.Chicago1.Level3.net (4.69.134.61) 121.628 ms
ae-68.ebr1.Chicago1.Level3.net (4.69.134.57) 109.004 ms
14 ae-23-54.car3.Chicago1.Level3.net (4.68.101.103) 105.517 ms
ae-23-56.car3.Chicago1.Level3.net (4.68.101.167) 134.150 ms
ae-13-55.car3.Chicago1.Level3.net (4.68.101.135) 104.972 ms
15 xe-0-3-0.cr2.ord1.us.scnet.net (4.71.100.26) 104.530 ms 115.913 ms 112.570 ms
16 v54.ar1.ord1.us.scnet.net (216.246.95.142) 118.894 ms 117.531 ms 118.950 ms
17 v902.aggr902.ord1.us.scnet.net (216.246.94.174) 103.587 ms 115.106 ms 103.685 ms
18 unknown.scnet.net (216.246.105.138) 105.046 ms 107.626 ms 103.729 ms
Thanks,
Drew |
|
imacamper
join:2005-05-17
Elk Grove, CA
| reply to Cogdis
said by Cogdis :said by imacamper :I was wondering if there was some recommended ToS setting that might give the VoIP packets higher priority than other packets? That's entirely up to your provider (and any other networks your traffic travels accross). I have Time Warner Cable and they give VoIP the highest priority (even competing VoIP), but once they route traffic off their network they can't control it. I understand that ToS is merely a request but what value gives me the highest priority if the routers honor it? It seems to me that I've read I can set the value between 0 and 7. I'll have to look through the Innomedia configuration guide again and see where that is. So is 0 the highest priority or 7? That's the piece I do not know.
Thanks,
Drew |
|
jay_rm
join:2002-04-12
Netville
 ·Fox Valley Internet
·ViaTalk
| reply to imacamper
said by imacamper :Here's a traceroute to sanfrancisco-1.vtnoc.net: traceroute to sanfrancisco-1.vtnoc.net (216.246.105.146), 64 hops max, 40 byte packets 1 69.62.246.3 (69.62.246.3) 41.077 ms 43.560 ms 57.205 ms 2 172.21.2.53 (172.21.2.53) 48.647 ms 41.204 ms 41.210 ms 3 172.21.0.250 (172.21.0.250) 62.261 ms 41.741 ms 63.552 ms 4 245.98-30-64.ftth.swbr.surewest.net (64.30.98.245) 56.324 ms 42.140 ms 44.762 ms 5 ge-6-3.car1.Sacramento1.Level3.net (64.158.148.9) 40.484 ms 43.561 ms 39.503 ms 6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) 41.092 ms 58.327 ms 69.350 ms 7 ae-4-4.ebr1.SanJose1.Level3.net (4.69.132.158) 59.600 ms 52.254 ms 53.625 ms 8 ae-81-81.csw3.SanJose1.Level3.net (4.69.134.202) 46.242 ms 51.047 ms 58.776 ms 9 ae-82-82.ebr2.SanJose1.Level3.net (4.69.134.217) 72.825 ms 55.752 ms 56.082 ms 10 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 78.274 ms 79.017 ms 89.892 ms 11 ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 83.104 ms 79.217 ms 90.819 ms 12 ae-3.ebr3.Chicago1.Level3.net (4.69.132.62) 114.002 ms 109.403 ms 144.807 ms 13 ae-78.ebr2.Chicago1.Level3.net (4.69.134.61) 103.803 ms ae-68.ebr1.Chicago1.Level3.net (4.69.134.57) 106.016 ms ae-78.ebr2.Chicago1.Level3.net (4.69.134.61) 117.194 ms 14 ae-13-53.car3.Chicago1.Level3.net (4.68.101.71) 125.010 ms ae-13-55.car3.Chicago1.Level3.net (4.68.101.135) 106.242 ms ae-23-54.car3.Chicago1.Level3.net (4.68.101.103) 103.481 ms 15 xe-0-3-0.cr2.ord1.us.scnet.net (4.71.100.26) 149.551 ms 105.801 ms 124.009 ms 16 v55.ar2.ord1.us.scnet.net (216.246.95.146) 106.595 ms 104.841 ms 105.064 ms 17 v902.aggr902.ord1.us.scnet.net (216.246.94.174) 104.867 ms 103.624 ms 116.525 ms 18 unknown.scnet.net (216.246.105.146) 102.352 ms 103.775 ms 103.731 ms Ouch !
--
3500/512 5.7 GHz Motorola Canopy Wireless; FoxValley.net |
|
Cogdis
join:2007-03-26
Floral Park, NY | reply to imacamper
7 is highest priority |
|
dcurrey
Premium
join:2004-06-29 | reply to imacamper
They don't appear to have any West Coast server in operation.
sanjose-1a is being routed to chicago-5
sanfrancisco-1a is being routed to chicago-6
Looks like houston is the best they can do. |
|
B
Premium,MVM
join:2000-10-28
| reply to imacamper
Here's where I'm confused.
The OP does not have a "1200 ms latency issue"; his or her worst time to a VT server is reportedly 160 ms.
It would seem that having a full-duplex conversation on a VT server that's 100 ms away should not add more than a quarter of a second or so of lag.
So what's the OP's real problem that results in "1/2 to 1 second delay"? Is that even the problem?
Perhaps we should go back to the real symptom: "several calls where the other party couldn't hear me or I couldn't hear him". Couldn't hear? At all?
-- B
--
In a realm outside causality and function |
|
imacamper
join:2005-05-17
Elk Grove, CA
| said by B :Here's where I'm confused. The OP does not have a "1200 ms latency issue"; his or her worst time to a VT server is reportedly 160 ms. OK, that's what I thought too. From what I've read, up to 150ms is OK. The 1200ms number came from the ViaTalk rep when he looked up my account.
said by B :It would seem that having a full-duplex conversation on a VT server that's 100 ms away should not add more than a quarter of a second or so of lag. So what's the OP's real problem that results in "1/2 to 1 second delay"? Is that even the problem? Perhaps we should go back to the real symptom: "several calls where the other party couldn't hear me or I couldn't hear him". Couldn't hear? At all? Let me clarify. The call problems are like on a cell phone where both parties have to stop speaking for half a second or so before one can start again. Otherwise they end up both speaking at the same time and neither can "hear" the other. I tested with both a POTS phone and my ViaTalk phone to my ear. I called the ViaTalk from the POTS and the lag time between speaking into either phone and hearing it on the other was 1/2 to 1 second. Then I called the POTS phone from the ViaTalk and had the same symptom.
Another symptom is that I use my regular home answering machine, not ViaTalk voice mail. (Just can't train the wife ) I will call the ViaTalk from an outside phone and let the answering machine pick up. Again, the first 1/2 to 1 second of the answering machine message is cut off. The recorded machine message is "You have reached Drew and ...". I hear "rew and ...".
I had no such issues with SunRocket or Teleblend. ISP and all equipment are the same.
The WAF is in the toilet right now. I've got to get this fixed or else she'll demand we return to POTS and be back to $100 monthly phone bills the way she likes to talk long distance.
Thanks,
Drew |
|
Cogdis
join:2007-03-26
Floral Park, NY | I see you're using the innomedia. Maybe it has something to do with that?
See »Hello... Hello? |
|
B
Premium,MVM
join:2000-10-28
1 edit | reply to imacamper
I suppose you could drop VTBrendan a line to expedite your support questions instead of waiting on hold again, and I'd love to know where the rep got the "1200 ms" (1.2 seconds!), but I'm starting to think that maybe you really should move on to another provider after all. At least until they put up a west coast server.
You could go month to month with any number of providers for a while to see how things go for you; best of luck.
(By the way, have you tried all the VT servers? Maybe one will work magic for you.)
Edit: By the way, the reason other providers like Sunrocket work better is that they are far less dependent on your time to their SIP server; the voice traffic heads directly to the terminating RTP gateway (on Level3 or elsewhere). With Viatalk, by contrast, all your voice traffic has to hit the Viatalk server in both directions, so latency to them is paramount. Again, I don't understand why they don't have an "opt out" to revert to the more common methodology for people like you.
-- B
--
In a realm outside causality and function |
|
imacamper
join:2005-05-17
Elk Grove, CA
| reply to Cogdis
said by Cogdis :I see you're using the innomedia. Maybe it has something to do with that? See » Hello... Hello? Yes, these are my symptoms except that it extends beyond the first "hello" and throughout the entire conversation. Also, I have the same issue whether I dial my existing SR number that's forwarded to ViaTalk or direct dial my ViaTalk number.
And after some more experimentation today, *on rare occasion* there is no delay. Maybe one out of every 6 or 7 calls there's no delay.
Cheers,
Drew |
|
