Index
Home
About
From: fgoldstein@bbn.|nospam.|com (Fred R. Goldstein)
Newsgroups: comp.dcom.isdn
Subject: Re: Need info on ISDN data format (relevant standards)
Date: 28 May 1997 03:49:09 GMT
In article <5mfkch$651@elvis.cmf.nrl.navy.mil>, kenh@cmf.nrl.navy.mil says...
>I have here some computers that have an ISDN ports on them, but essentially
>no software (please don't ask, it's complicated).
I know of some workstations like that. Heck, on some DEC models, there's not
even hardware HDLC for the B channels. Some have it in software.
Programming to them is not, uh, for the faint of heart.
>The hardware claims to implement an S/T interface (Level 1 Physical
>Layer). Fine, no problem -- we have tons of ISDN phones here, so I
>know that I can hook it to something that will be the right thing :-)
>
>I'm wondering if someone can tell me the relevant standards I would need
>to look at to discover what the data format is of the ISDN data stream.
>From my limited research, it seems that it will be partially switch-
>dependant -- I am pretty sure that I'm using a 5ESS (we have AT&T ISDN
>8510T phones here), but I can find out the exact info. Obviously,
>this all is in the US :-)
>My basic problem is that I see a _TON_ of ISDN standards information,
>but I'm not sure what's relevant. Can someone point me in the right
>direction? If it involves pointers to ITU documentation, then that's
>fine -- we actually have legitimate access to the ITU documentation.
>Something that tells what bits I need to send to start a call, receive
>a call (I guess I need signalling info, in telco speak) is what I'm
>looking for.
There are NO compiled written standards for ISDN in the US. It's more like
the British constitution, scattered across many documents, some critical and
some mostly nugatory, and often incomprehensible to anyone who didn't help
write them (and even sometimes to them).
In general, the switch vendors have the only semi-authoratative documents,
and each switch and each software release is different. Some refer in
part to the ITU-T specs, which are designed to work in conjunction with
"national" or "vendor-specific" documents. The AT&T/Lucent PBXs have very
poor documentation, basically incomplete delta pages from the CO "Custom"
specs, which sort of tell what's going on but only if you already sort of
understand what's going on already. NI-1's similar. I describe ISDN as
mostly a collection of "folklore".
Essentially no European has ever successfully ported a Euro-ISDN product to
the US market. And that's *with* experience with ITU specs, which are not
followed very closely in the US. You'd have an easier time rewriting Unix to
run on, say, a Foonly 36-bit computer.
--
Fred R. Goldstein k1io fgoldstein@bbn.com +1 617 873 3850
Opinions are mine alone; sharing requires permission.
From: fgoldstein@bbn.|nospam.|com (Fred R. Goldstein)
Newsgroups: comp.dcom.isdn
Subject: Re: Need info on ISDN data format (relevant standards)
Date: 28 May 1997 15:34:47 GMT
In article <5mgc8s$1so@nexus.cmf.nrl.navy.mil>, kenh@cmf.nrl.navy.mil says...
>Damn, you're good :-) In fact, this is for a DEC 3000, using the
>on-board 79C30A chip (unfortunately, Amd doesn't seem to have any
>useful on-line datasheets on this chip). This is complicated by the
>fact that I'm not running a Digital-supported operating system on it
>:-) From a system level, it doesn't seem that complicated to talk to
>the chip and do DMA to/from it ... that's all pretty well documented.
>I just don't know what bits to send :-/
I spent many years as DEC's Resident ISDN Weenie, and I argued for an HDLC
controller for the ISDN subsystem, but they claimed not to have room.
Besides, the 79C30A was *mostly* there for its codec, for the audio
subsystem, not its ISDN capabilities. I actually saw some "software HDLC"
code and its performance numbers, but they're not public. DEC's ISDN product
for Digital Unix does all that. Maybe you'd be best off trying to port it,
not that they'd give you the sources, but if you could fiche around for
them... :-)
>Well, certainly some people have produced some successful ISDN
>software/hardware that works in the US, so it's certainly _possible_,
>isn't it? :-)
Sure, but remember who does it. There's a modest community of ISDN Weenies
who have been following the specs for years. The earliest implementations
preceded the completion of the ITU standards, and the CO vendors didn't
really care about the standards after they already had "working" code.
Lucent and NorTel both have their own (not cheap) protocol manuals.
Bellcore's NI-1 spec is perhaps more useful today, along with ITU-T Q.931,
Q.921, etc. I did include some folklore in my 1992 textbook "ISDN In
Perspective", for instance.
>Are the ITU-T specs worth _anything_ in the US? Is there a least common
>denominator that I could use to implement something that works (just being
>able to send and receive calls would be good enough for now). Are
>the differences in switch protocol that fundamental, or are the changes
>mostly subtle? If I wanted to get even the bad PBX documentation, where
>would I go?
Some of the subtleties are fundamental. Heck, even Motorola got burned by
AT&T/Lucent's interpretation of NI-1 when the Terminal Type (which is not
well documented) was wrong. This newsgroup spent weeks debugging it :-) .
>>Essentially no European has ever successfully ported a Euro-ISDN product to
>>the US market. And that's *with* experience with ITU specs, which are not
>>followed very closely in the US. You'd have an easier time rewriting Unix
to
>>run on, say, a Foonly 36-bit computer.
>
>Which is one of my other nutty long-range projects (of which I have
>probably close to a dozen in progress simultaneously :-) ).
Hey, once upon a time BBN ported Unix to its own C-70 20-bit computer! A
friend of mine worked on it and was, uh, unhappy with the word size. But
ISDN's worse than Unix, because it has somebody else's product at the other
end of the wire, and you can't easily predict what that product will do.
--
Fred R. Goldstein k1io fgoldstein"at"bbn.com
BBN Corp., Cambridge MA USA +1 617 873 3850
Opinions are mine alone; sharing requires permission.
From: fgoldstein@bbn.|nospam.|com (Fred R. Goldstein)
Newsgroups: comp.dcom.isdn
Subject: Re: Which hardware (most popular) for new ISP?
Date: 25 Jun 1997 14:22:35 GMT
In article <01bc815a$5aeaac60$43b53a86@zeus>,
Peter.Stalmans@med.kuleuven.ac.be says...
>True, European and USA ISDN standards differ, and cannot be exchanged.
>BUT: most ISDN adapter manufacturers sell their product with USA standards
>to vendors in the USA and with European standards in Europe. For example: I
>use an AVM-A1 controller (high performance/price ratio) that exists in both
>variants.
Hahahahah.
I guess you didn't read my post.
AVM is a Euro vendor. It does not exist in the USA marketplace. It's
possible that they claim a USA variant, but it has no market presence to
speak of, and probably misses one or more critical items on the checklist.
USA ISDN, unlike the Euro version, is NOT documented in writing.
USA ISDN vendor understand this.
--
Fred R. Goldstein k1io fgoldstein"at"bbn.com
BBN Corp., Cambridge MA USA +1 617 873 3850
Opinions are mine alone; sharing requires permission.
From: fgoldstein@bbn.|nospam.|com (Fred R. Goldstein)
Newsgroups: comp.dcom.isdn
Subject: Re: Which hardware (most popular) for new ISP?
Date: 25 Jun 1997 19:43:23 GMT
In article <pk9en9qppeu.fsf@btm0qt.se.bel.alcatel.be>,
grayc@se.bel.alcatel.be says...
>In article <5or9jb$ohv$3@daily.bbnplanet.com> fgoldstein@bbn.|nospam.|com
>(Fred R. Goldstein) writes:
>
> USA ISDN, unlike the Euro version, is NOT documented in writing.
> USA ISDN vendor understand this.
>
>But how can you live like this?
Is that a facetious remark or do you mean it?
The USA takes the notion of "free market" a bit far at times, to be sure, but
we do get by. ISDN doesn't fail because of the lack of standards -- there's
no shortage of hardware vendors with products that work just fine, it's just
that we still have local telephone monopolies who don't like ISDN.
ISDN vendors here take the time to learn the "folklore", which is where ISDN
is described. They start with the different manufacturers' documents
(Lucent, Nortel) and the Bellcore and ITU specs, and then take notes on what
fails. A lot of the work is actually handled by third parties; Telenetworks,
for instance, sells its stacks to vendors who only make minor changes and
"glue" it into their hardware. But the real key is to listen to customers,
and make changes based on what's observed in the field. Claiming to work to
a spec gets you noplace! If the TE meets a spec and the network doesn't, the
telephone company will laugh at anyone who tells *them* to fix it, and the
switch vendor will laugh harder since they and not the phone company define
how the switch works.
In Europe, each PTT traditionally has a monopsony on switch procurement, so a
vendor must meet the spec to sell in that country. In the US, there are many
local phone companies and only two big switch vendors, so if the telco
doesn't like it, the switch vendor will still sell it to others, so the
telco pays their money and takes their chances. Different balance of
power....
--
Fred R. Goldstein k1io fgoldstein"at"bbn.com
BBN Corp., Cambridge MA USA +1 617 873 3850
Opinions are mine alone; sharing requires permission.
Index
Home
About