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)
* 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
Apparently the BS-11 sends soem undocumented cause 0x18 as part of a CONN FAIL IND message
shortly after we establish the call. If we close the channel, the voice call
is aborted. If we ignore the message, everything just continues to work.
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...