Quote
Originally posted by Jim Bennett:
Quote
Other than that, comparing TDM with VOIP is still incorrect, since they refer to different things.
Actually, comparing VOIP to TDM is spot on, and is the very core of this debate. When we talk about TDM we are talking about a real-time digital stream, the tried and true method of digital transport for voice for over forty years now. VOIP is a completely different paradigm (yeah, I hate that word too, but it fits) in that it uses a packet based (not real-time) protocol to carry voice. This was first concieved of decades ago, but it was never viable in the past because we didn't have fast packet based networks with low enough latency to be usable. Now we sort of do...

Getting people to understand real-time vs. packet based can be a challenge. Try explaining to a CG netwoking type that a true T1/DS1 carrying voice channels has no error correction, forward or back. They think only in terms of packets, so the idea of an eight (or seven, back in the day) bit sample with a usable life span of 125 microseconds (1/8000 of a second, otherwise known as "right now") is something they can't wrap their heads around. They insist the idea is crazy, and not a good way to do it. I guess all those crystal-clear long distance calls we enjoyed for so long weren't as good as I thought they were. Sigh.

I think I just saw the horse move.
Not really. TDM is a multiplexing scheme. Its use in telephony is incidental, and it has found uses in many other applications before and after the advent of digital telephony.
Thre were digital communications before the advent of digital telephony, and they used multiplexing too. The main reason being that there were always more user demand than circuits. Another reason was that circuits were expensive. Data communications, from the late 1950s/early 1960s up until the advent of a viable packet transport, were circuit switched and synchronous, just like most digital telephony has been.
But unlike applications like real time voice or video which present a continuous stream, digital data by definition moves in some sort of packet - a set number of bits or bytes. As long as the packets arrive in the destination, the ORDER at which they arrive is immaterial. A device (the PAD - packet assembler/disassembler) will put them right. This is a tremendous advantage because you need not be concerned with the TIMING of the stream. Clocks don't matter. After all this is not real time traffic, and latency was acceptable. All of these are requirements that make T-Carrier what it is. Couple that with the fact that different computer/data communication systems used wildly different clocking/timing schemes.
It just happened that T-Carrier (originally a DATA transport) used time slots (TDM) to cram many DATA streams on a single circuit. It could have used a frequency based scheme like other transports.
Because Voip is a packet-switched application it uses different kinds of switches. These switches also do multiplexing - but nothing as elaborate as time-based muxing.
The thing is, continuous, real time streams are better suited to circuit-switched networks, ie transports that pre-establish a connection and keep it under tight control. In connection-less packet networks, the solutions so far (including "virtual circuit schemes" where packet traffic goes through pre-established connections) have been...inelegant.