1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Google Voice trouble with QoS

Discussion in 'Tomato Firmware' started by blackwind, Oct 17, 2012.

  1. blackwind

    blackwind Serious Server Member

    I'm experiencing the following issue with Toastman v1.28.7497:

    When I make a Google Voice call, I can hear the other side clearly, but I'm receiving complaints that my voice is very, very choppy, to the point where I can't be understood. When I disable QoS, this no longer occurs. Prioritizing GV traffic (UDP 19295-19305) doesn't help, even when classified as "Service" and moved to the top of my rules list. "View Details" confirms that the rule in question is, indeed, functioning. Switching to pfifo had no effect.

    Is there anything I can do to resolve this short of disabling QoS for good?
     
  2. Porter

    Porter LI Guru Member

  3. blackwind

    blackwind Serious Server Member

    Got it. Thanks. :)
     
  4. Nitro

    Nitro Networkin' Nut Member

    I put google voice / google hangouts into VOIP/Game and applied the follow QoS rules.

    google voice also uses TCP btw on port 19294 (and 443 for SSL).

    ANY ADDRESS ON TCP/UDP DST PORTS 19294 - 19310

    This rule should catch both Google+ Hangouts and google voice.
     
  5. Mihamina Rakotomandimby

    Mihamina Rakotomandimby Serious Server Member

    I also have the problem for Google Hangout Qos: http://afnog.org/pipermail/afnog/2012-May/000371.html
    I solved the Google IP lookup with:
    http://support.google.com/a/bin/answer.py?hl=en&answer=1279090&topic=1658465&ctx=topic
    And
    Code:
    dig +short -t TXT _netblocks.google.com @8.8.8.8 \
        | sed 's/ip4://g' | sed 's/"v=spf1 //g' \
        | sed 's/ ?all"//g' | sed 's/ /\n/g'
    
    Code:
    wget  'https://stat.ripe.net/plugin/announced-prefixes/data.json?resource=AS15169' -O - \
        | grep prefix | grep -v '::' \
        | sed 's/"//g' | sed 's/://g' | sed 's/,//g' | sed 's/\[//g' | awk '{print $2}'
    
     
  6. koitsu

    koitsu Network Guru Member

    This is atrocious; I don't even know how to explain all the ugly that's going on here, so I'll just fix most of it for you:

    Code:
    dig +short -t TXT _netblocks.google.com @8.8.8.8 \
        | sed -e 's/ip4://g' -e 's/"v=spf1 //g' -e 's/ ?all"//g' -e 's/ /\n/g'
    
    One thing to be aware of here: the final sed piece that replaces spaces with newlines may not work correctly. You're making a blind assumption that the sed implementation supports things like \n, \r, \t, and so on. Not all sed implementations do; user/buyer beware. Next:

    Code:
    wget  'https://stat.ripe.net/plugin/announced-prefixes/data.json?resource=AS15169' -O - \
        | grep prefix | grep -v '::' \
        | tr -d '":,[' | awk '{print $2}'
    
    One thing to be aware of here is the blind assumption that IPv6 prefixes will contain "::" in them -- this is bad assumption. The current data happens to have that, but such may not be the case always. A proper egrep syntax should be used instead. However, what should really happen is that the RIPEstat folks should add a query parameter that lets you filter what prefix types you want (IPv4 only, IPv6 only, or both), e.g. /data.json?resource=AS15169&prefixtype=v4

    Another thing to be aware of is that some folks' wget versions may require --no-check-certificate since you're hitting an HTTPS URL. This is not entirely secure, but it's easier than setting up certs and getting root CAs and so on on for verification.
     

Share This Page