CAPI 2.0 Standard Question: Reject<>0 with multiple listeners

[Tilman Schmidt]

The CAPI 2.0 Standard (4th Edition, June 2001) states, in ch. 5.37 LISTEN_REQ:

"[...] If more than one applica-
tion attempts to accept the call, the first CONNECT_RESP received by COMMON-
ISDN-API is accepted. Every other application receives a DISCONNECT_IND mes-
sage which indicates this situation in the Reason parameter."

It is silent, though, about applications attempting to ignore or reject a
call for which a CONNECT_IND has been sent to other applications, too. For
Reject==1 ("Ignore") it seems logical that the other applications should be
unaffected, but what about Reject>1, ie. the application actively rejecting
the call?

- Should the effect of Reject>1 be global, triggering DISCONNECT_IND for all
other listeners? If so, with what Reason? 0x3304 "The call was given to
another application" appears a bit stretched.

- Or should Reject>1 be treated like Reject==1 ("Ignore") in the presence of
other listeners who haven't responded yet?

- What if several listeners respond with different non-zero Reject values?
Which one should prevail? The last one? The biggest one? The first one
not ignoring the call?

- Put differently, should the call be rejected if at least one application
rejected it, even if other applications ignore it later?

Thanks in advance for any comments,
Tilman

[CHW]

Hi Tilman,


with Reject (which is a connect_resp with a reason unlike 0 and not
IGNORE) you
inform the caller about an error condition (busy, ...). In this case
all other Applications
get a disconnect_ind and the call is lost.

0x3304 is the case when more than one application say accept the call
- the driver
decides which application will get it...

I think the first value which arrives the driver will be used there.
Any other value
then ignore or accept result in a disconnect, so i think the first one
will be used...


kind regards


Christian

[Tilman Schmidt]

Christian,

thanks for your answer.

Post by CHW
with Reject (which is a connect_resp with a reason unlike 0 and not
IGNORE) you
inform the caller about an error condition (busy, ...). In this case
all other Applications
get a disconnect_ind and the call is lost.
0x3304 is the case when more than one application say accept the call
- the driver
decides which application will get it...
I think the first value which arrives the driver will be used there.
Any other value
then ignore or accept result in a disconnect, so i think the first one
will be used...

To make the question clearer: I am writing a CAPI driver and I'm
trying to decide how it should behave.

Imagine a situation where my driver has a couple of applications
registered and listening for the same CIP. It has a call coming in,
and it notifies all of them with CONNECT_IND. Now the CONNECT_RESPs
are starting to arrive.

- The first one is saying: "Ignore" (Reject=1)

- The second one: "Reject call, user busy" (Reject=3)

- The third one, again: "Ignore"

- The fourth one, much later: "Accept" (Reject=0)

Should the fourth one get the call? Or should it have received a
DISCONNECT_IND already, when the second one said: "Reject"?

TIA
T.

[CHW]

Hi Tilmann,


well, since this behaviour is a problem of the Application which uses
your Hardware (?)
my opinion is to signal the Busy condition to the caller (this is the
easiest way). The other
solution is to wait (how long ?) for other connect_resp's...

I think that this would never happen or it would never be a problem
for you, since
nobody uses more than one IVR on the same system...

The next problem occours when you wait for connect_resp's when DDI is
used where all
applications are wait for dialed digits and one app says reject,
busy ...

Maybe investigate more time in AOC (99), Conferencing and
stabillity...
Maybe you can also send me some info for which company are you work,
maybe I
can test something for you (up to 4 E1 is my smallest system in the
moment)...


Kind regards


Christian

[Tilman Schmidt]

Hi Christian,

thanks for your answer.

Post by CHW
well, since this behaviour is a problem of the Application which uses
your Hardware (?)
my opinion is to signal the Busy condition to the caller (this is the
easiest way).

Yes, that's the easy way out. :-)

Post by CHW
The other
solution is to wait (how long ?) for other connect_resp's...

I could just wait until all listening apps have sent their connect_resp.
But of course that would bear the risk that one misbehaved app could
block all others. (Just like Windows 2.x :-)

Post by CHW
I think that this would never happen or it would never be a problem
for you, since
nobody uses more than one IVR on the same system...

It's not just IVRs. But you are right, in the majority of cases there
will only be one app listening.

Post by CHW
The next problem occours when you wait for connect_resp's when DDI is
used where all
applications are wait for dialed digits and one app says reject,
busy ...

Yes. There are definitely some more gaps in the standard.

Post by CHW
Maybe investigate more time in AOC (99), Conferencing and
stabillity...

Sure, there are more important topics. But it's easier to decide on
what to concentrate if at least the specs are clear. Which in this
case they aren't.

Post by CHW
Maybe you can also send me some info for which company are you work,

This is work I do on my own account. The hardware that the driver
controls is originally from Siemens, now Gigaset, but neither
Siemens nor Gigaset pay for my work or support it in any way, as
they are not interested in the Linux market.

Post by CHW
maybe I
can test something for you (up to 4 E1 is my smallest system in the
moment)...

Thanks for the offer, but I'm actually not sure what kind of tests
might help me. Right now I'm trying to determine what the standard
asks for rather than what actual implementations do. If it turns out
that the standard just leaves the question open (as it seems now),
I'd prefer taking advantage of that by doing what is easiest to
implement, like you proposed at the beginning.

Thanks,
Tilman