dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1324
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner

Premium Member

Chopped voice w. Google Voice & FiOS

So in a very interesting yet expected development, I'm having some trouble with calls to my Google Voice number.

I've observed this issue happening during primetime; 7pm ~ 10pm. The remote party hears me fine, yet the remote party sounds chopped on my end.

I used my Google Voice DID behind an Asterisk PBX PIAF Green box off a Dell P4 computer and Cablevision until November. From November until now, my setup runs on a Raspberry Pi using RasPBX behind Verizon FiOS 25/25.

I realize there are too many variables listed to begin narrowing this down. I know the setup worked perfectly behind Cablevision and the Dell, and now this is happening behind FiOS and the Pi.

The Pi also hosts a DID for my parents. They use Callcentric and their calls seem fine, so this makes me lean towards blaming it on peering congestion between Verizon, alter.net, and where the Pi appears to connect at Google.

I can post traceroutes and pings if requested, but I get the feeling that the typical Google Voice user here nowadays simply slaps an ObiHai behind their broadband connection and call it a day, so I can't really gauge culpability on the Pi other than what I know is happening with my setup between the two different ITSP's running on it.



So.......... To make a long story short.... Anyone using Google Voice, FiOS and a Pi? Or at least Google Voice and FiOS, and are having inbound chopped voice?

TIA
OzarkEdge
join:2014-02-23
USA

OzarkEdge

Member

Nope. But I just setup GV and an OBi202 on an Actiontec Verizon FIOS MI424-WR router and found the router's SIP ALG function already disabled, which is recommended. We will see how it trials... so far so good.

OE
Stewart
join:2005-07-13

Stewart to tired_runner

Member

to tired_runner
Run tcpdump on the Pi, capture a complete call, move the file to your computer and analyze the RTP with Wireshark. If lots of jitter or packet loss, you could try a GV call and a CC call simultaneously and compare the results, to rule out causes unrelated to GV.

You may be able to work around the trouble by forwarding GV to a free CC DID, which then rings into your PBX. That won't help outgoing calls, but you noted only incoming troubles.

If available, more conservative jitter buffer settings in your device may help. Or, try setting up jitter buffering in Asterisk. Of course, either will increase latency.

It's IMO unlikely that the Pi is contributing much jitter (assuming that it is not transcoding), but if you suspect that, try capturing both incoming and outgoing traffic, e.g. with a dumb hub or a PC with two NICs. You might be able to see it on the Pi itself. Or, compare with a Gmail or Hangouts Dialer call.

Possibly, replacing the PBX with a cloud VPS may help, either because the cloud has a better route from GV, or because the VPS has more horsepower.
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner

Premium Member

I'm running the same traceroutes tonight and noticed increased and erratic latency, and no surprise here as a consequence, calls are sounding like doodoo now as well.

There's 16 hops between me and the Google Voice IP's, so I have some pinging and plotting to do.

Once I narrow down the offending hop, I'll need to test that hop against my previous ISP to see if it also has the issue, or if this is Verizon doing what it does best, which in my opinion would be nickle and dime their customers.

So I guess so far, the Pi isn't getting the boot. We'll see...
Stewart
join:2005-07-13

Stewart to tired_runner

Member

to tired_runner
said by tired_runner:

Once I narrow down the offending hop, I'll need to test that hop against my previous ISP to see if it also has the issue,

Unfortunately, traceroute can only show you the hops on the outbound path, but your trouble is inbound. If you see a problem between nodes X and Y, this may just mean that the path from Y back to you is completely different than the path from X. And, if Y's path to you is not all Verizon, the chance of your getting VZ to fix the problem is IMO between slim and none.

What kind of SIP device(s) are you using? If there is Wi-Fi in the path, it could be adding significantly to the jitter and fixing that may make the calls clean again.

IMO, to attack this problem, you should be armed with some numbers. During prime time, how much jitter comes from GV on a bad incoming call? On an outgoing call? On an incoming call from Callcentric? How do these values compare with the variation you see with traceroute?
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner

Premium Member

I did some trace routes from other sites to the Google Voice IPs. All of the sites showed normal, consistent response and none were higher than 70 ms, mostly 20~40 ms.

Problem appears to be between alter.net and where the trace terminates at Google, so you're right about getting Verizon to fix this at all.

My final determination will be tracing to the Google IP using the cable company. If the MSO's carrier doesn't have the same prime time congestion, the choice is obvious for me.

No wifi in between at all. There's a Cisco router between my network and theirs, and a Cisco switch behind the router. I use a Sipura SPA-1001 ATA with the Pi.

I will check the path between me and Callcentric. It would be interesting to see what's happening there.
Stewart
join:2005-07-13

Stewart

Member

