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.
Microcap & Penny Stocks : FRANKLIN TELECOM (FTEL) -- Ignore unavailable to you. Want to Upgrade?


To: detroit denny who wrote (26564)2/4/1998 4:11:00 AM
From: Frank A. Coluccio  Read Replies (5) | Respond to of 41046
 
[[Multiple Replies]] LONG AND ESOTERIC, IN PARTS. READ AT OWN RISK.

=======================================================

Detroit Denny, Thanks for the greetings.

Pictures of two daughters, you say?

> Frank- are you married? We need someone like you in the family..... GREAT post. What did he say. i thought i was trout fishing upstream and downstream.<

That was pretty funny! I just woke up my wife with my laughter and now she's wondering what's wrong with me... Guess that answers one of your questions, eh?

>>Will send you pics of two daughters<<

.gif them to me, I have two Suns. <tech humor>

---------

Jack Sman, The pleasure was mine. Thanks.

-----------------

Seth L ,

> Frank you need to participate more often<

As time permits, I enjoy participating. Thanks.
-------------

Martin P. Smith,

> Frank, thanks for the post. I have a couple of questions.
> 1) The ADSL connection is a continuous link. If you were to try
> to use this for VOIP how would incoming calls be handled at the
> destination end? Would it be over the existing POTS system OR
> via ADSL? I assume POTS since ADSL on the other end
> would introduce routing issues( the ADSL link is no longer
> actually the phone number but effectively a TCP-IP address.)If
> this is the case is there any benefit to sending the
> call through the xDSL side from the source
>>>>>>>>>>>>>>>>>>>>

The beauty of DSP chip technology and well-orchestrated standards implementations is that eventually all of the permutations you've mentioned will be supportive of VoIP. We will be able to launch from one method to any other, as long as the standards are implemented by the vendors in an interoperable manner. In the proof of concept stages when low hanging fruit is at stake, it is OK to do proprietary solutions. But as history has demonstrated enough times in the past, vendors should know better going into the long stretch than to do one-of-a-kinds for too long. In the early stages, there will be the proprietary implementations that will score high marks as the technology gains acceptance, but these will serve to inhibit universal, any-to-any modalities in the long term. Just ask Dr. Wang.

When the big boys start to put their VoIP nets in place in earnest, all vendors will go back to the drawing boards, but quick, to ensure that they meet the then IMTC-ITU standards. The carriers don't want to mess around with one-of-a-kinds, simply to add to the number of kludges they already have in place. Some vendors will maintain the ability to do both standards-based and proprietary-based implementations where the latter offers an advantage to the user or carrier.

In your question you make an assumption that ADSL is a continuous link. It may be, and it may not be, depending on the implementation and the features chosen, and more importantly, what you mean by a permanent link. It certainly is continuous from a physical perspective, but the logical connection could be quite a different story. Let me say a few overly simplistic things about ADSL that do not usually hit the press in a pronounced way:

Aside from the differences in line coding, between MLT and CAP "modulation" schemes, there are three fundamentally different approaches to distributing ADSL in the last mile. Consequently, each has a different way of integrating with the larger WAN at the CO or POP.

The first is switched (via ATM), the second is routed (via IP) and the last is ad hoc, and can be adapted on the fly for various features and attributes. This last approach is likely to find its way into the traditional high density remote access service units mounted in ISPs and CLEC/ILEC COs that I referenced in my first post. This is because RAS units must be able to field a variety of different user hardware and software choices. To the best of my knowledge, this last variant of xDSL is the one that has the greatest likelihood of VoIP integration in the near future, akin to some of the cable modem architectures that have been announced that will also employ VoIP hooks.

Stated slightly differently, the architectural variants may be defined by the underlying backplane and backbone technologies used. One is switched (using an ATM fabric as the dominant architecture) and one is routed (using IP and a shared ethernet-like backplane).

Early on, way back in the early Nineties, Bellcore defined an ADSL model that was, and still is, largely "cell-" based ATM in the CO multiplexer stages, and onto the backbone (but could be, alternatively, routed to the core), and this model uses loop aggregation devices in the CO or POP known as Digital Subscriber Line Access Multiplexers or DSLAMs (pronounced dee-slams).

