Phoenix Rising BBS/phoenixrising.zip/phoenixrising/tele-dig/td14-052.txt

Text File | 1994-01-30 | 25KB | 580 lines

TELECOM Digest     Sun, 30 Jan 94 10:27:00 CST    Volume 14 : Issue 52

Inside This Issue:                          Editor: Patrick A. Townson

    Re: Cellular Billing of Third Party, etc. (John R Levine)
    Re: ITU-TS (CCITT) Automated Mail Interface (Dan L. Dale)
    Re: INTERNET Connections: What's Involved? (Peter M. Weiss)
    Re: ISDN NT1 Power Source (David le Comte)
    Re: New Area Code 360 in Washington State (David Breneman)
    Re: All Wire Isn't The Same (Larry Jones)
    Re: All Wire Isn't The Same (Todd Inch)
    Re: Real Time Audio Compression (Les Reeves)
    Re: Real Time Audio Compression (David Breneman)
    Re: Shannon's Law ([e-mail])
    Re: Shannon's Law (was Re: Hayes' New Modem) (Ken Leonard)

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 GEnie.
Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is compilation-copyrighted by Patrick Townson Associates of
Skokie, Illinois USA. We provide telecom consultation services and
long distance resale services including calling cards and 800 numbers.
To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone
at 708-329-0571 and fax at 708-329-0572. Email: [e-mail].

    ** Article submission address only: [e-mail] **

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 gatewayed to Usenet where it appears as the moderated
newsgroup comp.dcom.telecom. It has no connection with the unmoderated
Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
Digest" shares archives resources at lcs.mit.edu for the convenience
of users. Please *DO NOT* cross post articles between the groups. 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.
----------------------------------------------------------------------

Date: Sat, 29 Jan 1994 17:39 EST
From: [e-mail] (John R Levine)
Subject: Re: Cellular Billing of Third Party, etc.
Organization: I.E.C.C., Cambridge, Mass.


> Southwestern Bell Mobile Systems in St. Louis was unable, for
> whatever reason, to bill (900) numbers, collect calls, and third-party
> billed long distance calls to cellular phones, IF the call went
> through a long-distance carrier.

> my assumption is that ANI just doesn't work on some (all?) cellular
> systems.

It is my understanding that cellular exchanges connect to the rest of
the phone network like PBXes.  Some look like large PBXes, e.g. my
Boston NYNEX number which is in 617-645, where the entire prefix is
cellular, and others look like small PBXes, e.g. my Vermont Atlantic
Cellular number which is in 802-296, a prefix which is mostly normal
wireline customers in White River Junction.  In the latter case, I
expect there are just a bunch of DID trunks into the local switch,
with a modest block of numbers assigned to the cellular carrier.

For the Boston number, ANI works to some extent, because they have
equal access long distance.  My long distance calls appear on a
separate Sprint bill.  (Actually, long distance calls made through
NYNEX appear on the Sprint bill, even if I make them while roaming
somewhere else, while those made from other places appear on the NYNEX
bill.)  Sprint has no trouble figuring out what number I'm calling
from, although on the bill they give no direct indication where each
call was made from, and if I care I have to match them up with the
NYNEX local bill.

I expect that NYNEX has direct trunks to the long distance carriers
for toll calls, and pass only intra-LATA calls to the local exchange.
900 calls are a particular pain, because you have to translate them to
know what the appropriate carrier is, so that the cellular switch
would have to interface to the 900 lookup system, which would be
expensive, and even worse, who knows what they'd do if the number were
handled by a carrier with which they don't have a billing arrangement.
800 requires the same lookup, but they can pass them to the local
telco via the PBX interface, even though it doesn't pass correct ANI,
since they can get away without precisely identifying the calling
number.  That's why 800 calls from cell phones tend to report a random
trunk belonging to the cellular carrier.

But I expect that another reason that you can't bill anything other
than a direct dialed call to a cellular phone is that the cellular
phone companies don't have billing arrangements with the IXCs.
Certainly, if I were a cellular carrier, I wouldn't make such arrange-
ments unless the regulators forced me to, since the small amount the
IXCs pay for billing would be unlikely to pay for grief of customer
complaints about them.

On a related note, it appears that only cellular carriers controlled
by RBOCs (and probably GTE) have to offer equal access toll calling,
due to the MFJ.  Is this true?  And are there plans to require other
cell carriers to go to equal access and/or to require that they handle
arbitrary IXC billing any time?


