And another one: CONNECT_B3 collision

[Tilman Schmidt]

How should the situation be handled where both the application and driver
send CONNECT_B3_REQ / _IND before they see (and reply to) the other side's
CONNECT_B3 message? Specifically with a B3 protocol which doesn't support
multiple B3 connections over one physical connection (eg. "B3 transparent")?

I have a CAPI driver which sends CONNECT_B3_IND immediately after
CONNECT_ACTIVE_IND on transparent connections, no matter if incoming or
outgoing, and replies to subsequent CONNECT_B3_REQ messages from the
application with Info=0x2004 (No NCCI available) because the single possible
NCCI is already active.
I have also a CAPI app which on outgoing connections sends CONNECT_B3_REQ
immediately after receiving CONNECT_ACTIVE_IND, and dies horribly if that's
rejected with Info=0x2004.
So between the two of them, every attempt at an outgoing connection ends in
a crash.
Who's wrong?

TIA
T.

[Jochen Klein]

IMO this is nearly clear and quit obvious when looking ar CAPI 2.0
4.Edition Anex A.1.1. (Outfoing Call Callflow).

Well who is wrong, both ofcourse. The driver shouldnt change teh direction
of NCCI establishment by its slefe and the application schoudl never ever
crash just because it receives normal. correct CAPI messages indicating some
kind of an NCCI error condition.

Regards, Jochen Klein
www.servonic.de

Post by Tilman Schmidt
How should the situation be handled where both the application and driver
send CONNECT_B3_REQ / _IND before they see (and reply to) the other side's
CONNECT_B3 message? Specifically with a B3 protocol which doesn't support
multiple B3 connections over one physical connection (eg. "B3
transparent")?
I have a CAPI driver which sends CONNECT_B3_IND immediately after
CONNECT_ACTIVE_IND on transparent connections, no matter if incoming or
outgoing, and replies to subsequent CONNECT_B3_REQ messages from the
application with Info=0x2004 (No NCCI available) because the single possible
NCCI is already active.
I have also a CAPI app which on outgoing connections sends CONNECT_B3_REQ
immediately after receiving CONNECT_ACTIVE_IND, and dies horribly if that's
rejected with Info=0x2004.
So between the two of them, every attempt at an outgoing connection ends in
a crash.
Who's wrong?
TIA
T.

[Tilman Schmidt]

Post by Jochen Klein
IMO this is nearly clear and quit obvious when looking ar CAPI 2.0
4.Edition Anex A.1.1. (Outfoing Call Callflow).

Annex A is marked "(Informative)" (as opposed to "normative") and titled
"Sample Flow Chart Diagrams". It can hardly be taken to mean no other
sequences of events may happen.

Post by Jochen Klein
Well who is wrong, both ofcourse. The driver shouldnt change teh direction
of NCCI establishment by its slefe

I don't understand that. Where is the direction of NCCI establishment
changed? It's only started by CONNECT_B3_IND. Does anything in the CAPI
standard indicate that only the party that originally set up a physical
connection may set up logical connections over it?

Post by Jochen Klein
and the application schoudl never ever
crash just because it receives normal. correct CAPI messages indicating some
kind of an NCCI error condition.

But *is* it normal and correct for the driver to indicate "No NCCI
available" in the case of a CONNECT_B3 collision - in particular for
"B3 transparent" where setting up a logical connection is just a
formality that has no reason to fail? Should the driver perhaps
rather reply with "Success", indicating the same NCCI in the
CONNECT_B3_CONF it already sent in the CONNECT_B3_IND? Or will that
confuse your typical garden variety CAPI app even more?

Thanks,
Tilman

Post by Jochen Klein

Post by Tilman Schmidt
How should the situation be handled where both the application and driver
send CONNECT_B3_REQ / _IND before they see (and reply to) the other side's
CONNECT_B3 message? Specifically with a B3 protocol which doesn't support
multiple B3 connections over one physical connection (eg. "B3
transparent")?
I have a CAPI driver which sends CONNECT_B3_IND immediately after
CONNECT_ACTIVE_IND on transparent connections, no matter if incoming or
outgoing, and replies to subsequent CONNECT_B3_REQ messages from the
application with Info=0x2004 (No NCCI available) because the single possible
NCCI is already active.
I have also a CAPI app which on outgoing connections sends CONNECT_B3_REQ
immediately after receiving CONNECT_ACTIVE_IND, and dies horribly if that's
rejected with Info=0x2004.
So between the two of them, every attempt at an outgoing connection ends in
a crash.
Who's wrong?
TIA
T.