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
Set the threshold to 0% for the load indication. The paging buffer
space will be used by the paging notifications and we will ignore
the racch usage notification for now.
Start with a large number of available slots. It is guranteed
that we will - at some point - get a paging load and will properly
update the counter and keep it updated.
- The paging block calculation is wrong but I have a hard time finding
the right information. The table of 05.02 (Table 5 of 9) looks good
but my phone is not happy with that group...
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.
On channel allocation the bsc_hack added a cookie to the lchan on
ack and nack we will take a look and then assume it is the channel
we have allocated. This can be easily exploited by a MS sending fake
responses to paging commands. After the channel has been acked we would
have to ask for the tmsi or find the information on the channel
allocation. For now we will guess.
Currently it is not possible to know for which tmsi the channel
is going to be allocated. The bsc_hack will guess.. in the future
it might be forced to ask for the tmsi after the channel has been
opened...
* initialize OML and RSL based on TEI establish (ACTIVATE_IND) events
* fix abis_nm_raw_msg() to not overwrite the OML header with payload
* fix debug print statements
* fix msgb_dequeue: actually dequeue it from the list ;)