VoIP is a hybrid of data structure and voice application, so all the flexibility of data programming can now be applied to telephony applications.
Previously, phone systems were filled with proprietary hardware and software. If you wanted to add five more phone lines, you had to hope that your system had the room for an additional card — and the standard upgrade cards probably had more or less ports than you needed. After you finished installing the phone lines, your hardware vendor still had to sit on site to program the lines and give them the standard voicemail box.
The creation and release of VoIP has inspired a generation of programmers who didn’t stop at devising a way to send voice calls over the Internet. They took on the office phone systems, as well, and decided to write open source software, such as Asterisk, on which other programmers could build. Now, you can have a fully featured voice telecom application running off a standard server with interface modules that are as easy to install as a new video card.
The largest structural downside to VoIP is the legacy data network over which the calls are transmitted. The Local Area Networks (LANs) and Wide Area Networks (WANs) were built years ago for the smooth transmission of data, and not for a real-time application such as voice transmission.
Here are the challenges that VoIP faces because it has to use existing LAN hardware:
Packets Per Second: Servers, routers and network hardware are rated based on an idea of Packets Per Second (PPS). Data traffic doesn’t really concern itself with PPS because, instead of sending a large volume of small packets on the LAN, it solves the problem by sending fewer packets, with each individual packet containing more data. But the real-time demands of VoIP discourage sending large amounts of data in individual packets. Losing a single large packet of data on a voice call might keep the call from connecting or affect the quality of the call. VoIP requires ten times as many packets to send the same volume of information as a data transmission.
Retransmission potential: The primary protocol used to transmit data across the Internet is the Transmission Control Protocol (TCP). It confirms all packets are received by sending a count of how many packets were sent before the transmission is completed. If the receiving end received less than the total number of packets reported to have been sent, the missing packet can be resent without corrupting the transmission. Voice calls aren’t that forgiving. They’re transmitted with a leaner protocol called User Datagram Protocol (UDP), which doesn’t allow packets to be retransmitted. If a packet doesn’t arrive, it can’t be retransmitted; if it arrives out of sequence, it’s discarded.
The inability to retransmit lost or corrupted data removes the possibility of a simple redundancy tool in VoIP transmissions, and is why every network engineer deploying VoIP is concerned about any delays in the delivery of VoIP packets.
Traffic pattern: Data transfers tend to be long transmissions with a consistent flow of packets from end to end. Uploading or downloading a large file may take 30 or 45 minutes, during which time the packets are diligently being sent and received. Voice traffic has a patchier transmission style — your office may receive a barrage of calls between 9 a.m. and 10 a.m., and then the volume may drop off considerably before another spike hits in the afternoon.
All the issues in the preceding list are a challenge for VoIP to function within an environment that didn’t anticipate its arrival. The market is continually responding to new technological needs, and I’m sure that newer, faster equipment will evolve to cater to this growing market.
