Mike, this is a relatively fundamental point, as things go, but in the overall confusion that exists over VoIP, you ask an excellent question:
>>OR, can you use voice circuit switches on an IP based network?<<
Well, that's the other side (the under side?) of the painting.
All of the high capacity ITSPs who supply VoIP services today are utilizing, in one way or another, traditional voice circuit switching platforms.
Some of them are using programmables like the Excel or Summa platforms. Some of them Class 5 end office switches, such as 5E's, DMS's, EWSD's, AXE's; some of them are using international gateway switches, and some of them are using hybrids.
Whatever the platform, these switches are being used in conjunction with VoIP gateways and VoIP-enabled routers, as illustrated below in my John Naggi <sp?> drawing. <Does anyone remember John Naggi?>
Therefore, on phone-to-phone call setups which use the PSTN as the origination vehicle, the answer is:
Yes, traditional circuit switches are still, by and large, an essential part of the VoIP model.
Caller-->Class5-->Tandem Sw-->ITSP-POP-Switch-->IP Gateway--> Router--> IP Private Backbone (or) Internet--> (ditto in reverse)
The above diagram is perhaps overly generalized. Suffice it to say that variations of many types exist. But it does serve the basic purposes of this discussion.
The more sophisticated ITSP models, as they are evolving today, are beginning to employ SS7 hooks between ITSP locations, and between end office locations, on an as-required basis, for 800 calling, enhanced services, follow-mes, customized billing, etc. And some CTI-based applications which are tied into VoIP networks actually obviate the need for SS7, or will work in conjunction with SS7.
IP-based voice networks that support voice communications will continue to use switches, either on-prem or off-prem (through the use of PRI interfaces and T-1s, for now...with higher level flows later on), at least during an interim period (and probably longer), until call- and route- management features, along with automatic message accounting (billing) features evolve in the yet-to-be-defined family of routing network elements. At some point in time, routers <?> or a new class of network element, will be able to stand on their own, without reliance on the traditional model, which, by definition, involves circuit switching. We've got a long ways to go before then, IMO.
>>To add further confusion, I ran across this piece by George Gilder that almost directly answers my previous question. Here is what Gilder believes Qwest is doing:
"Consumers will access Qwest's IP long distance service by making a local call on a normal telephone, dialing into a circuit-to-IP platform made by Vienna Systems, a Newbridge Networks affiliate. Newbridge has long preened as the prime champion of asynchronous transfer mode (ATM), an additional smart layer between the customer and the hardware. The Vienna platform will simply packetize the raw, 64 kbit/s signal, and send it via IP." <<
Very few IP gateways merely convert and then transport 64 kbps voice without compressing it. I'm not sure about Vienna's, but I don't think that this is the case. In any event, there is more to this. There is a problem, I believe, in the way that this paragraph was written, or, at least, in the inferences that one draws after reading it. (Sorry about that, George.)
There are three independent statements being made here, which I believe are getting confused, unduly:
1.) Vienna Systems Inc. produces a Voice-to-IP gateway.
2.) Vienna Systems is an affiliate of NN.
3.) NN is a champion of ATM.
The obvious error that one can easily make (including myself, until I read it several times) is drawing a conclusion through inferences that the Vienna VoIP product is ATM-based. To the best of my knowledge, it is not.
But there are some products that do what these inferences suggest, or what I have inferred GG meant, and if Vienna's is one of them, then I stand to be corrected. If anyone knows better, please advise.
But let's just take this on a hypothetical level, and assume that the inference was correct, and that the product takes voice, packetizes it at 64 kbps, and sends it out over ATM. That is the hypothesis.
It makes sense here to point out that surely this is a possible variant of what I outlined above in my little character-based sketch. What this hypothetical model suggests (or we may take license to assume that GG has depicted), is the classical inter-machine trunk, or that portion between ITSP POPs as illustrated in my sketch.
In this instance, simply imagine utilizing IP over ATM instead of a pure IP Backbone (or the Internet), and the model works just fine, except for the fact that is less efficient. Sometimes this inefficiency is offset sufficiently, in the opinions of some carriers, by a greater degree of manageability of the overall network. This perceived "ease of administration" of the overall network is one of the stated strengths of ATM.
It's a classical example of case-by-case trade-off analysis that carriers will be forced to contend with: The cost of bandwidth versus ease of administration. Or, so the story goes...
One thing that would be missing in this 'hypothetical' account is the use of compression. It is unlikely that the full 64 kbps would be mapped to ATM, going forward, as this would be extremely wasteful of bandwidth for the normal telephone call, given voice quality that is attainable through the use of DSP compression algorithms available today.
It would be more like a 16kbps or 13kbps (cellular), or 8kbps compressed scheme, or even the G.721.3 scheme used in VoIP eventually, even if it were over ATM. There is, in fact, a VTOA (voice telephony over ATM) standard that speaks to these issues, and mfgrs such as NT and GDC are currently shipping these capabilities in their Magellan and APEX families, respectively, as we speak.
>>It makes sense, but isn't the quality going to be pretty bad? It's sent as an ATM IP packet (I think that is what Gilder is saying), but I thought even using ATM, VoIP still was not ready for prime time. Did I miss something in Gilder's comment?<<
Staying with our hypothesis, it's not the quality that would be pretty bad, rather it would be the throughput efficiency that I would be most concerned about, if I were counting the costs of transporting bits and bytes.
Actually, if the transmission were set up according to our hypothetical model, the quality would be "excellent," since there would be minimal if any degradation due to compression artifacts if the full 64 kbps were being employed on the line side. But the bandwidth costs incurred in sending these messages, would be increased eight-fold, or whatever the compression ratio would be, in a truly packetized scheme that uses compression.
Some important things to remember here are
(1) ATM is 'sometimes' a part of the underlying carriage, whether we know it or not, when the carrier or backbone provider so chooses to use it between major nodes (which is often the case), and
(2) the IP layer is actually the service or convergence layer protocol.
A very simplistic analogue is this: Where ATM is the railroad car, TCP/IP is the passenger. SONET, of course, is the track.
When IP is mapped on top of ATM, there are many redundant bytes in the overhead sections of these two protocols, whose stated intentions are almost identical. But only one set can be used. These overlaps can never be fully reconciled, hence, redundancy in the purposes of some bytes, and the ensuing lower efficiency on a packet by packet basis.
Translation: It takes considerably more bandwidth to deliver the same amount of information when both protocols are used. The flip side being: When both are used, call handling capabilities, administration, and overall network architectures "may be" greatly facilitated, depending on many variables which make up a list that is far too long to cover in this post.
HTH, and Regards, Frank C.
|
