From: Anthony Chor Date: Mon, 19 Dec 94 15:19:24 PST Subject: Re: Caller ID With Call Waiting Jason White writes: > It was also mentioned that Caller-ID would work with call-waiting; > if you're on the phone and get the call-waiting beep, you'd also see > who was calling you so you could "decide whether it's worth switching > to the other call." My question is: how is this implemented. I'd > hate to think that I'm going to have a 1200 baud data burst come > roaring over the line while I'm trying to talk. Anyone know anything > more about how this? In Caller ID on Call Waiting (CIDCW), the user is informed of the incoming call via an alerting signal. This alerting signal is composed of the Subscriber Alerting Signal (SAS -- this is the call waiting beep) and a CPE Alerting Sequence (CAS). If your CPE replies with a DTMF D, it is CIDCW compatible. If your CPE replies with DTMF A, then it is both CIDCW and ADSI compatible. So, if you have a Caller ID box which is CIDCW compatible, it will mute your handset and reply with a DTMF D. (The switch will mute the far-end's voice path before sending the alerting signal, so the caller won't hear all this.) Once the switch receives your ACK, it will transmit the CID info and will restore the far-end's voice path. Your CPE is expected to restore your handset operation. If your CPE does not ACK within some period of time, the switch will restore the far-end's voice path, NOT deliver CID information, and will proceed like normal call waiting. Tony Chor Microsoft Corporation Program Manager, Telecom Product Unit ------------------------------ From: oppedahl@patents.com (Carl Oppedahl) Subject: Re: Information Wanted: Pulse Rate in India Date: Mon, 19 Dec 1994 23:00:49 GMT Organization: Oppedahl & Larson In article mirle@castlab.engr.wisc.edu (M.A. Kumar) writes: > I am setting up a modem for a friend of mine in India and the > initialization requires the selection of proper pulse rate. Can > someone tell me from the following three which one is correct for > India: > 1) make/break ratio of 39% / 61% and 10 PPS (USA/Canada) > [DEFAULT SETTING] > 2) make/break ratio of 33% / 67% and 10 PPS (UK/Hong Kong) > 3) make/break ratio of 33% / 67% and 20 PPS (Japan). It depends on the central office. The correct answer might differ from one central office to the next. Have you tried the three choices? If so, what results did you get? Are you sure you can't use touch tone? I would try 3, because if it works it will dial your numbers very quickly. If not that, then try 2, given India's historic ties to the UK. Then, if not that, then try 1. Carl Oppedahl Oppedahl & Larson, patent law firm oppedahl@patents.com ------------------------------ From: bapat@gate.net (S. Bapat) Subject: Re: Cellular Roaming in New York Suspended Date: 20 Dec 1994 04:08:50 GMT pbeker@netcom.com (Paul Beker) writes: > The ESN problem is a much, much bigger issue that won't be solved > anytime soon, in the U.S. My solution? Move to an intelligent > cellular architecture (ala GSM, or GSM-like), which actually contains > hooks and facilities to begin to address this issue. Any algorithm or > validation scheme is beatable, but one of significant complexity would > certainly turn away the vast majority of the "crooks" ... Random, idle, blue-sky thought: could be possible to use a challenge/ response authentication model for cell phone security, using perhaps a public-key/private-key encryption scheme based on PGP or RSA (or a digital signature mechanism)? For example, each cell phone could have a really long (e.g. 1K) private key burned into EPROM. When it first sends out its ESN, the base station would look up the ESN its database and send out a challenge bit pattern, which could only be decoded with the private key in the cell phone. The call would only proceed if the cell phone responds to challenge successfully. Compared to the cost of the cell phone, the cost of adding a 1K or 2K EPROM would be marginal. In the event that the cell phone's security is compromised (e.g. someone records both your ESN and your cell phone's response to the challenge and uses both to spoof you), you could take it in to a branch office and have the EPROM reprogrammed with a new private key. Call setup times would be a couple of seconds longer (due to the overhead of an extra database lookup) but quite possible many users would accept this considering the benefits involved. Subodh Bapat bapat@gate.net ------------------------------ From: fontaine@sri.ucl.ac.be (Alain Fontaine) Subject: Re: Handshaking: Computer-Computer or Modem-Computer? Date: Tue, 20 Dec 1994 03:13:05 +0100 Organization: Universite Catholique de Louvain In article (Dans l'article) , martyj@ mrcnext.cso.uiuc.edu (martin johnson) wrote: > Is handshaking, ie xon/xoff or RTS/CTS, just between a computer and > its local modem or is it passed on to the remote modem and remote > computer? Can a modem whose RTS goes low, pass the fact of that event > to the remote modem by sending a Xoff? If a remote computer sends a > Xoff thru its modem, and my local modem receives it, will it lower CTS > if xon/xoff is disabled? Any enlightenment is appreciated. Ive been > using and setting up lots of communications equipment for at least ten > years, and just realized that I dont know the answers to the above! Things have changed a lot in ten years. Ten (mmm, let's say fifteen to be sure) years ago, modems were just that: boxes containing a modulator and a demodulator, with sometimes a few additional circuits like a relay to connect the modem to the line and a ring detector. The data communication interfaces we are still seeing today were invented at that time, and their purpose was to allow the host to exercise a direct and detailed control on those simple electronic functions. If dialing by the computer was needed, one had to add another box, with a second (parallel) interface to the computer. Then came the era of 'intelligent' modems. The box called 'modem' now contains, besides the electronic circuits performing the base functions, what can be described as a computer. This computer controls the electronic functions of the modem, and also performs some new functions like error correction and data compression. So the nature of the interface between host computer and modem has changed: it is now rather a computer to computer link. Since there is a computer in the modem itself, the way it reacts to interface signals and/or particular values in the data depends on the way the (modem) computer is programmed. The user has some control on its behavio(u)r by means of the various at commands and s registers. When data correction is used, the computers inside the modems use a sophisticated protocol between them. This protocol allows (of course) the transport of user data, with full error correction and 'transparent' flow control. On each end of the link, a flow control mechanism may be used between the computer in the modem and the host computer. A different mechanism may indeed be used at each end of the link: the computers in the modems are doing the necessary 'translation'. It all depends on the way the modems are programmed. ------------------------------ End of TELECOM Digest V14 #459 ******************************