Ken Hornstein writes:
|> 
|> But assuming you're crazy enough to go the next step ... you'll find
|> that getting documentation on US ISDN standards is quite an adventure,
|> because there doesn't seem to be any standards at all.  Most
|> software/firmware seems to be written to work with a few ISDN switches
|> which are fairly common, but finding out what protocol these switches
|> use seems to be very difficult (you need detailed technical documents
|> from the switch vendors, and those seem to be very difficult to get).
|> Our friends in Europe have it much easier, since European ISDN _is_
|> standardized (and that's why I've only found free ISDN packages
|> for Euro ISDN).

I agree.

I used to work on an ISDN videoconferencing system.  I also used to
maintain the comp.dcom.isdn faq, BTW.  But in any case, there are
really two major switch families in the US to worry about, the AT&T ESS
family and the Nortel DMS family.  To support these correctly, you'd
have to buy stacks of specs (which are orderable but not cheap) and
implement the variations of each implementation.  The international
specs are merely a framework, and tend to be the superset of all the
behaviors of an ISDN implementation.  Sad part is the implementations
aren't generous at all - if you send a message that is in the
international spec but not in the vendor spec, the switch will hang up
instead of ignoring the unnecessary message.  Basically, Craig
Partridge had it right when he said that ISDN (and ATM) were invented
by people with bell shaped heads.

Bottom line, to make this work one would have to buy lots of proprietary
specs, and buy something known as an ISDN switch simulator so you don't
crash your local telco switch by sending it confusing messages and hack
away at it.  Then, I actually don't know what legal issues one would face
in deploying it.  I know the companies I worked with used certification
labs to ensure the code worked before they deployed it.  I don't know if
this was a legal requirement, or if they were doing it so they wouldn't
get their butts sued by the local telco when the crashed a 5ESS by sending
it bogus stuff.  Yes, I realize a telco switch shouldn't crash when you
send it bogus stuff, but this is the US, and lawyers gotta eat too...

Another barrier is the specs themselves - they are about as interesting
as reading the ingredients off a soup can...

-- 
Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development
Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN
Email: cherkus@UniMaster.COM  When the music's over, turn out the lights!