Site Navigation
|
VOIP - The Con job of the
Century?
VOIP - for me it makes an excellent illustration of how ignorance,
Hype and Dishonesty seems to replace sound Engineering, careful
design and common sense in so much modern Technology.
Maybe
before we proceed we should start with a brief bit of history
In computing terms IP
is one of the last living dinosaurs, the idea
was originally proposed in the late 1950's and the protocol was
developed during the 1960's.
I expect many folk know of the history of
ARPA net but for those who do not - a bit of Background.
At the
time there were two competing ideas for how to shuffle Data around the
place one was packet switching (later to become X.25) and this was what is
now called a connection oriented service - that is it works pretty much
like a phone call, you send a lot of information out to set up the call
(phone number your number etc ) and after the call has been set up
from there on if you want to send data you only need to add a small header
to tell the network which 'Logical Channel' you want to use (with X.25 you
can set up multiple calls at the same time each call gets given
a Logical Channel Number or LCN a very short number often only 8 bits in
length unlike the X.25 address (phone number) which can be 80 bits in
length.
The other idea (which was later to become IP) was to build
a connectionless network in which each packet of data would carry the
addressing and routing information. The intention here was that since
there were no fixed routes through the network in the event of a failure
the packets would readily find alternate routes to their
destination.
Of course data on the connectionless network could
potentially have a higher latency (Delay across the network) as all the
switching nodes need to stop and look up a routing table for each packet
but since even X.25 used store, error detect/retransmission and
forward mechanisms there was not any appreciable difference in latency
between the two.
Both
these Networks were designed primarily with the idea of shuffling data
around - there were no mechanisms built in to provide any QOS (Quality Of
Service), There were no mechanisms built in to keep Latency to a
minimum.
In fact
as time went by the IP stack grew more and more unwieldy as
kludge after kludge after kludge got added on. Early on there was the idea of the OSI 7
layer model but IP has ended up carrying so much extra fat that the idea
of fitting everything into a mere 7 layers seems to have long
since gone the way of the Dodo.....
Roll forward nearly 50 years and we
are still trying to push this (now) aging and tired Legacy technology
on, to do things it was never designed or intended to do and the
latest two jokes seem to be 'Lets run real time applications over this
network, things such as voice and video.
A quick look at Voice before we head on.
Voice is carried
across Telecommunication networks as a 64Kbps stream which is made up of
8,000 8 bit samples a Second.
Voice is a 'real time' application so it needs
to cross the network with a minimum of delay. When we are having a
conversation with someone there is a 'comfort factor' of less than 200mS.
As
delay in voice transport approaches 200mS then we find, that while the delay
is not obvious our conversations start to trip over each other - that
is you find that both parties will start to talk at once. As the delay
approaches 500mS however it becomes quite noticeable and even
more annoying.
Voice in the digital domain has traditionally been
switched using Time Division Multiplexing where 8000 times a second
another 8 bits (or Octet - in the wonderful world of communications there
is no certainty that every group of 8 bits are connected in any way as we
could have 3 bits for a flag 4 bits for something else and a Poll or final
bit as a result a group of 8 bits in a data frame, cell or packets is
called an Octet not a Byte) for the channel or timeslot are switched
across the network.
VOIP, it promises so much and delivers so little!
Lets run through the promises made for VOIP shall we?
VOIP you only need to run one Network, Voice and LAN
traffic happily sharing bandwidth only one LAN needed - in fact
save money
on CAT 5 cabling only
one Ethernet port needed at each desk.
VOIP
save money on WAN
links, Only one link needed to each site instead of the messy arrangement
of running one link for data and another for voice.
VOIP a much more efficient
way of transporting voice than say ATM use it and save
money
.
VOIP you
will have no trouble talking over it and may
even understand the person at
the other end!
OK lets start with the first....
most people who implement
VOIP for a living recommend that you run a separate LAN for VOIP running
on an independent Ethernet switch.
Hang
on though, wasn't the whole point of VOIP the one unified
Network?
Well if we go all the way back to how IP was designed
in the first place we find that there is no way of prioritsing any Traffic
ahead of anything else*1
so there is NO
inherent way of prioritising Voice ahead of say Email (which is not a real
time application).
What we also find
with variable frame length traffic (such as IP) is that as Traffic levels on
a link (say that nice fat 100Mbps LAN link to your desk) go
up the latency increases exponentially so for a typical link running
several streams of data once the utilisation goes past 25%, we start losing
any hope of maintaining order or keeping latency down.
Picture
this you are on the phone to an important client and one of your mates
decides to Email a funny video clip. Mid conversation your email client
decides to check your email and down comes the file - making your IP phone
virtually unusable.
So if you want to run VOIP around the
office run one piece of cable for the PC and another for the VOIP phone. So that
hasn't saved us anything has it?
Save money on WAN links? If we are struggling to get it to share
a 100Mbps LAN with a single PC attached how on
earth are we going to get it to work on a link that is typically
less than 2Mbps link with multiple streams of Traffic?
Simple answer: YOU CANNOT.
OK I have managed to do it for various customers BUT this
is with the backing of a full QOS Wide Area Network (ATM) and by specifically
reserving bandwidth (in the case of frame Relay) on the link for voice AND
nailing down Traffic management on the Customer router.
What
this means is that for say a 256Kbps Frame relay link we need to run
multiple PVC's (Private Virtual Circuits) one for the voice and a separate
one for the data. Nail the PIR (Peak Information Rate) for
the data PVC so it allows room for the voice PVC - this is
typically 30Kbps per voice channel if the customer is running 8:1
compression so if the customer wants to run up to 4 voice channels across
a 256Kbps link then the maximum data we can let him push across the link
will be 136Kbps - at this rate they might as well buy a separate link for
voice and data - really it does not cost much more in the scheme of
things.
Run VOIP of acceptable quality over an
Internet link? Forget it....
*1 But what
about RTP? I hear you ask.....
Well RTP illustrates the kludge on a
kludge approach of IP nicely.
OK lets start with the voice
payload running at a fairly typical 8:1 compression we want to keep
latency down so this limits the sample size - most VOIP vendors reccomend
around 50mS or 160 bytes as this means round trip delay is not much more
than 100mS which allows for some latency across the network and a
missing packet does not make a significant hole in voice quality.
Now
if we compress that at 8:1 means we now have a tidy 20 bytes of voice
payload.
Now comes the real genius VOIP uses a protocol called
RTP which runs under UDP and then IP
so:
IP adds 20
Bytes
UDP adds 8 Bytes
and
RTP adds another 12 Bytes
This
means that we end up adding a 40 Byte header to our 20 Bytes of payload
and we have not yet even added transport layer Overheads is
this efficient or what?
Of course you can run cRTP (or compressed
RTP) which knocks the header down to a more comfortable 2 or 4 Bytes
provided; Your link is not going via ATM, Ethernet or another IP network -
which pretty well counts out most of the lower cost WAN options and only
leaves us with either a dedicated point to point link or Frame Relay,
either of which is likely to add about another 6 Bytes or so for
Transport.
Of course there are plenty of other caveats regarding cRTP and I have to
say that I have seen very few people using cRTP instead of fully fledged
RTP.
So in summary, on a good
day VOIP suffers about 50% overhead but more typically (and realistically) runs at a monstrously efficient
200% and the irony is the big marketing push for VOIP (over full Quality of service protocols
like ATM) was that it 'could' be much more efficient than
ATMs 10% overhead. |
