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.
We are going to have logical operations like Phone Call, SMS,
Paging, Updating Request on a logical channel and for each of
these operations we might need to store state. For now pointers
in gsm_lchan look like the best way of doing this and we start
by introducing an operation for the location updating request.
The new flow of things are:
- We get the location updating request and update/create
the subscriber and maybe send the identity requests to
the mobile station
- We start the updating timer, if it times out we will
reject the mobile station.
- Once we get the Identity Responses we have asked for
and the reject timer did not fire yet we might accept
the user.
When a channel is allocated, start a timeout, when a lchan_use
is used the timer will be restarted, when the timeout fires
we will try to recycle or restart the timer.
I removed gsm48_sendmsg(msg) when removing the send_sms from the
_acc method. This is obviously wrong. Fix the regression, spotted
while testing with LaF0rge. This regression was introduced in r120.
gsm_data.h add new callbacks, add some parameters, update bsc_hack and
other call sites.
Remember that we need to ACCEPT/REJECT the LOCATION UPDATE REQUEST and
then send the ACCEPT or schedule the sending of the reject. Currently
it is possible that for a new subscriber that we do not have a !subscbr
yet, we will trigger an IDENTITY REQUEST and schedule the reject timer.
This may lead to rejecting AND accepting (a new subscriber). This issue
is triggered when allowing everyone to connect to the network.
Holger Freyther
Harald Welte