Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id NAA23547; Fri, 3 May 1996 13:00:28 -0400 (EDT) Date: Fri, 3 May 1996 13:00:28 -0400 (EDT) From: ptownson@massis.lcs.mit.edu (Patrick A. Townson) Message-Id: <199605031700.NAA23547@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V16 #214 TELECOM Digest Fri, 3 May 96 13:00:00 EDT Volume 16 : Issue 214 Inside This Issue: Editor: Patrick A. Townson Voice/Fax Mail to Internet Mail (Richard Shockey) More Voice/Fax Mail to Internet Mail (Richard Shockey) Pac Bell *Still* Doesn't Recognize NPA 268 (Antigua) (Linc Madison) ANI Information From D-Channel (tjo94001@uconnvm.uconn.edu) ADSI Standards and Devices (Klaus Zuenkler) How Will Local Telephone Competition Work? (turner7@pacsibm.org) Need Basic Information On Direct Link Microwave (Theresa Riter) Does Caller-ID Hunt or Call-Forward? (David Brod) Re: Different Countries - Different Results (Hendrik Rood) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * ptownson@massis.lcs.mit.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 500-677-1616 Fax: 847-329-0572 ** Article submission address: ptownson@massis.lcs.mit.edu Our archives are located at mirror.lcs.mit.edu and are available by using anonymous ftp. The archives can also be accessed using our email information service. For a copy of a helpful file explaining how to use the information service, just ask. ************************************************************************* * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ************************************************************************* In addition, TELECOM Digest receives a grant from Microsoft to assist with publication expenses. Editorial content in the Digest is totally independent, and does not necessarily represent the views of Microsoft. ------------------------------------------------------------ Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- From: rshockey@ix.netcom.com (Richard Shockey) Subject: Voice/Fax Mail to Internet Mail Date: Fri, 03 May 1996 04:33:12 GMT Organization: Netcom Centigram Supports Universal Messaging Standard Protocol With Other Voice Messaging Industry Leaders; Company to Demonstrate Multimedia Internet Connectivity Between Disparate Voice Messaging Systems ------------------------------ EMA '96 -- VPIM Booth No.369, Centigram Booth No.332 This group may find the following announcement of considerable interest. It seems self evident that the voice mail industry is ready to jump into the internet in a rather big way. The companies listed below represent 60 percent of the voice processing industry in North America. Add to that fax traffic ... 45 percent of transatlantic telephone traffic is fax according to ATT. Microsoft is probably not to happy about all of this since the delivery of most mail object types [voice / fax /email ] over SMTP transport layers does nothing for their Exchange Server Strategy. Remenber ... though Microsoft was wise is supporting the moderator of this forum ... they have been known to drop the ball from time to time. In addition I sincerely recommend persons interested in this subject to point their browsers to http://www.imc.org The Internet Mail Consortium is the best single site for any information you would ever want to know about Internet mail. Of particular interest to this group would be RFC 1911 an expermental Voice Profile for Internet Mail done by some folks at Octel ... who seem to be leading the charge on delivering Voice Mail over Internet Mail. The following press release strikes me as only the beginning. ################################ ANAHEIM, Calif.--(BUSINESS WIRE)--April 29, 1996--Centigram Communications Corporation (NASDAQ: CGRM), a leading global provider of communications solutions, today announced its participation in the joint development of the voice profile for Internet messaging (VPIM) protocol for transferring messages between disparate voice messaging servers. Centigram, a member of the VPIM Demo Work Group developing this standard, will demonstrate interchanging voice and fax messages with the other members of the group -- Lucent Technologies (formally AT&T), Northern Telecom (Nortel), Octel Communications and Siemens Rolm -- at the EMA `96 conference. VPIM enables the creation of voice, fax or compound voice and fax messages on a Centigram Series 6 communications server, and sends them over the Internet or private intranet to other vendors' voice messaging systems. This interoperability would allow Centigram users to exchange messages conveniently with their suppliers, distributors, customers and even family and friends using different vendors' voice messaging servers. In the future, communicating among disparate voice messaging systems can be as easy as communicating between disparate e-mail systems over the Internet is today. VPIM builds upon two Internet e-mail standards, simple message transfer protocol (SMTP) and multipurpose Internet messaging extension (MIME), to include such benefits as sender spoken name and compound voice and fax messages. "We are excited to be at the forefront of this universal connectivity by supporting interoperability among disparate voice messaging systems using VPIM," said George Sollman, Centigram president and CEO. "It is imperative that the work group, as leaders in the voice industry, complete and deploy VPIM. In the near future everyone with a VPIM-enabled messaging server will benefit from more effective communications and higher productivity through fast, low-cost messaging." Centigram plans to use Internet protocols and Internet connectivity to enable voice and fax messages among different vendors' systems. The VPIM Work Group has utilized these well-established e-mail standards to implement working interoperability prototypes in only a few months. With VPIM, users will be able to make an Internet voice message from any telephone and deliver it directly into the recipients' voice mailboxes. The Internet also provides cost-effective network access points throughout the world. VPIM Work Group The Electronic Messaging Association (EMA) sanctioned the VPIM Work Group to develop a universal messaging standard protocol to promote effective communications among voice messaging users of various vendors' voice messaging systems. The VPIM Demo Work Group, made up of Centigram Communications, Lucent Technologies, Northern Telecom, Octel Communications and Siemens Rolm, began working on its cross-system voice messaging protocol in 1995. Centigram Communications Corporation Centigram is a leading global provider of communications solutions. Centigram delivers communications solutions by integrating voice, data and facsimile on its Series 6 communications server, and by providing access to this multimedia information through a telephone or PC. The Series 6 platform is based on industry-standard hardware and software. Centigram also licenses TruVoice(R), its patented text-to-speech software. Centigram is headquartered at 91 East Tasman Drive, San Jose, CA 95134. Phone 408/944-0250, fax 408/428-3732, World Wide Web http://www.centigram.com. Centigram has sales and support offices in North America, Europe, Asia, Latin America, and Australia. Centigram and TruVoice are registered trademarks of Centigram Communications Corporation. Richard Shockey Developers of Fax on Demand Solutions President For Business, Media, Industry and Nuntius Corporation Government. 8045 Big Bend Blvd. St. Louis, MO 63119 For a Demonstration Call our Voice 314.968.1009 CommandFax Demonstration Line FAX 314.968.3163 at 314.968.3461 Internet: rshockey@ix.netcom.com ------------------------------ From: rshockey@ix.netcom.com (Richard Shockey) Subject: More Voice/Fax Mail to Internet Mail Date: Fri, 03 May 1996 04:42:39 GMT Organization: Netcom More self serving but technically significant information about the future of voice on the Internet. ####################################### Designers of OcteLink Architecture Foresee Global Voice Messaging Interoperability MILPITAS, Calif.--(BUSINESS WIRE)--April 29, 1996--Octel Communications Corporation (NASDAQ: OCTL), the company that developed the innovative OcteLink global voice messaging service, is the driving force behind the VPIM protocol. As a core member of the VPIM work group, Octel provided the expertise necessary to author the voice profile for Internet mail, or VPIM, which provides for interoperability among voice messaging systems using any type of LAN/WAN network that supports TCP/IP protocols. "This protocol, along with OcteLink's unique ability to direct messages to the intended recipient, provides a framework for ubiquitous voice messaging services," said Charles Levine, senior vice president of Octel Services. "With the VPIM protocol and OcteLink's directory capabilities, people will be able to send voice messages to a global community, much as they do now with e-mails." In addition to the VPIM protocol, OcteLink supports the OctelNet and AMIS analog protocols. While VPIM enables peer-to-peer exchange of voice mail messages, OcteLink provides unique directory, protocol translation and network operations services. OcteLink determines from whom the message originated, discerns its specific destination and translates the message from one system protocol to another. As leader in development of the VPIM protocol, Octel is uniquely positioned to help facilitate ubiquitous voice messaging technology. Introduced in July 1995, OcteLink supports Internet mail, X.400-based AMIS-Digital and other proprietary and industry-standard messaging and directory protocols. "OcteLink provides the much-needed directory services, security and network operations to provide the truly global voice messaging that the VPIM protocol will make possible," said Mr. Levine. About OcteLink OcteLink is designed to link commercial, residential and institutional customers worldwide. OcteLink consists of messaging hubs (or "voice post offices") that connect disparate voice processing systems and ensure that every message is efficiently routed to its destination. The hubs act as multimedia gateways -- accepting voice and fax with delivery based on the telephone (hard-wired or cellular). Future delivery vehicles will include computers (PCs), personal digital assistants (PDAs), or fax machines; message transport will include e-mail and multimedia. OcteLink hubs are currently located in Dallas and Chicago. Additional OcteLink hubs will be placed in Canada and elsewhere in the U.S., as well as in countries throughout Europe, the Pacific Rim, South America and the Middle East, as demand requires. About Octel Communications Corporation Octel is the voice messaging company. Its worldwide leadership extends to over 40 countries and includes more than 30 million users of Octel voice mail. Octel's products are bought and used by businesses of all sizes, governments, educational institutions, telephone companies and cellular service providers. Octel is also the world's largest outsourcer of voice mail providing a wide range of outsourcing services to phone companies and businesses. Founded in 1982, the company is headquartered in Milpitas, California. It has development centers in California, Texas, England, France and Israel and major operations centers in California and Texas. Additional information is available at http://www.octel.com. Richard Shockey Developers of Fax on Demand Solutions President For Business, Media, Industry and Nuntius Corporation Government. 8045 Big Bend Blvd. St. Louis, MO 63119 For a Demonstration Call our Voice 314.968.1009 CommandFax Demonstration Line FAX 314.968.3163 at 314.968.3461 Internet: rshockey@ix.netcom.com ------------------------------ From: Telecom@Eureka.vip.best.com (Linc Madison) Subject: Pac Bell *Still* Doesn't Recognize NPA 268 (Antigua) Date: Thu, 02 May 1996 16:44:19 -0700 Organization: Best Internet Communications Well, it was a full month as of yesterday that area code 268 was allegedly in service for Antigua and Barbuda, a small island nation in the Caribbean. Permissive dialing still has another 11 months, though, which is fortunate, since Pacific Bell still hasn't gotten around to enabling it in their switches. I dial 1-268- and immediately get an intercept "We are sorry, your call cannot be completed as dialed. Please check the number and dial again." This is a Pacific Bell intercept, not an intercept from my LD company. I called in a trouble ticket to repair over a week ago. After I finally got the representative to understand what on earth (and where on earth) I was talking about, he put in the report. A couple of hours later, a different person called me back to explain that, no, the new area code that split from 809 is 441, not 268. I explained to her that 441 is only for Bermuda, that Puerto Rico is now 787 and Antigua is 268, with more on the way. She said, "Oh. 441 is only Bermuda? I'll have to look into that." Sunday afternoon, their computer called me up to tell me that they had been unable to locate the trouble in my line, but that the trouble seemed to have cleared, and to call repair if I had any further problems. I called just now, and they are referring it to their switch programming people. We'll see if anything happens. The rep this time did at least notice that it was quite unusual that the test number (1-268-268-4482, or 1-268-ANTIGUA) has the same area code and prefix. (FWIW, 809-268 is now 787-268 in Puerto Rico, in permissive dialing with either NPA.) Linc Madison * San Francisco, Calif. * Telecom@Eureka.vip.best.com ------------------------------ From: Dishu Subject: ANI Information From D-Channel Date: Thu, 02 May 1996 13:12:28 -0400 Organization: Yale University, Department of Computer Science, New Haven, CT I'm a lab supervisor for a Macintosh Lab at the University of Connecticut. In the very near future, this lab is going to be connected to the rest of the campus via a 56.6 ISDN network. It is my understanding that the D-Channel provides an ANI service that can be linked to telephones for the purposes of Caller ID. Is it possible to pass this information to a program residing on my server, perhaps? I wish to basically monitor incoming calls, to discern whether or not my staff is taking a greater number of personal calls or work related calls. Thanks for any help, e-mail responses to the address below would be appreciated, as I do not check the group often ... Tim tjo94001@uconnvm.uconn.edu ------------------------------ From: Klaus Zuenkler Subject: ADSI Standards and Devices Date: Fri, 03 May 1996 09:06:26 +0200 Organization: pc-plus COMPUTING GmbH Can anybody give me a pointer to the definition of the ADSI standard and sources for compatible devices? Does anybody know about the penetration of such phones? Any hint is appreciated. Dr. Klaus Zuenkler Operator Services Architecture Management pc-plus COMPUTING Tel: +49/89/62030-188 Schlierseestr. 73 Fax: +49/89/62030-113 D-81539 Muenchen email: zu@pc-plus.de ------------------------------ From: turner7@pacsibm.org (TUrner-7) Subject: How Will Local Telephone Competition Work? Date: 2 May 1996 19:57:15 GMT Organization: PACS IBM SIG BBS Right now, a pair of wires goes from my home to my local telco's Central Office, where I may be connected to almost anyone in the world. In terms of wiring and logistics, how will local competition work? Will the new company also string wires through the neighborhood? I assume all exchanges will be interconnected. Will the new competitors be forced to carry the unprofitable neighborhoods (ie inner city residential lines) as well as the cream (centrex in a huge office building)? [TELECOM Digest Editor's Note: If the competition so highly touted over the past few years were done in a truly fair way, that is what would happen. MCI, Sprint and the others would have been told they were free to compete *entirely*. That is, they would be free to build exchanges, build their outside plants (i.e. string wires and install telephones, etc), build their national infrastructure, set up their accounting and billing procedures, etc. They could also build their own research facilities, manufacturing centers and whatever else they deemed necessary. They could spend better than a century putting it all together. They could go out and solicit customers. The court would rule that *when that had occurred* -- *when they got to that point* -- Bell was requiried to interconnect with them. The court would rule that local communities were required to treat the competitors fairly regards easement rights, the laying of cable, etc. When they had their network up and running and ready to go, Bell would open their front door and hand out several cables saying 'here are pairs you can use to interconnect with us'. Bell would also be required to administer fairly any sort of numbering plan. **The subscribers would be deemed of paramount importance**, and all interconnections, etc would be totally transparent to the customers, along with billing. That would have been the fair way. All the competitors however feel they should not be required to spend billions of dollars over a period of a hundred years developing the infrastructure Bell has in place. They feel they should be able to use AT&T's collective wisdom and resources in putting together their own networks. They feel the existing telcos should be required to allow them to move right in to the same central office facilities on a co-location type arrangement. So what they will be doing, if you don't mind, is forcing the local telcos to jerry-rig their switches and rewrite their methodology in order to accomodate the competition. They'll be using the existing cable and requiring the telco to do some magic in the central office with call-forwarding to get the calls handled. Actually, it won't affect you anyway. The competition is not interested in your worthless account. They'll only be dealing with very high volume business customers -- not even *all* business customers. Residence and low volume accounts are like poison to them. The existing telco will be required to continue handling those, even if they have to raise the price of your service to make up for what the 'competition' stole of the big business accounts. I wonder why, back in the early 1980's when Judge Greene got this bee in his bonnet, he did not at least first consult his dictionary and look up the definition of the word 'competition' so he understood what it meant, as if he cared. So that is how local telephone competition will work. Endless squabbles among the telcos, massive customer confusion over who does what and when, wholesale ripoffs of the existing insfrastructure by the new- comers, and still futher degradation of what at one time years ago was the finest telephone network in the world. PAT] ------------------------------ From: Theresa Riter Subject: Need Basic Information On Direct Link Microwave Date: Fri, 03 May 1996 11:22:18 -0500 I would like to find out some basic information about direct link microwave. We got a price quote on a T-1 from South Dakota to Arizona ... ouch! A friend suggested that we look into direct link microwave for voice and data transmission. Any information would be appreciated. ------------------------------ Date: Thu, 2 May 1996 22:54:29 -0500 From: doc_dave@bga.com (David Brod) Subject: Does Caller-ID Hunt or Call-Forward? Rich asked: > Let's say I have two lines. A and B. Line A doesn't subscribe to > caller-id. Line B does. If line-A busy is set up to hunt to line-B, > what caller-id info if any is presented to B? Same question for a > call-forwarded line. Oh, lets toss in the same question for cell > phones (as line A) immediate, busy, and no-answer call-forwarding. Pat responded: > TELECOM DIGEST Editor's Note: No information is provided to B since > it is only being used as an overflow/alternate for A, and A does not > subscribe to the service. It has been my experience that line B DOES get the caller info. Any call that rings into line B, whether line B is direct dialed, or subjected to line A overflow, will result in a caller ID read. Just like if line B has call waiting. The feature is active when line B is called, regardless of the method. > The 'decision' in the software as to which > custom calling features to extend to a subscriber with an incoming > call are made before any 'decision' is made how to dispose of the > call if the specifically called line is unavailable for whatever > reason. As long as you *never* have incoming calls which were dialed > direct into your back lines, you are perfectly safe in having things > like caller-id and call screening on your first, main, listed number > only. In this instance, lets say line A has caller ID and is busy. The call then goes to line B. If you want to know who is calling, line B must be equiped with caller ID. Each back line must have a caller ID box, in the event that a given back line is receiving a call. > Obviously you need to have a Caller-ID display box on each line; > there still has to be a way to display what telco is presenting; > you just don't have to pay the monthly service fee. Service reps are > trained to tell you things like Caller-ID and Call Screening 'will > not work correctly' on multi-line arrangements unless you buy those > services for each line. You can tell them that is not true as long > as you have no 'independently delivered' calls into those lines. Now, > let your customers/employees/others find out the numbers for those > back lines and then all bets are off. Here, Southwestern Bell charges for caller ID on each line, regardless of what kind of hunt group you have. > Ditto on a call-forwarding situation. The central office 'finds out > about' your request to forward the calls after it has already decided > what privileges or services are to be provided you on your incoming > call. Naturally the final end stopping point still has to have a > Caller-ID box. It also has to subscribe to the service. A number with Caller ID service can not 'pass along' the service to a line that does not independently subscribe to the service. David Brod Crowley Communications ------------------------------ From: hrood@xs4all.nl (Hendrik Rood) Subject: Re: Different Countries - Different Results Date: Fri, 03 May 96 04:12:17 GMT Organization: XS4ALL, networking for the masses In article , Telecom@Eureka.vip. best.com (Linc Madison) wrote: >>> [dialed number in Innsbruck, Austria, from the Netherlands] >>> Instead of getting the modem, I got the answering machine of some >>> company (I couldn't understand which company). [truncating explained] > I tried the number from the U.S., and it reaches an answering machine. > A possible clue is provided by the fact that the number begins ringing > before I finish dialing the last one or two digits. The number is > +43 512 361.112.980, This is 14 digits, together with the Dutch acces-code 00 for international calls it means your dialing 16 digits. That must be possible nowadays. But you may have a chance it goes wrong. PSTN maximum allowed national significant number has been 12 (E.163) for international dialling plans and is currently upgraded too a maximum of 15 (E.164). This must extension of maximum allowable digits must be realized all over the world at the so called time T, which as far as I am informed is January 1th 1997 (can anybody confirm that? I allways read about time T in the specs, but never see the actual date). You must now the complete routing of the call (through a SS#7 trunk you might get through, through a R2 MFC, you are exposed the risk of getting truncated after 12 digits, which in your case explains why you miss the last digits and explains too why USA can not reach this number (USA international access is 011, which extends the total digit string to 17, I know some types of well known and much used public switches that cut digit strings after 16 digits). According to ITU-T international numbering plan ruling it is allowed for an international switch in the originating country to make a routing decision after 6 significant digits have been collected. In your case that means after you have dialled: +43 512 3. So when you are punching in 611129 (say it lasts 6 seconds, 1 second per digit punched on the DTMF-telephone) the international SS#7 has allready set up a complete route to the PABX in Austria. To this PABX an Direct dialling in call is set up from the local exchange with the digits 3611129 which is sufficient to reach the reception desk. When you dial the last digits 80 it might happen that the PABX makes the decision the call is for the reception desk and you last digit is not coming through because the routing decision is allready made. Succes of your call with such a long number is all very dependend on protocols used in the International trunk network, the Austrian downlink from their International exchange to the local exchange and the protocol used for DDI to the PABX, combined with routing decision speed in the PABX. The reason you succeeded during the numbering plan transition period in the Netherlands was because an extra waiting time has been implemented as a guard against misrouting caused by slow dialers. During the transition period the Netherlands had a double numbering plan with overlap in the decision tree for several area's. Therefore Dutch switches waited 5 seconds, which was just enough for you to punch +43 512 361.112. During the call setup time over the network to Austria you entered the last three digits 980, which meant that the local exchange received all the needed digits before the DDI call setup to the PABX was made. This explains: 1. Why you experience problems after transition period; 2. The fault is not the PTT, nor in the Netherlands nor in Austria. The problem is in the PABX routing in your Innsbruck-office and might happen from time to time, when dialled from countries with modern switches. Just remind that foreign countries you have mentioned calls succeed are known to still operate a large base of electro-mechinacal (slow!) switches, so they have implemented a much longer waiting period in their International gateway for collecting digits before they setup the international part of the call. A way to test this is to go to a PABX or line with ISDN and enter the number before setting up the call. When that call is succeeding you have tracked your problem. The reason why you do not succeed when setting up the call from mobile is that part of the trunks between the mobile exchanges and the international gateway are still R2 MFC. The interworking between R2 MFC and SS#7 on the international part can cause the same waiting time problems with long numbers as described above. ir. Hendrik Rood Stratix Consulting Group BV, Schiphol NL tel: +31 20 44 66 555 fax: +31 20 44 66 560 e-mail: Hendrik.Rood@stratix.nl ------------------------------ End of TELECOM Digest V16 #214 ******************************