gnu@toad.com (John Gilmore) (05/10/89)
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?
desnoyer@apple.com (Peter Desnoyers) (05/12/89)
In article <telecom-v09i0160m01@vector.dallas.tx.us> gnu@toad.com (John Gilmore) writes: >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 ^^^^ LAPD. >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. As far as I know it is EXPECTED (not required) that most ISDN data will be HDLC-framed. (e.g. X.25, proposed new packet-mode services) However, V.110 rate-adapted data is not HDLC-framed, and clear-channel data is not necessarily framed, either. Is there a standard restricting the format of clear-channel data to HDLC-framing? Who is responsible for that? What are they going to do about V.110? Names and document numbers would be appreciated - this is news to me and could be a Very Bad Thing. With luck it's just a misinterpretation on someone's part. I find it interesting that there is no HDLC controller on the B channels. How does the SPARCstation perform when it is being interrupted every 125uS? Peter Desnoyers
pugs@sun.com (Tom Lyon) (05/16/89)
Someday, if we're all very lucky and still alive, the entire world will use ISDN and it won't matter whether framing of packets in an ISDN channel uses byte oriented or bit oriented techniques. In the meantime, when there's a need for an ISDN device to talk to a non-ISDN device they had better agree on a protocol and SDLC framing fits the bill just fine. The V.120 standard seems to be the emerging winner for communication between ISDN and non-ISDN devices and it does indeed use SDLC framing. In my opinion, it is neither the power nor the purpose of ISDN to provide 64Kb channels between computers; rather, it is to make available all the telecom/datacom things that the phone system provides today from a single interface, and to provide continued interoperation with all the existing devices hung off the phone system. Tom Lyon Sun Microsystems