Date: Fri, 20 Jun 1997 15:27:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: adam@veda.is (Adam David) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG Subject: Re: getty modem control Message-ID: <199706202227.PAA24698@phaeton.artisoft.com> In-Reply-To: <199706200815.IAA15687@veda.is> from "Adam David" at Jun 20, 97 08:15:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> It's a pity modems don't allow for retrieving the caller-ID afterwards, > instead of spitting it out in realtime. The connect speed can be read > back on request, probably even between active sessions. Connect speed is evil. The data rate should be driven with the RS232C external clock for modems (described in the RS232C, Bell 103C, and Bell 212 standards). The negotiation for speed should be done at the carrier recognition, and not between the UART on the modem and the UART in the computer. This is an evil perpetrated on honest, God-fearing people by Intel and National Semiconductor. > Further to the discussion on the subject of (m)getty back in > February, would it work to use DSR as RI for those ports > without RI? 9 pins: chassis ground (evil waste of a pin) TXD RXD RTS CTS DSR signal ground DCD DTR I think the problem is that off-to-on DSR events are not interrupted by the UART. > AT&S1 DSR will become active after answer tone has been detected > and inactive after the carrier has been lost, i.e. becomes active > after RI and before CD (probably too late to catch caller-ID though?). Caller ID data is sent down the line between ring 1 and 2 when using POTS lines in the US. For ISDN, caller ID data is sent seperately. I still have the first Caller-ID to RS232 circuit I built (look for the circuit in an old Radio Electronics or Popular Electronics, I forget which). > I'm not making any progress with using the modem init string capability. > (DTR lights up but there is no flicker on TXD) Look at the CTS/RTS settings, and how they effect the modem and UART in the DCD-not-present state, in particular. > How could this be farmed out to a separate process? You make a "modem driver" and seperate "inbound" vs. "outbound" tty device operations. The main problem is that most of these damn "do everything" getty programs like to initialize the modems to a state which is optimal for them. This is the same reason you can't share amodem between an intermittent ISP connection and a FAX server on most Microsoft platforms. > The whole point was that the user only gets the features requested via > specific gettytab entries. Unless requested, they stay out of the way. Getty is the wrong place to do this. The corect thing for getty to do is to listen to the inbound tty pseudo device (no, not pseudo tty), and for a program to fan out the connection on the basis of DCD and DTR state transitions. The RI stuff is a hack I suggested to use as an inbound call marker; as you've discovered with 9 pin ports, it's not a very good hack. 8-(. Better to support inbound call fanning to voice/data/fax devices as seperate entities. There is actually one modem that creates two serial pseudo devices under Windows95/NT: that's the Intel modem for telephony (I can't tell you the model without going to the usability lab down the hall, sorry). I *really* liked the modem, but obviously, it required a per-modem driver to do its thing. It supported Caller-ID as well, as a device ioctl (and supported providing your own calling-ID, too). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706202227.PAA24698>