I don't have an ISDX switch, but I think I know ISDN. There are two issues
involved: one is what the ISDN standard (Q.931) says, the other is "what can
I do _now_, given that someone is violating the standard?"
First, the standard: Livingston/Lucent is functioning properly (I can't find
my copy of the Q.931 spec right now, but I did dig up my old AT&T TR 41449
"AT&T INTEGRATED SERVICES DIGITAL NETWORK (ISDN) PRIMARY RATE INTERFACE
SPECIFICATION" (dated July 1989) - this is _very_ close to the Q.931 standard,
as AT&T is usually a stickler for standards, so I don't think anyone will
contradict this unless they are quoting from the actual Q.931 standard and it
says something radically different (which is unlikely). :)
I am answering this question because I had to spend a few minutes convincing
AT&T's 4ESS compatibility testers that the device I helped build was doing the
right thing when their test script rejected the same SETUP / CONNect sequence.
(These phone guys sometimes forget that there are applications where nobody
has to hear a phone ring to answer a call.)
The second part is not as easy to answer. If the manufacturer (ISDX/Seimens)
is actively maintaining the switch software, they may accept that they made
a mistake and fix it. (But _when_?) I hope that is the case, because I don't
like the alternatives. One thought I had was to put another switch between
the ISDX and the PM3 - with the idea that a "SETUP / CALL PROCEEDING / CONN"
sequence _might_ work; this is not assured, and it would cost money to try,
so I don't like it a lot. The other thought was to pay Livingston/Lucent to
create a "special build" for you - if they are willing to do that sort of
thing and you can afford it. I don't like this one because it might cost a
lot of money and I dislike the idea of changing something that works properly
to accomodate something that doesn't work properly - the way to progress is to
fix the busted stuff, not to bust the good stuff so mediocre stuff works with
it.
To quote from my copy of the specs:
-------
5.2.5 Call Confirmation
5.2.5.1 Response to En-Bloc SETUP
When the user determines that sufficient call setup information has
been received and compatibility requirements (see Annex B/Q.931) have
been satisfied, the user responds with either a CALL PROCEEDING,
ALERTING, or CONNECT message and enters the Incoming Call Proceeding,
Call Received, or Connect Request state, respectively.
-------
also...
-------
5.2.7 Call Accept
A user indicates acceptance of an incoming call by sending a CONNECT
message to the network. Upon sending the CONNECT message, the user
shall start timer T313 (the value of timer T313 is specified in
Section 9.2).
If a call can be accepted using the B-channel indicated in the SETUP
message, and no user alerting is required, a CONNECT message may be
sent without a previous ALERTING message.
-------
Good luck,
David Acquistapace david@ap.net
AccessPort 1(707)522-5100
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>