Path: utzoo!telecom-request Date: Sun, 9 Jun 91 01:28 GMT From: Bob Frankston Newsgroups: comp.dcom.telecom Subject: Re: Hollings and Pac*Bell Message-ID: Organization: TELECOM Digest 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 437, Message 2 of 8 Lines: 54 The issue of protocols raises its ugly head. Pac*Bell is able to provide some compelling features because it owns the network. The issue is not simply one of pricing but rather the fact that it can create the protocols it needs to provide the services. In fact, many of the protocols are intranetwork protocols that are generally available to telcos. A common theme of my messages is that these protocols must be exportable. Unfortunately, protocols generally means CCITT and a design cycle that guarantees irrelevance. 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. 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. 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 otherwise the Judge Greene error is for naught. [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. Also, telco *could* now provide 'programmable forward on busy / no answer' if they wanted to. 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! Phooey on that ... it is useless to me. So they could give these two items to competing voicemail operators if they wanted to. PAT]