The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/t/tc13-107.zip/TC13-107.TXT

Text File | 1993-02-18 | 22KB | 470 lines

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: [e-mail] (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 <[e-mail]> John Higdon <[e-mail].
com> writes:

> Tas Dienes <[e-mail]> 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 <[e-mail]> 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
[e-mail] (gay stuff)
[e-mail] (telecom stuff)

------------------------------

Date: Wed, 17 Feb 93 11:27:30 CST
>From: [e-mail]
Subject: Re: One-Way Outgoing Service
Organization: AT&T Network Systems, Lisle, IL


In article <[e-mail]> [e-mail]
(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: [e-mail] (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 <[e-mail]> [e-mail]
writes:

> [e-mail] (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    [e-mail]


        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: [e-mail] (Jack Decker)
Subject: Re: Meaning of TTL in TCP/IP (was Jack Decker's FTP Problem)


In message <[e-mail]>, [e-mail]
(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: [e-mail] | 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: [e-mail] (Robert L. McMillin)
Subject: Re: National Data Superhighways - Access?


Andrew Blau <[e-mail]> 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:    [phone]
Hughes Aircraft/Hughes Training, Inc.  | Fax:      [phone]
Los Angeles, CA                        | Internet: [e-mail]

------------------------------

End of TELECOM Digest V13 #107
******************************