Regards,

John Levine, [e-mail], [e-mail], [e-mail]

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

Date: Sat, 29 Jan 1994 18:36 EST
From: Dan L. Dale <[e-mail]>
Subject: Re: ITU-TS (CCITT) Automated Mail Interface


Thanks John ... I have used both the Gopher and direct-dial method
with success.  Would you happen to know if the IEEE or ANSI has a
similar mailserver for pulling down standards? So far so good ... I've
got RFC's, FYI's and ITU's, but no IEEE's or ANSI's. Pointers Gladly
Accepted.


Regards,

Dan Dale   [e-mail]


Forwarded Message

Date:     Sat Jan 29, 1994  3:14 pm  PDT
Source-Date: Sat, 29 Jan 94 17:07 EST
From:     John R Levine
          EMS: INTERNET / MCI ID: 376-5414
          MBX: [e-mail]

TO:     * Dan L. Dale / MCI ID: 551-7538
TO:       telecom
          EMS: INTERNET / MCI ID: 376-5414
          MBX: [e-mail]
Subject:  Re: ITU-TS (CCITT) Automated Mail Interface
Message-Id: 80940129221408/0003765414NA1EM
Source-Msg-Id: <[e-mail]>


Users directly on the Internet should note that there are easier ways
to get ITU documents than the e-mail interface.  In particular,
they're all available via gopher.  If you have a local gopher program,
gopher to info.itu.ch, at the usual gopher port number 70.

If you don't have a local gopher client program, you can telnet to
either ties.itu.ch (a VMS system) or info.itu.ch (an OSF/1 system) and
log in as gopher.  Both attempt to adapt to your terminal type; if you
have a type they don't understand they give up and log you out.
Generally you can fake them out by setting your TERM variable to ansi
or vt100.

You can get to all of the documents via gopher menus.  Once you've
found the document you want, type D for download, and it'll give you a
large menu of choices.  If you're dialed in from a PC, you'll probably
want to use zmodem or kermit to retrieve documents to your local disk.
If you're telnetted directly from a workstation, you can e-mail
documents to yourself, and, on TIES only, give it a host, login, and
password and it will FTP you the document.

For people without a direct Internet connection, e-mail to the mail
server is usually the best option.  If you don't pay your own phone
bill (or you happen to be a local phone call from Geneva) their
dial-in number is [phone], and their X.25 address is
#228468111112.

The documentation suggests that documents are available by FTP, but at
this point anonymous FTP to ties and info doesn't work.  You can use
the FTP option on their gopher server to receive files by FTP.


Regards,

John Levine, [e-mail], [e-mail], [e-mail]

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

Date: Sun, 30 Jan 1994 09:07:17 EST
From: Peter M. Weiss <[e-mail]>
Subject: Re: INTERNET Connections: What's Involved?
Organization: Penn State University


I believe you want the PDIAL document.  Here is info on how to get
it (abstracted from itself) --

From: PDIAL -07-
Subject: How People Can Get The PDIAL (This List)

EMAIL:

  From the Information Deli archive server (most up-to-date):
    To receive the current edition of the PDIAL, send email containing
    the phrase "Send PDIAL" to "[e-mail]".

    To be put on a list of people who receive future editions as they
    are published, send email containing the phrase "Subscribe PDIAL"
    to "[e-mail]".

    To receive both the most recent and future editions, send both
    messages.

    From time to time, I'll also be sending out news and happenings
    that relate to the PDIAL or The Information Deli.  To receive
    the Info Deli News automatically, send email containing the
    phrase "Subscribe Info-Deli-News" to "[e-mail]".

  From the news.answers FAQ archive:
    Send email with the message "send usenet/news.answers/pdial" to
    "[e-mail]".  For help, send the message "help" to
    "[e-mail]".

USENET:

  The PDIAL list is posted semi-regularly to alt.internet.access.wanted,
  alt.bbs.lists, alt.online-service, ba.internet, and news.answers.

