This patch will fix subscriber usage countinig.
It may happen, that the subscriber count will not be 0 after releasing
of a call. (This problem is solved with the application patch (27),
which will replace static call transaction by a dynamic transaction
list, and use subscriber for each transaction created.)
A new function trau_recv_lchan() is used to link a channel to a call reference
of a transaction. (Transactions are used in later patches.) TRAU frames will
then be forwarded to the application with the given call reference (in later
patches). Also the application can send TRAU frames by using trau_send_lchan().
A new list is introduced in trau_mux.c. (upqueue_entry) All subslots
that must be sent to application are listed here.
Received TRAU frames are written in the upqueue of application
interface, if a call reference is found in the upqueue-list. If an entry
is found the ss_entry list, the TRAU frames are bridged as before. The
frames have a message type (msg_type), a call reference (callref) and a
trau frame (data). The length of trau frame is defined by the content of
the c-bits inside the frame.
There is no support for ip.access yet, as they don't use the traditional
TRAU frame format. Harald must add this in order to use application interface
with ip-access. The bridging with ip-access works as before.
(Andreas Eversberg)
no IE type included in the message. These information elements are
mandatory, so their actual IE type is known. The improved parse_tlv()
function allows to parse zero, one, or two length-value elements.
(Andreas Eversberg)
We directly assign the call->state and then check for something
that will never be true, and then immediately put the lchan and
schedule it's disconnect... and then directly after having closed
it down we send a message...
Change this to uncondtionally put down the lchan after having
changed the last(?) command.
* initialize some data structures before using them in RSL
* DATA_REQ is a transparent message
* more elaborate DEBUGP statements here and there
* don't call 04.08 with zero-length RSL DATA INDICATION
* reject 04.08 CC HOLD and RETRIEVE, as we don't support them yet
* correctly lchan_put the second lchan of a call at teardown
* map the RTP streams of ip.access onto each other
* fix bug that prevented a CONNECt message to ever reach the 'B' side
* initiate phone calls from one MS
* look-up the subscriber based on dialled extension
* page the called subscriber
* send the SETUP to the called subscriber, including CLIP/CLIR
* get ALERTING notification back to caller
* relay DISCONNECT from either side to the other
This is still far from being complete, but it at least works for the most common case
with the signals, but I think paging always has one reason and thus one caller wants to
get notified about completion, including a caller-specific context, etc)
* introduce TLV parser definitions for GSM 04.08
* parse and generate BCD number IE's for 04.08 call control
* introduce new notion of subsystem in addition to signal number
* no need for bitmasks of 'areas' (aka subsystems)
* pass subsystem/signal_nr/... per argument rather than by data structure
Assign the GSM subscriber to the lchan and then inform
the paging layer and dispatch a signal. This makes sure
that lchan is updated with the right kind of information.
After auto releasing a channel the next paging request will
not be immediately answered. The hypothesis was that we do
not release the channel properly. Implementing Channel Release
of GSM 04.08 should have fixed it, but it didn't. According
to the wireshark dissectors the message is correct though.
- Add the RR cause values to gsm_04_08.
- Implement the Channel Release message
- Invoke the release channel function before deallocating
the lchan.
The TMSI encoding is up to us but generate_mid_from_tmsi and mi_to_string
did not agree on the encoding. Adjust mi_to_string to properly decode the
TMSI generated by generate_mid_from_tmsi. Check that the four bits are '1111'
and that the length is five. Memcpy the bytes to tmsi (to work with ARM or such)
and convert the number to host order...
Implement the CM Service Request. Try to get the subscriber from the TMSI and
assign it to the gsm_lchan. There is a small issue that will be fixed in the
next commit.
(done by z.)
Be able to send Accept/Reject the Service Request. Use mi_string
instead of the the msgb buffer (even if it is memsetted and such)...
The TMSI allocation seems to be a bit problematic and needs some
further checking. The rough idea is that we try to find the subscriber
for a CM Service Request and then decide based on the subscriber
if we want to handle the call.
Increase when the refcount of the lchan when we initiate a call,
get a SETUP message and put it when we want to release the call...
Once we have proper Q.931 support the use/put needs to be improved,
e.g. we currently do not allow to hangup from the network, and it
will ring until the end of time...
It looks like that certain phones that send their old TMSI from
a different network and we assign them a new one with LOCATION
UPDATING ACCEPT will send us a TMSI Reallocation Complete. Print out
the the imsi.
Remove the callbacks from gsm_network for now. A set of different
callbacks will be back. E.g. when the paging is completed, when the
Q.931 like call handling is there...
Remove var's or move them into #if 0, remove unused stuff that looks
like we do not need it anytime soon or #if 0 them, move stuff around.
Call use_lchan early in allocate_loc_updating_req, do not directly call
rsl_chan_release but go through channel alloc to take the use_count into
account.
As reported by the operator the rejecting didn't work after the
first fix (wrong logic/missing negation). The hypothesis is that
that the lchan was released before the reject timeout was fired.
Fix it by getting a reference on the lchan when allocating a
logical operation and release the reference when the operation
is finished or timed out.
Harald Welte
Holger Freyther