TELECOM Digest Thu, 9 Feb 95 12:09:00 CST Volume 15 : Issue 89 Inside This Issue: Editor: Patrick A. Townson Re: Emergency Cellular Phone (Matthew Dukleth) Re: 28.8k bps Modem (James Carlson) Re: 28.8k bps Modem (Stephen Palm) Re: 28.8k bps Modem (John Combs) Re: 28.8k bps Modem (Ken Culbert) Re: 28.8k bps Modem (John Lundgren) Re: Chicago 630 Plan - Such As It Is (Kevin Kadow) Re: POCSAG to be Upgraded to APOC (Matthew Cheng) Re: Ten Digit Dialing (Carl Moore) Re: Unit to "Speak" CLID (Mike Roche) Re: Clock Slips Again (Martin McCormick) Looking for Hands on Networking Experience (Al Gharakhanian) Re: Who Belongs to 10732 Five-Digit Access Code? (Peter M. Weiss) Re: GTE PCS/Global Roam (John Mark) Re: Cellular Fraud: How Much of it is Real Money? (David Buerger) 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@eecs.nwu.edu * 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: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 500-677-1616 Fax: 708-329-0572 ** 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 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. * ********************************************************************** *** Additionally, 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. 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: mdukleth@ix.netcom.com (Matthew Dukleth) Subject: Re: Emergency Cellular Phone Date: 9 Feb 1995 17:50:51 GMT Organization: Netcom Yes, such a product is being developed. Here is the information I have: 1. Beta tests of the phone have been underway for about two months, and will be completed, sucessfully, soon. 2. Service is contemplated in about three months. 3. The phone will have alkaline batteries, and a cigarette adaptor, so it can be stored in a car glove box for an extended period of time, and still work. 4. And, the cost will probably not be zero, but will be very low compared to current cellular service. Also, the per minute charge will include long distance, as well as cellular airtime, for a fixed price - - to anywhere in the United States. If anyone would like more information, please contact either: Beth Walsh, The National Dispatch Center, bwalsh@ndcwireless.com Jack Nargundkar, The National Dispatch Center, jnargund@ndcwireless.com ------------------------------ From: carlson@xylogics.com (James Carlson) Subject: Re: 28.8k bps Modem Date: 9 Feb 1995 18:02:04 GMT Organization: Xylogics Incorporated Reply-To: carlson@xylogics.com In article , Paul Robinson writes: >> 1. Is the bps across the twisted pair wire actually running at 28.8 or >> 14.4 when 28.8 is invoked? Or is it just data compression? > The raw data rate for a modem will be from 110 to 28,800 baud (or > 14,400 baud) depending on what the other side agrees on. The rate > will be the lowest of whatever the two modems agree on. If you call up > a service that has only 14.4 modems, or 9600 baud modems, or even > 2400, you will only get 14.4 or 9600 or 2400 even though your modem > can do more. If both modems are 28.8 and both have their highest > speed enabled, you should see 28,800 baud before any compression > occurs. > The data is not sent at 28,800 bits per second, however. Typically > the modem will divide up the telephone line into six or more channels, > and run each channel at 2400 to 4800 bits per second. By multiplexing > six channels at 2400 baud, you get 14,400 baud, etc. One or two minor nits: the data are sent at 28,800 bits per second, but not at 28,800 baud. The difference is that a bit is a binary digit (a single one or zero) while a baud is a signal-element-per-second. The signal elements sent by the modem each represent several bits (actually, with 28.8Kbps, it's a variable amount), thus with about 3200 baud and 9 bits per baud you get 28,800. This is a synchronous data rate, so async framing conversion data and data compression run on top of this 28.8Kbps pipe. Unfortunately, too many sales and marketing folks have confused the bps versus baud issue, and the terms have lost much of their original meaning. The language is all the poorer for this. James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ------------------------------ From: palm@tokyo.rockwell.com (Stephen [kiwin] PALM) Subject: Re: 28.8k bps Modem Organization: Rockwell International Japan, JEDC Date: Thu, 9 Feb 1995 12:20:03 GMT Steve Midgley wrote: > With sheepish apologies to the moderator and readers, I amend my > previous post. I must have sleeping sitting down :-) > V.32 is not the protocol spec for 14.4 modems. It's V.42. Apologies, apologies. Actually, you still have it wrong. V.32bis is where the 14.4kbps full duplex modulation is defined. V.42 is an error correction procedure (than can be used with several different modulations including V.32bis). Paul Robinson wrote: > The raw data rate for a modem will be from 110 to 28,800 baud (or > 14,400 baud) depending on what the other side agrees on. Actually, it would be 110 to 28,800 bits ber second. A V.34 28,800 modem can use one of 6 baud (or symbol) rates at a time: 2400, 2743, 2800, 3000, 3200, 3249 > The data is not sent at 28,800 bits per second, however. > Typically the modem will divide up the telephone line into six > or more channels, and run each channel at 2400 to 4800 bits per > second. By multiplexing six channels at 2400 baud, you get > 14,400 baud, etc. This is incorrect for V.34 (28,800) modems. A V.34 modem only uses a single "channel". During negotiation, the line is characterized by a process refered to as "line probing". Based on that information, one of the 6 symbol rates listed above is selected. To achieve multiple bits per baud, Trellis Coding is used. [stuff deleted... now discussing FAX] > There are two speeds for transmissions. First, when the connection is > being set up, each side will send an identifier sequence. I call it > the "answerback" after the similar sequence sent by a telex machine. > This identifier sequence is called a TTI or CSI. One of these will > typically appear in the log that the fax machine prints after 20-40 > transmissions indicating the identifying machine. The other is the > telephone number or other identifier that appears in the display > window. The two items may be different. This information is > transmitted by each machine at 300 baud, which is okay since it is > typically no more than 60 characters for each side. This 300 baud (which is also 300 bits per second in this case) modulation is the V.21 high channel. Several other pieces of information (such as machine capabilities, page width, etc) are also transfered in a protocol defined in T.30. > The sending machine then increases its speed and the transmission > takes place in the equivalent of "half duplex" mode, except that the > recipient machine typically acknowledges the end of each page and end > of transmission. Image transmission is done by V.17, V.29, or V.27ter which are all Half Duplex only modulations. > The ITU standard for fax machine transmissions supports 4800, 9600, > 12000, and 14400 baud, but typically a fax machine that does printing > will do 9600 tops, and can be downgraded to 4800 if line conditions > are bad. The bottom speed is 2400 bits per second for really crummy lines. > 12000 and 14400 are typically for fax modems in computers. But many expensive FAX machines support 14,400 (V.17) too. And you should see a lot more "cheaper" FAX machines supporting V.17 in the coming year. Regards, Stephen [kiwin] Palm TEL (Voice mail): +81-3- 5371-1564 Rockwell - Digital Communications Division COMNET: 930-1564 Japan Engineering Design Center (JST=PST+17hours) FAX: +81-3- 5371-1507 palm@tokyo.rockwell.com s.palm@ieee.org spalm@cmu.edu palm@itu.ch ------------------------------ Date: Wed, 8 Feb 1995 23:41:00 EST From: Testmark Laboratories <0006718446@mcimail.com> Subject: Re: 28.8kbps modem I connect to MCImail late at night via a 14.4kbps modem, with V.42bis compression, which is theoretically 4:1. I regularly get throughputs of 4200cps or better, which shows a compression ratio of 3:1. I recently saw a review of 28.8kbps modems in {InfoWorld}, and they saw true 4:1 bit compression on modems under "ideal" circumstances, i.e., very high- powered PCs, using V.34 modems with V.42bis compression on parallel ports, or on specially-buffered serial ports. This is not what occurs in the "real-world" because the local PC, or the host/main- frame, is often the slowdown, not the modems themselves. John Combs, Project Engineer, TestMark Laboratories, testmark@mcimail.com ------------------------------ Date: Thu, 09 Feb 1995 12:35:10 GMT From: ken@funk.com (Ken Culbert) Subject: Re: 28.8k bps Modem Organization: Funk Software, Inc. In article , tailored@netcom.com (Steve Midgley) wrote: > With sheepish apologies to the moderator and readers, I amend my > previous post. I must have sleeping sitting down :-) > V.32 is not the protocol spec for 14.4 modems. It's V.42. Apologies, > apologies. Wrong again. V.32bis is the modulation protocol spec for 14.4 kbaud; v.42 is the reliability spec; v.42bis is the compression standard; v.34 is the modulation protocol for 28.8 kbaud. Not too confusing, eh? ;) Ken Culbert ken@funk.com Funk Software, Inc. http://www.funk.com 222 Third Street voice: 617 497-6339 Cambridge, MA 02142 fax: 617 547-1031 ------------------------------ From: jlundgre@kn.PacBell.COM (John Lundgren) Subject: Re: 28.8k bps Modem Date: 9 Feb 1995 10:39:49 GMT Organization: Pacific Bell Knowledge Network David Sacerdote (DSacerdo@world.std.com) wrote: > If you purchased a modem which supports the v.34 standard AND are > using a computer to modem communications speed which is faster than > 28800bps it will actually travel across the wire at 28800bps, assuming > no line noise, no error correction, and no compression. I am also > assuming that you are connecting to another modem which supports the > V.34 standard, or whatever proprietary standard your modem supports. What is 'it' in 'it will travel..' above. I think that the above isn't telling much of the story. The link between modems may be at 28,800 BPS, but the bytes are being transmitted as octets, synchronously. They are not 10 bit asynchronous bytes as they are between the PC and modem. Also, there are other things done between the two modems, such as error detection and correction, and compression. So what is going on between the PC and modem has little relationship to what the modems are doing on the link. John Lundgren - Elec Tech - Info Tech Svcs Rancho Santiago Community College District 17th St. at Bristol \ Santa Ana, CA 92706 jlundgre@pop.rancho.cc.ca.us\jlundgre@kn.pacbell.com ------------------------------ From: kadokev@ripco.com (Kevin Kadow) Subject: Re: Chicago 630 Plan - Such As It Is Organization: Ripco Internet BBS, Chicago Date: Thu, 9 Feb 1995 08:08:31 GMT If they really are running out of numbers in the 708 area code, why not allow people and companies to voluntarily 'give up' their 708 numbers for their choice of 630 numbers? For example, businesses could release their DID lines, the 2nd ... Xth lines of hunt groups, or give up a 708 number for a 'vanity' number in in the new area code. This would at least have the effect of freeing up enough phone numbers that new residential lines could remain in the 708 code. kadokev@ripco.com Kevin Kadow FREE Usenet/Mail, inexpensive Internet - Ripco... Wearing white hats since 1983 Dialup:(312) 665-0065|Gopher:gopher.ripco.com|Telnet:foley.ripco.com ('info') ------------------------------ From: eemcheng@uxmail.ust.hk (Matthew M L CHENG) Subject: Re: POCSAG to be Upgraded to APOC Organization: Hong Kong University of Science and Technology Date: Thu, 9 Feb 1995 13:48:04 +0800 In article : > To everyone interested in POCSAG, and new more advanced terrestrial > paging systems for communications in tommorrow's world: > An overview of APOC, the upgrade to POCSAG, is now available by EMail. > If you are interested, please send a request to me (ukcbajr@ukpmr.cs. > philips.nl) stating the reasons for your interest. I would like the overview of APOC. I am now pursuing a research postgraduate degree in The Hong Kong University of Science and Technology in the area of wireless communications and so anything in this area such as paging, cellular radio and PCS is in my interest. However, I have tried the email address twice to request for the overview but all the emails are bounced back. Would the original author kindly send the overview to me by email? My email address is: eemcheng@ee.ust.hk. Thanks very much in advance. Matthew Cheng Wireless Communications Research Group HKUST ------------------------------ Date: Thu, 9 Feb 95 11:05:38 EST From: Carl Moore Subject: Re: Ten Digit Dialing Usually, the same three-digit combination has NOT been used as both a prefix and an area code (that one or a nearby one). Therefore, an area code given in a telephone number in, say, spoken form in an advertisement can be recognized by the listener as such. Such courtesy became "legal" in the Washington DC area (area codes 202,301,703) and along the 301/410 border in Maryland; in those places, local calls to another area code are published as NPA +7D (can omit the leading 1, but you may include it). Someone told me of having to use leading 1 on local call from Delaware úÿ County, PA (possibly 610-485) to Philadelphia. There are some exceptions to the above-stated use of area codes as prefixes: I believe it is 909 which is used as a prefix somewhere in southern California. And I sent a 312-630 prefix to the Digest recently. ------------------------------ From: mr@Tadpole.COM (Mike Roche) Subject: Re: Unit to "Speak" CLID Date: 9 Feb 1995 16:24:16 GMT Organization: Tadpole Technology, Inc. Austin, TX Reply-To: mr@Tadpole.COM Voice Powered Technology has a phone (Tel-It Phone I believe) which holds 40 recorded names. Each name can have up to three numbers (home, work etc). It will replay the recorded name between rings if the number received via CID matches one of the stored numbers. The recorded numbers can be dialed using voice recognition also (fair accuracy, names are divided into two groups of 20 which you have to tell it by pushing a button, up to two speakers with seperate memories for the voice recognition ... this doesn't mean you can store 80 "names".) Also has an Name and number CID with a one line LCD Display and call timer, on-hook dialing (NOT a speakerphone! only mike is in the handset). A good value IMHO at $129.95. I bought two and a friend got one after seeing mine. Available through Sharper Image etc. Also available direct although I've found VPT diffficult to deal with directly (bad delivery times and they initially quoted a higher price when it came out, terrible order line people, customer support poor and excellant in two calls. I own a Voice Organizer also.) I wanted the phones for the CID recital function. Nits: -Display bezel makes reading the upper edge of the display very difficult at most angles; -When the voice recognition feature is used, it will replay the recorded entry it thinks you said before dialing (good), but if it's wrong you have to hang up and retry (bad!!!). I wish it would recognize a spoken "NO" and "guess again" the way the Voice Organizer does. (Feedback for the VPT lurkers who I once promised some opinions to after they responded to an earlier post.) Mike mr@tadpole.com ------------------------------ From: Martin McCormick Subject: Re: Clock Slips Again Date: 8 Feb 1995 16:27:31 GMT Organization: Oklahoma State University Stillwater, OK In article dmac@trans.timeinc.com writes: > If you believe the clock slips are in the LEC's internal network > then attack it as a quality issue that they must resolve. Several people have suggested the method of using a modem with error-correction turned off to find clock slips. I have been trying this and determined that the problem is still there but is very small compared to what it has been in the past. The lines leading from the campus to Southwestern Bell are analog and there is some question about what they connect to after leaving the campus. There are definitely no T1's between here and there. What we will probably do is wait until we get another trunk that is really bad and keep it seized until it can be identified. This will make it easier to point it out to all concerned and maybe eventually lead to procedures to automatically watch for the problem before customers tell us about it. Many thanks to everybody who has sent past discussions of the problem or suggestions on how to identify or solve it. Martin McCormick WB5AGZ Stillwater, OK OSU Center for Computing and Information Services Data Communications Group ------------------------------ From: agak@ix.netcom.com (Al Gharakhanian) Subject: Looking For Hands on Networking Experience Date: 9 Feb 1995 10:52:08 GMT Organization: Netcom I have a significant amount of product development experience in the field of FDDI, ATM, SMDS, LAN and T1/T3 networking. I am looking for a way to gain some hands on network design and implementation experience in an IS or Systems Integration environment. I would be willing to dedicate a portion of my time (free of charge) to work toward this goal. Does anyone have any recommendation? Thanks. ------------------------------ Organization: Penn State University Date: Thu, 9 Feb 1995 10:42:14 EST From: Peter M. Weiss Subject: Re: Who Belongs to 10732 Five-Digit Access Code? 10-732 is also used for AT&T-customer' employee "deals" E.g. PSU has a True PSU (sm?) deal with AT&T. Similar but not the same as True USA (sm). The only time you need to dial 10-732 is when you want to call intra-LATA (from your home phone), otherwise it is your PIC. Billing is NOT handled by the LEC. Pete-Weiss@psu.edu ------------------------------ From: johnmark@tigger.jvnc.net (John Mark) Subject: Re: GTE PCS/Global Roam Organization: Third Millennium Industries Date: Wed, 8 Feb 1995 23:44:50 GMT CO/NY has already launched a similar service (January 1995). CO/NY customers get a SIM card (they call it a CellCard) for $49.99/year. They can then purchase or rent a GSM phone and can roam in 23 GSM countries. The agreement is with Vodaphone in the UK. Incoming calls must be routed through the customer's NY cellular number. The cost of roaming is a flat $2.49/minute for outgoing calls regardless of destination (local or international) and $2.49/minute + toll from NYC for incoming calls. ------------------------------ From: dbuerger@pipeline.com (David Buerger) Subject: Re: Cellular Fraud: How Much of it is Real Money? Date: 9 Feb 1995 09:11:01 -0500 Organization: The Pipeline TELECOM Digest Editor noted: >> Adam Gaffin correctly mentioned that AT&T's Bell Labs were connected to >> the network. >> Most amusing was Brayall's assertion that people should not have called >> that number since it was never listed or advertised. > [TELECOM Digest Editor's Note: I wonder where Adam has been lately? We > used to get some very nice articles from here here once in awhile, but not > for a long time now. PAT] Adam Gaffin is a reporter for {Network World}. I believe he's about to become more involved with reporting on the Internet. You can reach him at agaffin@world.std.com. David J. Buerger v: (404) 495-7494 dbuerger@pipeline.com f: (404) 495-7857 3455 Peachtree Industrial Blvd. Suite 271 Atlanta, GA 30136-2657 [TELECOM Digest Editor's Note: I wish he would stay in touch with us more often. His reports were always quite good. PAT] ------------------------------ End of TELECOM Digest V15 #89 *****************************