Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  human factors aspects of echo delay
Message-ID: <25609@amdcad.AMD.COM>
Date: 12 May 89 15:26:05 GMT
References: <8905120035.aa07267@huey.udel.edu>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 24

And lest we forget, the main reason Ethernet-as-a-packet-voice-PBX didn't
fly so well was that to get good efficiency you need to bundle up several
milliseconds of speech per packet. [256 data bytes per packet means a 36ms
delay *minimum*, plus elastic buffer delay.] As long as all parties to the
conversation were on the same network *and* all had "4-wire" phones, it worked
just fine, even with a 100ms round-trip time, since there were no echos.
[Note that you did *not* have any delay in your own sidetone!]

But when a call had to go "off net" to a phone "out there" somewhere, the
inevitable imbalances in the 2-wire/4-wire hybrids exposed the delay to
the parties on the packet-voice side [the party on the 2-wire analog side
never heard the problem], and the packet-phone users started getting echo
with delays right in that most irritating range!

[Given recent advances in adaptive echo-cancellation processors, and also
with end-to-end ISDN coming, maybe it's time to try "EtherPBX" again...]


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403