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 (n1epotsp@ibmmail.com) 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: * telecom-request@eecs.nwu.edu * 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: ptownson@townson.com. ** 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 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: johnl@iecc.com (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, johnl@iecc.com, jlevine@delphi.com, 1037498@mcimail.com ------------------------------ Date: Sat, 29 Jan 1994 18:36 EST From: Dan L. Dale <0005517538@mcimail.com> 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 0005517538@mcimail.com 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: johnl@iecc.com TO: * Dan L. Dale / MCI ID: 551-7538 TO: telecom EMS: INTERNET / MCI ID: 376-5414 MBX: telecom@iecc.com Subject: Re: ITU-TS (CCITT) Automated Mail Interface Message-Id: 80940129221408/0003765414NA1EM Source-Msg-Id: 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 +41 22 733 7575, 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, johnl@iecc.com, jlevine@delphi.com, 1037498@mcimail.com ------------------------------ Date: Sun, 30 Jan 1994 09:07:17 EST From: Peter M. Weiss 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 "info-deli-server@netcom.com". To be put on a list of people who receive future editions as they are published, send email containing the phrase "Subscribe PDIAL" to "info-deli-server@netcom.com". 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 "info-deli-server@netcom.com". From the news.answers FAQ archive: Send email with the message "send usenet/news.answers/pdial" to "mail-server@rtfm.mit.edu". For help, send the message "help" to "mail-server@rtfm.mit.edu". 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] (pmw1@psuvm.psu.edu) Peter M. Weiss "The 'NET' never naps" +1 814 863 1843 31 Shields Bldg. -- Penn State Univ -- University Park, PA 16802-1202 USA ------------------------------ From: davelec@extro.ucc.su.OZ.AU (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 whs70@cc.bellcore.com (sohl,william h) writes: > In article , Paul D. Guthrie > 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 davelec@extro.ucc.su.oz ------------------------------ From: daveb%jaws@dsinet.dgtl.com (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 0003991080@mcimail.com 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 (hiro@lynx.com) 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: daveb@jaws.engineering.dgtl.com System Administrator, Voice: 206 881-7544 Fax: 206 556-8033 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: larry.jones@sdrc.com (Larry Jones) Subject: Re: All Wire Isn't The Same Date: 29 Jan 1994 23:11:41 GMT In article , oppedahl@panix.com (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 larry.jones@sdrc.com ------------------------------ From: Todd Inch 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 Subject: Re: Real Time Audio Compression Organization: CRL Dialup Internet Access (415) 705-6060 [login: guest] In article : > 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: itudoc@itu.ch ------------------------------ 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 (alfredo@quickt2.it12.bull.it) 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: daveb@jaws.engineering.dgtl.com System Administrator, Voice: 206 881-7544 Fax: 206 556-8033 Product Development Platforms Digital Systems International, Inc. Redmond, Washington, U. S. o' A. ------------------------------ Date: Sun, 30 Jan 1994 05:58:38 EST From: n1epotsp@ibmmail.COM 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: leonardk@happy.vf.ge.com (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 , yatesc@eggo.usf.edu (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 ***************************** ------------------------------------------------------------------------------- Downloaded From P-80 International Information Systems 304-744-2253