FTP ARCHIVE SITES (PDIAL and other useful information):

  Information Deli FTP site:
    ftp.netcom.com:/pub/info-deli/public-access/pdial [192.100.81.100]

  As part of a collection of public access lists:
    VFL.Paramax.COM:/pub/pubnet/pdial [128.126.220.104]
    (used to be GVL.Unisys.COM)

  From the Merit Network Information Center Internet information archive:
    nic.merit.edu:/internet/providers/pdial [35.1.1.48]

  As part of an Internet access compilation file:
    liberty.uc.wlu.edu:/pub/lawlib/internet.access [137.113.10.35]

  As part of the news.answers FAQ archive:
    rtfm.mit.edu:/pub/usenet/news.answers/pdial [18.70.0.209]


([e-mail])
Peter M. Weiss         "The 'NET' never naps"             [phone]
31 Shields Bldg. -- Penn State Univ -- University Park, PA 16802-1202 USA

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

From: [e-mail] (David le Comte)
Subject: Re: ISDN NT1 Power Source
Organization: Information Services, Sydney University, Sydney, NSW, Australia
Date: Sat, 29 Jan 1994 21:16:30 GMT


[e-mail] (sohl,william h) writes:

> In article <[e-mail]>, Paul D. Guthrie
> <[e-mail]> wrote:

>> I'm looking for a couple of answers about some ISDN questions that
>> experience and Stalling's ISDN book have both left me unclear on.

>> First, a CPE can be line powered (the AT&T 7506 e.g.), but my
>> experience with NT1's are that they must be DC powered (but I've only
>> dealt with rack mounted units).  Can NT1's be line powered?

> I am unaware of any "line powering" of ISDN CPE in the USA.  Perhaps
> what is meant by "line powering" of the AT&T 7506 is that the NT-1 and
> associated power supply is located in a telephone equipment closet
> somewhere at a customer location and that is the power supply for the
> 7506.

This is quite surprising.  The standards were arranged around some
(limited) power feeding at 60V.  This power is(was) intended to supply
sufficient power to drive one (and only one) TA attached to the "S"
bus of the NT1 (2B1Q to "S" Bus interface).  The power for this
"special" device is supplied by an extra pair on the S bus reserved
for it, or by reversing the polarity of the normal power feed supplied
in Cailho fashion on the Rx and Tx pais of the "S" bus.  In this
manner, an ISDN telephone for, instance, would draw power from the
normal Cailho feed and the reserved pair, or by use of a bridge from a
reversed polarity Cailho feed.

Are you sure that a 60V feed (max current of about 20-30ma) is not
provided bu US Telcos, not even to power repeaters (if required)?
Excuse me for being scheptical, but I'm not convinced, but then I am
an Australian so "what would I know?".


David le Comte   [e-mail]

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

From: [e-mail] (David Breneman)
Subject: Re: New Area Code 360 in Washington State
Date: 29 Jan 1994 20:29:47 GMT
Organization: Digital Systems International, Redmond WA


[e-mail] wrote:

> I have not yet seen a map that shows exactly where the boundary
> will lie, but scuttlebutt is that the northern boundary of 206 should
> be somewhere between the King/Snohomish county line and the city of
> Everett, and the southern boundary just south of Tacoma.  The eastern
> boundary should enclose the suburbs of Seattle that are currently
> dialed toll-free from the city, but will not go all the way to the
> boundary with 509 at the crest of the Cascade mountains.  The western
> boundary should be in Puget Sound, with islands that are currently
> within the Seattle toll-free dialing area (Vashon, Bainbridge) to
> remain in 206.

I would assume therefore that islands and parts of the Peninsula that
are part of the Tacoma toll-free dialing area will be included as
well.  This would make the western boundary somewhere near North Bay
and the northern boundary roughly equivalent to the Pierce/Kitsap
county line.

Hiro Sugawara ([e-mail]) wrote:

> Just curious. I heard that all area codes have either 0 or 1 as the
> second digit and so do all special numbers such as 911 and 411. Is
> "360" possible?

> [TELECOM Digest Editor's Note: In the past, what you said was correct.

> about thirty years ago, the three digit prefixes were letters of the
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> alphabet rather than numbers and those letters were the first three
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> letters of words. As the usable supply of those became in short supply
> exchange names were ditched in lieu of using all numbers. Time marches
> on. Who knows what our phone numbers will look like a decade from now.  PAT]

In PNB country, the rule was two letters an a number.  So, you had
BRoadway2 (tacoma) EMerson5 (seattle) ULysses8 (Gig Harbor), etc.
(although Gig Harbor was not PNB - it was the Island Empire Telephone
Company).


