Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
* add support for parsing measurement results (both BTS and MS side)
|
|
Introduce the internal gsm0408_authorize that will determine
if we allow the user into our network. If allowed a new tmsi
will be allocated, the subscr_update will be called, the loc_operation
released, and the accept sent. Otherwise just return 0.
The code was copied from mm_rx_id_resp.
|
|
If location update is requested, but subscriber is not yet authorised
within mm_rx_loc_upd_req() function, the subscr_update() is not called,
because subscriber information is not complete.
During mm_rx_id_resp() the subscriber informations is may be complete,
so authorize subscriber succeeds and database must be updated.
|
|
Do not allow two location updating requests on the same lchan. Such
an event is certainly spoofed and can confuse the internal logic of
the application. Prevent that.
|
|
The abnormal case is that lchan_free ist getting called due
a RSL_MT_CHAN_REL_ACK in the RSL but the refcount of this
channel is not zero. This means that some "logical operation"
is still going on that needs to be cancelled.
Instead of always queuing up all operations in the
struct gsm_lchan use the signal framework to inform higher
layers about this abnormal case.
In gsm_04_08.c a signal handler is installed and in the
abnormal case the location updating request operation is
freed.
|
|
|
|
subscr_get_by_tmsi might log as well and then the order of
debugging it not as clear as it could be.
|
|
Some debug outputs now correctly use end-of-line characters.
|
|
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)
|
|
|
|
* the return value of bsc_update_timers() is required for applications to find out if a timer was fired
(Andreas Eversberg)
|
|
from phase1 should work now.
|
|
|
|
Introduce subscr_put_channel to release a channel and to
allow gsm_subscriber.c to hand this channel to any suitable
pending requests.
|
|
When sending LOCATION UPDATING REQUEST Accept or when getting
a IMSI Detach update the gsm_bts of the gsm_subscriber.
|
|
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
|
|
|
|
bytes in length)
|
|
|
|
|
|
|
|
|
|
* modify the RSL channel mode (BTS) side) after the 04.08 (MS side) has acked MODIFY
|
|
correct lchan rather than crashing
|
|
* 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
|
|
somewhat of an overlap
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
|
|
some different ideas)
* 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.
|
|
Remove the parameter and move the signal kind into the
signal struct. Make register/deregister fully symmetric.
|
|
Inform people about the successfull paging response and
provide access to the subscriber, lchan and bts...
|
|
* implement function for CHANNEL MODE MODIFY
* don't use hard-coded SETUP message but construct it with tlv functions
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
And unreference the gsm_subscriber object otherwise we would leak.
|
|
implementation
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.
|