Depends on the codec. Yes, most people default to G.711, but
my experience with G.729 and header compression has been good,
and closer to 12Kbps.
I definitely agree that it's much more symmetrical than web
traffic, and could therefore mess with someone's capacity
planning. Denying traffic that doesn't conform to your engineering
is one response. Re-engineering is another. Do what you will
with your network, I know what I'd do with mine.
Lee
the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be
half duplex whereas codecs tend to run both directions at once. who's getting
good service over 802.11 using G.711 or G.729? (no fair if your wireless
handset has its own proprietary halfdup codec, i'm talking real SIP here.)
hmm running g711 on a wifi handset or a lan phone with wifi bridging in the
middle results in decent quality.
at 2x80kbps vs 11mbps or 54mbps there should be plenty room for both directions
to communicate without too much delay
Steve
I could be 1) over simplifying, 2) misunderstanding, the problem, but all
of the networks that make up 'the Internet' are really just private
networks. there is nothing that says any of these private networks have to
transport all bits in all streams from end to end, yes?
Given that, certainly some networks might choose to NOT transport VOIP or
HTTP or BitTorennt across their networks. There are market reasons why
this will, or could, eventually force them to re-evaluate their practices
or face the consequences.
I don't find it shocking at all that ISP-Y decides to block VOIP,
especially if they have their own VOIP service offering. It might not be
the BEST plan in the long run for them, but certainly it makes some sense
to them... Just don't use their network(s), and complain to their support
organization(s) about the failures on their networks.
-Chris
you didn't ask for the size of the wireless network(1), in my
experience i've not had any (major) problems with this, the key is to
insure that the packets are somehow QoS'ed at the edge, even if your
provider won't do QoS to you, you can do some neat artifical QoS on
your upstream/uplink interfaces..
What i've done is rate-limit TCP inbound to be around 75-80%
of the link speed to force things to back-off and leave space for
my UDP packet streams.
I think one of the major problems is that very few people know
how to, or are capable of sending larger g711 frames (at increased
delay, but more data per packet) because they can't set these more granular
settings on their systems.. this means you have a lot higher pps
rates which I think is the problem with the radio gear, it's just not
designed for high pps rates..
big thing i've noticed in operational experience is that
not all 802.11 handsets handle AP roaming seamlessly, some want to
disconnect then re-dhcp for what is the same ssid/network domain.
- jared
(1) - i'm speaking for a single-ssid network with more than one AP that
covers long-distance clients at 1Mb/s speeds on 802.11b (250meter+ one way)
[...]
I think one of the major problems is that very few people know
how to, or are capable of sending larger g711 frames (at increased
delay, but more data per packet) because they can't set these more granular
settings on their systems.. this means you have a lot higher pps
rates which I think is the problem with the radio gear, it's just not
designed for high pps rates..
So, how are the WISP folk dealing with VOIP traffic as it becomes a
larger piece of their customer's traffic? Does anyone have a way
to force a given VOIP endpoint to use larger data frames? Or are
the WISPs forced to deal with with a shredded business plan because
their gear is optimized for large packets? (Or am I simply
missing something?)
Or do you write a TOS that says: "Customer is not allowed to send and
receive lots of small packets quickly?" 
2610(config-dial-peer)#codec g711ulaw ?
bytes Specify number of voice data bytes per frame
<cr>
2610(config-dial-peer)#codec g729r8 bytes ?
Each codec sample produces 10 bytes of voice payload.
Valid sizes are:
10, 20, 30, 40, 50, 60, 70, 80, 90, 100,
110, 120, 130, 140, 150, 160, 170, 180, 190, 200, 210,
220, 230, 240.
My Hitachi WIP-5000 also lets me set this locally on the handset
but it uses the delay between packets instead of size..
The Cisco ata-186 can set this as well:
# -----------------------------------------------------------------------------
# Parameter: NumTxFrames
# Access Code: 35
# Value Type: Integer (1 - 6)