Possibly, connections via Cablevision and FiOS end up selecting different media servers. When I called directly from Gmail, media came from a server in Japan.

Here's a traceroute via a VPN connection to a friend who lives about 30 miles north of New York. As you can see, a server close to NY was selected.

C:\>tracert 74.125.39.12

Tracing route to 74.125.39.12 over a maximum of 30 hops

1 302 ms 302 ms 299 ms 192.168.99.1
2 301 ms 300 ms 302 ms FWDR-1.FWDR-1.FWDR-168.FWDR-192 [192.168.1.1]
3 308 ms 305 ms 305 ms L100.NYCMNY-VFTTP-165.verizon-gni.net [96.239.54.1]
4 309 ms 310 ms 306 ms G102-0-0-33.NYCMNY-LCR-22.verizon-gni.net [100.41.215.172]
5 * * * Request timed out.
6 314 ms 308 ms 316 ms 0.so-4-0-3.XT2.NYC4.ALTER.NET [152.63.0.73]
7 322 ms 320 ms 321 ms TenGigE0-7-0-7.GW8.NYC4.ALTER.NET [152.63.21.73]
8 310 ms 310 ms 307 ms google-gw.customer.alter.net [152.179.72.62]
9 309 ms 308 ms 308 ms 216.239.50.106
10 309 ms 311 ms 310 ms 209.85.246.4
11 313 ms 315 ms 316 ms 209.85.143.120
12 341 ms 323 ms 325 ms 209.85.143.127
13 324 ms 327 ms 329 ms 216.239.49.253
14 * * * Request timed out.
15 325 ms 327 ms 325 ms 74.125.39.12

Trace complete.


The first two hops are the VPN box and the Actiontec Router, so I'd call that 13 hops to the media server.

I'll take another trace in the morning, when it's prime time in NY. If it's bad, I'll record simultaneous GV and CC calls and compare jitter values.

Do you have trouble with outbound calls on GV? If I test incoming, the results may not be valid for your case, since my GV number is in San Francisco.
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner

Premium Member

The chopped voice on my end happens whether I'm the caller or the remote party is.

I would be curious to see what your latency looks like between 7pm - 10pm EST.

According to the Pi and the router, today's destination Google Voice IP seems to be 74.125.39.11. It was something else when I first posted here and my WAN IP changed sometime between then and now. As expected, pings look fine now.

Tracing route to 74.125.39.11 over a maximum of 30 hops
 
  1     1 ms    <1 ms     1 ms  10.17.12.3
  2    11 ms     9 ms     8 ms  l100.nycmny-vfttp-170.verizon-gni.net [xxx.27.23
9.1]
  3    14 ms    18 ms    19 ms  g2-3-4-3.nycmny-lcr-21.verizon-gni.net [100.41.2
12.86]
  4    12 ms     9 ms     9 ms  ae5-0.ny325-bb-rtr1.verizon-gni.net [130.81.163.
208]
  5     *        *        *     Request timed out.
  6    13 ms    17 ms     9 ms  2.ae1.xt1.nyc4.alter.net [140.222.228.119]
  7    19 ms    21 ms    24 ms  tengige0-6-0-7.gw8.nyc4.alter.net [152.63.21.69]
 
  8    17 ms    18 ms     9 ms  google-gw.customer.alter.net [152.179.72.62]
  9    12 ms     9 ms     9 ms  209.85.255.68
 10     9 ms    17 ms    10 ms  72.14.236.208
 11    23 ms    19 ms    18 ms  72.14.239.93
 12    29 ms    29 ms    29 ms  72.14.235.12
 13    30 ms    30 ms    28 ms  209.85.252.25
 14     *        *        *     Request timed out.
 15    25 ms    28 ms    28 ms  74.125.39.11
 
tired_runner

tired_runner

Premium Member

Went back to Cablevision, problem solved.
79176722 (banned)
VoIP.ms, Magento, and lotsa open tabs
join:2015-02-19
Miami, FL

79176722 (banned)

Member

Thanks for the update. Now we'll add this naughty ISP to the short suspect list whenever a VoIP issue arises and this naughty boy is involved.
tinky2
Premium Member
join:2013-12-18
usa

tinky2

Premium Member

Here in central jersey peering congestion between fios and alternet is the norm. It used to be worse before fios routed netflix so it was watchable -- but you can still see the congestion between the two from here.
tired_runner
Premium Member
join:2000-08-25
CT

tired_runner

Premium Member

It's pathetic in New York City. And what's silly is their speed match sales pitch.
79176722 (banned)
VoIP.ms, Magento, and lotsa open tabs
join:2015-02-19
Miami, FL

79176722 (banned)

Member