Another more recently popular version, fostered by the success of the Internet, especially when the Internet is the sole reason for using xDSL, is the router-connected backbone which uses a "framing" approach on a collision domain backplane, and this method uses a loop aggregation device known as a DSL Access Concentrator (DSLAC). I suppose that someone had to make this distinction at some point so that we could have this discussion today. The DSLAM is cell-based and switched, and the DSLAC is frame-based and routed.

Getting back to your question about a call being set up on an ADSL permanent connection... as you can see, if it is over a DSLAM it may need to be intentionally established, since it is capable of "homing" to a variety of targets on a switched basis, hence it may need to be a deliberate call set up. If, OTOH, we are discussing a DSL Access Concentrator, the odds are much better that it is a nailed up or nascent session/connection to the ISP at all times by virtue of the IP routing protocol which finds its way through thick and thin. Much has to do with how the provider wires the service, and whether it is for Internet only, or a more widely selectable utility. I should note that either of these models can support the now-popular concept of a "persistent connection," or IP DialTone. The ATM-based DSLAM version can be "virtually" nailed up, using a "permanent virtual circuit" (PVC) connection to a router.

The DSLAM is administratively more involved with mappings, but it is at the same time, "deterministic," and all that that implies.

The DSLAC, on the other hand, is comparatively free from administrative headaches, but it is "probabilistic," and offers instead a "best-effort" approach to establishing connections. Hence, there are considerable cost implications and tradeoffs, not the least of which are financial, favoring the DSLAC.

And there are other "cost" factors in the networking sense, as well, such as latency, QOS, data loss, hop counts (potentially) and administration, which all play a role in the continuing cost of ownership and receding hair lines. And there is certainly room here for the traditional sort of theological warfare that makes life interesting for all involved when it comes time for the provider to select the "right" architecture.

> 2) What costs will be involved in ADSL connections. These are
> going to be permanent connections.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Early adopters are paying through the nose in many cases. It's funny how the Canadians seem to be getting it right in many of their implementations, and US users are paying almost three times as much for the same types of implementations.

As it scales up, and as more and more specialized ISPs and CLECs begin to offer it, the costs will come down on a region-by-region basis, and I guess that in certain geographic regions it will reach commodity status sooner than others. In fiber-rich terrains, however, where there is a shortage of feeder and distribution copper... where it has been literally pulled out in favor of fiber-based subscriber carrier systems... and where copper is being retired, even in many urban settings, I don't see new copper being pulled (justified) by the prospect of installing ADSL. The latter regions, rather, will be better suited for fiber-to-the-curb-based VDSL, where fiber reaches the neighborhood or curb more readily, and very short runs of copper could extend from a pole or pedestal to the residence or business. Next Level Communications is doing this now in Boston, and is slated to go into the Big Apple later to wire upwards of several million units, combined. VDSL in turn can support extremely high bit rates (52 Mbps in various splits) and support not only what we're discussing here, but multiple NTSC-grade MPEG video channels, simultaneously, as well.

For those settings where ADSL is well suited now, and where there is a ready market for it, I see no reason why the fixed costs of it should be that much more than the "fixed costs" of today's ISDN connections in another two or three years, assuming that it goes in. The usage (time or packet based) costs, however, of ADSL - and virtually every other technology at this point - are questions that are still very much up in the air. The days of all-you-can-eat may be with us for a little while longer, perhaps, but the quality of those all-you-can-eat cloud segments may not be worth a whole lot for anything other than email and recalcitrant downloads, before long. Tiering is right around the corner, where it hasn't shown up yet, and tiered usage will cost proportionally more, tracking performance improvements.

>>>ISDN is similar in this respect and is comparatively expensive.<<<

In many cases the monthly fixed cost component of ISDN have come down, but the usage costs are still egregious in many areas.

