I think that something's been lost in the quoted statement concerning the need for a high bandwidth channel for voip. Telephony over IP usually "consumes" only between ~ 13 kb/s and ~20 kb/s including overhead. The UDP portion (without the overhead) of those protocols is actually less, typically between ~5 and ~13 kb/s.
Of course, higher-quality voip can be achieved by using less compression, which would crank up its bw requirement, such as to 64 kb/s or even 128 kb/s or higher. But the latter grades of service are not typical for consumer grades of voip, which are intended to supplant PSTN voice.
The higher bandwidth voips would, however, be characteristic of higher-quality voice and program-grade audio services, including studio (broadcast-grade) stereo services. Today, MPEG over ISDN - and in some cases, T-carrier DS0 channels that have been bonded - performs this function nicely.
Getting back on topic, it is not assumed that voip will be the "only" application working over a nailed up (i.e., always on) broadband, or most other forms of access services. If it were intended to be the only service, then a much lower bandwidth than 2 Mb/s (or even lower than 30 kb/s) would suffice.
Explanation:
Since VoIP it is not a deterministic protocol (read: it's not a nailed up connection and must find holes in the pipe to get through), it performs best when it is free to sprint in a clear, uncongested channel. Which is not to say that voip can't find its way through cracks in the traffic, but only that it performs best when there are visible holes.
Such would be the case with adequate (abundant) bandwidth, even if other applications were traversing the same pipe, provided that overall utilization of the channel allowed for it. Consider what would happen if voip were competing with background downloads on a 56 k line, or active surfing activity. There would be considerably less room for the voice application, and performance would suffer. This, despite the fact that the voip app only uses a small fraction of the total available bandwidth.
The problems caused by poor performance would be untenable on a 56 k line if simultaneous surfing was going on. Less noticable, but probably still jerky (and by no means commerical grade voice) over ISDN, when FTPs were taking place.
One would assume that a 1 Mb/s pipe would be more than suitable for both applications, until you introduce VoD or gaming apps. The lower the bandwidth it has to operate in, however, the more it begins to perform like an old cockroach squeezing through a plugged up crack in a wall (i.e., other demanding applications competing for bandwidth).
The lower the bandwidth, the less likely it is that voip will find room in a timely manner. If it doesn't find an opening in a timely manner, it backs up in buffer, causing jerkiness, resulting in an overall poor-sounding product.
Conversely, the more "head room" (or under-utilized bandwidth) in the channel that the roach has to function in, the easier it is to travel with the other applications, with the least amount of latency. The high bandwidth requirement, therefore, is not what voip actually "consumes." Rather, it is a statement of the best environment in which voip functions with low latency and jitter, when other applications are sharing the pipe.
Having stated that, the author might have been just as correct, for all practical purposes, if he had stipulated 512 kb/s. Or 256. As you go lower, the higher the frequency of jerky events (jitter and other artifacts of latency). Better yet, he could have done us a real service and introduced some of the facts I've listed above, and provided a graphic showing the various traffic mixes and what the prescribed bandwidths for those mixes would look like.
It is assumed in these cases that voice is not the only application riding over the larger bandwidth pipe. The voice packets, along with the remainder of the applications sharing the bandwidth, of course, are subject to the rules of arbitration carried out by the constructs that make up the IP protocol.
The remainder of the bandwidth, in conclusion, would be "consumed" by other, more-demanding data applications, or it goes un-utilized... which is not uncommon.
The alternative is to provide a much narrower bandwidth, say, 32 kb/s (as might be the case with a nailed-up ATM PVC), that is dedicated to voip at all times, only. This would result in an unshared situation, hence, a less-efficient channel.
In the end, it could very well be that a 4 Mb/s pipe will someday be insuffucient to support high quality voip, if the pipe becomes stressed beyond its operating limits by future applications, as they each compete for their fair share of head room.
FAC |
