Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!rutgers!texbell!vector!telecom-gateway From: gnu@toad.com (John Gilmore) Newsgroups: comp.dcom.telecom Subject: Re: TCP/IP over ISDN Basic Rate Message-ID: Date: 29 Oct 89 20:59:19 GMT Sender: news@vector.Dallas.TX.US Lines: 49 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 479, message 2 of 10 It seems clear that either nobody is doing IP over ISDN, or they don't read Telecom! My thanks to the authors of the several useful responses; however, there seem to be some misconceptions about ISDN in general among Telecom readers. goldstein@delni.enet.dec.com wrote (others said similar things): > You get 64 kbps per > second. It's "raw bits" (oat hulls, wheat chaff...) and no more. > It's isochronous (sync) so you need to have some framing technique. > It is NOT byte oriented at this point! I beg to differ. First, the rate is 64000 bits per second; "64kbps" implies 65536 bits per second (at least to me!). Second, the frame sent between the on-premises ISDN interface and the terminals (phones) contains its own framing, and individual BYTES of data for the two D channels are contained in the frame. The AMD speakerphone chip provides byte oriented access to all ISDN B-channels and routes *bytes* among the different interfaces (audio in, audio out, two B-channels, microprocessor port, and serial interfaces). But we don't even have to refer to the standards; we have brains. If you are sending raw audio data over this link, the network had better retain byte synchronization, or the 8-bit audio samples would quickly garble into unintelligibility (7 chances out of 8 to get the wrong byte sync, unless the network maintains it for you). > Two standards exist... And you can of course create > your own if you want, since it's end-to-end. This begs the question of interoperability, which was my whole point. If I "create my own" IP-over-ISDN standard, and you implement it another way, we can't talk to each other even though we can dial each others' computers. Someone else said "what's the point -- ISDN only runs for two or three miles anyway". I don't know where they got that idea. Last I heard, ALL of the >500-mile AT&T switching centers went to digital transmission years ago, and they have been pushing digital encoding back toward the CO's ever since. ISDN is the standard for the stretch between the CO and the customer. (There *is* this problem with the idiots who designed the AT&T T1 relays not putting in enough frame sync, so they had to steal the bottom bit of one 8-bit subchannel as frame sync -- leading to "56K" (8000 7-bit samples) rather than "64K" (8000 8-bit samples) service. But I read that they have a plan in place to upgrade those bogus relays -- and meanwhile, they could just software-route the real 8-bit ISDN traffic through one of the subchannels that doesn't get its low order bit munged by the relays. Technical corrections welcomed.)