Unlike xDSL, ISDN is more than just a last mile technology. It is an end-to-end technology that is infinitely more complex than DSL from a protocol and hardware/software networking perspective. Demanding specifications reach into the end office switches as well as into the customer's premises (as I am sure many here will attest to from their own experiences), and it requires an extensive patchwork of hooks and fixes between the switches of different vendors.

DSL, on the other hand, "is" a last-mile technology, only, and much simpler to implement once the copper has been qualified. One would imagine that based on this fact alone there should be some pricing favor given to DSL. But the outside plant gremlins and the internal politics (inertia) of the LECs are not always apparent on the surface. There are still a number of inhibitors, real and imagined, that can stunt DSL's progress and keep its pricing artificially high in many regions for a long time to come.

Diversity is such, both in terms of demographics and service provider inclinations, that no single answer to many of your questions can be offered. This is a direct consequence of diffusion in the marketplace, and it began in this industry right after the divestiture of AT*T.

> I may be wrong but I think that plain phone to phone VOIP will
> likely rely on POTS for a number of years yet.
>>>>>>>>>>>>>>>>>>>

IMHO, I think that incrementalism and backwards compatibility will demand that POTS evolves by engulfing VoIP, or vice versa. Maybe write offs in this new age of revolutionary events will be more forthcoming than in the past, but backwards compatibility is still very important. And end users will not tolerate two or more different sets of call profiling, nor will they tolerate two or more different directory models. Evolution (gradual integration) and not revolution (sudden displacement) would seem inevitable for this reason alone...

> When we start getting into dialed simultaneous Voice and
> Video over IP then xDSL may come into its own. Voice and Video
> over IP (VVOIP)will require hardware that the xDSL chip can be
> built into. I also imagine that Video phone numbers will be
> different from standard phone number (in fact most likely a
> TCP/IP type address) this would eliminate the need for lookups > in the gateway.
>>>>>>>>>>>>>>>>>>>>>>>>>

My, you cover a lot of territory! You may not realize it, but what you've stated here effectively makes the case for the creation of a platform that bridges the chasm between TCP/IP, Internet domain name services, a variety of other directory services on the Internet, and the PSTN's (POTS') Signalling System Number 7 and its associated data bases.

---------------

Stephen Temple,

> Frank C> Your in depth forward-looking statements in a few
> area's raise questions regarding Telephony and more importantly
> Franklin's products for the future.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I wouldn't jump too quickly and make any snap judgements about the gateway marketplace, especially since what I've been discussing here is still for the most part in the alpha stages and, depending on who you speak with, approaching the proof of concept stage. Remember that within the established carriers there exists an embedded plant worth hundreds of billions of still-depreciating dollars, and a back-office environment the size of Greenland. Incrementalism, for many of them, will be the only way to go, and that means using gateway "adjuncts" to a large degree where they choose to employ VoIP.

Adjuncts or gateways are nothing new, whether they are for VoIP, or for ISDN or ACDs (automatic call distributors used in call centers). Existing switches don't have the inherent capabilities to execute local number portability, so they go out and they buy adjunct switches to assist in this process. Gateways. Every time a new technology appears, it is first "attached" in some way or another to the prevailing "host" through an adjunct (gateway), and then later "integrated" into some future rev or upgrade that hasn't been in the queue for too long.

To add to this backdrop, all local carriers have been issued mandates that translate into making local competition more accessible, and the way they will do this is by extending billing and operations support systems and local number portability capabilities to the competitive LECs or CLECs. How would they do that with anything other than what they have in place now? The operations support systems (OSSs) alone, never mind their associated actual switching "machines," take many years to shake out.

> If we make the statement> "As we are seeing more and more, the
> computer is the network", then how do you see the (ATOM ASIC's /
> chips optimized for xDSL products), working in conjunction with
> the next generation of ADSL modems which will make internal
> cards a reality.? "As you know, these cards will be
> predominantly ATM-based and offer native ATM services within the
> PC".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

