It is a bit arbitary to decide which one is the global
and which one is the local one. We might change it around.
I don't think we want to introduce it based on BTS.
We need to use different LAC/CI towards the core network.
It is a bit problematic as LAC/CI is a per BTS attribute
so this feature only works if a BSC manages everything in
the same LAC.
Related: SYS#1398
We want to reduce the background traffic and might set the ping
interval to be in the range of minutes. But this means that if
the TCP connection is frozen several "SCCP CR CM Service Requests"
will be stuck in the send queue without ever being answered. I
could have used the logic of not receiving the "SCCP CC" to close
the connection but instead I am introducing an overload to schedule
the ping as part of the normal SCCP connection establishment.
The VTY write case has been manually verified, I have also looked
at a single trace to see that the SCCP CR and the IPA PING is
transfered in the same ethernet frame.
Send an USSD message to the mobile station requesting a connection
for a call or a SMS when the link to the MSC is down or in the
grace period.
The messages can be set (and this feature activated) by setting
bsc/missing-msc-text resp. msc/bsc-grace-text via the vty.
The generation of both messages has been tested manually.
Ticket: OW#957
Send an USSD message on each MS connection if the connection to
the MSC has been lost.
Add a vty config command 'bsc-msc-loss-txt' in 'config-msc' to set
the notification string and to enable the feature.
Ticket: OW#957
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.
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.
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.
We want to have multiple MSCs but we also have some data
that is only present on a per BSC basis. Right now the
MSC data is not allocated with talloc, so we have some
change in the talloc contexts.
Be able to configure a list of destinations (duplicates allowed)
that will be tried in a round robin fashion. The change is in
the bsc_msc_connection to operate on a list. We achieve the
round robin nature with the same trick used in the paging code
to delete and append the current entry. The nat code was updated
to compile but one can only configure one destination.
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
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.
Sending this as the RTP_PAYLOAD2 will produce a MDCX NACK
as we send the RTP_PAYLOAD in the CRCX. It does not seem to
be necessary to send anything != 0 for the RTP_PAYLOAD2.
This will change the LAI of a LU accept message to the LAI
used for the on-air network. It will also detect when to
send a welcome ussd to the subscriber.
Add the code that is forwarding data, from and to the MSC, also
handling ping/pong timers and authentication. Hook it into the
osmo_bsc. The code is only compile tested and ported from the
on-waves/bsc-master branch.
Holger Hans Peter Freyther
Harald Welte