Age | Commit message (Collapse) | Author | Files | Lines |
|
* Send Modify requests during release
* Send multiple SACCH deactivates
* Optionally do not send IMM.ASSIGNMENT during channel granting
to force the phone to send multiple RACH bursts..
* abort() when a channel goes broken
|
|
GSM 08.58 is not clear if the SACCH Deactivate is an idempotent operation,
it has exposed a bug in my osmo-bts channel release re-work with the queue
and I assume the nanoBTS will not deal with it any better.
In my tests it was possible to get a N200+1 times error during the channel
release procedure which lead to releasing the SACCH again. When this timeout
occurs it is very difficult to find out if the SACCH was already deactivated.
Re-introduce the usage of the sacch_deact flag in the lchan. When the release
is triggered by higher levels the SACCH should be active and we check for this
with a log message, in case of the error handling we check if the SACCH was
de-activated before de-activating it even if we are requested to do it. This
way we know the SACCH will be de-activated at most once.
|
|
If after release has been sent, the call control layer waits for:
- reception of release complete
- or timeout
- or release of transaction (due to radio link failure)
In this case, an MNCC_REL_CNF is sent to upper layer. The callref must
still exist, so the upper layer can handle this confirm.
|
|
If transaction is destroyed, but callref still exists, the
mncc_release_ind function is called. If the upper layer already sent an
MNCC_REL_REQ, the state N19 was entered. In this case it expects an
MNCC_REL_CNF.
|
|
|
|
... as an empty system-id would render the openbsc.cfg unparseable on
next openbsc start.
|
|
|
|
Work on the 'forward' part.. tell the sms queue that something has been
submitted for it..
Conflicts:
openbsc/src/libmsc/smpp_openbsc.c
|
|
For PCS1900 the SI1 does not contain the ARFCN of the serving cell.
This is because the arfcn2band method will return GSM_BAND_1800 and
not GSM_BAND_1900. The academic fix would be to set the ARFCN_PCS bit
but this would require increasing the bitvector sizes from 1024/8 to
(0x8000 + 1024) / 8. This would increase the storage size for each
bitvector by three.
It is not possible to have DCS1800 and PCS1900 in one network so we
can avoid increasing the memory usage and check if the ARFCN resolved
to 1800 and then check if the BTS is a 1900 BTS and then claim that
this is compatible.
|
|
This makes reading the condition more easy and allows me to fix it
for GSM1900 more easily and I can remove one level of indention.
|
|
The code predates the TLV parser and we were parsing the RLM from the
wrong offset. In general we were using the length of the TLV which
happened to be equal to the T200 indication.
After consulting the RLM cuases not every of them should generate a
BSC_RLLR_IND_ERR_IND as these are forwarded to the MSC as a SAPI reject
right now.
TLV parsing now generates this due a bug in the osmo-bts code:
abis_rsl.c:1605 (bts=0,trx=0,ts=2,ss=0) SAPI=0 <0000> abis_rsl.c:1547 (bts=0,trx=0,ts=2,ss=0) ERROR INDICATION cause=Fraeme not implemented
|
|
Returns opearional, administrational state and RF policy
|
|
|
|
For short IP failures we want the RF to stay up and wait for
the re-connect but in case the A-link is gone too long it is
good to switch off the RF and wait for commands to enable it
again.
|
|
|
|
Merge the code from the On-Waves branch. Use the internal RF control
interface to switch the TRXs on/off. This code has the necessary delays
to not crash the nanoBTS. Introduce signals for re-connection of the
BSC on the A-link.
|
|
Provide an error message that makes it more clear that the command
is rejected because RF handling is not enabled in the BSC.
|
|
|
|
Send the current position when the MSC connection is established.
|
|
Use the delayed scheduling feature of the osmo_bsc_rf class to
avoid crashing the site controller of the nanoBTS.
|
|
|
|
Send the signal whenever a MSC appears to be authenticated.
|
|
The issue can be reproduced by typing the following 9 or more times.
OpenBSC> subscriber id 2 sms sender id 2 send bla
For some unknown reason the phone sends us a CP-ERROR for a transaction
identifier we have allocated and used but don't remember. Due the way
we use the SMC/SMR we 'establish' the machine and this results in a CP-ACK
being sent out. But the CP-ERROR is not having the content we want for
an establish so we send out a RP-ERROR. This will result in a CP-ERROR
because the phone does not know the transaction...
Avoid the issue by checking the direction of the transaction. If we do
not know the transaction and it is supposed to be allocated by us then
just ignore it and do not create a new transaction.
|
|
|
|
Make the macros use the cmd->node instead of the data pointer. The
naming of the variable inside the macro already indicates that it
should use the nodes data structure.
|
|
Like with all type unsafe callbacks we will need to cast from
void to the dtype. This addresses some compiler warnings.
Make it possible to only include the control_cmd.h to use the
macros defined in this file.
|
|
|
|
The SDCCH8 is only allowed on trx 0 if there is no BCCH/SDCCH4 on it.
|
|
Allow to select the AMR multirate config using the VTY.
|
|
Provide VTY options to allow/forbid the usage of a
specific multirate option.
|
|
Handle the mr_config request and set the AMR multirate config for
the given MSC. Initialize the mr_config with the AMR5.9 default we
have been using until now.
|
|
Be able to move a call from one MSC to another MSC based on a regexp
for the phone number and pre-defined dial plan.
|
|
|
|
When we are asked to route calls on a local link and
the link is not available we would crash when trying
to send a packet over a deadline. When we have decided
to move a connection it is guranteed that the current
SCCP connection will vanish, we either migrate to another
MSC or the RSL/subscriber connection will be closed.
|
|
|
|
Inspect the CC Setup messages and if the dialed number is matching
the regexp of the local MSC the connection will be rerouted. The
original MSC will get a GSM0808 CLEAR REQUEST, a new connection with
a CC Setup message will be opened.
|
|
Allow to merge barr certain subscribers with a given error code
|
|
For USSD we remember that it is a supplementary service but this
means we sent no CM Service Reject down to the subscriber. Treat
NAT_CON_TYPE_CM_SERV_REQ and NAT_CON_TYPE_SSA the same and send
a cm service reject.
|
|
|
|
Do the auth check in bsc_nat_filter_sccp_cr, remove the cause from
the signature again. For the bsc_nat_filter_dt restructure the flow
but leave the auth inside the id response message.
Return 1 when the IMSI has been extracted as indicator for running
the auth check. 1 has not been used before and is safe to be used
as this indicator.
|
|
For the new barr feature get the cause struct down to the imsi_auth
code so we can add the blacklist there.
|
|
In preparation for another kind of black-list allow the filter code
to decide how the connection should be rejected. Introduce a new struct
that will carry the reject causes for certain operations.
|
|
Move all routines related to filtering to a separate file.
|
|
|
|
Move the code around to make it more clear what the routines should do.
|
|
For now we need to keep the sacch_deact in OpenBSC as we couldn't get
the new activation/de-activation code working.
This reverts commit 0c282f52684ac033e20ab411ab206e8559d564c9.
|
|
This implements exipiry of subscribers, requires a schema change. A permanent
attachment (time set to 0) is not supported any more and would require some
more work. This code was used at the 29C3.
|
|
|
|
Set the subscriber expiry timeout to twice the duration of the location
update period and provide functions subscr_expire() and
db_subscriber_expire() to mark subscribers offline that have missed two
location update periods.
This patch increases the DB revision to 3, so the hlr will be
incompatible with prior versions.
We should allow 0 for T3212 as well to disable the location update
period. In that case we will need a way to indicate that in the
database.
|
|
libcommon: Default to 30min location update period
libbsc: Limit VTY value for periodic update and disallow the value 0
According to GSM 04.08 Table 10.5.33 "The value 0 is used for infinite
timeout value i.e. periodic updating shall not be used within the cell."
This was the default value until now, but the code that deals with
expiring inactive subscribers in the next commit can't handle that case
so this remains a TODO for now.
|