Date: Sat, 21 Jun 1997 00:43:55 +0000 (GMT) From: Adam David <adam@veda.is> To: terry@lambert.org (Terry Lambert) Cc: freebsd-current@freebsd.org Subject: Re: getty modem control Message-ID: <199706210043.AAA17361@veda.is> In-Reply-To: <199706202227.PAA24698@phaeton.artisoft.com> from Terry Lambert at "Jun 20, 97 03:27:38 pm"
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. Terry, I think we are not describing the same thing here. I meant simply to record the line speed (modem to modem) established on connection (and retrain). This is not data rate, which on asynchronous modem DTE is regulated by handshaking. The incoming DTE link speed is constant. Oh, you are referring to the UART handshake? In that case I do not understand your comment about speed negotiation, unless you are referring to synchronous transfer. Concerning caller-ID storage by modem for later retrieval, I see that serious modems do this, but why Rockwell didn't include it is a total mystery to me. > This is an evil perpetrated on honest, God-fearing people by Intel > and National Semiconductor. Oh, it's a far bigger conspiracy than that. ;) > > 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 Serious 9-pin ports put RI on pin 1. Chassis ground is available at the shielding. > I think the problem is that off-to-on DSR events are not interrupted > by the UART. Yeah, it would have been a hack anyway. > > 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 could build or buy a circuit for each incoming line, but it makes better sense to have it builtin to the modem, especially when it already is. > > 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. Are you saying I need a special cable because the software is a hack, or am I misconfiguring the software? > > 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. If there is a modem driver, getty does not have to meddle with the modem at all, correct? > > 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 no other marker of calls inbound. CD signals an established call. RI is much simpler to implement as an external circuit than CID, but if the serial port is broken by design then you take your chances. > 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). Does this or any other readily available/affordable modem handle full duplex (simultaneous realtime) voice to data conversion that would be usable for an internet phone gateway? -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706210043.AAA17361>