TELECOM Digest Fri, 7 Oct 94 13:45:00 CDT Volume 14 : Issue 390 Inside This Issue: Editor: Patrick A. Townson Re: UDI vs RDI in ISDN (Al Varney) Modem Saver Devices (Dan Ts'o) Re: Frame Relay vs. ISDN vs. T1 vs. ???? (Michael Gray) Re: Cellular From a Small Plane (Bob Keller) Re: Cellular From a Small Plane (John Gersh) Re: MCI Employee Charged in $50 Million Calling Card Fraud (Aaron Woolfson) Re: MCI Employee Charged in $50 Million Calling Card Fraud (styri@nta.no) Re: MCI Employee Charged in $50 Million Calling Card Fraud (Carl Moore) $50 Million in Quarters? (A. Padgett Peterson) "$50 Million" Fraud (Will Martin) 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: varney@usgp4.ih.att.com (Al Varney) Subject: Re: UDI vs RDI in ISDN Organization: AT&T Date: Fri, 7 Oct 1994 12:11:44 GMT In article , perpetual psycheness wrote: > In the world of ISDN, what exactly does UDI and RDI mean? And when > would a person know which one to use? (e.g. you try making a UDI call > and then realize that it doesn't work, so then you try RDI? What kind > of indications does the network use to determine what to do?) UDI = unrestricted digital information -- also called 64U or "64 clear" or 64C RDI = restricted digital information -- also called "64 restricted" or 64R or sometimes 64I An ISDN user does not make a UDI or RDI call. UDI/RDI is one part of the Bearer Capability information passed to/from the network. Specifically, the "information transfer capability" can be set to either UDI or RDI. The "information transfer rate" for a data call would then be set to "64 kbps". Together, the two parts are used to request 64K IDSN data calls, commonly abbreviated as 64U or 64R calls. Sometimes the 64U calls are calls "64 clear" or 64C; the "clear" signifies that the channel is "clearly" or transparently carrying all data values. The 64R calls can be used to allow calls over facilities (or trunks or circuits) that are not capable of transporting all data values -- specifically the 8-bit value "0" (or "11111111" if you are inverting data before transmission) cannot be carried. The requester of an RDI call is responsible for ensuring no "0" values are transmitted -- if they occur, the network will alter at least one bit to enforce the restriction. The "network" attempts to complete calls using the information in the Bearer Capability you provide and information provided by the operator of the network. If you request UDI, the call will route (or attempt to route) over facilities that have been designated by the operator as supporting UDI. If the facilities don't, in fact, support UDI -- you get some of your bits mangled. But this is no different TO THE NETWORK than routing you over a bad facility -- the facility is not working as the switches have been told it does. > I think that UDI is supposed to be a 64kbps clear channel xmission > (and I think you can have an RDI call over a trunk conditioned for UDI). If you request RDI, then the network (switches) will route over facilities designated to support RDI, and will use UDI routes if no RDI facilities are available. Regardless of what that switch selects, the switch at the other end of the selected facility will receive the same Bearer Capability you originally requested, so that it can attempt to select a trunk from all the original possibilities. The above "rules" apply to SS7-connected switches which are carrying the selected UDI/RDI request via SS7 signaling. I understand RDI can be a problem when calling out of or into the USA, since many countries use E1 (vs. T1) facilities that do not have a data value restriction. > And I think that RDI means that the data is restricted in the > sense that you can't have some number of contiguous 0's, which > effectively reduces the maximum bit rate to 56kbps, right? But then, ^^^^^ NO! > could you try sending data at 64kbps for an RDI call or is one of the > bits for each channel used to keep sync (I'm assuming this is over T1 > type trunks for RDI; I guess E1 type trunks don't have this problem > and are 64kbps clear channel trunks by nature?). The 56 kbps bit rate vs. RDI is confusing. I can't assure you that I can un-confuse the issues. RDI is a restriction on 8-bit data values; the value "00000000" is prohibited. But there is no rate adaption or change to the data rate implied by RDI. You send at 64 kbps, period. The reason for RDI is due to T1 facilities that don't use B8ZS or other schemes to remove the original T1 restriction that no more than 15 "0"s could be sent over the facility -- more "0"s meant loss of sync. (Some pre-B8ZS schemes used non-adjacent channels for data or borrowed bits from a control channel to remove the RDI restriction.) The use of 56 kbps in the USA/Canada and a few other T1 countries came about because one bit of the channel was sometimes used as a signaling bit (on-hook,off-hook indicator). In standard T1, this happens in every sixth frame. Because the sixth frame on one circuit isn't the sixth frame on another, the 1-out-of-6 position cannot be predicted end-to-end. This effectively removes the ability to use 8 bits -- 7 bits at the 8000 frames/second T1 rate yields 56 kbps. When SS7 signaling is used, switches don't need the signaling bit in the T1 channel. For some switches, this permits 64 kbps over RDI as soon as SS7 is implemented between 2 switches. Others require hardware upgrades to remove the "hard-coded" signaling bit. But even when the signaling bit is removed, the T1 transport facility still can't handle unrestricted data -- that requires a change to the facility (sometimes a hardware upgrade, sometimes just changing data in the facility). From an ISDN end-point, 56 kbps is a V.120 rate adaption scheme. The network knows which bit to ignore (and force to a "1"). The far end end-point will get 64 kbps data, and will ignore the eighth bit. > But, 64kbps or 56kbps doesn't necessarily mean UDI and RDI, respectively, > does it? Correct. You can, in theory, use UDI or RDI with 64 kbps calls. Or you can use UDI or RDI with 64 kbps calls rate adapted to 56 kbps. To confuse the issue, Bellcore requirements for ISDN don't recognize RDI, so they only talk about 64 kbps via UDI and 56 kbps rate adaption over 64 kbps via UDI. Unfortunately, there are some vendors who adopted the rule that 56 kbps calls would use an "information transfer capability" of RDI. When connecting to networks/equipment that only recognizes an "information transfer capability" of UDI, the call will be refused. Also, some carriers (LEC and IXC) may still have some 56Kbps facilities (trunks and "switched 56" customers). If such trunks are in the path of the call (which could start out 56 kbps with UDI or with RDI, the switches/customer beyond the 56Kbps facility receive only the called number -- and must assume a value of UDI or RDI for your 56Kbps call. The value assumed depends on the network, the switch and lots of other semi-random information. > And how does rate adaption come into the picture? Is it possible to > have 9600bps data stream rate adapted up to 56kbps for RDI? or up to > 64kbps for UDI? Is V.120 or V.110 common in the U.S.? What is > commonly used overseas? What are the advantages of V.120 over V.110 > or are there not any? V.120 common in USA. V.110 common in Europe. V.120 is more flexible, but has some added overhead. V.110 has less overhead if you can keep its fixed sub-channels full of data. 9600 bps is supported by both. Since 56 kbps is itself a rate adaption, it's hard to say 9600 bps is supported by 56 kbps -- I believe you could indicate 56K in the Bearer Capability rate adaption and would use LLC to indicate the actual partitioning of one or more 9600 bps over the 64 kbps B-channel. (Keep in mind that the ISDN end-points never actually transmit at anything other than 64 kbps.) If I remember correctly, V.120 rate adaption for 9600 bps forces 1 out of the 8 bits to a "1", so the same bit pattern would work over both 56 kbps or 64 kbps calls, whether UDI or RDI. Asking a more specific question on comp.dcom.isdn might get you a more correct (and shorter) answer ... Al Varney - just my opinion ------------------------------ From: tso@cephalo.neusc.bcm.tmc.edu (Dan Ts'o) Subject: Modem Saver Devices Date: 7 Oct 1994 07:03:59 GMT Organization: Baylor College of Medicine, Houston,Tx [TELECOM Digest Editor's Note: The original message on this did not appear in the Digest. It was ported here from some other news group where it appeared under the title "Digital Phone Lines Spell D-A-N-G-E- R". Thanks to Dan for passing it along. PAT] In article santra@netcom.com (Sandy Santra) writes: > Digital phone systems run current through their phone lines. > This current is capable of frying modems, including PCMCIA > modems--as in: PLUG THIS IN AND YOU CAN KISS YOUR MODEM GOODBYE. > One alternative is to buy a Modem Saver, a product which you can > use to test a phone line before connecting it to your laptop's > modem. IBM makes the Modem Saver, and you can order it by > calling 1-800-388-7080. Ask for part #73G5395. It's $25. > The Modem Saver will tell you whether the phone line you have > connected it to is a (1) normal line, (2) a reversed polarity > line, or (3) a digital line (with a current of more than 90 > milliamps). If it registers as a digital line, you should NOT > plug your modem into the line. It will destroy it. If the > voltage is below 90 milliamps, it apparently may register as a > "normal" line, but at least you know that plugging the line into > your modem won't damage it. Radio Shack sells a similar device without the high current function. It detects one or two lines on an RJ-11 and tells you its polarity. It costs $6. The schematic is: --------+----------+ \ | Line 1 / V red/green LED \680ohms | / .5W | --------+----------+ The circuit for Line 2 is identical. Note that each red/green LED comes standard as reverse wired (red LED "forward", green LED "reversed). Based on the above, I think an appropriate modification to include a high current indicator would be: (I've tested it) 20ohm --+-\/\/\/--+-----------+----------+ | | \ | +--->|----+ / V red/green LED red/green \680ohms | LED / .5W | ------------------------+----------+ You can adjust the 20ohm resistor value to set what is considered "high current". 20ohms lights the LED at around 90ma. Total parts costs <$4, or if you use Radio Shack's $6 line tester and add the above resistor and LED, then <$7. (I'm not faulting IBM for charging $30). This whole issue really bothers me, because it means that I can't bring a PCMCIA modem with me on trips and count on it working at any given hotel. That means I should carry around my pocket modem just in case. So then what's the point of having the PCMCIA modem! Cheers, Dan Ts'o Div. Neuroscience 713-798-3331 Baylor College of Medicine 1 Baylor Plaza S553 dan@dna.neusc.bcm.tmc.edu Houston, TX 77030 tso@cephalo.neusc.bcm.tmc.edu ------------------------------ From: misha@panix.com (Michael Gray) Subject: Re: Frame Relay vs. ISDN vs. T1 vs. ???? Date: 7 Oct 1994 10:50:13 -0400 Organization: PANIX Public Access Internet and Unix, NYC 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. > My initial recommendation was for T1 if they expected heavy usage > (>$3K/month in long distance charges). But I've seen enough articles > recently about ISDN and frame relay to be hesitant in putting my > recommendation in stone. > I know very little about telecommunications, only what I've picked up > during conversations with long distance carrier sales people. My > brief education on ISDN tells me that if I wish to implement this > scenario, people who want to call into our customer's BBS will have to > have a special terminal and their local Ma Bell has to offer ISDN. > I'm even more cloudy on Frame Relay. Can I have one 800 number with > Frame Relay? Do you need a special terminal/modem to dial into a > frame relay network? How does it compare to T1? vs. T1 cost? vs. > T1 reliability? Please correct any assumptions that I've made T1, > ISDN, and Frame Relay. I am no expert in this field, but my guess is that for long distance costs, the T1 would offer the most savings. There is a lot of compitition for long distance traffic in the T1 market. T1s can be had directly from long distance carriers with 800 services at better prices than can be had on POTS lines. I don't know if there exists modem hardware that connects directly to T1 lines. You would probobly need some expensive switching equipment to switch calls from a rack mounted array of modems to the T1. I would recommend purchasing only V.34 28.8Kbs modems, since they WILL be the new standard and if you are purchasing them in bulk, the costs will not be as great as you may think. You will also pay less in long distance time by sending data faster. 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. Also the equipment costs may be higher. This would allow you to recieve calls from people with dial-up modems and people who have ISDN service. The ISDN customers could connect at speeds of 64Kbs. If you don't need this high bandwith, then don't go with ISDN. I am not sure what Frame Relay is. I think they are talking about X.25 service. I don't know the specs on this. I think that it is a low bandwidth connection. It sends data across shared packet switch networks so the cost of such services is low, usually lower than standard long distance POTS services. It does require special hardware and connectivity at the customers end, but is generally cost efficient for low bandwidth dedicated lines. If I am wrong, maybe someone in Netland will correct me. Hope this helps some. Mike ------------------------------ Date: Thu, 6 Oct 1994 22:03:19 EDT From: Bob Keller Reply-To: Bob Keller Subject: Re: Cellular From a Small Plane On Tue, 4 Oct 1994, in TELECOM Digest (Vol 14 Iss 386) Linc Madison wrote: > I was under the impression that using a cellphone from any sort of an > airplane was a bad idea, if not outright illegal. It is outright illegal. FCC regulation prohibits the use of any cellular unit once an aircraft (large or small, jet or prop, hot air balloon or glider) is airborne. The FCC has further clarified that "airborne" means off the ground, so it matters little whether the plane flies at 30,000 feet or at 500 feed for purposes of this regulation. The FAA and the commercial airlines have their own ideas and their own separate requirements (hence the admonition on most commercial flights that you can't use your cellular phone -- although I notice they are now calling them wireless telephones -- at any time on the aircraft, ------------------------------ From: John_Gersh@aplmail.jhuapl.edu (John Gersh) Subject: Re: Cellular From a Small Plane Date: Fri, 07 Oct 1994 11:47:02 -0400 Organization: The Johns Hopkins University Applied Physics Lab In article , LincMad@netcom.com (Linc Madison) wrote: > As I was driving through San Francisco the other day, I saw a dealer > of cellular phones with a sign painted in the window with a biplane > trailing a banner announcing that you could use their cellular phones > from any small plane... > I was under the impression that using a cellphone from any sort of an > airplane was a bad idea, if not outright illegal... It is illegal, or at least contrary to FCC regs, to use a cell phone from an aircraft *while airborne* 47 CFR 22.911(a)(1) says: (1) Cellular telephones shall not be operated in airplanes, balloons or any other aircraft capable of airborne operation while airborne. Once the aircraft is airborne, all cellular telephones on board such vehicles must be turned off. The term airborne means the aircraft is not touching the ground. Cellular telephones may be installed in aircraft. A cellular telephone which is installed in an aircraft must contain a posted notice which reads: "The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the ground is subject to FAA regulations." [Parsing that first sentence was fun, wasn't it?] To be as charitable as possible toward the dealer (perhaps more charitable than warranted), the sign is technically correct in that "you could use their cellular phones from any small plane," as long as the plane is still on the ground. It would be interesting to see if the dealer actually spells out the regulation to purchasers and offers them placards of the official notice with the phones. John R. Gersh John_Gersh@aplmail.jhuapl.edu The Johns Hopkins University Applied Physics Laboratory Laurel, MD 20723 +1(301)953-5503 ------------------------------ From: awoolfso@uop.edu (Aaron Woolfson) Subject: Re: MCI Employee Charged in $50 Million Calling Card Fraud Date: 6 Oct 1994 18:58:31 -0700 Organization: University of the Pacific Well ... I sit here looking over an inter-exchange carrier switching system at our carrier and am thinking to myself: WAS that really $50,000,000 lost or was it just $50,000,000. not collected? It somehow just doesn't seem the same as someone getting on to some scheme to actually steal money. Does anyone know that the telephone network is ALWAYS transmitting to it's maximum capacity, regardless of the information placed over it? T1's are hooked up between locations and all the data is placed over those facilities in the form of 0's or 1's. If there are 1's and the A&B bits over the T1 show that there is traffic there, then a circuit gets billed. That's how simple it really is. I know that I will probably get a lot of heat from people within the telephone industry and especially the companies who we build fraud detection devices for just for saying this. But I just do not see how it can possibly really be hurting MCI. 1) MCI has FIXED costs for leasing the T1's between the POPs. 2) If a circuit logs 10 or 10,000 minutes of billable time, MCI is paying the same amount anyway. 3) Perhaps if the calls were being terminated to locations where MCI is using WilTel's or AT&T's facilities, there may be some nominal termination charges. Although I am not suggesting that it is not a big deal what happened, I just don't see how MCI can be running around and crying that they are losing all this money, when THEY REALLY AREN'T! They are just not collecting nearly as much revenue as before. Aaron Woolfson awoolfso@unix1.cc.uop.edu ------------------------------ Date: Fri, 7 Oct 94 02:11:15 +0100 From: styri@balder.nta.no Subject: Re: MCI Employee Charged in $50 Million Calling Card Fraud upsetter@mcl.ucsb.edu (Jason Hillyard) writes: > I wonder if the long distance companies will ever wake up. This kind > of crime is only possible because of the utter lack of security > inherent in calling cards. [...] It's worrying, that kind of argument. In most cases of calling card fraud the fraudsters seem to have made some effort. Making it harder to break the law doesn't make it more wrong to do so, does it? Saying it's "only possible because of the utter lack of security" is a pretty one-sided view. (Not that it's anything wrong with improving security.) Haakon Styri styri@nta.no ------------------------------ Date: Fri, 7 Oct 94 13:30:24 GMT From: Carl Moore Subject: Re: MCI Employee Charged in $50 Million Calling Card Fraud Cary, NC? That's in the Raleigh-Durham area, quite far from Charlotte. Earlier article from you said he was employed in the Charlotte switching center. [TELECOM Digest Editor's Note: The version I got referred to Charlotte. My source was the {Los Angeles Times} and a couple other places where raids took place last week. Now I believe the {Chicago Tribune} account which was used in the Computer Underground Digest placed it in Cary, as did the report in the papers in New York. PAT] ------------------------------ Date: Fri, 7 Oct 94 09:20:35 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: $50 Million in Quarters? > I wonder if the long distance companies will ever wake up. This kind > of crime is only possible because of the utter lack of security > inherent in calling cards. Why are the long distance companies so > cheap when it comes to implementing secure billing systems? Unfortunately the answer is simple -- the courts have repeatedly agreed with the service providers that *their customers* are responsible for the charges. Thus there is no financial incentive (and some disincentives) for the providers to do anything. We are just fortunate that some telco's do provide some management as a part good customer relations. What I would like to know is "if the telco/gov knew early in the year that numbers had been compromised, was anything done to notify the people whose numbers were involved then ?" Warmly, Padgett [TELECOM Digest Editor's Note: Padgett, what I do not understand and believe to be wrong about the court rulings you cite is the apparent conflict with federal regulations pertaining to fraud and misuse of credit cards generally. To the extent that telephone calling cards are credit cards -- and they are intended to allow you to pay 'later' -- how can the user be held responsible for more than some minimal amount -- usually fifty dollars -- in damages? Federal regulations pertaining to credit cards are quite clear that the card holder will not suffer as a result of fraud when the cardholder had nothing to do with it. PAT] ------------------------------ Date: Fri, 7 Oct 94 8:38:33 GMT From: Will Martin Subject: "$50 Million" Fraud While I make no defense of this thievery, and I think this particular method of stealing LD service is particularly wicked, because the charging of such phraud calls to legitimate customers' calling card numbers causes all those thousands of innocent people untold annoyance and bother to get the call-billing reversed if they notice it, and their own money if they don't, I always have a problem with the telco or the prosecutors throwing around these large numbers and claiming that these are the actual amount of the theft. The "$50 million" cited is what the billing for all these calls would have been if they had been made legitimately. That is NOT what was actually stolen. What was stolen was the cost to the company of providing these calls, not what they would have charged a customer for them. The amount of theft should be judged at the wholesale level, not the retail level. I venture to say that the actual amount stolen for a call billed at $10 is actually only a few mills' worth of electricity that MCI paid on its various utility bills at the sites through which the call traveled. The amount that MCI charges a regular customer for this exact same call is a largely fictitious number, created with little (if any) relationship to MCI's actual costs for completing that call. One could claim that some overhead factor should be applied that amortizes a share of the costs of all the physical plant, the labor expenses for all MCI employees, the cost of depreciation of the switches and other equipment, etc. But this is merely an accounting exercise -- those costs would all have been incurred whether or not these stolen calls were made. One could state that these stolen calls increased the calling level to a point where new additional switches needed to be bought or lines strung. If this can be proven to have happened -- that these specific stolen extra calls increased a service-usage level to that degree in some specific area(s) -- then I would accept those costs as being applicable to this theft. But I doubt that this will be asserted or proven. I predict that these stolen calls are subsumed in the sea of legitimate calls, and did not, in and of themselves, necessitate any such increased support costs. There ARE other costs that should be charged, though -- all the expenses incurred by the billing department in answering customer inquiries about these phraud calls that appeared on their bills, and the costs involved in reviewing the claims and processing the reverses. Each customer so inconvenienced has a claim on the thieves, too. A class-action civil suit following the criminal case's conclusion seems called for, if the defendants, after being found guilty, have any assets that could be seized. The other factor to consider, if MCI claims that the amount stolen was the retail price of these calls, is whether or not the calls would have been made if they had NOT been stolen and thus free to the caller. If the call really would have been made regardless, and the caller simply opted to steal it by using a phraudulent calling-card number, then I accept that the value of the theft is the amount the caller avoided paying. But I doubt that many of these calls fall into that category. I will venture to say that the vast majority of phraud calls that are made are made simply BECAUSE they are phraud and therefore free. People call the weather numbers in Australia; they call international phone-sex lines all over; they make data calls to some obscure BBS across the country; they make harassing calls to celebrities or political organizations; etc. -- all of which they do ONLY because these are "free" calls to them. They would not have made the call otherwise. MCI would NOT have gotten the income from these calls made legitimately because the calls would never have been made. This doesn't excuse the theft. The callers are not in any way exonerated by this fact. But it does belie the telco claim of "lost revenue" in such phraud cases. They would not have had the revenue in any case. So in short, these phreaks and crackers deserve severe penalties. In today's legal climate, it is doubtful that they'll get it. But let us all be objectively realistic in evaluating exactly what was stolen and not encourage the "sound bite" mentality of prosecutors and law enforcement who love to throw around large numbers to indicate the severity of a case or to help justify their expenditures at the next budget hearing of their legislative overseers. Will Martin ------------------------------ End of TELECOM Digest V14 #390 ****************************