See my reply above concerning DSLAMs and DSLACs. DSL devices handle both cells and frames and can be either switched or routed. We should keep in mind here that DSL is an OSI Layer 1 technology, whereas ATM is Layer 2 and IP is Layer 3. What this means is that they are not interchangeable, per se, rather, the lower layers are designed to support the higher layers where they "converge." In the case of Layer 1 DSL, it can support Layer 2 Cells (ATM) or it can equally support Layer 2 Frames (Ethernet). In turn, cells and frames can support Layer 3 IP.

In any event, the ITU standard should create the potential for any to any connectivity, whether we are using cells or frames on top of the DSL. Once the hooks are in place to support the IP in the VoIP standard, then the hooks are already in place for the IP to ride over either cells or frames, and both of these can ride over DSL.

> Since Franklin builds "ethernet cards", could a ATM/ADSL &
> TEMPEST-CARD be built for the PC, (home&office use), since as
> you said " this market is relatively new", have a chance for
> success.?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Let me dance a bit here. Increasingly, if you can conceptualize it, then it can be done - unless it is entirely off the wall. I am not privy to the intentions of Ftel's marketing and engineering in this regard. In a more general sense, tho, you seem to have gotten the right idea. It's a matter of marketing strategy and timing, however, and where resources can best be expended.


> You made the statement> "This does not minimize the role of
> gateways, rather, it extends the VoIP paradigm to yet another
> means of deployment: One that I feel will be more in line with
> the capabilities of the IP world in the future. But we ain't
> there yet".
> Is it your understanding that the "Tempest" in general as we
> know it, will also work hand-in-hand **Through the TCP/IP
> session into the cloud _**without**_ the need
> for entering a POTS switch?, at the area POP's?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

If you are referring to the total elimination of telco switches at this point in time, to the best of my knowledge the gateways are not designed or intended to do that on their own, yet, unless, of course, you are referring to placing calls to network PCs <as opposed to POTS phones>. They still need interaction with POTS, if for no other reason than to secure a path to existing phone lines to the called parties. And this requires data base lookups that are not a part of the Internet, yet.

> Or, how would you ultimately see the DVG's being utilized within the Business and
> Private Sector?.

In every way possible where the price was right and the quality was good. I see a large potential, initially, where the gateways allow for the creation of virtual inter-machine tie lines over private IP backbones. These would replace dedicated and costly tie lines. And they would allow for maximum quality, provided they were engineered properly.

In the short term, however, I do not see the largest businesses doing any uptake, despite some exceptions, because they are already getting high quality voice for under a nickel. The career risks are huge to anyone suggesting Internet Voice in those organizations who can justify 4 cpm, and could be fatal if anything should ever go wrong. FUD Lives. Later on, when the small to mid size businesses prove the technology in, and the technology has had some time to mature, larger businesses will begin to lop the voice onto their heavier data backbones, and begin realizing even larger economies than they are today. More importantly, though, they will begin to use IP for application convergence purposes, where voice will be but one component.


> Correct me if I'm wrong, but I see Franklin's Telephony Service
> and no doubt "quality of service" with Worldcom & MCI's
> ATM capabilities a real threat to the Telephone Companies as we
> know it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Whom, aside from Worldcom and MCI, "are" the telephone companies as we know them? Combined, they constitute the second largest entrenched behemoth out there, and both of them with aging and non-VoIP enabled goods, no? The scale and diversity of hardware that they have erected in their POPs is almost incomprehensible at first viewing. Their (WC and MCI) bread and butter are at stake here just as much as any other telco, and they will have to learn how to turn the threat into an asset of their own just as quickly as the BOCs. As we speak, MFS and Brooks are plowing ahead with new announcements every day about their latest acquisitions of Class 5 CO Switches. Haven't heard any mention yet of them buying any VoIP gear of their own (doubtless they have, for trials), but this business about "if anyone is going to cannibalize our business it had better be us" has a long way to go before it can prove in from a five-year flow perspective.

Much of the rest of your post is very interesting, but I am afraid that I cannot speak to, or even begin to guess, what directions Ftel plans to take on many of the issues you bring up. I suggest that you contact them directly. They seem to be a good bunch to talk to.

Regards to All, Frank Coluccio