TELECOM Digest Thu, 19 Jan 95 08:01:00 CST Volume 15 : Issue 47 Inside This Issue: Editor: Patrick A. Townson CO/Boston Added to NACN (Doug Reuben) Canadian CIC Codes: (Chris Farrar) Questions About WAN Compression For Data Networks (Peter Granic) Re: DQDB and SMDS (Kristoff Bonne) ANSI Terminal Communications (David O. Laney) Internet Software Wanted (L.C. Clower) Re: T1BBS Gone? (Mark Fraser) Re: BC Tel, SaskTel, Internet (Mark Fraser) Re: Wireless CO's Challenge New NPAs? (Liron Lightwood) Re: Attention: 800 Number Subscribers (News Alert) (Colum Mylod) Re: GSM Cellular Operators List (Ben Wright) Summary: Looking For a CHILL Compiler (Andreas Junklewitz) Re: NANP 800 Numbers From the UK (Carl Moore) Re: Legal Problem Due to Modified Radio (Alan Boritz) 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: dreuben@interpage.net (Doug Reuben) Subject: CO/Boston Added to NACN Date: Thu, 19 Jan 1995 03:37:13 EST I just noticed that CO/Boston was added to the NACN today. Although a bit late, it is a welcome improvement! Prior to CO/Boston's (00007) addition to the NACN, there was a large coverage "gap" for automatic call delivery from Rhode Island (which Metro Mobile for some reason never hooked up with NY) all the way up to southern New Hampshire. (Central/Northern Seacoast NH as well as Vanguard Cellular in Maine were added last year.) CO/Boston also "shares" a seemingly bizare system with Atlantic Cellular (CO/Vermont) in the Lakes region of central New Hampshire, and it is possible that on BOSTON-owned towers NACN customers will get automatic call delivery there as well. I tried my Boston account out, and all features work very nicely, even to a limited extent redirects. In summary: -Redirects: If your call is delivered to a visited NACN market from Boston, redirects, or treatment of a call after no-answer to either voicemail or some other no-answer-transfer number WILL work, although to a very limited extent. Calls will NOT go back to voicemail, but will no-answer-transfer (NAT) to other numbers. From only a few cursory tests, it looks like what they are doing is allowing NAT to calls within the same local service area. That is, as long as the call would NOT have to go over an IXC if it were placed by the roamer in the visited market, then it will be allowed. Thus, for example, a Boston customer who roams in CO/NY's (00025) system will NOT be allowed to have redirects go back to his/her voicemail in Boston, nor will redirects be allowed to a NAT# in Washington, DC. However, NAT will be allowed to a number within the NY Metro LATA (but not, it seems, the local "toll-free" area.) Thus, if the NAT condition in effect for the Boston subscriber is while the subscriber is visiting the CO/NY system is: *71#555-1212 (the #555-1212 instructs the Boston switch to NAT to voicemail, which is problematic at times, especially on other Motorola switches linked to Boston [non-NACN]), the result is a "xx-20" switch recording informing the caller that the roamer/visitor is unavailable, generated by the visited (NY) switch. *71-305-555-1212, OR *71-1-305-555-1212 results in an ERRONEOUS "xx-44" recording, which is roughly "As a roamer, you must first dial a 1 when calling this number. Please call 611 and reference message [xx]-44." Quite confusing to landline callers indeed! *71-212-555-1212 or *71-800-555-1212: NAT works properly. This seems to make sense: If the DOJ forbids SWBell/Boston to offer redirects over an IXC (or from what I am told since SWBell is potentially too lazy to get a waiver for VM purposes :( ), then as long as the calls are NOT carried via an IXC, NAT can be offered without a waiver. The ANI from sample local redirects in the CO/NY system show a 516/Long Island number, and I suspect that these are coming from the Woodbury Switch. Hence, as long as the calls can be processed by CO/NY and/or do not cross LATA boundries (?), NAT will work. Although it would be nice if NAT would work back to VM in Boston, the ability to have some sort of local/800 redirect is a CERTAINLY better than nothing. -Call Forwarding: It's nice to see that Boston was not forced to adhere to the McCaw feature codes, and that they are allowed to retain their own codes for their own customers. *71 (NAT for Boston), *72 (Call Forwarding for Boston), *713 (NAT Cancel), *723 (CF Cancel), *73 (Global NAT/CF/Busy Transfer Cancel) all work fine, and receive a prompt confirmation tone. Moreover, CO/Boston customers who use NAT, *713, or *73 do NOT have to lose voicemail as they do in Connecticut or other non-NACN markets (I'm am no longer sure of CT's "non-NACN" status - they are doing weird things with roaming from what I hear. I need to test a few things out next time I am there to be sure...). If a CO/Boston customer who roams on the NACN chooses to set NAT away from voicemail to another destination (such as a "local" number as in the above example), and subsequently wishes to re-establish NAT to VM in Boston, entering *71#555-1212 WILL work, ie, it will set up the correct NAT coding in the Boston switch. Although as noted above a redirect will not work back to Boston VM, if the subscriber chose to activate the Do Not Disturb (*35) feature to turn off call delivery to the visited market, an incoming call would be properly treated in Boston and sent to voicemail. The ability activate/deactivate voicemail remotely and establish different NAT settings from anywhere within the NACN is a useful feature, one which is seemingly not widely available on the B-side auto call delivery network. -Do Not Disturb: *350/*35 works perfectly. It's odd that Boston chose to go with these codes, they use the more standard Motorola codes *28/*29 for their auto call delivery in VT, Mass, and CT. Perhaps they want to distinguish between the NACN and New England call delivery? Why? Boston makes call-delivery difficult enough already with their "call delivery home airtime sometimes" charges, why add an extra layer of confusion? -Call Waiting: Works perfectly, as do unanswered Call-Waiting redirects. -Three-Way: Again, works perfectly- it is more "elegant" to the roamer on the Ericsson than it is back at home on the Motorola! Bugs: 1. As noted before, the "xx-44" codes seem to be in error. Perhaps they are using the 1+ mechanism to determine if a redirect should occur or not and if not for some reason the switch coughs up the 44 recording? 2. If a visiting roamer has no conditional forwarding (NAT, BT) set, the call will ring in the visited market for an exceptionally long period of time (over 1 minute!), which is unusual and wastes airtime and handheld battery power. After about a minute or longer, the calling party does not get a recording, but rather a fast busy. 3. Sort of a bug: CO/Boston customers must (unfairly, IMHO) pay AIRTIME for call delivery, even though it is obvious to anyone that no airtime is being used if the subscriber isn't even in Boston system. (And the old excuse that "oh, you utilize a lot of trunk lines with call delivery" is nonsense -- the visiting system's roaming charges are enough to discourage flagrant overuse of CO/Boston's trunks). CO/Boston always used to maintain that customers could avoid these charges by having callers reach them by using the local roam ports. However, traditionally, when a system is added to the NACN, its customers are no longer accessible via the roam ports of another NACN member's system, and thus, if the same holds true for Boston, there is now NO WAY to receive calls without paying home airtime in Boston. Since the entire idea behind the NACN is nearly seamless service, it would be in SWBell's best interests to rid itself of this inane money-grabbing policy. However, if they are too stingy to let it go, then the roam ports need to be "open" for Boston subscribers who wish to avoid these charges. Overall, however, a very nice and smooth addition to the NACN, with only a few minor problems to resolve. Doug Reuben dreuben@interpage.net (203) 499 - 5221 Interpage Network Services -- E-Mail/Telnet to Alpha or Numeric Pagers & Fax ------------------------------ From: CHRIS.FARRAR%prothink@csrnet-bbs.com Subject: Canadian CIC Codes Date: Wed, 18 Jan 1995 21:26:54 GMT Organization: CSRNet(Voice 1705-949-9275 Data 1705-942-5370) To Pat and all those looking for the Canadian 10XXX codes, here is the latest list I have, issued by Industry Canada (formerly Dept. of Communications), and the address to write to for updates: Stentor says that responsibility for 10xxx and 950-xxxx numbers has been trasnferred from Stentor to Industry Canada, effective March 1, 1994. The new address for the Canadian Nmmbering Administrator (CNA) is: Christiane Chasle Canadian Numbering Administrator (CNA) Industry Canada 300 Slater Street, 18th Floor Ottawa, Ontario K1A 0C8 Telephone (613) 990-5554 Stentor also sent me a list of the codes, as they were before responsibility for numbering was assigned to Industry Canada. CIC stands for Carrier Identification Code, I think. The table is confusing. A code of 869 identified as 3D FG B&D is a three digit code used for both Feature Group B (950-xxxx) and Feature Group D (10xxx), so it would expand to 950-0869 and 10869. A CIC identified as 4D FGB expands to 950 followed by the four digits. Assigned Carrier CIC Code Feature Group Unitel 869* 3D FG B&D *869 is U.S. CIC Unitel 686 3D FG B&D Unitel 858 3D FG B&D AGT 424 3D FGD BC Tel 323 3D FGD Bell Ontario 363 3D FGD Bell Quebec 484 (see note) 3D FGD Note: Bell Quebec CIC reclaimed 1993-11 Island Tel, PEI 422 3D FGD Manitoba Tel System 783 3D FGD Maritime Tel & Tel 434 3D FGD NB Tel 448 3D FGD Newfoundland Tel 445 3D FGD Sask Tel 242 3D FGD EdTel 324 3D FGD Sprint Canada 5348 4D FGB Sprint Canada 348 3D FGD ACC 1234 4D FGB ACC 234 3D FGB Fonorola 507 3D FGD Fonorola 5507 4D FGB Westel 5978 4D FGB Westel 978 3D FGD STN 773 3D FGD ATCI 235 3D FGD TelRoute 318 3D FGD I assume that Bell Quebec will be using the Bell Ontario code of 363. After all, both Bell Quebec and Bell Ontario are simply divisions of Bell Canada, not separate corporations. A more up-to-date list of these codes may be available from Industry Canada, at the above address. Note: Not all carriers accept casual calling, and not all carriers are available from each province. Chris The Collosus Soo Resource Network - CSRNet - Gated InterNet Newsgroups 40,000 + Files Online - 6 Lines - 1-705-942-5370 (16.8 USR DS) File Request CSRNET or FILES from 1:222/21 or 11:11/0 Satellite Downlink - 5-10 Megs of New Files Daily 1-705-949-7224 (28.8) ------------------------------ From: stari@io.org (Peter Granic) Subject: Questions About WAN Compression For Data Networks Date: 19 Jan 1995 08:09:29 -0500 Organization: Internex Online (io.org) Data: 416-363-4151 Voice: 416- 363-8676 I would appreciate it if someone could fill me in on how WAN compression is developing as they see it. Currently, we are only using V.FAST Motorolla modems with synchronous data compression in order to get throughputs of up to 30Kbs on a data-conditioned phone line. I was more interested in the use of compression in order to improve leased line performance, and thus leased line costs. By the way, the V.Fast modems are used to give us some decent bandwidth to "hick town" sites, where we can't get centrex or ISDN. Now regarding compression on regular leased circuits: As far as I can tell, the option is a no-brainer. Most companies advertise compression of 2.5-4 times, so that say 56K circuits can give an effective bandwidth of 130-200Kbs. So, for example, Cisco is advertising that they will be bundling this capability with their routers in order to help reduce customer's costs. Question: Is most of the compression which bridge and router manufactures use for WAN access implemented in software or hardware? Question: Is most of this technology developed in-house using standard compression algorithms? Do they license compression algorithms/technologies from other companies? Question: Assuming compression is being done with a third party vendor, i.e. hypothetically, let's say a Wellfleet router is used in combination with say some Motorolla equipment (I imagine they have it for leased lines) to increase WAN bandwidth. Is adding the extra vendor a major headache in terms of operating the network, as opposed to bundling the components into one vendor's products? Thanks, Peter Granic ------------------------------ Date: Thu, 19 Jan 1995 09:41:21 +0000 From: KRISTOFF.BONNE@PIRESSYS.BELGACOM.RTTIPC.belgacom.be Subject: Re: DQDB AND SMDS Greetings, Fred. >> 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. Right! (BTW: How many bit/s are T1/E1/T3/E3. etc.?) > 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. Sounds a lot like a OSI-variant of the IP Internet. (?) > 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. Seames to be the situation here in Belgium. > 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. I am more interested in the situation in Europe. Anybody any info on MAN networks in Europe. (As far as I know, there is -at least- a MAN in stockholm and one somewhere in the UK). úÿ Technology? Number of users? Pricing? Interconnection? Talking of interconnection: I've read some the 'grand plan' is to build a number of high-speeds interconnection pockets (mainly using DQDB, ...) and the interconnect them all using ATM-links. Are there already such interconnections? Does there exists an international numbering-sceme for all these networks? For the record, this is the situation in Belgium: BelgaCom (up to 1998 Belgium's sole operator) operates a MAN in two cities: Brussels and Antwerp. They use DQDB and operate at 140 Mbit/s internally. The MANs are interconnected at 34 Mbit/s. Connections to the MAN are possible at speeds of 2 and 34 Mbit/s, using 802.3 ethernet, 802.5 token ring, 802.6 DQDB and G.703. (whatever that may be ;-)) SMDS is supported. Apart from that, there is a ATM-based network in the province of Antwerp (called 'MANAP'), operated by the {city|province} of Antwerp. Brussels also houses a switch of the (well known) pan-European ATM pilot network. (of which I have no further information neither ;-)). Cheerio! Kristoff Bonne, BelgaCom IS/TeLaNet netwerk planning en - beheer (C=BE;A=RTT;P=RTTIPC;S=Bonne;G=Kristoff) fax : +32 2 2025497 kristoff.bonne@rttipc.belgacom.be Voice mail : +32 70 615492 ------------------------------ From: ua291@fim.uni-erlangen.de (David O. Laney) Subject: ANSI Terminal Communications Date: Thu, 19 Jan 1995 13:12:32 GMT Organization: Free-Net Erlangen Nuernberg, Germany Hi Netters, I am interested in getting the ANSI Terminal Standards (i.e. escape sequences) to use to drive a communications package. I would like to get the full set of sequences of which ansi.sys in the DOS world is only a subset of. If you know how to get a hold of the standards or Ansi people. Please drop me a line at dl211@randr.com. Thanking you in advace. From: David O. Laney Internet: ae711@dayton.wright.edu Voice: +1 (513) 443-2765 Fax: +1 (513) 443-2489 ------------------------------ From: L.C. Clower Subject: Internet Software Wanted Date: Thu, 19 Jan 95 02:09:29 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Somebody please drop me an email re: software packages to access Internet. I have local access to Sprintnet but what do I need now? Have PC. Thanks, L. C. Clower LCCLOWER@DELPHI.COM ------------------------------ From: mfraser@vanbc.wimsey.com (Mark Fraser) Subject: Re: T1BBS Gone? Date: 19 Jan 1995 07:32:22 GMT Organization: Wimsey Information Services I've answered my own question. ftp ftp.t1.org ; telnet t1bbs.t1.org. New phone numbers in Washington, DC. The site moved from California. That explains why my problem. ------------------------------ From: mfraser@vanbc.wimsey.com (Mark Fraser) Subject: Re: BC Tel, SaskTel, Internet Date: 19 Jan 1995 07:39:22 GMT Organization: Wimsey Information Services I shouldn't be so irreverent, but I interpret BCTel's response to mean "Someone already has control of the urban centers at 1.60 an hour, we're getting 9.00 or more an hour from the smaller places now, why should we reduce it to the three bucks or so that Sask is charging ..." I bet they don't say THAT when you call. Earlier information -- New Brunswick. NBTel went from free to 10.00 an hour last year, so everyone went away. Last I heard, only a few came back when they reduced it back to five bucks. And then we have Brent Sauder of the Advanced Systems Institute [sorry, Brent ....] who was also quoted in the Sun as rejecting the concept of "put it in place and they will find a use for it". Set the movement back ten years. And the telcos are telling us that Rogers and Shaw are arrogant. Time for the revolt, folks ... /Mark ------------------------------ From: Liron Lightwood Subject: Re: Wireless CO's Challenge New NPAs? Date: Thu, 19 Jan 1995 19:12:20 +1100 Regarding the question of people always having to dial an area code if cellular phone numbers were moved to their own prefix. This does not have to be the case. Here in Australia, we have the best of both worlds. Our cellular phones have their own area code like prefixes, e.g. 018, 015, 041. However, when making a local call from a cellular phone, you only have to dial the six or seven digit number, no area code required. For example, if you're in Melbourne (03), to dial (03) 123 4567, you would dial 123 4567. If you were in Sydney (02) and you wanted to dial (02) 123 4567 you would dial 123 4567. To dial another cellular phone from a cellular phone, you would have to dial the whole number, including the prefix. Perhaps this sort of system could be implemented in the US, thus solving the problems which the wireless CO's are concerned about. The only problem is areacode splits. Suppose you were near the 213/310 boundary. How would the cellular phone base station know which side you were on? What about the customer? Liron (Ronny) Lightwood - liron@insane.apana.org.au <=== NEW ADDRESS Insane Public Access, Melbourne Australia [TELECOM Digest Editor's Note: Unless I am misunderstanding something, we do dial calls now as you suggest. If a cellular phone is in area 708 (that is, *based* in 708, or using that as its 'home') then we need to merely dial the seven digit number. It does not matter where the phone actually happens to be in at the moment; the phone could be in New York for all anyone cares. If 'follow me roaming' is turned on, we still just dial the seven digits if in the same 'area'. PAT] ------------------------------ From: cmylod@nl.oracle.com (Colum Mylod) Subject: Re: Attention: 800 Number Subscribers (News Alert) Date: 19 Jan 1995 09:05:01 GMT Organization: Oracle Corporation. Redwood Shores, CA Reply-To: cmylod@uk.oracle.com Dik.Winter@cwi.nl wrote: > Why would any European customer wish numbers like 800 THE CARD, unless > they expect most of their traffic from the US? [...] > In Europe letters are *not* used. And when they were used assignment > was not identical to the US assignment. See the telecom archives for > an article were I gave some European assignments. Ah but Dik, British Telecom intends to reintroduce letters in phone numbers (they've been on various phone units for a long while -- imports mainly). Even in non-English Europe you'll see them back if for no other reason than introducing variety in freephone numbers. Currently a lot of European (monopoly) telcos issue patterned numbers like 123456 or 876 876 etc. Having letters ups the 'saleable" freephone number combinations. According to a brief glimpse I got at uk.telecom (is this available via listserv anyone?), BT will use the same letters-numbers pattern as the Bell one but with Z added to the 9 key and Q on 0 (I think, going from memory). The original British pattern had letter-O on number-0 (THAT's sensible IMHO). ------------------------------ From: bwright@jolt.mpx.com.au (Ben Wright) Subject: Re: GSM Cellular Operators List Date: 19 Jan 1995 12:16:42 GMT Organization: Microplex Pty Ltd Australia has three GSM networks, Telecom, Optus and Vodafone. ------------------------------ From: ajdsv@ind.rwth-aachen.de (Andreas Junklewitz) Subject: Summary: Looking For a CHILL Compiler Date: 19 Jan 1995 13:44:14 GMT Organization: RWTH Aachen Reply-To: ajdsv@ind.rwth-aachen.de The solution for my problem seems to by the pre-release of the GNU Chill compiler. It is available by anonymous ftp at ftp.cygnus.com: pub/chill-1.4.tar.gz. Thank you very much for your answers: Per Bothner Mike Stump With best regards, Andreas Junklewitz, Phone: ++49-241-806984, Telefax: ++49-241-8888186 Institute for Communication Systems and Data Processing RWTH-Aachen (University of Technology) Muffeter Weg 3, 52072 Aachen, Germany E-Mail: ajdsv@ind.rwth-aachen.de or junklewitz@rwth- aachen.de ------------------------------ Date: Wed, 18 Jan 95 23:05:51 GMT From: Carl Moore Subject: Re: NANP 800 Numbers From the UK Drat, I forgot to ask (or notice?) what happens when you dial that North American 800-MY-ANI-IS from the UK. [TELECOM Digest Editor's Note: Two or three people reporting on this said MY-ANI-IS reported they were calling from something like 702-000-5555. Someone else mentioned their belief that calls from Europe to 800 numbers are being sent to somewhere in Nevada where they are then in turn being sent out to the actual numbers, thus the 702 part of the ANI. PAT] ------------------------------ Subject: Re: Legal Problem Due to Modified Radio From: drharry!aboritz@uunet.uu.net (Alan Boritz) Date: Thu, 19 Jan 95 07:42:46 EST Organization: Harry's Place - Mahwah NJ - +1 201 934 0861 bill.garfield@yob.com (Bill Garfield) writes: > While the writer is correct in his statement that Amateur or Ham radio > equipment is not 'type-accepted', equipment which -lawfully- operates > on commercial frequencies (police frequencies) and is capable of > TRANSMITTING thereon, _must be_ type accepted, approved and certified > for such use. The modifications therefore would constitute an equipment > technical violation. No, Bill, they wouldn't. The transmitter wasn't operated on those frequencies, therefore there was no "technical violation." > Although the act of 'tampering' with non type-accepted equipment is > allowable, the moment that equipment radiates energy on frequencies > where type acceptance _is_ a requirement, then the modified equipment > is in violation and as "property" it becomes contraband. But the equipment described wasn't operated on non-amateur frequencies, therefore it was never "in violation." > While FCC regulations deal mainly with use and not possession, the > writer may still be on shaky ground. I certainly wouldn't want the > local constabulary _aware_ that I possessed transmitting equipment > capable of operating on their lawfully assigned frequencies. Not shaky by any means, just not wise. > But the obvious question which remains unanswered is -why- was the > person's room searched in the first place? "Reasonable suspicion" is > sufficient grounds in most jurisdictions, but suspicion of what? Suspicion of ACTUALLY causing harmful interference doesn't seem to be an issue, since it doesn't seem to have been raised. It would appear that the sole purpose of confiscating the radio was because it MIGHT be used to transmit on local government frequencies. There's a big difference between MIGHT and DID. > [TELECOM Digest Editor's Note: Well, this is something the original > writer did not explain to us, and as you suggest, it seems like a very > important part of this whole mystery. If their 'reasonable suspicion' > had to do with improper or inappropriate transmissions on the radio, > then the defenses discussed to date may go topsy-turvy in court. Not exactly. I would expect that it would be just the opposite. If the officers were looking for a pirate transmitter that *caused* (in the past tense) interference with their communications, they were CLEARLY outside of their jurisdiction. ------------------------------ End of TELECOM Digest V15 #47 *****************************