[e2e] Re: crippled Internet

[Eric A. Hall]

> why not ship a PCI, USB, or Firewire device including CODECs, Ethernet,
> UART, CPU, DSP, and whatever else you want?  If necessary, make the PC
> no more than a GUI.

This is something vendors have been talking about for the last three
years. "The size of deck of a cards, with Ethernet and POTS jacks" has
long been the target. Lack of features, interoperability problems, market
positioning, and costs overhead have kept it from happening.

> The easy answer to that question is "because it would be far too
> expensive." My point is that even if you could price it at $5
> including cables, packaging, and support, it would still be too
> expensive.

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
running a switch infrastructure locally and have data lines back to HQ,
since it is cheaper than buying a PBX plus maintenance plus long distance,
and can give more features than centrex. This especially includes
telecommuters with fixed data access (nailed up ISDN or DSL). For larger
networks that have to rebuild first, it's not cheaper until the network is
rebuilt on some other project's ticket.

> Desktop VoIP is dead for the foresseable future not because it doesn't
> work and not because it is too expensive, but because it is too much
> hassle compared to the almost free alternative of $0.05/minute or less
> for any-U.S.-phone-to-any-U.S.-phone.

This ignores the unfulfilled promise of advanced integration. Packetized
voice allows for much more than flash-hook features can ever provide.
Packetizing voice traffic means being able to do things like link a
customer record with a call and then transfer them *as a pair*. While
current CTI solutions allow for looking up callers data based on CID, they
don't let you forward the database query along with the call. There are a
million more examples, more than we can imagine, and this is the true
promise for VoIP.

Once these kinds of applications are developed, then VoIP will be very
useful to the end users. But yes, dead until then because it doesn't
provide any extra value to the end users directly. Currently, VoIP
features are extremely limited. Even the expected typical features like
"hold" don't work across vendor lines, and result in dropped calls more
often than not.

I would also agree that PCs make lousy phones, for all of the reasons
cited here and a few others. Call centers hate PCs already since they are
mildly unreliable; when a PC crashes, the ability to enter an order is
lost, period. Imagine asking one of these people to put their phones on
this stuff, then when the PC crashed they couldn't even complete the phone
call. Not gonna happen. This is also why the external "deck of cards" form
factor is compelling, but see above, the vendors aren't able to provide it
in the current early-adopter market, where costs and positioning are the
roadblocks.

That doesn't even address the issues like echo cancellation, silence
suppression, and the myriad other usability factors. The user experience
is (or was last time I looked) very low in comparison, with no payback in
terms of new and advanced functionality from using packets. That is the
real area that the IETF should be focusing on, promoting and building a
standardized architecture for applications to leverage. Standardized
feature negotiation mechanisms will be what makes VoIP a reality, if
that's the general goal.

Regarding TOS-based routing, the oddball observation from my tests showed
that nailed-up ISDN was better for VoIP transit because the channels were
committed bandwidth. If you could guarantee that voice calls went over B1
and data went over B2, you would getter perfomance from VoIP and the TCP
applications than if you ran them both over a shared 384k DSL circuit. The
use of TOS markings made a lot of sense for doing the custom bonding and
for routing over intermediary networks, although nobody supported TOS
routing with ISDN routers at the time to my knowledge, and OSPF was
dropping it, so we ended up forcing the tests with static routes and a lot
of praying.

This separation is also why rebuilding the network is important for larger
installations (Fred commented that they had a lot of experience with
over-provisioned LANs, which both is telling and expected). QoS lets you
choose the packets you are willing to throw away, but if you aren't
willing to lose any of them then you must overprovision.

Getting it off the desktop changes the argument to toll-bypass, we're no
longer talking about desktop VoIP as the driving issue. Toll bypass is
compelling and easy because there's no great demand for end-user features
or even for interoperability. It is cost effective and worthwhile when you
aren't putting it in front of users, and when you can guarantee firmware
revs on each end of a dedicated link.

I have some slides somewhere from a presentation on these issues (1999)
that I can pull off tape if anybody is interested. Not that any press
materials on a snake-oil next-gen technology would be useful;/.

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