Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!texbell!vector!telecom-gateway From: gnu@toad.com (John Gilmore) Newsgroups: comp.dcom.telecom Subject: Bit-oriented protocols 'standard' for ISDN byte-oriented channels? Message-ID: Date: 10 May 89 01:51:18 GMT Sender: news@vector.Dallas.TX.US Lines: 41 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 160, message 1 of 8 The new Sun SPARCstation-1 uses an ISDN chip for its audio interface (the AMD Am79C30). The chip is designed for use in an ISDN speakerphone; it talks the "S" interface (towards the phone network) on one end, has a micro-oriented 8-bit bus on another, two audio inputs (mike and handset), and two audio outputs (earpiece and speaker). It has full SDLC support for the 16kbps "D" channel, but the two 64kbps full-duplex "B" channels are simply accessed a byte at a time. It appears that Sun will not support plugging your SPARCstation into an ISDN phone line, because some standards committee somewhere decided that, when used for data, the "B" channels should carry SDLC-formatted data, and the SPARCstation (and the Am79C30) has no support for this. I find this the height of lunacy. The "B" channels are physically transmitted as 8,192 8-bit bytes per second. Each frame on the "S" interface has 4 bytes of "B" channel data. It knows where all the byte boundaries are, and it doesn't lose any of them in transit. If you think for a minute, this is obvious. Voice encoded into a 64kbps channel had BETTER retain its byte boundaries, since it consists of 8-bit samples which would be gibberish if resampled on random bit boundaries. So data encoded into the same 64kbps channel would also retain its byte boundaries. SDLC framing was designed for bit-oriented channels that need a certain number of clock transitions to keep their bit timing accurate. ISDN frames already provide byte orientation and enough clock transitions, completely outside the 64kbps of data. Any bit pattern, including infinite zeros and infinite ones, can be sent down the 64kbps channels without harm. There is no need for bit-stuffing here. If framing is desired (in some cases it may be), this should be up to the communicating parties to pick a framing. The "Asynchronous SDLC framing" standard, designed for another byte-oriented communications environment (sorry, don't have its X.number) would be a possible choice. A trivial software driver for this chip would let users transmit full duplex TCP/IP data back and forth between two SPARCstations at 64kbps, anywhere that end-to-end ISDN service is offered. I'm sure that someone will code one up and probably give it away like SLIP, but if the standard had been reasonable, this capability would have been built-in by Sun. Does anyone understand why the ISDN standards bodies made what looks like a major botch here?