Do you guys bother complaining to the FCC about the blatant body shaping errhhmm I mean bandwidth shaping? Seems to me it'd be pretty easy to prove Verizon is illegally giving its own VoIP network a higher QoS priority than packets to competing providers...
PX Eliezer1
Premium Member
join:2013-03-10
Zubrowka USA

1 edit

PX Eliezer1

Premium Member

said by 79176722:

Do you guys bother complaining to the FCC about the blatant body shaping errhhmm I mean bandwidth shaping? Seems to me it'd be pretty easy to prove Verizon is illegally giving its own VoIP network a higher QoS priority than packets to competing providers...

But....

Verizon (with one exception noted below) no longer runs a VoIP service that would be comparable to an independent provider such as Ooma or Vonage or Voip.MS (etc).

That would have been Verizon VoiceWing, which was closed down a few years ago.

Likewise, AT&T closed down their CallVantage service.

Now if you are talking about in-house services such as Verizon FiOS, Verizon Digital Voice, AT&T U-Verse, Comcast Digital Voice, Cablevision Optimum Voice:

Well of course they are handled differently. By design, they don't go over public internet at all!

Unlike traditional Voice over Internet Protocol (VoIP) offerings that run on the public Internet, Comcast Digital Voice calls originate and travel over Comcast’s advanced, proprietary managed network.

So in answer to your original question---you couldn't prove a case from that per se.

Now, totally separate from FiOS, Verizon DOES provide some VoIP service to businesses, over lines that are [not] Verizon. For example you could have Verizon Business VoIP running over your TimeWarner cable. But in that case the question would be whether or not TimeWarner was doing the traffic shaping.

AFAIK it's partly a semantic issue and partly a technical issue, but the question is not really whether Verizon (or Comcast etc) are favoring their own traffic, but rather whether they are actively screwing other traffic.

Certainly Comcast was accused of that in the past with regard to Vonage. they didn't admit it, but they agreed to stop.

Of course one can accuse Comcast of pretty much everything (except conspiracy with the Vorlons) and one would be right much of the time.
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner to 79176722

Premium Member

to 79176722
I could fill out the online form over at the FCC. Is anyone else doing the same thing? Does anyone else besides me care?

Mr. Wheeler seems to pay attention when the complaints are coming in by the thousands, or when you run a SamKnows router and to that effect, it would only tell them how consistently advertised speeds are delivered, not what parts of their network they're deliberately neglecting.

Maybe more folks can prove a point and we can get this going. I'm game for pissing off Verizon any time.
79176722 (banned)
VoIP.ms, Magento, and lotsa open tabs
join:2015-02-19
Miami, FL

1 edit

79176722 (banned)

Member

PX Eliezer, thanks for the detailed explanation. But what Verizon is doing is just playing games. I think the FCC can and should force Verizon to not "decide for the customer" what specific traffic is more important to him. And it looks like Verizon is using peak-usage hours as leverage against its customers, because at those times they can claim "they have to throttle everyone". They do have to throttle, but not according to their self-serving algorithm...

IOW, the FCC can force Verizon to offer a simple web page where customers will be able to enter specific URLs (or domains) that are highest priority for them. Those destinations should ALWAYS receive AT LEAST 5% (just throwing a #) of the account's "average" speeds. Guaranteed. Even at peak hours. VoIP, after all, can live beautifully with even 0.1% of modern net speeds.

I think if the FCC hears more stories like Network Guy's, they'll start coming up with various solutions to end the games all those nasty ISPs play...
tired_runner
Premium Member
join:2000-08-25
CT
·Frontier FiberOp..

tired_runner

Premium Member

The SamKnows router is a good start, and that only came about after the masses contended with sub-par connectivity and nowhere else to go.

The problem with issues like what I discovered is that it's really a non-issue if no one else complains. It's the only reason Netflix was fixed for Verizon customers.

I suspect Verizon employs several peering partners in the same fashion that the VoIP world implements so-called "premium" routes versus "grey" ones. Those who pay get the VIP entrances through the gates, those who don't get stuck with everyone else. And good luck proving they're doing that without figuring out traffic patterns and appropriate data to go with it.
79176722 (banned)
VoIP.ms, Magento, and lotsa open tabs
join:2015-02-19
Miami, FL

79176722 (banned)

Member

With millions of customers, I don't think it should be tough to prove if only a group of "aggrieved parties" unite and fight.

You could also sue Verizon for the time you wasted and the lies they told you. No reason in the whole wide world that a 64kbps voice-packet connection will be throttled. Ever.
nickdigger
join:2009-06-13

nickdigger to tired_runner

Member

to tired_runner
Another FIOS/GV Chopped Audio user here. Asterisk + Pogoplug + PAP2. I'm extremely overdue to dump these Verizon assh0les.