| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The new structure divides the code into a number of libraries
for the BSC core functionality, MSC core functionality, Abis transport,
TRAU and other bits.
This doesn't introduce any functional code change but simply moves
around files and alters Makefile.am accordingly.
Next step would be to disentangle a lot of the inter-library
dependencies and make the individual bits of code more independent.
|
|
|
|
Move the SMS from text code from the VTY interface into the
gsm_04_11.c code next to the sms_alloc and sms_free.
|
|
|
|
The conn might be released during the loop and then conn->bts
is a null pointer and we end up crashing. Store the gsm_network
in a local variable and access this one.
|
|
The active channel might or might not be gone when the transaction
has been released. Instead of passing an invalid subscriber conn
we will pass the subscr that is ref-counted and guranteed to be
valid at this point. subscr_put_channel could search the connections
for an active connection if that is ever needed.
|
|
The reason for this is quite simple: We want to make sure anyone
running a customized version of OpenBSC to operate a network will
have to release all custom modifiations to the source code.
|
|
The SMSqueue will be responsible of sending to the user. It will
do so in a loop and will also try not to overload the BTS. This
means the throughput of SMS will be limited.
|
|
This is providing access to the paging result, the sms,
the transaction. This will allow the SMS queue to do
decisions based on the source of the failure.
|
|
This attempts to dispatch a signal whenever a MT-sms is failing. In
some cases, e.g. with freeing the transaction, this will also happen
for MO-sms.
|
|
The signal_data was inconsistent. Sometimes we passed the transaction
and sometimes we passed the sms. Change it to always pass the sms. The
S_SMS_SMMA is a bit special as it does not involve any SMS.
|
|
|
|
Start counting the attempts of each paging request and call
the callback with the PAGING_BUSY type when the paging request
timed out but the subscriber was not paged at all. This can
only happen with a huge paging backlog.
In case the system has so many pending paging
|
|
For SAPI=3 on a TCH it might be nice to use the SACH to submit
the message. The api allows to automatically use the SACH if
a message like this is submitted.
|
|
Try to get the company name of our sponsor right...
|
|
gsm411_send_sms
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
|
|
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
|
|
A channel will be released in case of
* Errors via the clear_request callback...
* no more transactions and operations are going on.
This means that if we do something without a transaction
the channel might be closed down right away. The bug fix
will be to create a transaction/operation.
|
|
gmtime(NULL) returns NULL at least in glibc and *can not* be used as
time(NULL). Since we compare two time_t values when checking the validity
period this can be replaced by time(NULL)
|
|
|
|
The next step in the way to the BSC API. We have a clear a
new connection was opened signal now... and the MSC could
use it...
|
|
Do not use the lchan for the paging but operate on the
subscriber_connection, change the signals too to not carry
the lchan but the subscriber connection... the silent call
and vty code still assume there is a lchan inside the
subscriber connection.
|
|
|
|
|
|
|
|
|
|
With handover and late/early assignment there might be two channels
for one subscriber and only the BSC knows which one to use, so use
the gsm_subscriber_connection everywhere...
|
|
If there is a connection, return before paging... otherwise
we will delete the SMS twice.
|
|
|
|
|
|
Directly send a SMS using the send method, in case of an error
we will need to find the transaction and free the SMS and the
transaction.
|
|
Sometimes we need to free the SMS, sometimes also the transaction.
|
|
|
|
The paging message should not be called directly and the GSM Subscriber
can handle multiple requests at the same time... Now a subscr_put_channel
should be called after the message sending. But it is not very clear when
this can be called. The current code works by luck that the SAPI=0 will
be released...
The MT-SMS was tested via the VTY interface and a N900.
|
|
|
|
|
|
As we don't support compressed SMS, we have to properly reject it.
In the existing code, we segfaulted at some later point since the error
handling was incomplete.
This was triggered by some obscure STK SIM card that insisted on sending a
compressed SMS after registering to the OpenBSC network.
|
|
Do not use RSL to release the SAPI/Channel from within the code,
the normal channel release procedure will take care of releasing
the SAPIs and there should be no issue in keeping the SAPI=3
established until the end of the session.
|
|
|
|
|
|
|
|
|
|
Remove further usage of lchan from the gsm 04.11 bits
|
|
The 08.08 API will interface with the internal BSC code and it is
the boundary between MSC and BSC. So nothing that calls the BSC
functionality should know about lchan or such.
|
|
|
|
Change the MSC transaction code to operate on a GSM Subscriber Connection
instead of the lchan. This will help us to separate the two commands properly.
|
|
Prepare to split the BSC and the MSC part by putting the
MSC data for a connection into a "gsm_subscriber_connection"
struct and renaming the macros.
|
|
|
|
This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
|
|
See GSM 04.11 Chapter 5.4 for details. The idea is that when
multi-SMS are mobile originated, it's possible the CP-ACK of
the previous transaction to be lost and the reception of a
new CP-DATA for a new transaction should close previous transaction
"as-if" we had received the CP-ACK ...
Note that testing is hard since it's an exceptional condition that's
hard to create. I tested by temporarly disabling CP-ACK processing
and checked it worked as expected.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
