SI
SI
discoversearch

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 : AUTOHOME, Inc
ATHM 23.48+1.2%3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: ahhaha who wrote (17901)12/13/1999 6:01:00 PM
From: Frank A. Coluccio  Read Replies (3) of 29970
 
While it could be made coherent, it isn't coherent the way you've presented it thus far. Your use of the common term "tap" suggests things that are logical from a generic perspective, but it does not support the architectural underpinnings of the real world, without considerable engineering to make it happen. Neither SBC's voice and data, nor T's video/voice/and data services, ride over commonly-engineered paths or circuits, not even within their own networks.

The latter would be the goal of a fully converged network architecture using IP, or ATM, or whatever, but such does not exist yet, leastwise not anywhere that I am aware of. At least not on networks the size of those you've stipulated. Maybe LVLT will do this with IP, and some smaller entities have succeeded in doing this with ATM. But neither of these is as widely deployed, yet, as the majors you've mentioned.

In other words, in each case the specific form of content (voice, video or data) requires its own special engineering treatment and usually its own pathways, as well, per type of provider. The fundamental nature of the voice pathways that SBC would use in its core and edge networks are different from the types of voice pathways that MSOs might employ, as related to the handing off of voice to the last mile.

Stated another way, the packaging of switched voice over POTS that SBC would deliver is far different than that of IP Voice (or even circuit-emulation voice) over Cable that T would deliver.

When a connectoin is made anywhere along another carriers plant, it isn't a "pass-all-things" kind of "tap," as you say, as though just anything could flow through it at will.

The data (voice or data flows) which flows through that "tap" needs to come from a specific type of fabric, and must be discretely mapped; the source-sink relationships of those streams must be type-specific and their handling must be compliant to the rules of each specific type of traffic.

It's as though voice, video and data are all traveling in different dimensions. While those dimensions could be made to intersect and feed one to the other, it would take a deliberate act (mapping) to make it so, and in the process each dimension would need to respect and adopt the rules of travel of the other. These processes are usually facilitated through "gateways" whose purpose is to perform signaling-, protocol- and framing- conversions, among other things.

In conclusion, while everything you suggested is possible and in some ways already being done through gateways, getting from here to there is not as straightforward, or as simple, as your post would suggest. The reason for this, again, is that in an unconverged universe, specific types of traffic require different handling. This fact is further aggravated by the fact that the handling is also media type (SP type) specific, as well.

BTW, when you say T is delivering data through the ATHM face, you did mean via its own cable plant, right? You were not referring to resold SBC plant, in other words...
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext