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 (1721)	10/27/1998 10:04:00 PM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 3178

Hal, I think that I've answered many of the questions, but if you don't think so, then I didn't do a good job of it :-\| Now that I know what you're referring to in the way of Accelerated's line of wares, let me do a study of it tomorrow and I'll get back to you with my take. One thing though, is that VoIP rides at a higher layer (Layers 3 and 4) in the stack than most of the protocols that this platform uses. Most of the DSLAM and AN 20/30 shenanigans, in other words, are at Layers 1 and 2. So, no matter what the traditional POTS and GR 303 distinctions are, the VoIP aspect is constant at Layer 3, and does not conflict or contend with the lower-layer legacy voice space. It's independent, so to speak, and will be facilitated by the devices ability to transport TCP/IP, and it does this in a variety of ways, including IP over ATM. But I've gotta look at this closer, and try to read between the lines of the marketechture and the future. On the surface, I don't think that their wording of certain capabilities is accurate to their true capabilities... OR, they're banking on the other service providers to have certain interfaces in place that may not always be true. For example, how many PBXs, or Class 5 CO switches for that matter, do you know of that accept native ATM streams on their interfaces? And their use of the "any.DSL" term is at best puzzling to me (see their definition of this in the glossary), especially when they make reference to a 2B1Q line format in their specifications section. Are they saying that this 2B1Q format can be flashed out on the fly to adapt to other line protocols? Or it is flash reconfigurable? Perhaps configured to "any" dsl from the CLEC's operations center or central office? If either of these is so, that would explain it, but I don't find that stated anywhere on their site, but in fairness I haven't gotten to the white papers yet. Maybe I've misread some major points during my cursory skim-through this evening. Tomorrow's another day. Later... Frank Coluccio