|
How Far Does Your Voice Go Before Getting "IPed"?
One area of continued confusion in VoIP discussions is the question of where in a given network does the voice get converted to IP. There are several differing approaches to this issue and given that each has its pros and cons, the discussion below serves to identify the options.
A voice comes out of our mouths as movement of air which goes into the telephone handset and gets transformed into an electrical signal. Initially the amplitude and frequency of the electrical signal vary in proportion to the voice's amplitude and frequency (an analog signal). An analog phone sends that signal out along its wires. A digital phone on the other hand takes that analog signal, samples it at frequent intervals, describes it numerically, converts the results into a sequence of binary numbers (1s and 0s), and sends that binary sequence as a series of electrical "pulses."
In the case of Voice over IP, rather than just sending the digital sequence out along the wires as pulses, the digital sequence is transmitted using the (TCP/IP) protocol suite. This involves chopping the data into packets with addressing and labeling headers. There is considerable variation on where this "packetization" occurs:
- In an IP Phone the voice gets "packetized" and transmitted over the IP network by the phone itself. (This is the case with systems like the Cisco AVVID where the telephones connect directly to the IP network.) In this category we place IP soft phones . IP soft phones are computer applications which use the computer's microphone and speakers (or headset) in the place of a regular telephone handset. Dialing and feature access is then through the software's interface. Digitization and packetization are performed in software.
If the phone isn't an IP phone, then the signal must be carried over a circuit to another device.
- This device could be an IP converter for the individual phone, so the phone-and-converter together act just like an IP phone.
Alternatively, the device could be a line gateway which provides an IP interface to a number of phones, and switching incoming IP streams between them. Line gateways vary from providing analog telephones the equivalent of POTS line access with no special features, to gateways for full-featured digital telephones.
Finally, the phone could connect to a fully-fledged (IP-enabled) PBX .
The situation with connection to circuit-switched networks is somewhat analogous. The trunk lines (either single lines or multiplexed lines) would connect to either a trunk gateway or an (IP-enabled) PBX.
What Is an IP-enabled PBX?
If we look at diagrams (d) and (f) the phones and the trunks are connected to the IP-enabled PBX exactly the way they would be connected to a traditional PBX. So the question naturally arises, what "IP-enables" a traditional PBX?
A traditional PBX has its phones connected as in diagram (d). But theoretically a PBX could also work with phones connected to the IP network via mechanisms (a), (b), or (c). In this instance an IP connection between the PBX (or its IP line interface ) and an IP Phone (or converter or line gateway) is treated by the PBX as a special sort of telephone line. Many of the PBX vendors have released line-side VoIP implementations for their PBXs.
Another use of the IP network by a PBX is to carry communications to another PBX or its own remote nodes, replacing PBX-to-PBX trunks or the direct fiber of a fiber remote with an IP trunk interface . Most of the major PBX vendors, like Nortel, Lucent, and NEC to name a few, have released trunk-side implementations of VoIP.
Finally, PBX vendors are eyeing the enormous capacities (in the terabit-per-second (10 12 bps) range of the new generation of IP switches (or packet switches in general). A digital telephone produces a 64 kilobits-per-second (6.4x10 4 bps) stream. Even with the overhead of packetization, the IP stream is less than 100 kilobits-per-second (10 5 bps),and terabit switching corresponds to 10 7 or 10 million separate voice connections! So packet switching is much more efficient/cheaper than traditional circuit switching. It is therefore not surprising that the vendors are showing in their "road-maps" IP switching replacing circuit switching inside PBXs. So a PBX can be IP-enabled, even without IP-connected lines or trunks, using an IP switching matrix . NEC has on its roadmap the use of a Cisco router for IP switching internal to its PBXs in the future.
To Switch or not To Switch?
In the earliest IP-enablements of traditional PBXs, the PBX treated each IP line or trunk pretty much the way it treats any other line or trunk, and each conversation was switched through the PBX switching matrix. The diagram below shows 2 such IP PBXs, connected using IP trunking via a Wide Area Network (WAN) Link between the two IP clouds. A telephone call from an IP Phone on one of the clouds to an IP Phone on the other cloud uses a lot of system and network resources: involving the switching matrix in each PBX and 2 IP streams for each PBX.
This is to be contrasted with the "pure IP" situation. For example, with a Cisco AVVID implementation, a Call Manager is involved in the set-up of a call between 2 IP Phones, but once the call is established, the 2 phones exchange packets directly.
There is no theoretical reason why an IP-PBX couldn't behave just like the pure IP system and just set up the call between 2 IP Phones and then have them communicate directly, and increasingly implementations of IP-PBXs are moving to this model. In practice the features we have come to expect from a modern phone system are provided at the PBX and so by passing the calls through the PBX the (PBX) vendors found it easier to provide those features to the IP Phones. But this approach means that any IP-Phone-to-IP Phone conversation involves 2 packet streams and burdens the PBX, making it difficult to scale to large numbers of phones and/or simultaneous calls.
In the "pure IP" situation, it would be possible to pass all calls through the controlling device (e.g. H.323 Gatekeeper or Cisco Call Manager) but the vendors have typically chosen the scaleable approach at the expense of features.
Standards
The H.323 family of standards under the aegis of the International Multimedia Teleconferencing Consortium (IMTC) and the International Telecommunications Union (ITU) is central to VoIP. This set of standards includes standards for voice (G.711, G.722, G.723, G.728, G.729) and video (H.261, H.263) compression which are accepted industry-wide. On the other hand, the accompanying signaling/control standards (e.g., H.225) are less widely implemented. In fact, the IETF has a competing standard, called Session Initiation Protocol (SIP). Moreover, Cisco has introduced its own Skinny family of "open" protocols.
Which standards a particular device supports effects interoperability, but, at this stage in the development of VoIP most of the implementations are single-vendor trials. The issue of the success of competing standards is more important in that a device which fails to support the standards which eventually prevail will have a limited lifetime.
Conclusion
We have already referred the reader to our discussions of the current short-comings and future prospects for VoIP technologies. The purpose of this paper has been to present the various current technologies combined under that rubric.
|