David Breneman                        Email: [e-mail]
System Administrator,                 Voice: 206 881-7544  Fax: [phone]
Product Development Platforms
Digital Systems International, Inc.        Redmond, Washington,  U. S. o' A.


[TELECOM Digest Editor's Note: Well, I gave a hasty rendition of the
history. We went from 3L/4D to 2L/5D about 1950 or so; then about 1960
we began seeing 7D in the phone book and as the only way things were
being assigned. We had a mix of 2L/5D and 7D in the phone book from
about 1960 through the middle 1970's at which point the few remaining
(on paper only, in the directory) 2L/5D listings were expressed only as
7D.   PAT]

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

From: [e-mail] (Larry Jones)
Subject: Re: All Wire Isn't The Same
Date: 29 Jan 1994 23:11:41 GMT


In article <[e-mail]>, [e-mail] (Carl
Oppedahl) writes:

> Let's define four colors - R G Y B - and with that, here is a typical
> so-called "quad" wire.

>    R  G

>    Y  B

> This is Bad Wire For Two-Line Use.  It is the cloverleaf type wire
> mentioned above.  Many Readers Have Reported Cross-Talk With Such
> Wire.

If your quad wire looks like this, it is indeed bad for two line use.
The good kind of quad wire, in addition to the cloverleaf jacket that
keeps the wires accurately positioned relative to each other, has the
wires arranged like so:

   R  B

   Y  G

(note that the yellow and black wires are reversed if you're looking
at the other end of the wire).  Arranging the wires in this
configuration prevents crosstalk as well as twisted pair does.  Since
the yellow and black wires are equidistant from the red and green
wires, any signal induced by the current running through the red wire
is exactly canceled by the signal induced by the equal but opposite
current running through the green wire and vice versa.  If you're
having a crosstalk problem with quad that has the good cloverleaf
jacket but has the pairs side by side rather than opposite, you can
fix it by ignoring the traditional color code and using opposite wires
for each pair.

Although good quad is as effective as twisted pair in preventing
crosstalk, it is more susceptible to external interference, which can
still cause problems in some cases.


Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH 45150-2789
513-576-2070   [e-mail]

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

From: Todd Inch <[e-mail]>
Subject: Re: All Wire Isn't The Same
Date: Sat, 29 Jan 1994 13:26:50 PST


After reading everyone's thoughts on this exciting topic, I thought
I'd better add my own.  (Read: straighten you guys out :-)

I USED to think that the solid-colored 22 AWG stuff (Red, Green,
Yellow, Black) was not twisted pairs and that the striped 24 AWG stuff
(White/Blue, Blue/White, etc.) was twisted, which is GENERALLY true,
but I've since seen quite a few exceptions.

Lots of the solid colored six-conductor stuff GTE installs (outdoor 22
AWG) is actually paired, as is some four-color underground drop cable.

Then I recently bought some cross-connect cable (no outer sheath --
for jumpering between punch blocks in phone closets) which has a
blue/white and orange/white "pair" but is actually four unpaired
conductors.  I ASKED for two-pair, but the label on the spool says "4
cond." and the pairs aren't individually twisted.

So, now I strip off a few feet of sheath from "unknown" cable and
determine for myself if the pairs are twisted or not.  The pairs
should be independantly twisted in twisted-pair cable.

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

Date: Sun, 30 Jan 1994 11:47:38 GMT
From: Les Reeves <[e-mail]>
Subject: Re: Real Time Audio Compression
Organization: CRL Dialup Internet Access  [phone]  [login: guest]


In article <[e-mail]>:

> I am just wondering if there is any device/algorithm which may
> compress audio in real time, and let say use e.g. 4 kHz bandwidth for
> an original audio bandwidth of 8 kHz, or likewise for higher
> bandwidth?

> To my knowledge there are such devices which compress audio signals
> and then transmitt it in digital form over a digital (radio, satellite
> or cable) link, but I never heard if that could be done over an audio
> channel itself.

I dunno about bandwidth compression via *analog* channels.

There are many different ITU recommendations regarding digital audio.
Many of these are available from the ITU's TIES (Telecom Information
Exchange Services) automated document server.

To get info on using it, send a message with the line "help" in the
message body to: [e-mail]

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

From: daveb@jaws (David Breneman)
Subject: Re: Real Time Audio Compression
Date: 29 Jan 1994 20:37:28 GMT
Organization: Digital Systems International, Redmond WA


