TELECOM Digest Wed, 17 Feb 93 14:59:45 CST Volume 13 : Issue 107 Index To This Issue: Moderator: Patrick A. Townson Re: ANI on 800 Line w/o T1? (Brent Capps) Re: One-Way Outgoing Service (Al Varney) Re: FCC Proposed Ruling on Scanners That Receive Cellphones (John Langner) Re: Meaning of TTL in TCP/IP (was Jack Decker's FTP Problem) (Jack Decker) Re: National Data Superhighways - Access? (Robert L. McMillin) ---------------------------------------------------------------------- >From: bcapps@atlastele.com (Brent Capps) Subject: Re: ANI on 800 Line w/o T1? Organization: Atlas Telecom Inc. Date: Tue, 16 Feb 1993 17:26:13 GMT In article John Higdon writes: > Tas Dienes writes: >> Does anybody know if it is possible to get ANI on an 800 line without >> having to get T1 service? I just have a couple of regular (actually, >> Centranet) lines - local service is GTE, 800 is Sprint. Sprint says >> no, but I was wondering if anybody else can? > In order to receive realtime ANI from a long distance carrier, you > must have a "trunk-side connection". All connections from your telco's > switch are "line-side connections". So the answer is no, you cannot > get realtime ANI without having a direct trunk connection to a > carrier's switch. Correct. MCI offers a "DTMF ANI" service that may mislead some people into thinking that they'll get ANI over a line-side circuit. However, what this service is really designed to do is replace the MF with DTMF so you won't need to order MF receiver circuits for your PBX or ACD gear. You still need a trunk-side circuit. In article tim gorman <71336.1270@ CompuServe.COM> writes: > Third, having said trunk side connections are available from the > telco's switch, it is also necessary to point out that this probably > won't help you in getting your ANI in any way. No switch I am aware of > that is in use in the LEC networks will accept ANI from a carrier so > the telco switches couldn't tandem ANI to you anyway. The telco > switches aren't setup to pass ANI on the trunk side unless you are the > billing office for a toll call, are a 911 PSAP, or are a Feature Group > D interLATA carrier. If your PBX can handle Feature Group D signaling > formats, you want to go through the process of being designated as an > interLATA carrier, want to get an 800 NXX assigned (or wait until May > 1 when 800 portability comes into play), and provide trunks into every > sector where you may receive calls from then this may be a viable > solution. It's not necessary to be designated as a carrier. You are correct about the LECs giving FGD ANI only to IXCs and never accepting it from them, but an IXC can still drop ANI to you over a trunk-side FGD circuit (analog or digital). FGD actually encompasses four different protocols. The one that the IXCs use to terminate to LECs is called the terminating protocol, and it makes no provision for passing ANI information (which is why you've never seen the LECs accept ANI from the IXCs). However, the Exchange Access North America (EANA) protocol used by LECs to terminate to IXCs does provide for ANI signaling, and even though it's not officially defined for IXCs terminating to end-users, it can be and is done all the time, generally to inbound calling centers running large ACD systems. The only carrier I'm aware of that *won't* support this is AT&T, and the reason seems to be that they want you force to buy PRI or BRI if you want to get calling party information. There's one more way to get ANI -- you can order an SMDI data link, which is used by Centrex voice mail systems, and will also work on the 1ESS. However it's much more limited in the ways it can be used than FGD ANI. Brent Capps bcapps@agora.rain.com (gay stuff) bcapps@atlastele.com (telecom stuff) ------------------------------ Date: Wed, 17 Feb 93 11:27:30 CST >From: varney@ihlpl.att.com Subject: Re: One-Way Outgoing Service Organization: AT&T Network Systems, Lisle, IL In article jeffj%jiji@uunet.UU.NET (Jeffrey Jonas) writes: > I am curious about this: >> [Moderator's Note: Clever response. Since you only make outgoing calls >> on those lines occassionally, and never have incoming calls, you >> should ask telco to set the lines up as one-way outgoing service only. >> Then you'd never see any wrong numbers at all. PAT] > Is "one-way outgoing service" an additional cost? I've heard of the > opposite (incoming only, to prevent any long distance billing), but no > incoming calls -- interesting. Would those lines even HAVE a phone > number? Could they all be the same number, and billed based on some > imaginary number (trunk/line number just as places with more than one > line at the same number)? > At home, I have a second line that I'm currently using only for > outgoing modem/data calls. Someday I may have a FAX or BBS, so I do > not intend to block incoming calls, but it is a curious idea. Could > you elaborate why this service is offered? See below. > If it is possible to have a phone line with no number, what would > Caller-ID report? ANO? I guess that *SOME* number must be associated > with every line for billing purposes. Drat -- I'd like to have a > number with no ANI so 900 numbers can't bill me. Or was I not > supposed to notice that? Lines without Calling Party numbers are not uncommon -- PBXs can interface that way on some switches, and "rural" or multi-party lines do not have a single number associated with them. Most cellular calls don't have a calling number with the current interfaces. International numbers don't usually get transported, since the current Bellcore specs specify only ten-digit numbers. One way or another, every line has a billing number (and thus has ANI). Multi-party lines get "per-call ANI" assigned by the Operator Number Identification service ("What number are your calling from, please?"). PBXs get one (or more) billing numbers assigned to outgoing facilities. Trunks, except for Private Facilities and PBX/Service Provider trunks, don't have a billing number. > [Moderator's Note: Lines equipped for outgoing only service generally > have regular phone numbers attached to them. Callers to those numbers > either get a busy signal (if the line is in use on an outgoing call) > or an intercept message, "The number you dialed, xxx-xxxx is not in > service for incoming calls" if the line is not busy. There are other > variations: Lines for incoming service only generally provide battery > but no dial tone to the subscriber if picked up with no call coming > in. ...] Bellcore's LSSGR calls the two line capabilities "denied origination" and "denied termination". You can have either or both assigned to a line. (Service denial due to non-payment of bills is normally accomplished using a separate capability that remembers all your old line features. Denied origination requires that all originating features (call forwarding, etc.) be removed first. Anyway, denied origination should give no dial tone, but will appear busy to incoming calls if off-hook. Denied termination should never receive a call (but operator ring-back is permitted), and should NEVER appear busy to a caller, even if off-hook. The appropriate announcement on termination attempts is not suggested by Bellcore. One use for denied termination occurs in COs. Usually at least one line is marked this way, to assure there is always one line available for outgoing calls. That way, they can't all be tied up with spouses calling in with a shopping list, etc. I once was working on a CO problem (remotely), and the WECo installer gave me a number for a later call-back. He didn't know (he claimed) that it was denied incoming calls. Not any worse than giving me the WRONG number, which has happened more than once. Al Varney - just my opinion, of course. [Moderator's Note: In order for the operator to ring back, doesn't she have to already be on the line (and apply ringing voltage) rather than just dialing in? If the operator dials in, won't the response be the same as anyone else dialing in? If she was talking to someone on that line and they hang up (while she still has control of the conn- ection) then she could ring their bell, but the connection has to be there already. Am I correct on this? Regards an outgoing only line never giving a busy signal to a caller when it is in use, I have never seen any in IBT territory which work that way! I always assumed it was the nature of the wiring on that type of service, at least in the older crossbar offices, etc. Lots of payphones here are outgoing only, and when I tested this by dialing the number from the same phone I always got a busy rather than an intercept. Hang up the phone, go to the next one over and dial the first number, then being idle, I got the intercept message saying it was not in service for incoming calls. Lest you think it is me calling myself which generated the busy, I'd get the same response if someone else was using that phone when I dialed the number; busy signal if in use, intercept message if idle. PAT] ------------------------------ >From: johnl@avs.com (John W. Langner) Subject: Re: FCC Proposed Ruling on Scanners That Receive Cellphones Organization: Advanced Visual Systems Inc. Date: Wed, 17 Feb 1993 12:56:13 GMT In article kaufman@cs.stanford.edu writes: > john@zygot.ati.com (John Higdon) writes: >> Scanner laws will be just about as effective as gun laws -- only much >> sillier. The FCC is seriously deluded if it thinks it can win a >> technological war with anyone. The below-average moron outguns the FCC >> in the brain cell department. > Actually, it's not the FCC by itself in this. In fact, they have > declined to attempt to regulate scanners in the past. If you read the > NPRM, you will see that the FCC is only attempting to set a rule in > accordance with legislation passed by Congress. It's the dummies in > Congress who are short in the brain cell department. Whining about the idiots in Congress won't do any good but a half million letters to the FCC pointing out the problems with Docket 93-1 can't be ignored. So, if you want to express your concern about this issue, please write a letter to the FCC. It will only take a few minutes. Here is a rough draft of what I plan to send. Feel free to use it with little or no modification. John Langner WB2OSZ johnl@avs.com Comments on Docket No. 93-1 --------------------------- < Your address here > Feb. 16, 1993 Office of the Secretary Federal Communications Commission 1919 M Street, NW Washington, DC 20554 Dear Commissioners: After examining the text of Docket No. 93-1, I am convinced this proposed rule would NOT contribute to the stated objective of ensuring "the privacy of cellular telephone conversations." Recent magazine articles on this topic indicate that there are already millions of scanning receivers in use that can receive frequencies in the 800 MHz range. The proposed law would not not take effect for another year, providing ample opportunity for scanner manufacturers to sell many millions more. Even if a scanner isn't capable of receiving signals in this frequency range, a simple converter can be used between the antenna and receiver to shift the frequency of the radio signals. Trying to ban converters with 800 MHz in and some other frequency range out would be a futile effort. These are very cheap and simple circuits that any electronics hobbyist could build. Plans have been published in electronics magazines. Besides having no benefits, this proposed rule creates several problems: (1) The technically ignorant public might get the idea their conversations are suddenly more secure. When they learn the truth they will be bitter and more distrustful of the telephone companies and government agencies that deceived them. (2) Privacy might even be reduced. Before the publicity on this topic, most people didn't realize it was so easy to listen to cellular phone calls. Many who never considered buying a scanner will run out and buy one during the next year. (3) New regulations would place an unnecessary burden on electronics manufacturers who would have to change designs and have them recertified. (4) It would set an unfortunate precedent. If we have a ban on receivers capable of receiving a certain range of frequencies, other businesses will expect the same treatment for "their" frequencies. (5) The regulations could hit unintended targets. For example the 902 MHz band is now experiencing explosive growth for low power commercial and "ham" applications. Surely much of this equipment could easily be modified to pick up signals in the 800 MHz range even if the manfacturer didn't design it with that intention. I'm all for guarding the privacy of cellular telephone conversations but this is not the way to do it. There is only one solution. The cellular telephone companies must make encryption options available. In summary, I urge the Commission to reject the proposed regulations in Docket 93-1 because they would create many problems without making any progress toward the stated goal. Thank you for your attention to this important matter. Yours truly, < Your name here > ------------------------------ Date: Wed, 17 Feb 93 12:21:15 EST >From: jack_decker@f8.n154.z1.fidonet.org (Jack Decker) Subject: Re: Meaning of TTL in TCP/IP (was Jack Decker's FTP Problem) In message , add@philabs.philips.com (Aninda Dasgupta) wrote: > Perhaps Jack Decker will let us know whether he finally succeeded in > his attempts to ftp to mintaka. No, I haven't, but I want to take this opportunity to thank all those who wrote with suggestions. Unfortunately, I don't have the source code for the KA9Q program, and while sources are available, I think the one I am using has been specially modified somehow for use with MichNet (the statewide public data network in Michigan that I'm using) ... I'm not sure of that but do know that I have tried newer versions of KA9Q and for whatever reason, they don't seem to work as well. And even if I did have sources, I have no way to compile them here. There is a parameter that supposedly sets the IP TTL in KA9Q. In fact, my autoexec.net file (a list of commands that is automatically implemented at startup) contained the line "ip ttl 32". I doubled the 32 to 64 with no apparent change (I've even tried considerably higher values temporarily). I do know that someone using the EXACT same software, and also using MichNet (but at a different access port in a different city) is able to reach lcs.mit.edu with no problem. However, it seems that in the Internet, where there is a will there is a way! While I still can't do FTP, I have found a way to at least read some of the files stored in the telecom archives, thanks to a TELECOM Digest reader who told me about this (I don't know if he would want his name mentioned, but I've already thanked him via mail). If you can telnet to a Gopher system (which I can), and if that Gopher allows you to access "other gophers" (most do), you should eventually be able to find one that offers remote FTP access. I've found that it is often buried under some pretty cryptic menu items ... for example, on one such Gopher you have to select "Network Info", then "Internet files (FTP sites)", then you enter the location you want to FTP from and then the Gopher automatically goes out and gets the directories and lets you choose the item you want to read. If you go in through the right gopher system for your initial point of contact, you may even have the option of mailing a copy of anything you find interesting back to yourself (not sure I'd try that with some of the larger archives, though ... some are pretty huge!). I'm not mentioning which gopher(s) have the FTP access because I'm sure that several do, and I don't want any one of them to get overloaded. Try all the gophers in your home state first, then try adjacent states and fan out from there. The closer you get to home, the less delay you should experience (and gophers can be painfully slow at times anyway, so every little bit helps). As a side note, it seems as though there ought to be a newsgroup for gopher users; a place where folks can share their "finds" on the gophers. Many of the gophers have fairly cryptic menus, so it can be a daunting task to find what you are looking for, but there is a real wealth of information out there IF you can find it! I do have one request, if anyone has considerably better access to the archives than I do. I would like to find any references in the archives to the referendums in the states of Maine and Oregon (I believe these were both in the fall of 1986, if memory serves correctly) in which the voters turned down mandatory measured service. I've always wanted to get more information on that, including (if possible) text of the actual initiatives passed by the voters. If you have the capability to grep the files and let me know of any issues in which this information might appear, I would much appreciate it. Of course, I wouldn't mind receiving information on this from other sources as well! Anyway, thanks again to everyone who wrote! Jack Decker | Internet: jack.decker@f8.n154.z1.fidonet.org | Fidonet: 1:154/8 [Moderator's Note: Jack's suggestion about using gophers *does* work! I just now went to the Telecom Archives using gopher and mailed a file to myself. It is slow and cumbersome, but it gets what you want. PAT] ------------------------------ Date: Wed, 17 Feb 93 04:20:41 -0800 >From: rlm@indigo2.hac.com (Robert L. McMillin) Subject: Re: National Data Superhighways - Access? Andrew Blau writes: >> The telcos view such a highway as a monopoly arrangement, something >> the public has stated they don't want anymore. > In fact, the telcos have become *very* involved in this. During > President Clinton's Economic Summit after the election, the one moment > of reported conflict was when Robert Allen of AT&T challenged Mr. > Gore's contention that the superhighway should be a public works > project. Allen said, "I believe I have some points to make about who > should do what in that respect. I think the government should not > build and/or operate such networks. I believe that the private sector > can be and will be incented to build these networks...." He held to > this even after being challenged by Gore, who seemed to suggest that > Allen couldn't have meant what he seemed to be saying. Three cheers, then, for Robert Allen. We should hold off on the 21-gun salute until AFTER we've heard AT&T's full proposal. > LECs, too, are getting into this quickly. They see data transport as > a big part of their future, and notion that the government might come > in and build a national infrastructure that isn't the telco > infrastructure raises lots of red flags (such as bypass on a massive > scale, for one). It's no surprise that the LECs see digital services in their crystal balls. The question that needs to be asked is this: will these digital services to the residential demarc be affordable? My guess is not, especially if the LECs or the IXCs have anything to say about it. Outrageous pricing of digital services is the reason that EDS is currently sueing AT&T (I believe -- I haven't got the {Forbes: ASAP} article handy) over the issue of so-called "dark" (i.e., redundant and unused) fiber. EDS bargained for use of these dark fiber links, pushing high-volume image data over them. AT&T figured it was losing T1 and T3 business this way, so after a time, tried to cancel its existing "dark fiber" contracts with EDS. But EDS, armed with General Motors' capital and battery of lawyers, fought back under the common carriage laws. Moral: no player with the capital and the equipment wants to see you get cheap two-way digital services. (This story was much better told in the {Forbes: ASAP} supplement that came out several months ago. Therein was presented the reason behind the "dark fiber" conflict, what it means for telephony, and why tunable lasers and cheap fiber optic pipes can let you throw your 5ESS in the dumpster -- at least, in theory. The article forms the kernel of a soon-to-be-published book entitled, {Into the Cybersphere}.) Somebody once said that the triumph of capitalism is not that it can produce silk stockings for the Queen, but that it makes affordable nylons for the secretaries. That is the approach we need to take with digital services: by making them available cheaply, we can spread their benefits widely. All we need is the capital and the vision to apply it. Robert L. McMillin | Voice: (310) 568-3555 Hughes Aircraft/Hughes Training, Inc. | Fax: (310) 568-3574 Los Angeles, CA | Internet: rlm@indigo2.hac.com ------------------------------ End of TELECOM Digest V13 #107 ******************************