Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Voice-on-the-net (VON), VoIP, Internet (IP) Telephony -- Ignore unavailable to you. Want to Upgrade?

To: hal jordan who wrote (1699)	10/27/1998 8:37:00 AM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 3178

I've got some questions for you about how IP telephony would work in the context of xDSL and dslam technology. Hal, With diversity and progress being what they are today, there are probably a growing number of ways to answer each of your questions. If we look at the historical model of asymmetrical digital subscriber line (ADSL) we really have a very simple specimen to use as a back drop for discussion. There is a POTS line and a data line, the latter being perhaps a bit lopsided, but a data line, nonetheless. In this model, you have two discrete access lines, effectively, separated by a splitter, that do all of the things that either one would normally do on their own. Today, however, with the growing number of protocol conversion capabilities, aided by DSP processes, and the alternative transmission schemes that the last mile vendors are making available, I'd have to tread very carefully in answering your questions. [g] But you've narrowed it down to Generic Requirements GR 303, which makes it somewhat simpler to handle, although I'd want to caution that my reply is aimed solely at that space, and not the more widespread proprietary implementations that are now available. >>1. How would support for voice features such as forwarding or busy tones be accomplished?<< These CLASS-like functions would still be the purview of the Class 5 end office switch, making use of their operating system code, no different than a discrete wireline or digital loop carrier- (DLC-) derived connection. >>2. I'm sure the idea here is that the customer can eliminate separate T1 lines for voice by multiplexing the ATM based voice traffic in with the data traffic. What kind of interface or equipment would a customer based PBX and key system need to get the voice traffic to the xDSL modem with integrated DSP codecs?<< A hard wire cross connect, it would appear to me. >>3. What does a GR303 interface at the dslam buy the customer?<< A consistent look and feel for handing off traffic to the PSTN, and to other generic forms of networks. When brought to the extreme, it standardizes on POTS and ISDN hand offs, in such a way that the customer has access to a variety of different service models. >>My interpretation is that the ATM conversion of voice traffic means the CLEC can multiplex both voice and data packet traffic through the backbone without needing 5Es or DMS at every CO, except at the final handoff in the megapop.<< I'd need to see the particular deployment plans you're referring to. Can you point me to the reference you are using to cite these potentials? The introduction of ATM into the loop, and at the central office gateway, does permit a switch bypass, as is proposed by Sprint's ION, and others, but these are carrier specific adaptations of the technology that most probably do not fit the intended plain vanilla intent behind a more simple use of DSL. The beauty (some would argue the 'limitation') of these standards is that once you have a Layer 2 or 3 fabric in place, which frees one of the limitations of metallic distances... all sorts of wonderful things become possible through established and time-proven mechanisms to get from here to there. For example, through FR-ATM interworking I can handoff the cells from the DSLAM to a FR cloud, for delivery to a remote PBX via frame relay (see my next post), or use some other design that happens to be handy. >>I guess the IP gateway converts the IP/ATM to voice at that final handoff before hitting that 5E/DMS. Does this sound correct? Is SS7 support needed anywhere here?<< If one is trying to navigate PSTNs over distances, using established calling plans and numbering schemes (as opposed to Internet Directories and IP addresses), the answer is still yes, SS7 still plays a role here. But at this point I think you're entering into a different space without my benefit of being set up properly to answer the question. Please elaborate on this one for us, and point to a specific carrier's offering, or create a model in theory that you are referring to. ATM/IP/Voice gateways can be contrived in any number of ways, and I'd need to see specifically what you are referring to. In the meantime I'll brush up on my 303 [it's been a while since I've touched it and have not kept up with all of the latest add-ons] and probably wind up critiquing my own post in a later one... In the meantime, maybe an XDSL expert can jump in here and save me the time? [g] Interesting set of questions, Hal, thanks. Regards, Frank Coluccio