atcomsystems.ca/forum Forums Other TDM Phone Systems Allworx Telephones & Systems Some observations on VOIP.

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.

There seems to be allot of confusion between VoIP and IP... IP telephony is the system run over a local (intranet) LAN and VoIP is the SIP trunk running over the internet... SIP trunking right now is overated... The cost of long distance with POTS and PRI is now minimal with perfect quality... The value of IP telephony is in the applications, remote employees and remote offices.

Now there is something I can agree with.

-Hal

I am not against VOIP where warranted. I started withit back in 1999 with NBX. at the time I was partners with a company called Data Technologies, who handled networks and Data Recovery.
When I first saw the user GUI I went nuts over it
Talk about sweet. We put it the Dallas office then Houston, then London then Washington. This was on a closed Sprint Network.
They were easy to sell and setup. Then 3 Com bought them out and all hell broke loose. Any SW upgrade they came up with would crash the server, no recovery, you had to wipe and reload.
Put one in a medical environment and when they started to move those huge files, more hell.
Solution? Separate cable plant. The big selling point was one cable plant.
Promised upgrades did not happen. We got out but lost a couple shirts. So when they reared up a few years later I was skeptical.

I dislike them being sold where there is no need and also the CG's blinding them with BS.
A local county school transportation district bought into this a while back. The first Guinea pig was a facility with 15 admin people in a office, a mechanic shop and a tire shop and a huge parking lot. Existing system Panasonic DBS.
We did not install but had been caring for 10 bus barns for years. We get a call to this particular one for service. Tire shop phone are not working.
Great surprise to see Cisco phone on the desks of office people. Even more surprising was to see the Panasonic phones still there. First thing I had to ask was why? The response was the computer cannot access the paging system and there was no Voice page to each ext.
The parts guy is almost always running around the parts room and he used Voice announce a lot. Guys would just call and say what they needed and he could holler back. So they used the Panny for in house comm.
I checked with the tech people at the school district headquarters (they really don't know much).
The seller told them that voice announce was an upgrade license. Also that to use the public address they would need to buy a VOIP compatible paging system or get a paging server. They opted for the server but had to wait for the next budget cycle to purchase it. $4200.00
We had a meeting with those that would listen and explain that VOIP compatible paging system was mucho BS. Paging could be connected with a trunk port for a few hundred. The selling company would not authorize a trunk port for paging. So it stayed like that till next budget and they got the server. I think there is more BS being sold to end users than Carter has Liver Pills.
The lack of buttons did not go over well either.
The shop guys were used to touching one button
with their clean finger to get who they wanted.
Also the install was joke.

HAL Hal - I feel like I have conquered Mt. Everest, we agree on something concerning IP/VoIP :toast:

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.

The selling company would not authorize a trunk port for paging.

Of course not. Why would they let you supply and install a UPAM when they can sell them a $4200 server for friggin paging? This is insanity.

This is what I'm talking about. The greed and BS is out of control.

-Hal

WHAT?

Since when does the selling company control the sale?

There has to be more to that story.

Willing to bet the reason was they didn't want to provide a trunk port so somebody else can connect something to it. That will void the warranty.

-Hal

Yes, we are clearly moving (rapidly) to an all-packet based world. This is of course an economic decision for the reasons you cited.

However, I do beg to differ concerning the history of T-carrier. It was designed to carry voice from day 1, not data. It was concieved from the beginning to be the sucessor to the N- and O- FDM trunk systems of the day. Talking about clocks not mattering and packet re-assembly as a being "requirements that make T-Carrier what it is" is just plain wrong. T-Carrier is, was, and always will be a synchronous transport. Clocks and timing sources are one of the first things one looks at when a T1 goes down....

In fact, early attempts at using T1 to carry actual data resulted in all sorts of worm-cans being opened up. In the days before B8ZS, it was not easy to pump real binary data over a T1 without basically repackaging it into 7-bit bites. The reasons for this (and this whole digression) is swingly wildly off-topic though, so I'll sign off now.

Thank you, Jim, for the observation of being off topic. If you go to this thread, you may post to your hearts' content on the history and technology we are currently discussing.

Now, back on topic?

:read: