There were many places in the code where we had to explicitly
reference the transaction_id and put it into a packet. By introducing
and optional gsm_trans parameter to gsm48_sendmsg(), we can implement
this code once rather than dozens of time.
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
Since a transaction is associated to a gsm_subscriber, and the subsciber
is part of a network, we don't need to have a dedicated transaction->network
pointer.
This changeset factors out gsm_transaction as something independent
of call control in preparation to re-use the code from SMS. A
transaction is uniquely identified by either its callref, or by
a tuple of (transaction_id, protocol, subscriber).
since a subscriber is an element of the gsm_network, we have to ensure
subscr->net is always set correctly. We do this by using gsm_network
as an argument to all functions that resolve or create a subscriber.
For further evaluation/analysis, this patch stores the classmark 1, 2 and 3
values of every equipment in the SQL database. We can use this non-volatile
data to determine the supported features for each handset that we've ever
seen on our network.
* when paging callback is called, we need to consider a failed paging
operation (i.e. lchan == NULL)
* we have to zero-initialize every transaction that is allocated
after passing the mncc structure (contained in msgb) to the mncc layer,
we have to release its memory. This leak was discovered as a direct result of
using talloc.
This is Harald's reworked MNCC base, slowly heading towards integration
into master. The key changes are:
* provide much more structure to the data in gsm_mncc
* encode_* and decode_* functions now take a structure rather than tons
of individual arguments (whose order nobody can remember)
* make sure we don't have copies of the same code everywhere by introducing
mncc_set_cause() and mncc_release_ind()
* save horizontal screen space if possible
* make sure we break lines > 80 characters
Reuqests for a subscriber a stored within the gsm_subscriber
datastructure and it will keep track how many channels are
allocated for this user and of which type to decide on policy...
e.g. attempt to submit SMS during a phone call and not doing
paging but a simple (immediate) assignment of the channel...
Andreas Eversberg is suspecting that some of these messages
are not balanced and we are seeing a leak here. The general location
updating request is guarded by the "location updating request" object
inside the lchan that will keep the channel open for at least five
seconds to get all the information we need.
Move the secret of how to find the BTS in a LocationArea into
the paging layer. This allows to implement different strategies
without changing other parts. E.g. we might want to try the BTS
were the device was seen last and then try...
There should be no semantic change and things should continue
to work. It is sadly not tested though.
Search for the MS at BTS in the location area of the
called_subscr. This makes the case work where caller and
receiver are not in the same location area. In fact this
looks like a breach of a BSC/MSC separation, I have no idea
if in true networks a BSC is managing BTS in different location
areas.
this patch implements the encoding/decoding of 04.08 call control information
elements. It adds new functions to be used for the application interface
patch, and is basis for the application patch (currently patch 36).
Please ignore warnings about unused static functions for now.
(Andreas Eversberg)
when paging is successfull, the paging_request_stop() function is called
with the current lchan, so the callback function will be called. for all
other bts', the paging_request_stop() function is called without lchan,
so the paging is stopped, but the callback function is not called.
this ensures that only one paging result is received when paging
multiple BTS. (Andreas Eversberg)