Subj : A little help... To : Peter Knapper From : Mike Luther Date : Wed Jul 26 2006 03:30 am 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) .