Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA08536; Wed, 15 Oct 1997 09:35:05 -0400 (EDT) Date: Wed, 15 Oct 1997 09:35:05 -0400 (EDT) From: editor@telecom-digest.org Message-Id: <199710151335.JAA08536@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V17 #282 TELECOM Digest Wed, 15 Oct 97 09:35:00 EDT Volume 17 : Issue 282 Inside This Issue: Editor: Patrick A. Townson Toll-Fraud via Remote-Access to Call-Forwarding (Chris Telesca) Book Review: "Mobile Data Communications Systems" (Rob Slade) "Sky Word Plus" - How Does it Work? (J.D. Baldwin) Number Pooling in Virginia (Tad Cook) Re: 101-XXXX For Traditional Intra-LATA LEC Toll (Al Varney) 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@telecom-digest.org * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-727-5427 Fax: 773-539-4630 ** Article submission address: editor@telecom-digest.org ** Our archives are available for your review/research. The URL is: http://telecom-digest.org They can also be accessed using anonymous ftp: ftp hyperarchive.lcs.mit.edu/telecom-archives/archives (or use our mirror site: ftp ftp.epix.net/pub/telecom-archives) A third method is the Telecom Email Information Service: Send a note to archives@telecom-digest.org to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * 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. * ************************************************************************* Finally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. Please make at least a single donation to cover the cost of processing your name to the mailing list. 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: ctelesca@pagesz.net (Chris Telesca) Subject: Toll-Fraud via Remote-Access to Call-Forwarding Date: Tue, 14 Oct 1997 07:42:57 -0500 Organization: Pagesz.net Hello again! I have posted several messages to this group over the last 17 months or so about some problems I was having with someone apparently hacking the PIN number to a Remote-Access to Call-Forwarding service, remotely forwarding my phone number to long-distance numbers without my knowledge or permission. It wasn't until a friend of mine called me on another line to tell me that someone other than me answered on my line that I knew something was up. According to my phone bill, I am supposed to have call-forwarded LD calls identified by a special calling rate code on my bill. But (at least according to both BellSouth (the phone company supplying the local phone service and the call-forwarding service) and to AT&T (my LD provider), the reason why the code doesn't show up is because I don't use BellSouth as my LD provider, and that the only way that BellSouth would have to provide that information is if I change from AT&T to BellSouth as my LD provider. I don't want to change to BellSouth because I like paying AT&T $0.10 per minute for dial-direct calls (through the One Rate Plus plan). At first I complained to both BellSouth and AT&T, but I didn't get anywhere after playing lots of phone tag. Neither company would give me enough information about: how the R-A to C-F service worked; how the calls are billed; and about other fraud (in fact everybody says I'm the first person to call and complain about this type of toll-fraud). After getting nowhere with the phone companies, I finally filed a complaint with my State's Public Utility Commission. At first I thought this was the right thing to do but now I'm not so sure that this will accomplish much. In fact, the PUC might be blocking or holding-back the phone companies here in NC from making changes in the service to not place smaller teleco's at a disadvantage. And now another interesting twist has occurred. This past Friday I called BellSouth repair service to report a suspected problem with my *66 service (calls back a busy number) at about 2:45PM, after having been logged-on to my ISP at various times throughout the day. After reporting the problem, I logged back on for about ten minutes, then called a friend in Fayetteville and talked for about five minutes, then left the house at about 3:10PM for about two hours, returning home around 5:30PM. When I got home, I went to use the phone and heard a stutter dial tone, indicating that I had a Memory Call voice-mail message. The message was time-stamped at 3:16PM that day, and was from someone with the BellSouth repair service saying that my *66 feature was working fine, but that my phone number was forwarded to a long-distance number. I finally got in touch with this repair person ans was told that the number my call was forwarded to belonged to a friend in Maryland. Problem: I didn't forward my phone to her number. At this time, the phone company either can't (or won't) tell me when the call was forwarded, if any LD calls were made and billed to me, or where the call that inititated the R-A to C-F call came from (it's for security purposes). I'm still waiting for someone with BellSouth Security to call me about this. An engineer with the PUC says he doesn't want to help me with this problem, because he thinks he can use his time better. He also told me that he thinks the phone comanies don't want to solve this problem because it isn't worth their time to solve it (apparently it costs more to solve it in terms of labor rates for technicians and engineers as opposed to the charges involved). He also says I should drop the service. I think that this is a poor attitude for a public servant to take with an issue like this. I am also bothered by the fact that somehow my phone number is being forwarded by someone other than myself) to LD numbers (some of which somehow are numbers I occasionally call). The only way somone other than myself could get that number is to: access my Voice-Mailbox (where my friend left me a message with her relatively- new phone number); my Caller-ID box (a Radio Shack Caller ID System 250 - can someone cause the CID box to remotely download information and/or somehow forward calls to a number stored on the CID box?); or that someone at the phone company is accessing my PIN number to R-A to C-F and/or Voice Mail (R-A to C-F PIN is 4 characters long ans set by phone co, Voice Mail PIN can be set by me and presumably can be read by someone at phone co) and trying to screw with me to make it look like there is no fraudulent use of R-=A to C-F by anyone other than myself - thereby making this look to be a frivolous complaint to the PUC that the PUC will likely dismiss? Any help or information would be appreciated. E-mail or call at (919)676-2597 (home phone with voice mail) or (919)982-0866 (digital pager). Please -- don't try to hack the PIN and forward any more calls please! ;-) Chris Telesca ------------------------------ Date: Tue, 14 Oct 1997 10:48:39 EST From: Rob Slade Subject: Book Review: "Mobile Data Communications Systems" BKMDCMSY.RVW 970407 "Mobile Data Communications Systems", Peter Wong/David Britland, 1995, 0-89006-751-1, U$59.00 %A Peter Wong %A David Britland %C 685 Canton St., Norwood, MA 02062 %D 1997 %E John Walker %G 0-89006-751-1 %I Artech House Publishers %O U$59.00 617-769-9750 800-225-9977 fax: 617-769-6334 artech@world.std.com %P 189 %S The Artech House Mobile Communications Series %T Mobile Data Communications Systems According to the preface, this is a less technical book intended for students, salespeople, and marketers. By and large, the book does cover the material on a conceptual level, and a number of the ideas are presented in a way that does not require recourse to mathematics. Topics dealt with include modulation techniques, radio characteristics, error control, specific proprietary networks, analogue and digital cellular, mobil data networks, wireless LANs, applications, and the future. While most of the material should be accessible to the determined reader, the author's definition of "minimal" mathematics *does* seem to contain one heck of a lot of formulae. And, unfortunately, in a number of cases, the explanations fall short, and the equations are the only explanation available. The sections on applications are a bit of a disappointment, as well. Most of the discussion is limited to the usual point-of-sale or paging functions. There is little exploration of possible future uses, or even functions such as broadcast information. copyright Robert M. Slade, 1997 BKMDCMSY.RVW 970407 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca ------------------------------ From: baldwin@netcom.com (J.D. Baldwin) Subject: "Sky Word Plus" - How Does it Work? Organization: Revealed on a need-to-know basis. Date: Tue, 14 Oct 1997 13:53:28 GMT OK, so I got this SkyTel "Sky Word Plus" pager yesterday and I've tested it out a bit and it seems to work as advertised. Other people in my company have expressed an interest in just how reliable this thing is going to be. Unfortunately, the marketing junk enclosed with the unit is pretty short on technical details (no surprise) and Customer Service seemed pretty unprepared to deal with customers who express an interest in the workings of this thing. So here I am, asking c.d.t, which seems an appropriate group for this sort of discussion. The SWP pager has three "levels" of service, depending where you are: Full Service, Basic Service and Storing Messages. What you're getting at any given moment depends on where you are relative to the company's transmitters and is displayed in text on the unit. (Coverage in southern Michigan is pretty good.) Here's what the levels mean: Full Service - Pages received are confirmed as received by the unit, apparently with some kind of checksum (?), and messages received as less than complete or garbled are re-sent. Basic Service - Pages received are not confirmed, but if you get a garbled one (or miss one), this fact will be detected (how?) when you get back to Full Service coverage, and any problems will be corrected at that time. Storing Messages - The pager can't even "hear" new pages (like when you're in the machine room in the basement of a big, metal building), but will announce itself (how?) when you return to Full Service and all missed pages will be downloaded at that time. Obviously, this pager *must* be transmitting something. (Right?) I imagine that it sends some sort of "here I am" code periodically, and if it receives an acknowledgement, it "knows" it's in Full Service, otherwise it makes its determination according to whether it can "hear" other transmissions. What happens when it goes from Basic (or storing) to Full Service? I surmise that the electronic dialogue goes something like: PAGER: "Hey it's me, pager #32E567R9!" SYSTEM: "OK, I hear you, #32E567R9. Send me checksums from any unconfirmed messages." PAGER: "5F43, 6DAA and 3321." SYSTEM: "No, that last one's incorrect, here's the message again: [...] and you're missing a message, so here it is: [...]" PAGER: "OK, checksums for those are 332A and 5B52." SYSTEM: "Yes, you're up to date now." How far off is this picture? And how good is this thing in actual practice? How often does the pager try to tell the network where it is? What are the frequencies and signal strengths involved? (I notice that this thing *eats* batteries at the rate of one AA per month, according to SkyTel. So the transmission would seem to be a significant power burden.) Any information or pointers would be greatly appreciated, and probably interesting besides. From the catapult of J.D. Baldwin |+| "If anyone disagrees with anything I _,_ Finger baldwin@netcom.com |+| say, I am quite prepared not only to _|70|___:::)=}- for PGP public |+| retract it, but also to deny under \ / key information. |+| oath that I ever said it." --T. Lehrer ***~~~~----------------------------------------------------------------------- ------------------------------ Subject: Number Pooling in Virginia Date: Tue, 14 Oct 1997 18:43:11 PDT From: tad@ssc.com (Tad Cook) Virginia Official Suggests New Area Code Scheme By Greg Edwards, Richmond Times-Dispatch, Va. Knight-Ridder/Tribune Business News Oct. 14--Changing the way phone numbers are assigned might delay the need for a new area code in Northern Virginia, a State Corporation Commission official says. In a recent report to the commission, SCC Hearing Examiner Glenn P. Richardson said that "number pooling" might be the best way to delay a second Northern Virginia area code now expected to be needed by late 1999. Currently phone numbers are assigned to telecommunications carriers in blocks of 10,000. Those numbers represent all available in a local exchange code as defined by the first three digits of a seven-digit phone number. In number pooling, which is made possible by new technology, phone numbers are assigned to telecommunications companies in blocks of 1,000 or fewer. Numbers that are now being held but not used by a carrier could be re-assigned to other carriers, possibly delaying the need for a new area code. Richardson didn't predict how much time could be bought through pooling before growth makes a new area code inevitable. Bell Atlantic, the major local phone company in Northern Virginia, has no objection to number pooling as long as it's done fairly, company spokesman Paul Miller said. Bell Atlantic prefers, however, that the state wait until a national standard for pooling is developed, he said. During the past two years, because of increasing use of phones, faxes and pagers, two new area codes have been created in Virginia. In the western part of the state, the 540 code was carved out of the 703 region, and in Hampton Roads part of the 804 region became 757. A single area code contains roughly 7.6 million possible phone numbers. In his report to the SCC, Richardson also recommended that when a new area code can be avoided no longer that Northern Virginia be split into two geographic regions with Arlington and Alexandria keeping the current 703 area code and all other Northern Virginia exchanges assigned a new area code. Representatives of local phone companies Bell Atlantic and GTE, however, said their companies favor "overlaying" a second area code over the same geographic area as the existing 703 area code. If an overlay were used, businesses wouldn't have to go through the expense of reprinting their stationery and other materials because their area code had changed, the two companies said. Because local phone companies and long-distance carriers, such as AT&T, couldn't agree last year on how the new area code should be put in place in Northern Virginia, the decision was left to the SCC. In recommending a geographic split of the region, Richardson reported that a split had been the preference of most people commenting on the issue. He also reasoned that a split would mean local calls could still be made by dialing seven digits as opposed to the 10 digits that are required when making local calls in an area with an overlay. Bell Atlantic's Miller, however, said a split doesn't eliminate 10-digit dialing. Northern Virginians who make local calls into the District of Columbia already have to dial 10 digits and, if the 703 region is split, those making local calls into the new area code will have to dial 10 digits, he said. Richardson's report is available on the Internet at www.state.va.us/scc. The SCC will accept comments on the report until Oct. 24. ------------------------------ From: varney@ihgp2.ih.lucent.com (Al Varney) Subject: Re: 101-XXXX For Traditional Intra-LATA LEC Toll Date: 14 Oct 1997 04:35:00 GMT Organization: Lucent Technologies, Naperville, IL Reply-To: varney@lucent.com In article , Jeffrey Rhodes wrote: > Al Varney wrote: >> Switches generally implement two levels of routing. One is based on >> dialed digits only -- no carrier code is needed or used. The other is >> routing based on carrier code. Dialed digit analysis can trigger >> carrier routing (using an interLATA or intraLATA PIC), or the customer >> can force it with a Carrier Access Code (CAC=101XXXX)... > Forcing no intra-LATA toll calling unless casually dialed is trickier > than simply not having a default PIC. I doubt this option is really > offered since billing and routing are distinctly different processes The option certainly exists in the switches -- whether it's "offered" or not is a tariff issue. But absence of a default intraLATA PIC doesn't mean "blocking" an intraLATA call, it means "route using LEC toll". To really "block" the non-CAC intraLATA call, you have to assign a code that effectively means "block any calls that yield this PIC". > and most lines have some sort of "free" radius of non-toll intra-LATA > calling. Calls within this radius are often charged as toll when > dialed with access codes, ie. so-called casual dialing, either 10XXX > or 101(0,5,6)XXX. Nope. Calls to a carrier are not TOLL calls from a LEC perspective. If you dial 10XXX in front of a free call, the LEC passes the call to the IXC (or whatever the XXX code selects), assuming the PUC allows such calls to be handled by an IXC. Per-second access charges are billed to the IXC, but the LEC collects nothing from the caller, and the IXC is perfectly free to not charge the caller either. In fact, the LEC doesn't require the IXC to ever charge callers for calls, so long as the access charge bill is payed by the IXC. :) > The XXXX carrier can refuse to accept such calls dialed as 101XXXX1+ > in order to force 101XXXX0+ when a suitable billing arrangement is not > in place for casual dialing. Carriers are free to refuse any call (except, perhaps, to their customer service number). > The XXXX carrier can even require the dialing carrier's network to > block the casual calling at their network. This comes up with > traditional inter-LATA carriers who must pay per-second access > charges, even for calls that they do not wish to complete! Intra-LATA carriers pay those same access charges. > When do LATAs go away? What is keeping GTE from converting all their > local customers to use GTE long distance? That might not go over too > well with the public (or the state PUCs) but does the Telecom Act of > 1996 require a CLEC or ILEC to provide choices for "toll" calling? I'd > kind of like it if I could extend my GTE local unlimited ISDN voice > and data calling for $50 a month to "any" distance ;-) The RBOC ILECs are required to offer equal-access to callers and IXCs by a consent decree. GTE is required to offer the same in some areas by a similar ruling. IntraLATA, intraSTATE rules are up to the individual PUCs. Most of the ILECs fall under PUC rules that require them to support equal access, if they want to be considered "local exchange carriers". The Telecom Act of 1996 didn't change any of those rules. Nor did it prohibit GTE from making your free calling area larger or smaller. But I don't see a lot of carriers in the near future beating a path to your door to offer 24-hour fixed-price (cheap) calls to the world. If you were, say, WorldComm, how could you keep the shareholders happy with such a revenue stream? Al Varney ------------------------------ End of TELECOM Digest V17 #282 ******************************