ms6b+@andrew.cmu.edu (Marvin Sirbu) (05/11/89)
I believe that the reasons for requiring HDLC framing within an ISDN B channel is that, because of clock differences in the network, it is possible that an 8-bit byte may get dropped somewhere along the way. This makes little difference in a voice conversation, but messes up data. SDLC framing with a frame check sequence allows you to detect the error. Marvin Sirbu
stanwyc@mtfmi.att.com (D. Stanwyck) (05/13/89)
First, I have been one of the most active ISDN data standards people in the US for the last several years. I feel I can address this terrible misconception that has been being passed around the net. ISDN does not mandate HDLC or any other framing for B-channel data. While some standards exist for particular data transfer arrangements, there is intentionally left of the user to determine what data will be sent and in what form. When a request for a 64 kbps clear channel is granted, the ISDN guarentees that 8 kilohertz integrity exists. This means that bit in is bit out. Any bit oriented protocol can be used. It is up to the two end users to determine a way to agree to what the data transfer protocol is, and haow it will be used. For CCITT standard protocols (e.g., X.25), there are ways to pass information about the throughput, rate adaption protocol, etc. I don't know the problem with the Sun workstation that started this discussion, but I suspect it is based on misinformation somewhere along the line. If there are specific questions or comments on what I have said, I will be very willing to supply chapter and verse from CCITT Recommendation X.31, or Q.931 (which I am the editor of the data parts of), or other CCITT Recommendations on the topic. I just hate to see so much misinformation about ISDN bandied about. -- Don Stanwyck o o 201-957-6693 AT&T-Bell Labs || mtfmi!stanwyc Middletown, NJ USA \__/ Education Center