Re: Overflow circuit

["Alexei Roudnev" <alex () relcom net>]

It means, that satellite (with it's 1 second delay and unavoidable echo)
should be better accepted for _profeccionsl_ phone connection (such as, for
example, connection between remote oil wells and central office), because
you can always stay with delay, if follow some talking discippline (and it
is better than trunking radio, anyway), while it will be less acceptable for
home / residential users.

Delay (by itself) does not influence voice quaility, but it required strick
talking discipline / policy to avoid misunderstanding, echo and so on. We
can expect such discipline from professional workers, but you never expect
it from your 5 y.old kid.

Alex





> In message <05bb01c41431$dd522e00$6401a8c0@alexh>, "Alexei Roudnev"
writes:
> > Thanks for the answers about Voip usage over satellite (I did not know,
that
> > it does not cause unacceptable delays and echo).
> > Responses (which I received) shows, that many people deployed such system
> > successfully.
>
> Define "unacceptable".
>
> Old-style telcos have delay budgets for their designs; if the
> round-trip time is too long, people find the call unpleasant.  While
> VoIP does have its own delay issues (see below), the big problem here
> is the satellite link.  VoIP doesn't give you an exemption from the
> speed of light laws; if you find satellite phone calls unpleasant -- I
> do -- you're not going to like satellite VoIP calls, for reasons that
> have little to do with the IP.  This is one reason why companies have
> spent fortunes putting in transoceanic fibers instead of launching more
> satellites -- the customers prefer the quality.  Satellite calls are
> cheaper, but they're noticeably -- and for many people, unacceptably -- 
> worse in quality.
>
> I should note that many VoIP systems make this noticeably worse, though
> (of course) less so as a percentage of the total delay than for
> domestic US VoIP calls.  The problem is the tradeoff between delay and
> efficiency.  Suppose you're sending 56 Kbps, uncompressed -- the
> equivalent of so-called "toll quality" voice.  That's 7 kilobytes/sec.
> If you want nice, big UDP packets with 1K payloads, you've just
> incurred about 143 ms of buffering delay, independent of transmission
> time.  (And on a DS1 line, transmission time for that packet is
> non-trivial.)  The total delay budget is, as I recall, about 150 ms.
> You can go to nice, short packets -- say, 100 bytes -- but then your
> IP, UDP, and RTP headers add a substantial amount of bandwidth
> overhead.  Apart from line efficiency, on relatively slow lines that's
> a lot of serialization time going out over the wire.  Compression makes
> the packets nice and short; depending on what you do, it may or may not
> help with the headers, but you have to spend a chunk of CPU time after
> you've collected a large enough voice sample to be worth compressing,
> and that means more delay time.
>
> Bottom line:  VoIP is inherently costly, either in delay time,
> bandwidth, or both.  It doesn't mean it's unacceptably bad, but that
> 150 ms delay budget came from many years of psychoacoustic studies.
>
> Cisco has a good web page on this, with lots of numbers.  See
> http://www.cisco.com/warp/public/788/voip/delay-details.html
>
> --Steve Bellovin, http://www.research.att.com/~smb