Here exist two differnt content versions of octet 5b in bearer capabilities
but only alternatively depending on the L1 protocol, so we only need one octet 5b here.
If using a tty for sending/receiving B3 data, the mc buffer for data sent is
not freed by ncciDataConf() because this is done only by AnswerDataB3Req()
which is not called when using a tty. Fix this by explicitly freeing the mc
buffer when a tty is used.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Until now, B3ReleaseLink() did not care about BType_tty B3 links. This commit
makes them behave like BType_Direct links.
Signed-off-by: Christoph Schulz <develop@kristov.de>
In hijacking mode (CAPIFLAG_HIGHJACKING), a PTY master/slave pair is created to
pass data back and forth between the application and mISDNcapid. However, there
is a small time window between creating the PTY slave and the application
opening the PTY slave. If a B3 data connection is established before the
application has opened the PTY slave, and B3 data is received and written to the
PTY master end, it is immediately read back by the B3 data receiver thread
(BCthread), which then sends the data back to the original sender, causing a
loopback. This e.g. happens when the application is the PPP daemon pppd which
has been configured to not send any data until it receives a valid LCP packet
("silent" option).
In order to fix this, an additional flag called tty_received remembers whether
the B3 data receiver thread has already read data from the PTY at least once.
Only if this is the case B3 data is written to the PTY master end, otherwise it
is discarded as there is no potential receiver at the PTY slave end yet. This
effectively avoids any loopback situations due to an unconnected PTY slave end.
Signed-off-by: Christoph Schulz <develop@kristov.de>
The function lPLCIDisconnectInd() is called by plci_cc_disconnect_ind() when a
EV_L3_DISCONNECT_IND event is being handled. If the B3 link has already gone,
lPLCIDisconnectInd() returns -ENODEV, which prevents plci_cc_disconnect_ind()
from calling lPLCILinkDown() and therefore from cleaning up properly. This
commit makes lPLCIDisconnectInd() returns zero (i.e. success) in such a
situation.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Always sends PH_ACTIVATE_REQ and not DL_ESTABLISH_REQ down the mISDN stack when
opening a B-channel, as DL_ESTABLISH_REQ is only understood by layer-2, and
B-channel management is done at layer-1.
Signed-off-by: Christoph Schulz <develop@kristov.de>
If early B3 is enabled we are currently opening channel B on appropriate
"Progress" IE.
If it turns out that this IE arrives in the same message that also sets
which B channel should be used the current code will fail to open
the B channel for early B3 as the current order is to first handle the IEs
then parse channel id.
Change this to first parse the B channel id then handle the IEs so in such
situation the B channel id will already be set at "Progress" IE handling
time.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Early B3 support is an useful functionality not only to listen to actual
exchange ringback tone but also to hear announcements like number changed,
line not provisioned, etc.
This commit adds partial early B3 support: mISDNcapid will try to open
B channel on "Call is not end-to-end ISDN; further call progress
information may be available in-band" and "In-band information or an
appropriate pattern is now available" progress indications, so CAPI
application will be able to connect to this B channel with CONNECT_B3_REQ
message.
Doing it this way needs only minimal changes to existing code - we just
need to make sure that B channel opening function ( lPLCILinkUp() )
doesn't try do it again when it is called for the second time.
Full early B3 support would need further decoupling NCCI management
from PLCI management so B channel could be opened on demand when CAPI
application issues CONNECT_B3_REQ.
While we are at it also make sure that lPLCILinkUp() function also
cleans up what it has already done when it exits early with an error.
Since this functionality is experimental it is not enabled by default -
a define needs to be uncommented at top of capi20/lplci.c to enable it.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
According to Q.931 (05/98) some of variable length information elements
may occur more than once in a message.
parseQ931() from mISDN layer3 library would store such second and next
occurrence of particular IE in an "extra" array of l3 struct.
This commit adds support for sending these repeated IEs to mISDNcapid
INFO_IND IE posting function ( lPLCIInfoIndIE() ) so they will be
available to CAPI applications.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
lPLCIInfoIndIE() in lplci.c returned early when mc->l3m was set and
continued execution when it was NULL, however from code further in this
function it is clear that opposite behavior was meant.
This caused CAPI applications to not receive INFO_IND with information
elements, as this function was no-op when called correctly.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
When CAPI application asks for B3 disconnection the NCCI state machine
sends disconnect request further down the stack and then goes into N_4
state waiting for disconnection confirmation.
If B channel was in direct layer 1 mode the disconnect request will be
sent as PH_DEACTIVATE_REQ which will go all the way down to an individual
mISDN chip driver.
It looks like all current chip drivers reply to such requests by sending
only PH_DEACTIVATE_IND message, however the state machine in N_4 state
only reacts to PH_DEACTIVATE_CNF message (translated into
EV_DL_RELEASE_CONF).
This means that such call will get stuck until remote side disconnects it.
Fix this by reacting to PH_DEACTIVATE_IND message also in N_4 state,
just like it is done in N_ACT state.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
CAPI specs say that CONNECT_B3_RESP message uses Reject parameter for
deciding what happens to incoming connection, however mISDNcapid code
used Info instead.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
According to Q.931 (05/98) on user-originated calls that did not select
a particular B channel in a SETUP message the selected B channel is sent
in a first message returned by the network in a response to
the SETUP message.
This Recommendation explicitly mentions SETUP ACKNOWLEDGE or
CALL PROCEEDING as examples of such response messages, however mISDNcapid
code ignored channel indication in CALL PROCEEDING messages.
This resulted in a no channel selected error on outgoing calls
on exchanges that reply with CALL PROCEEDING to SETUP.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Under some conditions it could be happen that on a freeing capi object
a other thread still get a reference and then it use the already freed object.
To avoid this, we do 2 things, we only take a refernce if get_obj() succeed, it
do not longer succeed if the object is already cleaned. We also force scheduling
after releaseing the lock before really freeing the object - so the waiting thread
will not get a new reference.
CAPI 2.0 spec defines the CIP value indicated by CONNECT_IND
als highest matched bit position, not the higest CIP value
calculated from bearer + HLC info.
This bug caused that if a application did not request listening
for some of the higher bit values a not requested CIP was sent, so the
call was ignored.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Implement a method to disable temporary messages from applications to
synchronize the delivery of a incoming call. It is important, that
all listening application get informed before the first answer was handled.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
if a call was not taken by an application and multiple applications
are listening, it could happen that the PLCI was deleted before we
did sent the CONNECT_IND to all applications.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
- Add a timeout in the B-channel handler to catch a broken
downlinks on release
- Do not join the own thread
- pthread functions return error directly, not via errno
- better debug messages
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
Not only the bit of the cip value has to be set, also
the more generic bearer service bit (not depending on HLC)
need to be set.
Without the fix valid calls got ignored.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
Many users difd report problems to compile this package because
they had installed different versions of the autotools.
From now it is not longer possible to compile this package without
having autotools installed.
You can generate the the autotool files simply with running 'make'.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
If a CAPI message was bigger as it was indicated, the buffer
length was not set at all. Now use the indicated length.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
The capi thread or the B-channel worker thread can create the faxcontext. We need a lock
to protect the operation, sometimes we did create 2 NCCIs.
Signed-off-by: Karsten Keil <kkeil@linux-pingi.de>
Karsten Keil