Text 254, 145 rader
Skriven 2006-07-26 02:30:36 av Mike Luther (1:117/3001.0)
    Kommentar till text 240 av Peter Knapper (3:772/1.10)
Ärende: A little help...
========================
Thanks for the training Peter..

 PK> If you effectively mean a modem connection over VoIP, then forget it, 
 PK> your chances of anything working are near zero.

 PK> Voice is now regularly compressed to around 8Kb per
 PK> channel, and fax is similar at around 14Kb (for an
 PK> effective 9600bps Fax connections), however a modem
 PK> modulation scheme designed to work at 56Kb has bugger
 PK> all room left for any compression scheme to be applied.

So said that way I should have realized it before posting, wince.

 PK> So you are adding extra conversion steps that MUST 
 PK> degrade the quality of the ANALOG component of the 
 PK> service. And the compression possible for a Modem 
 PK> signal is MUCH harder to achieve due to the inherrent 
 PK> bandwidth requirements for an Analog Modem Modulation 
 PK> scheme (such as V.92).

Ah yes, be a contortionist!  Wrap your arm totally around your head to modem
over your cell phone sir!  It won't hurt a bit!

 PK> ADSL, CABLE, in fact ALL modern WAN transmisison 
 PK> formats are PURE DIGITAL in nature, therefore NONE of 
 PK> these device are MODEMS, they do not MODulate and 
 PK> DEModulate anything. They actually ENCODE and DECODE 
 PK> everything. So what on POTS is known as a MODEM should 
 PK> (technically) for broadband be known as a CODEC 
 PK> (enCOde, DECcoder). however humans being what we are 
 PK> dont; like change so the term MODEM has hung around...

Which I also should have thought about before I even posted!

 PK> ... with Ananlog data such as voice .. Latency, humans
 PK> cannot stand more than about 200ms of delay in getting 
 PK> voice data from one place to another to be able to 
 PK> hold a "normal" conversation between 2 people. ANY 
 PK> time we convert data between 2 formats we induce a 
 PK> delay, and the largest delay in modern tranmission 
 PK> systems is when MODULATING and DEMODULATING data. The 
 PK> more conversion steps, the worse off you wil be.

Sure, but again, all I was thinking about was four silly letters 'VOIP' when I
posted the question.  Which now that you have so beautifully framed you answer
I now realize what the real 'issues' are!

 PK> This is why trying to run voice over Analog modem
 PK> connections will never achieve the same level of 
 PK> quality of service as over a pure digital path such as 
 PK> broadband. Yes it may work fine for local calls, but 
 PK> for long distance, well that has many variables that 
 PK> are hard to predict. Also if you use VoIP only to 
 PK> connect to a LOCAL Exchange and your calls go via 
 PK> standard voice methods from there, then you have the 
 PK> best possible introduction into VoIP.

Reality time!

 ML> I've already got the OS/2 world up and proofed via the Hughes bird. 
 PK> And what may be a "Hughes" bird???

The Hughes satellite service.  Which, incidentally, since they acquired the
Direcway operation which was selling and servicing satellite data links to them
with both hand aimed and even mobile in motion auto-aiming systems, so told me
has gotten worse in quality.  The system uses a 54 inch arc and about a 12 inch
wide sliced section of a dish for the the RF link to and from the bird.  In the
hand aimed version you set it up on a surveyor's tripod anywhere in the world
you can see the 'bird'. You use an aiming program to find and optimize the dish
angle.  You get a decent data path from anywhere in the seeable world for the
bird.

With the exception, of course, in line with your teaching above as to timing in
VOIP issues, of the latency for the time it takes to go up and down full
circuit between you and the bird and wherever it hooks to back down on earth
for your other half of the needed path.

Of interest, my cohort working with this tells me when Hughes recently bought
out Direcway, they are cramming more users on each channel than before.  Thus
performance is getting worse for the users as well as they are going up on the
price.  For whatever level of service my cohort was paying $70 USD a month,
starting next year it will rise to $100 a month.  The basic hand aimed
equipment was about #1600.

But for motor coach installation, passing under overpasses and so on accounted
for, the whole aiming and connection process actually is done automatically! 
This level of equipment starts out at about $4500. Which there are tons of
well-off USA RVer's and oil drilling outfits and so on which apparently are
perfectly happy to pay for this stuff.  Not me. But the concept is viable for a
rapid response disaster communications system which can be completly ready and
up in an hour with big-time data rates should you need it.  Take the recent USA
shuttle re-entry disaster out in the farm fields of East Texas for example.

 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? 

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

As I now realize.

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

Sure.

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

Yes, so I'm now focusing upon in my thinking.

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

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

Fat chance.


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001



--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)