[e2e] Re: crippled Internet

[Eric A. Hall]

> > It depends on what market you're talking about (and this thread has
> > covered most but not all of them). For branch offices with less than
> > 30 users it is absolutely a cost effective solution if you are
> > already ...  [overprovisioned]
> 
> That has nothing to do with desktip VoIP.

Sure it does. Small LANs are already over-provisioned but generally
neglected (having centrex or less). VoIP to the desktop comes into that
scenario looking pretty good. Not necessarily with PCs as the phones (as
most of us have said, PCs make lousy phones), but in hardware devices like
the Selsius or NBX phones.

> "Advanced integration" outside the very specialized telemarketer or
> help desk world involves the craziness evident in the do-all tools in
> zillions of discount bins.

You act like "mobility" is not a compelling feature of cell phones.
Obviously there are some features which are compelling to wider markets.
My feeling is that the features which are offered by fully leveraging the
packetized voice will be what makes VoIP compelling as well.

I am thinking about the ability to perform tasks like send a small note
back to an incoming caller and place them on hold ("I'm on the other line
but I really need to talk to you, hold on a sec"). You just can't do that
with flash-hook technology, and packets mean we don't have to run ISDN to
every wall jack in the world before there is a compelling market.

If the new features that leverage the new technologies are worthwhile, the
hassle will be accomodated. My guess is that the featurs will drive VoIP
regardless of the cost or usabilty issues.

> That is not and cannot be the case with reasonable software that
> actually has TOS support.  64k kbps for voice and 64 kbps for data
> (or 128 and 128 if you have two BRI's) is less and works worse than
> 384 kbps for voice and data.

We were using G.723 and G.729 codecs and hardware-based devices (Selsius
phones, Cisco gateways, etc.) for the tests. A single 64k B channel
between two nodes was more than enough for bidirectional voip. It was
still possible to totally screw things up by overloading the router's
queues, but for simple mixed tasks, it worked better than 384 DSL.

> This is the second time recently read someone claiming OSPF is related
> to IP TOS and diff-serv.  Do people really think that diff-serv and
> IP-TOS are impossible in the Internet, since it uses BGP instead of
> OSPF?  Are people confusing policy routing with diff-serv and IP TOS?

Corporations running VoIP to all of their desktops (including the
telecommuters) aren't using BGP internally. We wanted to use TOS to
provide end-to-end handling of the traffic within an OSPF-routed calling
areas so that the access and WAN equipment could treat the calls
separately from other data (eg, route the low-latency traffic down B1 and
everything else down B2).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/