Alfredo E. Cotroneo ([e-mail]) wrote:

> I am just wondering if there is any device/algorithm which may
> compress audio in real time, and let say use e.g. 4 kHz bandwidth for
> an original audio bandwidth of 8 kHz, or likewise for higher
> bandwidth?

There is something akin to analog audio compression - the dbx noise
reduction system.  It raises the level of audio during periods of low
volume, and reduces the level as volume builds.  In this way, you can
cram a greater dynamic range onto gawdawful recording media like
cassette tapes.  Still, there is no way to "compress" analog audio to
get a greater frequency response than the wire it's travelling down.
You have to get into the digital domain to do that.  There are types
of remote broadcast encoders used by radio stations that can split and
frequency-shift a 15 kHz audio signal and feed it down four "voice
grade" telephone lines, to be reassembled back at the station, but
substituting four lines for one isn't exactly compression!


David Breneman                        Email: [e-mail]
System Administrator,                 Voice: 206 881-7544  Fax: [phone]
Product Development Platforms
Digital Systems International, Inc.        Redmond, Washington,  U. S. o' A.

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

Date: Sun, 30 Jan 1994 05:58:38 EST
From: [e-mail]
Subject: Re: Shannon's Law


> I'm the one who originally posted this question, for those who don't
> know. It's nice to know what Shannon's law says -- if you assume a 30
> dB SNR and 3100 Hz bandwidth, the law above works out to about 31
> kilobits per second. If you happened to get a quiet channel, say, 40
> dB SNR, the equation returns about 41.2 kilobits per second. However,
> this is still quite a ways off from a full-duplex, 28.8 kbps link, or
> 57.6 kbps total transfer rate. So my question still stands: How do
> they do it? Are they assuming a particularly quiet channel? Are they
> assuming more than the standard 3100 Hz of bandwidth is available?

   Yet another statement of S's Law:  C = W.log(1 + (P/(WN)), where
W = bandwidth;  P = transmitter power;  N = noise power;  C = capacity in
bits/s.

   The important points are:

   1:   S's law is for the additive white Gaussian noise channel, not for
        any other model, so multiplicative noise, for example, is not
        taken into account.

   2:   S's law gives the capacity for arbitrarily small error rates.  That
        is, up to the Shannon rate, we can transmit with as small an error
        as we please (by increaing the power, or the bandwidth).  If we accept
        a non-zero probability of error, the Shannon rate can be exceeded.

   3:   In duplex transmission, you cannot add the rates in the two directions.
        S's law is monodirectional.

   4:   Efficient modulation and coding, can give up to 6dB extra S/N
        (e.g. high level QAM with adaptive trellis coding).

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

From: [e-mail] (Ken Leonard)
Subject: Re: Shannon's Law (was Re: Hayes' New Modem)
Organization: GE Aerospace - VF
Date: Sun, 30 Jan 1994 14:27:54 GMT


In article <[e-mail]>, [e-mail] (Charles
Randall Yates) writes:

> I'm the one who originally posted this question, for those who don't
> know. It's nice to know what Shannon's law says -- if you assume a
> 30 dB SNR and 3100 Hz bandwidth, the law above works out to about 31
> kilobits per second. If you happened to get a quiet channel, say, 40
> dB SNR, the equation returns about 41.2 kilobits per second.

> However, this is still quite a ways off from a full-duplex, 28.8
> kbps link, or 57.6 kbps total transfer rate. So my question still
> stands: How do they do it? Are they assuming a particularly quiet
> channel? Are they assuming more than the standard 3100 Hz of
> bandwidth is available? The 57,600 bps is _not_ the bit rate on the
> telephone line -- it is the bit rate between the computer and the modem.

The bit rate on the telephone line is only 14,400 bps.

The 4:1 compression is the _maximum_ that can be achieved by the (MNP)
compression protocol.  And that maximum compression can be achieved
only for data having sufficient statistical redundancy -- compression
happens by essentially removing redundant bits and recoding the
remainder to eliminate ambiguity.

A (nearly) truly (statistically) random data stream (like an .zip or
.arc or .Z file already compressed) is usually not usefully
compressible, and the computer-to-modem useful data rate will drop to
the line rate.


Ken

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

End of TELECOM Digest V14 #52
*****************************