| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix two bugs in OML software download code where we allocate data structures
using talloc, but free() them using the system memory allocator. Spotted by
dexter.
|
|
Each BTS gets its own E1 line data structure. They are meant to bind
each to their own (virtual?) mISDN device.
BTS0 uses TS01 (siganlling) and TS02/03 (TRX0), TS04/05(TRX1)
BTS1 uses TS11 (siganlling) and TS12/13 (TRX0), TS14/15(TRX1)
BTS2 uses TS21 (siganlling) and TS22/23 (TRX0), TS24/25(TRX1)
|
|
In order to use multiple mISDN cards, we need to:
1) move driver initialization out of line initialization
2) make sure we allow partial (virtual) E1 cards with < 30 B-channels
|
|
|
|
|
|
|
|
also fix a minor error when printing BTS/TRX number
|
|
For now, we assume that TRX1 (and higher) all have a TCH/F configuration
on all of their timeslots
|
|
* remove old HAVE_TRX1 definition, replace it with '-1' commandline argument
* make sure we actually configure the OML TRX attributes with a different
ARFCN than TRX0
* make sure we configure timeslot 0 of TRX1 also in TCH/F mode
This code is untested, but if you have a dual-trx BS-11, and the second TRX
is activated, you should be able to run bsc_hack with the -1 option to enable
and use the second trx. It works like this:
* TRX1 shares E1 timeslot 0 for signalling
* TRX1 RSL link uses TEI2 (TRX0 uses 1)
* TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124
|
|
* we only need one piece of code to calculate rsl_ie_chan_mode from
our run-time data structures (gsm_lchan)
* add some more channel modes for TCH/H and data
* use enum's to make the compiler warn us about unhandled enum values
* make sure the caller determines the (signalling,speech,data) mode
|
|
also make sure we always print the speech_mode on IPAC_BIND
and IPAC_CONNECT.
|
|
only after the LCHAN_MODIFY we know the final mode of the channel,
so we have to postpone our IPAC_BIND until then to make sure we set
the correct speech codec.
|
|
|
|
|
|
This was spotted by zecke, thanks.
|
|
|
|
|
|
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
|
|
* explicitly set the "ip speech mode" IE during BIND and CONNECT messages,
depending on the speech codec used by the voice call
* more verbose debug messages regarding IPAC_BIND and IPAC_CONNECT
* do not always blindly specify RTP payload type, but use the value
returned by BIND_ACK, _if_ it is present.
|
|
|
|
|
|
|
|
|
|
This is much more optimal than checking if the context exists every
time we allocate the respective object.
|
|
The rtp_proxy.[ch] code is intended to be used as a transparent
RTP/RTCP proxy, relaying the media streams from one ip.access BTS
to another. In an 'ideal' network, this is obviously not needed,
since the BTS's can send those streams directly between each other.
However, for debugging, 'lawful interception', transcoding or interfacing
a TRAU/E1 based BTS, we actually need to process those RTP streams
ourselves.
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
As per specification, we first send the RR CHANNEL RELEASE to the MS,
and then tell the BTS to disable the SACCH on that channel.
|
|
|
|
|
|
Fix the FIXME and replace the hardcoded site_id's of the
nanoBTS with a command line option. You can use -i DEVICE_X
for every BTS you want to handle.
|
|
|
|
|
|
to reflect that we now know their true names/meanings
|
|
|
|
we also rename some existing attributes to reflect reality
|
|
It appears to be the table of TS 05.02.
|
|
Currently we send the attribute changes in a send and forget
fashion. But sometimes the nanoBTS is sending us a NACK, e.g
with a invalid unit id. Start handling the NACK and provide
an error message to the user. The error message is not yet
describing the cause of the error but this is a slight progress
to the previous silent failure.
|
|
|
|
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.
|
|
As Dieter has pointed out, we currently send incorrect information
in the rest octets, particularly about our GPRS capability. Since
the format of the rest octets is highly complex, and we don't
actually need any of those features yet, we might just fill them
with padding.
|
|
Just a beginning...
|
