TELECOM Digest Tue, 10 Jan 95 14:24:00 CST Volume 15 : Issue 23 Inside This Issue: Editor: Patrick A. Townson Re: Noise Introduced by Bit-Robbing? (Wally Ritchie) Re: Chatter Heard on Scanner Leads to Criminal Charges (Michael Deignan) It is Legal to Modify Receivers (Ed Mitchell) Re: New Alert - 911 Access (Wayne Huffman) Re: New Alert - 911 Access (Gerald Serviss) 800 Numbers From Overseas (Robert Hall) Re: Cellular Phone Technology (Wally Ritchie) SS7 ISUP to SS7 TCAP Conversion (Fernando Vicuna) Planning to Purchase a Voice Mail System (Paul Hebert) Re: Video Servers (Wayne Huffman) Re: DQDB and SMDS (Fred R. Goldstein) Re: Source Code For Audio-Voice Modem Programming? (Russell Nelson) Biographies/Sketches of Our Participants (TELECOM Digest Editor) 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: * 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. 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: writchie@gate.net Subject: Re: Noise Introduced by Bit-Robbing? Date: 10 Jan 1995 14:34:39 GMT Reply-To: writchie@gate.net In , Tim Gorman writes: > whs70@cc.bellcore.com (sohl,william h) writes in TELECOM Digest V15 #11: >>> In , naddy@mips.pfalz.de (Christian >>> Weisgerber) writes: >>>> What kind of noise/distortion does American-style bit-robbing cause to >>>> voice band signals transmitted through PCM channels? >>> In the U.S., most intermachine trunks are common channel direct >>> connections so only the robbed bit at each end of the IC/EC connection >>> introduces the robbed bit (as well as ny non CCS systems in the EC). >> Today, most end-to-end voice connections do not include any trunking >> which uses robbed bit signalling. The great majority of local >> trunking, especially in metro areas, has all been converted to CCS. >> One way to determine the probability of what type of local trunking is >> in your area is if caller ID is available. If you can have caller ID, >> then the local trunking is using CCS and thus no robbed bit signaling >> is involved at that end of any connection. > This is probably a little misleading. While the robbed bit signaling was for > use in per-trunk signaling for passing supervision information, merely > converting to SS7 signaling (i.e. making caller id available) doesn't > automatically make the robbed bits available. This also requires conversion > to B8ZS/ESF signaling. > I think you will find lots of places that have converted to SS7 still > have the older AMI/SF facilities in place thus limiting circuit bandwidth > to 56kb. Lets beat this horse one more time and see if we can keep him down for awhile :) 1. An end to end connection will be clear channel IF AND ONLY IF all transmission facilities (and switches) connected in tandem are clear channel. This includes the EC local loops, the EC/IC trunks, and the IC network (or the international equivalents). 2. T1 is clear channel ONLY if it is B8ZS. However, a B8ZS facility is NOT NECESSARILY clear channel. Any B8ZS facility that uses D4 or ESF signalling WILL NOT BE CLEAR CHANNEL on the channels that use D4 (AB) or ESF (ABCD) robbed bit signalling. (European E1's, on the other hand are always clear channel). 3. USING SS7 or any other CCS system does NOT IMPLY that AMI facilities cannot be used. The fast majority of EC/IC connections are AMI and therefor not clear channel EVEN WHEN SS#7 is used on the trunk group. The main reason for this is that the installed base of AMI trunking is just too large. There is no pressing need to replace all AMI facilities with B8ZS. CCS does not imply Clear Channel. Clear Channel, however, implies either CCS or other or some other form of signalling other than robbed bit. 4. The trend is to use B8ZS for new facilities. AMI facilities will be converted as necessary (not just for fun) to meet the demand for ISDN clear channel switched calls. There is no way to obtain any kind of T1 subscriber connection to an EC that does not use robbed bit signalling unless you count PRI (which is still a dream for the most part). 5. Even if ISDN were to eventually account for 50% of calls, there would still be no justification to replace existing AMI IC/EC facilities that are fine for the non-ISDN subscribers. A regulated carrier that tried to do this would be subject to charges that it was trying to inflate its rate base. 6. As a practical matter, you get clear channel ONLY with ISDN and only with bearer classes of service that are clear channel. Otherwise, the robbed bits is gonna get you unless you are extremely lucky. (Fortunately the effect is relatively small). 7. If I got ISDN, why would I be screwing around with modems anyway. To interwork is the only reason and that means I am coming from clear channel to the robbed bit world unless I'm very lucky (which I'm not). 8. Finally, an AMI intermachine channel, through not strictly clear channel (due to Zero Byte Suppression) is effectively clear channel for modem transmission when robbed bit is not used (i.e. CCS). This is because there is no need to ever transmit the signal level encoded by the zero octet. Wally Ritchie Ft. Lauderdale, Florida ------------------------------ From: md@pstc3.pstc.brown.edu (Michael P. Deignan) Subject: Re: Chatter Heard on Scanner Leads to Criminal Charges Date: 10 Jan 1995 14:34:14 GMT Organization: The Ace Tomato Company In article , Tony_Pelliccio@brown.edu (Tony Pelliccio) writes: > Of course if you really want to follow a cell call just get a DDI and > hook it up to your PC. The interesting thing is that the company that > sells the DDI will only release software with ESN capability to law > enforcement people. Makes you wonder doesn't it? Actually, the software that comes with every DDI has the capability of displaying ESNs. You just make a few minor software patches to the executable. Not that *I* would ever do such a thing, mind you. MD ------------------------------ From: Ed Mitchell Date: Tue, 10 Jan 95 08:37:36 PST Subject: It is Legal to Modify Receivers Pat writes in reply to Bill Sohl's FAQ on Cellular and Cordless telephone monitoring: > Aside from what the Electronic Commuications Privacy Act says, the > Federal Communications Commission addresses the question of radios > which have been modified. Illegal modification (i.e. modification by > an unlicensed person) voids your FCC authority to operate the radio. Pat this is not true at all except for transmitters. You do not need a license to operate a receiver (If you have one, I'd like to see it!). You do not need any certification to modify a receiver. There are no laws prohibiting your own modification or maintenance of your own receiving equipment. The only thing that self-modification does is to void your warranty. If someone wishes to make modifications for any number of purposes, often legitimate and not merely for scanning illegal frequencies, there are many BBS, online services and Internet sites that have files on modifying nearly every radio or transmitters or transceiver ever built. In addition to the millions of existing scanners that receiver these frequencies, many will remember that the cellular frequencies were carved out of what had been television specturm (channels 71 to 83 of the UHF spectrum). Such televisions and VCRs (with built in tuners) continued to be sold until the late 1980s. Such TVs can very much be used to receive cellular frequencies by tuning with the fine tuning control through the old channels. Before it was illegal to do so, I did use a common TV to tune through and intercept cellular calls just to prove how silly was the then proposed prohibition on the sale of cellular recievers. Because estimates suggested there were over 100 million such tuners capable of receiving cellular phones coupled with the gradual phase in of digital networks, I believed then that the legislation concerning the sale of cellular receivers should have been declared moot. There are too many receivers out there now -- digital networks are being deployed now and their deployment will soon accelerate. New technology will obsolete the need for the legislation. Ed Mitchell edmitch@aol.com kf7vy@kf7vy.ampr.org tcp/ip packet net ------------------------------ From: whuffman@ix.netcom.com (Wayne Huffman) Subject: Re: New Alert - 911 Access Date: 10 Jan 1995 12:13:15 GMT Organization: Netcom In mjsutter@aol.com (Mjsutter) writes: > This is a good idea. However, it could be at odds with another good > idea which is that the cell ID that the caller is using be passed > through the cell switch to the tandem so tha the 911 database can use > the cell ID as an approximate location of the caller. In metro areas > the size of the cell would be very small indeed. Less that a year ago > a life would have most likely been saved in Rochester N.Y. if this > capability had been available. This reminds me of a time when I was an AT&T Account Executive working in my sales territory near the Capitol and Union Station in Washington, DC. I was about to be mugged outside a fast food place, and I dialed 911 from my (Bell Atlantic Mobile) cell phone. I was connected to the 911 dispatcher in Arlington, VA! They were able to connect me back to DC, but I was quite surprised to get Virginia, when I was in the middle of DC. I hope they can get this straightened out for good. Wayne Huffman [TELECOM Digest Editor's Note: So when you reached the DC police did they respond in a timely manner to keep you from getting mugged? When they arrived, did they arrest you for bothering them? :) Were you able to identify the mugger? Did he by chance resemble Mayor Berry? :) How are things in Our Nation's [Drug Sales and Murder] Capitol these days, anyway? Did the mugger steal your cellular phone as well? PAT] ------------------------------ From: serviss@tazdevil.cig.mot.com (Gerald Serviss) Subject: Re: New Alert - 911 Access Date: 10 Jan 1995 17:02:19 GMT Organization: Cellular Infrastructure Group, Motorola In article , Mjsutter wrote: > Jim Conran writes: >> In addition, the FCC should require all cellular phones to be >> equipped to access the strongest cellular base station signal when 911 >> is called. Finally, the FCC should make the 911 provision an issue as >> it currently reconsiders cellular license renewal applications. > This is a good idea. However, it could be at odds with another good > idea which is that the cell ID that the caller is using be passed > through the cell switch to the tandem so tha the 911 database can use > the cell ID as an approximate location of the caller. In metro areas > the size of the cell would be very small indeed. Less that a year ago > a life would have most likely been saved in Rochester N.Y. if this > capability had been available. I theory, 911 access for cell phones is a good idea. The problem is reducing that theory to practice. Let's consider a metro area as the previous poster suggests. In our most dense operations that I am familiar with the smallest cell radius is 500 meters. This gives an area of 785,000 meters-square or about .25 miles-square. If you consider that in a metro area where this cell would be located is built up and that the average number of floors covering this area is just say four (source ... PFA) you have one square mile of area that this caller could be located in. Even if we include information on the sector of the origin of the call we are down to .33 or .16 square miles of area. Compare this to the typical 911 call from a land phone which can isolate the caller to a specific location (home, office, payphone ...) and you can see that the information that a cellular system can provide currently is hardly useful for delivering a 911 call to the proper dispatch center. In a suburban setting where there are lots of jurisdictions and cell placement and thus coverage is dictated by traffic patterns there are just as many problems. The use of the strongest signal is no guarantee of routing the call correctly, especially if you are in a building. The closet cell may have its line of site thru a wall and the next closet thru a window. In this case the location data is even less useful. Sure we could add GPS receivers and exact positioning information to the 25 million cell phones in use in the US, of course, you would also have to replace or modify all the fixed equipment in all the systems to use that information and the the air specs would have to be updated. And we thought that rolling out digital service was a hard problem to solve. It pales by comparison with this problem ;-) I think that the FCC exemption is based on good engineering and the realization that today we do not have the capability to locate the caller easily, if at all. Jerry Serviss Motorola Inc serviss@cig.mot.com ------------------------------ Date: Tue, 10 Jan 1995 22:41:29 HKT From: Mr Robert Hall Subject: 800 Numbers From Overseas Judith Oppenheimer and Ari Wuolle have both discussed the fact that it is now possible to access U.S. 800 numbers from international locations. Following Judith's dialing suggestions, I attempted to call a number of 800 numbers from Hong Kong. For example, I dialed: 011 International Access Code 1 Country Code for U.S. 800-555-1212 800 Directory Assistance The call appears to have been processed by the Hong Kong switch, but I get a recording in a very American voice telling me: "access to the 800 number you have dialed is not free when dialed from outside the United States. If you proceed with this call, you will be billed international direct dial rates for this call. If you do not wish to proceed with this call, hang up now". So, I wonder if the assumption that it's up to my local IDD provider to just turn on access to U.S. toll-free numbers is, in fact correct, or whether the U.S. 800 service provider has a say in the deal as well. Are there all of the usual tariff negotiations between the carriers? What about calls from the U.S. to other countries' toll-free numbers? Since Hong Kong is a small country and local calls are free, the use of 800 numbers here has been pretty much limited to accessing a particular foreign carrier's "home direct" service. For example, from within Hong Kong, I dial 800-1111 to get the AT&T "bong" to place calls charged to my AT&T card. If someone Stateside dials 011-852-800-1111 do they loop back to AT&T's "bong"? I'd be intersted to see this thread continue as there are some real business applications for my company with this. Thanks, Rob Hall Hong Kong ------------------------------ From: writchie@gate.net Subject: Re: Cellular Phone Technology Date: 10 Jan 1995 18:25:17 GMT Reply-To: writchie@gate.net In , stanb@netcom.com (Stan Brown) writes: > Having recently acquired a cellular phone, I suddenly find > myself curious about how the systems operate. Could someone point me úÿ > to a good reference on the operation of cellular systems? I am > particularly interested in the technical side (not economics) of > roaming, and follow me. There was an FCC technical report describing the system. You might try fishing around gopher.fcc.gov. I do know that it was published in full in the federal register a few years back. You can probably sneakernet it from your local library. Wally Ritchie Ft. Lauderdale, Florida ------------------------------ From: fvicuna@tandem.cl (Fernando Vicuna) Subject: SS7 ISUP to SS7 TCAP Conversion Date: 10 Jan 1995 10:01:41 -0300 I am looking for a provider of a solution to the following problem. There is a telephone switch that accepts SS7 ISUP signalling, and I have a computer that accepts SS7 CCITT TCAP signalling. Is there some kind of gateway that can translate the information provided by ISUP into a TCAP query? Do I have to look for a switch provider that has a Service Switching Point (SSP)? The interface I am looking for will be used to provide Intelligent Network Services. Does anybody have experience in IN? Thanks for your help. Fernando Vicuna fvicuna@tandem.cl ------------------------------ Date: 10 Jan 1995 11:18:32 -0500 From: Paul Hebert Subject: Planning to Purchase a Voice Mail System My company is doing research for selection of a voice mail system. We have presentations scheduled with Octel and Centigram. Would anyone have some technical or user related insight into these systems? We have an NEC 2400 switch. Any interface issues we should be aware of? Paul Hebert MARKEM Corp Keene, NH paul_hebert@markem.com ------------------------------ From: whuffman@ix.netcom.com (Wayne Huffman) Subject: Re: Video Servers Date: 10 Jan 1995 11:38:45 GMT Organization: Netcom In alwin@ec.ele.tue.nl (Alwin Mulder) writes: > I am a graduation student at the University of Technology at > Eindhoven, and I am working on a VOD project. I was wondering if > anybody could tell me where I could find some information on > video-server-systems. Are there any specific newsgroups and/or > WWW-pages? I have found a new publication that may be of help to you. It is called Interactive Week. It is new, but they have already had VOD articles. You can reach them at the following addresses: http://www.interactive-week.com or e-mail them at 72002.1567@compuserve.com. I don't work for then but I like the publication so far. Wayne Huffman ------------------------------ Date: Tue, 10 Jan 1995 10:14:55 -0500 From: Fred R. Goldstein Subject: Re: DQDB and SMDS From: KRISTOFF.BONNE@PIRESSYS.BELGACOM.RTTIPC.belgacom.be > Can anybody explain to me what the difference and/or connection is > between DQDB (Distributed-Queue dual-bus) and SMDS (Switched > Multi-Megabit Data Service). Interesting topic, since the two are easily confused. DQDB is a "Metropolitan Area Network" defined by IEEE 802.6. It provides for a cell-based (48-byte payload, similar to ATM) data transfer, shared media with arbitration (telco speeds, T1/E1/T3/E3/ SONET/SDH as intended PMDs), and a novel combination of MAC services. It has a "connectionless" service that resembles any LAN (long variable-length packets) and an "isochronous" service that resembles circuits (fixed-bandwidth channels). DQDB was invented by Australians (QPSX Comms. is its promoter) but never really caught on in a big way. SMDS is a connectionless packet-switched public network service developed by Bellcore. It uses E.164 (ISDN/telephone numbers) for addresses, allows long (9KB?) packets, etc. When SMDS was being invented, DQDB was hot, so Bellcore specified that the data link layer of SMDS would be the DQDB protocol. This is "SIP layer 2" and part of "SIP layer 3". Thus it is possible to implement SMDS using DQDB multiport bridges. This is done in some places. In effect, SMDS is a service that DQDB delivers using a subset of its capabilities. In American practice, most users do not accept DQDB's odd cell-based datalink, so SMDS now usually uses the "DXI" format, which maps SIP3 packets into HDLC frames. Some DQDB vestiges (packet header, trailer) remain but it's really just a packet service now. Fred R. Goldstein fgoldstein@bbn.com Bolt Beranek & Newman Inc. Cambridge MA USA +1 617 873 3850 ------------------------------ From: nelson@crynwr.crynwr.com (Russell Nelson) Subject: Re: Source Code For Audio-Voice Modem Programming? Date: 10 Jan 1995 15:30:07 GMT Organization: Crynwr Software In article System Operator writes: > I'm looking for any sample or public domain source code used to > control an audio-voice (AT+FCLASS 8) modem used in any kind of > interactive application. > Any pointers to FTP sites, etc, would be appreciated. mgetty+sendfax works with ZyXEL (and possibly ZOOM and Rockwell-voice- chip) modems. It works on various unices -- I use it on Linux. Look for it on ftp.leo.org. russ http://www.crynwr.com/crynwr/nelson.html Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it? Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress? ------------------------------ From: telecom@eecs.nwu.edu (TELECOM Digest Editor) Subject: Biographies/Sketches of Our Participants Date: Tue, 10 Jan 1995 14:00:00 CST The results to date have been pretty positive. Many of you have written to say you would like to see a section in the Telecom Archives for the biographies or 'thumbnail sketches' of the people who participate in this forum from day to day. So ... I've set it up. It is located in the Telecom Archives at lcs.mit.edu. It is *not* available to FTP/Gopher/WWW readers. It is only available/readable via the Telecom Archives Email Information Service with the PASSWORD command. You get the current password when your entry has been received, reviewed and installed. In other words, install your own, then you get to read the others. These items will not be published in the Digest. It will be up to you from time to time to get a new 'index' of the biographical files on line to select the ones you want to read. What would be appropriate? Your name, address and phone number if you wish to include it; a paragraph so so about your education and past or present employment; if you have published anything you might want to mention that as well. If you have a .signature file you are particularly proud of you can include that. Altogether, maybe 150-200 words or so in a couple paragraphs. Please note that a log of activity for the Telecom Archives Email Information Service is available to me on a daily basis; particularly of interest are those requests to the server which invoke the PASSWORD command. I'll send full instructions for accessing the biography files to each person who submits one, and remember, these are closed files available only to the people who wish to participate. Please report *any* abuses to my attention. By and large, snoopers, name-/list-gatherers won't have access. Send your submissions to 'ptownson@eecs.nwu.edu' -- not to the Digest. Thanks, PAT ------------------------------ End of TELECOM Digest V15 #23 *****************************