TELECOM Digest Thu, 13 Oct 94 13:34:00 CDT Volume 14 : Issue 395 Inside This Issue: Editor: Patrick A. Townson Re: Frame Relay vs. ISDN vs. T1 vs. ???? (Lars Poulsen) Re: Frame Relay vs. ISDN vs. T1 vs. ???? (lawrim@inforamp.net) Re: Frame Relay vs. ISDN vs. T1 vs. ???? (Greg Ruml) SONET/ATM, Video Compression Short Courses -- UC Berkeley (Harvey Stern) Re: 25 Years of Call Waiting (Danny Burstein) Re: GSM SIM Card: Different? (Stephen Ermann) BCH 3/5 Error Detection Modules (Allan Rypka) Re: V.34 From ITU-T (John E. Lundgren) Re: V.34 From ITU-T (Ken Krechmer) Dialstrings on DMS-100 (George L. Sicherman) Re: UDI vs RDI in ISDN (Kevin Paul Herbert) Re: Need Amp to Boost DTMF Strength (Les Reeves) Re: OSI OM-Related Tools (Grover McCoury) 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 at no charge to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@eecs.nwu.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: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 708-329-0571 Fax: 708-329-0572 ** Article submission address only: telecom@eecs.nwu.edu ** Our archives are located at 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. * ********************************************************************** * Additionally, 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. 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: lars@spectrum.RNS.COM (Lars Poulsen) Subject: Re: Frame Relay vs. ISDN vs. T1 vs. ???? Date: 13 Oct 1994 10:35:37 -0700 Organization: Rockwell Network Systems A couple of recent contributions indicate that there is some confusion about contemporary data communications options. spelegan@csc.com wrote: > We have a commercial customer who's asked us to setup a BBS system for > them. They've asked us to recommend a telecom option for them to > use that best suits their needs. They'd like to start out with 8 > lines going into the BBS with the ability to move up to 16, 24, etc. > They'd like their customers to have one 800 number to call to reach > this BBS, no matter where they are in the US. Their customers will > have off-the-shelf modems, ranging from 1200-14.4 baud. The requirement here is for an economical way to accept POTS calls for modem traffic. This means that X.25 service, Frame Relay, ISDN etc are all outside of the scope of this query. That will not prevent me from getting back to them at the end, though. The simple, easy solution is to get 8 lines (in a hunt group) from your local exchange carrier, and arrange for an 800-number from a competitively priced long distance company which forwards to these lines. If you have really high volume, you may save a couple of cents per minute bypassing the local carrier and installing a T1 line directly to the long distance carrier's POP, but then you will need a channel bank to split the lines back out to individual lines before they go into your modems. Any modems installed today should be 28800 bps models; either V.FC or V.34. V.34 may still be hard to get at a reasonable price, though. And now a word about ISDN: In article misha@panix.com (Michael Gray) writes: > ISDN connections would allow you to connect to BOTH customers with > POTS (Plain Old Telephone Services) services and with ISDN services, > however you need separate ISDN modems and 28Kbs modems, special > equipment to hook the 28.8Kbs modems to the ISDN lines. In Europe, it is not uncommon to find ISDN adapters that include a V.32bis (14400 bps) modem, so that they will accept connections using either V.32bis (from customers with ordinary phone lins and ordinary modems) or V.110 asynchronous rate adaptation (from customers with compatible ISDN adapters). In the US, these dual-mode adapters have not been very popular. If they could be had, the cost would be nearly USD 2000 per port. My conclusion is that it is not worth it yet, and when you do gear up for ISDN, you will probably be better off with separate ports / separate lines for ISDN access.. Sp> I'm even more cloudy on Frame Relay. Can I have one 800 number with Sp> Frame Relay? Do you need a special terminal/modem to dial into a Sp> frame relay network? How does it compare to T1? vs. T1 cost? vs. Sp> T1 reliability? Please correct any assumptions that I've made T1, Sp> ISDN, and Frame Relay. Frame relay is sort of similar to X.25, sort of similar to leased 56 kbps lines. The physical jack is a leased 56 kbps (or 384 kbps) line into the carrier's Frame Relay switch. This line is shared by connections to multiple, presubscribed locations. So if you have 4 sites, you can have them all talk to each other by giving each of them a leased line into the telephone company's FR switch, instead of needing 6 lines to connect them all. The equipment at all locations must understand the FR multiplexing protocol. Finally: You should give serious consideration to putting such a BBS on the Internet. Lars Poulsen Internet E-mail: lars@CMC.COM Rockwell Network Systems Phone: +1-805-562-3158 7402 Hollister Avenue Telefax: +1-805-968-8256 Santa Barbara, CA 93105 Internets: designed and built while you wait ------------------------------ From: lawrim@inforamp.net Subject: Re: Frame Relay vs. ISDN vs. T1 vs. ???? Date: 13 Oct 1994 01:10:26 -0400 Organization: InfoRamp, Toronto Ont. (416) 363-9100 Reply-To: lawrim@inforamp.net T1 service is getting cheaper by the month.I have seen prices here in Toronto range from $750.00 to $1500.00 (Canadian) ISDN is offered by Bell Canada very cheap.There Megalink service for example can be had for $78.00/mo.This isfor basic services providing what is called 2B+D,2-64k channels and one 16k channel. Frame Relay is a high speed packet switching network.Each packet of data carries a much higher payload then X.25 packets.You usually pay a monthly port charge and usage based on a committed information rate (CIR).Access is 56k and the CIR is a portion or all of it.Frame relay applications are generally used in a multipoint situation. Other options could be centrex data and dial-up X.25.A competant data provider should have no problem costing out the various applications mentioned. Good Luck, Lawrie ------------------------------ From: gruml@buscomm.mts.mb.ca (Greg Ruml) Subject: Re: Frame Relay vs. ISDN vs. T1 vs. ???? Date: Tue, 11 Oct 1994 15:49:20 -0400 Organization: MTS For your application you are suggesting 800 service. 800 service is a voice service by definition where the subscriber pays the long distance charges. Frame relay is not your answer. I have heard that some of the carriers will have dial access to frame relay, but I don't believe it is available yet. Frame relay is a dedicated data service at speeds of 56,000 bps or 64,000 bps (and multiples thereof). Frame relay requires a device called a FRAD. This device packetizes the data into frames, putting a header and trailer around a block of data. The FRAD also checks the data when it is sent and then when it arrives to ensure the data is without errors. These FRADs required cost $1000 and up. Your answer really depends on what equipment your client has today. If they have a PBX with T1 ISDN PRI capability, it may make sense to put these lines on ISDN. ISDN is a voice and data service that is a digital signal and therefore you get a higher grade of service. ISDN, because it is digital, is less susceptible to interference from traditional noise sources (ie. motors, signal induction from other cables, etc.). If they just have an analog key system today it may make sense just to keep adding standard dial-up lines. Hope this helps. Greg Ruml ------------------------------ From: southbay@garnet.berkeley.edu Subject: SONET/ATM, Video Compression Short Courses -- UC Berkeley Date: 12 Oct 1994 17:06:17 GMT Organization: University of California, Berkeley U.C. Berkeley Continuing Education in Engineering Announces 3 Short Courses on Broadband Communications, and Video Compression SONET/ATM-BASED BROADBAND NETWORKS: Systems, Architectures and Designs (October 19-21, 1994) It is widely accepted that future broadband networks will be based on the SONET (Synchronous Optical Network) standards and the ATM (Asynchronous transfer Mode) technique. This course is an in-depth examination of the fundamental concepts and the implementation issues for development of future high-speed networks. Topics include: Broadband ISDN Transfer Protocol, high speed computer/network interface (HiPPI), ATM switch architectures, ATM network congestion/flow control, VLSI designs in SONET/ATM networks. This course is intended for engineers who are currently active or anticipate future involvement in this field. Lecturer: H. Jonathan Chao, Ph.D., Associate Professor, Brooklyn Polytechnic University. Dr. Chao holds more than a dozen patents and has authored over 40 technical publications in the areas of ATM switches, high-speed computer communications, and congestion/flow control in ATM networks. GIGABIT/SEC DATA AND COMMUNICATIONS NETWORKS: Internetworking, Signaling and Network Management (October 17-18, 1994) This short course aims to provide a general understanding of the key issues needed to design and implement gigabit local and wide area networks. The topics are designed to compliment those covered in the SONET/ATM-Based Broadband Networks course (above). Topics include: technology drivers, data protocols, signaling, network management, internetworking and applications. Specific issues addressed include TCP/IP on ATM networks, design of high performance network interfaces, internetworking ATM networks with other network types, and techniques for transporting video over gigabit networks. This course is intended for engineers who are currently active or anticipate future involvement in this field. Lecturer: William E. Stephens, Ph.D., Director, High-Speed Switching and Storage Technology Group, Applied Research, Bellcore. Dr. Stephens has over 40 publications and one patent in the field of optical communications. He has served on several technical program committees, including IEEE GLOBECOM and the IEEE Electronic Components Technology Conference, and has served as Guest Editor for the IEEE Journal on Selected Areas in Communications. VIDEO COMPRESSION AND VISUAL COMMUNICATION (October 13-14, 1994) Video Compression and Visual Communication is a rapidly evolving multidisciplinary field focussing on the development of technologies and standards for efficient storage and transmission of video signals. It covers areas of video compression algorithms, VLSI technology, standards, and high-speed digital networks. It is a critical enabling technology for the emerging information superhighway for offering various video services. In this course, we will fully treat video compression algorithms and standards, and discuss the issues related to the transport of video over various networks. Lecturers: Ming-Ting Sun, Ph.D, is director of Video Signal Processing Research, Bellcore. Dr. Sun has published numerous technical papers, holds four patents, developed IEEE Std 1180- 1990, was awarded the Best Paper Award for IEEE Transactions Video Technology in 1993 (with Tzou), and an award for excellence in standards development from the IEEE Standards Board in 1991. He is currently the express letter editor, IEEE Transaction on Circuits and Systems for Video Technology (CSVT), and associate editor, IEEE Transactions of CSVT. He was chairman and now serves as secretary of the IEEE CAS Technical committee on Visual Signal Processing and Communications. Kou-Hu Tzou, Ph.D., is manager of the Image Processing Department, COMSAT Laboratories. Dr Tzou won the Best Paper Award for IEEE Transactions Video Technology in 1993 (with Sun). He holds 6 patents, has served as an associate editor for IEEE Transactions on Circuits and Systems, is currently associate editor for IEEE Transactions on Circuits and Systems for Video Technology, and served as a guest editor for Optical Engineering Journal special issues on Visual Communications and Image Processing in 1989, 91, and 93. He is the committee chair of the Visual Signal Processing and Communication Technical committee, IEEE Circuits and Systems Society. For more information (complete course descriptions, outlines, instructor bios, etc.) contact: Harvey Stern U.C. Berkeley Extension/Southbay 800 El Camino Real Ste. 150 Menlo Park, CA 94025 Tel: (415) 323-8141 Fax: (415) 323-1438 ------------------------------ From: dannyb@panix.com (danny burstein) Subject: Re: 25 Years of Call Waiting Date: 13 Oct 1994 00:19:44 -0400 Organization: mostly unorganized In marya@titan.ucs.umass.edu (jwm) writes: advert from Nynex about call waiting being in existence for twenty-five years > Discover why Call Waiting has been our most popular service for more > than 25 years. > really deployed as early as 1969? What switches at the time supported > them? Did anyone out there have Call Waiting from New England > Telephone and Telegraph Co. in 1969? I was one of the first public customers for call waiting in NYC. In fact, I picked up call waiting, call forwarding, and three way calling as soon as I could in mid 1975. Back in those days I used to call New York Telephone's semi-internal Newswire which had all sorts of interesting, sometimes technical, sometimes amusing, material in it. (It also had the AT&T stock market price as well as the weather report, and it was a free call...) Anyway, they mentioned in the report that their internal tests had just been finished and it was being rolled out to the public. So the initial NYC public offering was in 1973/early 1974. I had to wait a bit until I left campus residential housing before I could get my own phone, and when I did, I got the features installed. (BTW this had the side effect of leaving me with one of the older switches in NYC - i.e., since it was a 'new' one in 1974, it's not being replaced anytime soon ...) Back then they were called CSS for Custom (something) Sevices, and trying to get it ordered for my phone line was one of my early experiences in telco frustration. But I did get it. Back in those days, by the way, the codes used for implementing forwarding were different than the ones used today (I -think- it was '1191' to start it and '1193' to end). The call forwarding was the more interesting of the features. Back then I would forward the number to the (last hunt line) of where I was working. So if a call came in on that line, we all knew it was (probably) a private call for one of us and answered appropriately. (After I had the service for a few weeks, the other people also got call forwarding on their lines). Keep in mind, by the way, that in 1975 telephone answering machines were a lot clunkier and more expensive, and remote message retrieval was not readily available. And a unit with remote message changing cost me about six-hundred dollars a few years later. Yes, really, and that's when $600 was real money ... So it's -just- possible that it was available to a few select areas on the early #1-ESS machines in 1969, but certainly not on a widespread basis. Oh, another point: In those days telco equipment was amortized over a -looonnngggg- period, so a central office would not be replaced simply becuase something newer and better was out there. In fact, it's only in the few years that the last mechanical exchanges in the NYC area were retired. O, yet one more point: The first area of NYC to get fully computerized equipment was the lower east side/Gramercy Park neighborhood. You see, New York Tel had a bit of a fire at their 13th street and 2nd avenue office which put Hinsdale to shame. In the space of a month they had completely replaced all the equipment in teh building with what were then brand-new ESS's. danny burstein dannyb@panix.com (or dburstein@mcimail.com) [TELECOM Digest Editor's Note: I don't think the New York fire in the early 1970's was as severe as Hinsdale, but I guess that's a matter of each person's judgment. Hinsdale certainly handled a wider scope of services and geographical territory than the office in Manhattan. You are correct about the 1191 and 1193 codes. 11 (pronounced 'eleven' in this application) was to be used by people with older touch tone pads that did not include the * and # buttons. You may recall the original touch tone pads only had ten buttons with the bottom row only having the zero/operator key and nothing on either side of it. So you turned on forwarding with 1191 or *91 and turned it off with 1193 or *93. I was one of the first subscribers here in 1973 or 1974, I forget which. The interesting thing about the original call forwarding here was that chain forwarding would not work at all. A would forward to B and B would forward to C for example ... but calls to A absolutely stopped at B regardless of what B was doing with calls directly sent to him. The idea was B is entitled to forward to C but B has no authority to assume A is willing to have his calls go to C. Apparently the switch was able to tell when a call hit B from whence it came, and respond accordingly. If you were actually looking for B, you were sent on to C as instructed but if you were looking for A and got sent to B in the process you stopped there. Also, the early version of call waiting had no provision to suspend the service for those calls you did not want interuppted. If you had call waiting on the line you were stuck with it. Of course modems were pretty rare in the middle 1970's so it was not a big problem with data as it would be today if suspend call waiting (usually *70 before the dialing string) were not available. PAT] ------------------------------ From: 100111.1007@compuserve.com Date: 13 Oct 94 03:24:30 EDT Subject: Re: GSM SIM Card: Different? >> Is this true? As I understand, with only one SIM card you can use any >> GSM handphone in any country (of course as long as the countries have >> roaming agreement). Well, yes and no: The SIM card exists in two physical formats: large (credit-card sized) and small (chip sized, 1cm x 1.5cm). The Motorola 5200 & 7200 use the large card, while most other manufacturers use the small one in most models to my knowledge. The chip itself seems to be the same, as when I switched from a Motorola 5200 to a Nokio 2110, I just cut the SIM card to the right size and inserted it. So to answer your question: you can use any SIM card in any GSM phone, as long as it has the same form factor. Regards, Stephen Ermann Switzerland ------------------------------ From: pp000762@interramp.com Subject: BCH 3/5 Error Detection Modules Date: Thu, 13 Oct 94 23:04:22 EDT Organization: PSI Public Usenet Link Can anyone provide the name/number of firms producing pre-programmed off the shelf BCH 3/5 forward error correction modules for use in data transmission systems? Thanks in advance, Allan Rypka Focused Research ------------------------------ From: jlundgr@eis.calstate.edu (John E. Lundgren) Subject: Re: V.34 From ITU-T Date: 13 Oct 1994 07:50:50 -0700 Organization: California Technology Project of The Calif State Univ tannil@tcl.com.hk (Tannil Lam) writes: > Please advice the newest status of V.34 from ITU-T. I hope to know > whether V.34 has been official approved for modem manufacturers to > produce their V.34 products or not. I read a post saying that a vote had been taken and it had been approved, and it will be published in late October. John Lundgren $$$$$$ jlundgr@eis.calstate.edu $$ jlundgr@ctp.org jlundgre@rsc.rancho.cc.ca.us $$$$$$ Standard Disclaimers apply. Rancho Santiago College - 17th St. at Bristol - Santa Ana, CA 92706 ------------------------------ From: krechmer@ix.netcom.com (Ken Krechmer) Subject: Re: V.34 From ITU-T Date: 12 Oct 1994 22:20:03 GMT Organization: Netcom In tannil@tcl.com.hk (Tannil Lam) writes: > Please advice the newest status of V.34 from ITU-T. I hope to know > whether V.34 has been official approved for modem manufacturers to > produce their V.34 products or not. The V.34 and associated V.8 Recommendations are approved. The ratification cycle ended about two weeks ago. Ken Krechmer Technical Editor Communications Standards Review e-mail: kkrechmer@attmail.com ------------------------------ From: George.L.Sicherman@att.com Subject: Dialstrings on DMS-100 Organization: AT&T Network Systems Date: Thu, 13 Oct 1994 14:23:50 GMT How does Northern Telecom's Digital Multiplex Switch 100 (DMS-100) treat fourth-column dialed digits? The AT&T #5 Electronic Switching System accepts them pretty much wherever it accepts Star and Box; it calls them O, S, I, and P, apparently following AutoVON usage. (Nowadays I think they are more commonly called A, B, C, and D.) The DMS-100 can be programmed to accept "overdecadic" digits from A to C, or from A to F. Can anybody explain how (if at all) they correspond to the fourth-column tones? Col. G. L. Sicherman gls@hrcms.ATT.COM ------------------------------ From: kph@cisco.com (Kevin Paul Herbert) Subject: Re: UDI vs RDI in ISDN Date: Thu, 13 Oct 1994 07:46:26 -0700 Organization: Cisco Systems, Ashland, OR RDI is a 64K channel on which you are expected to maintain a particular ones density. This can be used to transmit HDLC data if you invert the bits; HDLC has a different reason for avoiding 6 one bits in a row; by inverting this, you can assure that there are never 6 zero bits in a row. I'm not sure if RDI is actually supported anywhere. Kevin ------------------------------ From: lreeves@crl.com (Les Reeves) Subject: Re: Need Amp to Boost DTMF Strength Date: 13 Oct 1994 08:41:42 -0700 Organization: CR Labs htc (htcink@teleport.com) wrote: > I need an inexpensive in-line amplifier circuit capable of boosting dB > level of DTMF generated from newer ("non-network") telephone sets > (mfg'd by Panasonic, Sony,...) Telephone sets connect to a PBX board > (in IBM PC) that causes a slight loss of signal strength. Usually > only column 2 (i.e. 2,5,8,0) is too weak. Any suggestions/help or > schematics would be greatly appreciated. fax: (503) 645-3566 WATS resellers used the R-TEC (Reliance Comm/Tec) VFR5050 2-Wire to 2-Wire repeater for boosting signals. The repeater is easy to set up, and unconditionally stable. It automatically disables itself when data carriers of any sort are detected. It is widely available on the secondary market for about $100. I keep one connected to my line all the time. My IVR system is able to get my DTMF signals under the worst conditions with the help of this repeater. The VFR 5050 requires a type 400 shelf for mounting. R-TEC (AKA Lorain): (817) 267 3141 Les lreeves@crl.com Atlanta,GA 404.874.7806 ------------------------------ From: gcm@fep50.fns.com (Grover McCoury) Subject: Re: OSI OM-Related Tools Date: 13 Oct 1994 07:31:07 GMT Organization: Fujitsu Network Switching In article , andrew lavigne writes: > I've been looking for information on the availability of OSI Object > Model Management-related toolkits and compilers (ASN.1/GDMO compilers, > object class inheritance display tools, browsers, etc). > Does anyone know of such tools and/or where I can get more information > on them? DSET Corp. provides a set of tools to handle ASN.1 types in C++. The toolkit is called "ASN.C++" and includes an ASN.1 compiler among other tools. DSET Corp. 1011 Rt. 22 West Bridgewater NJ 08807 (908)526-7500 Grover C. McCoury III Fujitsu Network Switching Of America, Inc. physical: 4403 Bland Road Raleigh, NC 27609 audio: 919-790-3111 electronic: gcm@fns.com ------------------------------ End of TELECOM Digest V14 #395 ****************************