Subj : A little help...
To   : Mike Luther
From : Peter Knapper
Date : Sun Jul 23 2006 11:35 am

Hi Mike,

ML> In contemplation for yet another fallback
ML> vector for disaster relief emergency setups using OS/2
ML> and the old BBS system game.  Have you ever tried using
ML> VOIP and 'standard' modem connections to the FidoNet
ML> stuff over VOIP?

If you effectively mean a modem connection over VoIP, then forget it, your
chances of anything working are near zero. We do Voice PABX Tie lines using
VoIP and 30 voice channels will still use up around 700Kb of IP bandwidth
(including VoIP management traffic), and no Modems or Faxes work on that.

"Real" Voice (and Fax, modem) calls need bandwidth, in fact a "standard" Telco
voice grade "circuit" uses 64Kb digital channels (for most of the globe except
USA where many areas still use 56Kb) to pass pure voice circuits. These
"channels" use minimal Analog to Digital "conversion" or encoding protocols and
can pass good quality voice, modems, and fax traffic no problem, however to
maximise the available bandwidth, Telco's now often use various compression
schemes to reduce the needed bandwidth (maximise ROI) and there is no ONE
compression scheme that works well for Voice, Modem and Fax. Voice is now
regularly compressed to around 8Kb per channel, and fax is similar at around
14Kb (for an effective 9600bps Fax connections), however a modem modulation
scheme designed to work at 56Kb has bugger all room left for any compression
scheme to be applied.

ML> But I'd like to know what the answer to that question
ML> might be.  Could be an interesting fall-back down a
ML> long an lonely road at the other end of 'someplace'
ML> where the wolf has alrady eaten both Hansel and Gretal.

Think about it. In a pure copper line situation, Digital Data from a PC is
MODULATED by a modem into Analog signals, which is then DEMODULATED back to
Digital again for the receiving PC. The result is something like this -
 Digital ==> Modulated to Analog ==> Demodulated to Digital.
Using Voip, you would using be something like this -
 Digital ==> Compressed/Encoded to VoIP ==> Expanded/Decoded to Digital ==>
Modulated to Analog ==> Demodulated to Digital.
So you are adding extra conversion steps that MUST degrade the quality of the
ANALOG component of the service. And the compression possible for a Modem
signal is MUCH harder to achieve due to the inherrent bandwidth requirements
for an Analog Modem Modulation scheme (such as V.92).

Sort of related to all this, but one of my big gripes abot the descriptions
provided for the broadband community is that "broadband" communications ALL use
a PURE DIGITAL transmission format, they have left the dial-up world that uses
the ANALOG tansmission formats. That means ADSL, CABLE, in fact ALL modern WAN
transmisison formats are PURE DIGITAL in nature, therefore NONE of these device
are MODEMS, they do not MODulate and DEModulate anything. They actually ENCODE
and DECODE everything. So what on POTS is known as a MODEM should (technically)
for broadband be known as a CODEC (enCOde, DECcoder). however humans being what
we are dont; like change so the term MODEM has hung around...

One of the BIG issues with Ananlog data such as voice is Latency, humans cannot
stand more than about 200ms of delay in getting voice data from one place to
another to be able to hold a "normal" conversation between 2 people. ANY time
we convert data between 2 formats we induce a delay, and the largest delay in
modern tranmission systems is when MODULATING and DEMODULATING data. The more
conversion steps, the worse off you wil be. This is why trying to run voice
over Analog modem connections will never achieve the same level of quality of
service as over a pure digital path such as broadband. Yes it may work fine for
local calls, but for long distance, well that has many variables that are hard
to predict. Also if you use VoIP only to connect to a LOCAL Exchange and your
calls go via standard voice methods from there, then you have the best possible
introduction into VoIP.

ML> I've already got the OS/2 world up and proofed via the Hughes bird.

And what may be a "Hughes" bird???

ML> But as a last resort if nothing else game, I wonder if
ML> VOIP could be used to take the BBS game (Fido) to a
ML> place where curiously, only phone line support existed?

Yes, in theory it could, but I predict that you would to be HUGELY disappointed
with the result........;-(

Lastly, remember that an Analog Modulation scheme is 100% Analog signal the
ENTIRE time a MODEM call is established (IE while the modem has Carrier present
on the line), REGARDLESS of any digital traffic flowing. With voice traffic, a
person does not talk 100% of the time, when there is no voice traffic, there is
minimal (if any) VoIP traffic. Fax manages to work around this because it is
99.9% one way traffic and it uses highly optimised modualation schemes that
enable compression to work very well on it. Voice is not quite so...
predictable.

ML>  And thus pull the cost effectively to zero to create a
ML> long term time connection to someplace that needed it,
ML> yet by old phone line slower but effective use?

Odly enough, the best way t oachieve this is to go 100% digital from machien to
machien communiacitons, the fewer "conversion" steps, the better the quality of
service and Bandwidth utiliisation and therefore a lower operational cost.

As I see it, the answer is to get ALL users onto some sort of "broadband" (in
this context meaning a permanent digital transmission path) connection (even
64Kb could work wonders for many people), where digital data is all that has to
flow and this bypasses so many conversion isses.

Ultimately the "problem" in all this is the HUMAN BEING, they need ANALOG
signaling, so the optimum configuration is where the ONLY Analog to Digital
conversion would be at the Human interface points at each end of a connection.

Either that or someone comes up with a better way to ship analog data round and
forget the conversion points..........;-)

Cheers.........pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)