Path: utzoo!telecom-request Date: Mon, 10 Jun 91 03:59:15 CDT From: Al L Varney Newsgroups: comp.dcom.telecom Subject: Re: Hollings and Pac*Bell Message-ID: Organization: AT&T Bell Laboratories Sender: Telecom@eecs.nwu.edu Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 443, Message 2 of 5 Lines: 136 In article Bob_Frankston%Slate_ Corporation@mcimail.com (Bob Frankston) writes: > The issue of protocols raises its ugly head. An evil I'd love to stamp out, but I haven't thought of a better way. An the most evil part is the letter "s" at the end of "protocols". > Pac*Bell ... can create the protocols it needs to provide the services. > .... Unfortunately, protocols generally means CCITT and a > design cycle that guarantees irrelevance. It would be interesting to compare the US staff-years spent on CCITT and ANSI protocols in 1990 vs. 1980 (pre-divestiture). And the cycle is soooo slooooow. Even Bellcore's drags on. > In the spirit of naive optimism I'd like to see a law that allows > telcos to offer these services but with the condition that the > services be done with an arms length subsidiary and that any protocols > used would be made generally available to third parties. Most services are tested during the protocol discussion stage. I'm not aware of any TELCo yet stating they would NOT make protocols available to the public (but not free), and ONA probably forces this to occur. This does not mean a private vendor can't develop something without public input and offer it to one or more Telcos as a product. The standardization lag would give the original vendor a large market window, however. This doesn't happen often because TELCos don't like to be stuck with a hot-shot product with only a single source (unless they start manufacturing themselves, of course). There is always the threat that the Standard will be deliberately different from the original product ... > Understanding the difficulty of designing good protocols, there would > be a grace period in which they can experiment with protocols without > invoking the full standards wrath but that they would have to have a > process for advancing the protocols beyond their initial design. > Perhaps they would also be allowed a not-for-profit grace period in > which they can experimentally try out the services. Happens all the time today. I am not aware of any law/rule that prevents the TELCo from having "market trials", "technical trials", etc. Many RBOCs also have "test labs" for trialing new technologies in a "non-penalty" environment. The "Intelligent Network" view, where TELCos do their own feature programming would allow them some lead time over other vendors and/or RBOCs. > I do appreciate the difficulty of creating good protocols and I don't > want to inhibit the process but with transition from POTS to ISDN and > other digital interfaces, we need to realize that the ability to offer > these services, even in arms-length subsidiaries with no revenue > sharing, is based on a policy of proprietary protocols. > Making these protocols available external raises many network > integrity and performance issues, but these issues must be faced What protocols are not external, if you have the cash for the CCITT, ANSI T1 and Bellcore requirements? I know there is some black holes around Autovon, 911 and Call Trace mechanisms, but ISDN is well documented. Of course, you have to decide which version(s) to support .... The "stutter dial tone" issue, even in its old form, is simply one of providing access lines from the Message Center to the switch(s) of it's subscriber(s). If PacBell is using a different implementation, the only one that's available on AT&T switches is also Publicly documented. Again, there are 3 versions, but its standard :-) (See below). > [Moderator's Note: One of the nicest features of telco-operated voice > mail is the stutter dialtone which advises the subscriber of new > messages waiting. It should not be that hard for telco to provide this > to the competitors: A third-party voice mail system would send > messages to the serving CO (of the subscriber) saying 'turn on > stutter' or 'turn off stutter'. They'd send this message on a special > data circuit, and your CO would toggle it on or off, just as it does > now for telco's own voicemail service. Patrick, You ain't gonna believe your suggestion has been turned into code already!! Bellcore's TR-866 provides the interface spec. for ISDN-connected Voice Messaging Services, allowing them to turn stutter tone on or off, or light a lamp/indicator on your ISDN terminal. ANSI T1S1 has requirements mostly ready for approval that provide the National specs. for both the ISDN- and non-ISDN- Voice Messaging Services. This includes the method for switches to notify other switches (via SS7) to activate/deactivate the appropriate indicator. With ISDN, you can actually have multiple indicators, one per Message System. So in theory, the protocol IS available to the public (and the switch vendors). In SS7 areas, the Voice Messaging provider will only need connectivity to one switch (unless you want backup lines). The real problem here is the usual one with protocols. No, not the snails pace of design or the lack of detail. It's too many cooks. TR-866 specifies an inter-switch protocol that will not work with ANSI (even though Bellcore wrote the ANSI version??), and the two ANSI specs disagree on whether or not one parameter is required. > Also, telco *could* now > provide 'programmable forward on busy / no answer' if they wanted to. This isn't available on all Ameritech switches (especially those nice 1A ESS(tm) switches). Ameritech Mobile's oldest switch is probably two years old; they ditched all the original switches. Try to talk the regulators into allowing the wholesale replacement of all those old(er) switches!!! > Ameritech Mobile presently allows me to toggle 'forward on busy / no > answer' as I wish; AND program it to any number, anywhere, but > Illinois Bell (my hardwired service) insists that this feature can > only be programmed in the CO on a work order (that of course means a > fee), and that it cannot be turned off or on (except by CO action), > and that forwarding MUST be to another number in the same exchange! Actually, intra-office is no longer a restriction, if IBT wants to buy the feature ... But the Busy/DA forwarding is CO only unless you want to pay for a "Centrex Station Rearrangement" capability; your own Recent Change terminal (but only for lines in YOUR Centrex). So PAT, how about helping me out with something? I need the exact quote and author for something like: "That's the wonderful thing about Standards; there're so many to choose from!" Thanks, Al Varney, AT&T Network Systems Disclaimer: These are my opinions, and hardly proprietary. [Moderator's Note: I've heard this quotation before, but don't know who authored it. Maybe other readers can tell us. PAT]