The vty option bts->codec-support allows the user to set the supported
codecs per BTS level. However, those values are currently only used to
make the handover decision but the logic that handles the BSSMAP
ASSIGNMENT REQUEST does not check those flags.
- Do not ignore bts->codec-support flags on BSSMAP ASSIGNMENT REQUEST
Change-Id: I285234e9c81de74d9fb9907fca2c443b08537435
Closes: OS#3361
At the moment there are three sources that may advertise a list of
supported audio codec/rate settings. There is the MS that advertises
advertises a speech codec list and the MSC that sends a channel type
information element over A and there are also settings in the bsc
configuration file that may restrict the codec/rate types that are
allowed to use.
The function match_codec_pref() looks at all of the three buckets and
selects a codec that satisfies all three. This is already a somewhat
complicated process, overit is very isolated, so lets give it its own
c-file.
Due to the lack of unit-tests it is very hard to make changes here so
lets add also unit-test to make sure that regressions are catched early.
- Put match_codec_pref() and all its helper functions into a separate
c-file.
- Add a unit test.
Change-Id: Iabedfdcec8b99a319f2d57cbea45c5e36c7b6e29
Related: OS#3361
Before this, a handover request in a conn state that disallows it would leave a
lingering handover state in the conn, also thwarting any future handover
attempts. (It would be deallocated on conn teardown, so no memleak.)
Change-Id: I839a05495ae93c5dbbd1616efa2469e5b1990a61
If an invalid phys_chan_config is specified in osmo-bsc.cfg, raise
a parsing error at program startup.
If an invalid phys_chan_config is specified in in the VTY while
the program is running, show a warning to inform the user that
the configuration change was not applied.
Change-Id: I97baa359464a0e94de2497bc9214b99ed2a24041
Related: OS#1876
xua_msg allocations should not go unnoticed by our root ctx. libosmo-sigtran
recently added this API to fix that.
Depends: I618878680a096a7f7fc2d83098590f2e4cb08870 (libosmo-sccp)
Change-Id: I8d5edda17be82e0cb4a1af3e2a62cbcb3a2ddda3
Fixes following runtime warning:
libosmocore/src/rate_ctr.c:219 counter group 'nat:filter' already exists for index 0, instead using index 1. This is a software bug that needs fixing.
Forward-port from openbsc.git c08d58802e03a45f95b8f7d28b29dc7026f664ba.
Change-Id: I7c5054c374281bb1d4bd1ecd76ddcca7a010d50a
The '.' is illegal character in counter names, as they are exported
via CTRL interface, where '.' has a special meaning that cannot be
used by strings comprising the variable name.
Forward-port from openbsc.git 360284d4d797519faed33559b0ae746b6c17e68a.
Change-Id: I57b78162701a6a101b5cbaf68aaea89d17a0f819
Previous state is harmless because the pointer is stored but not used in
that function. However, it's more clear this way.
Change-Id: I048ebc120306ea30ea973d6ee16ed84c9f341183
While GSCON is setting the codec info when operating on the MGW, LCLS
is not doing that yet. This means that the MDCX messages that are
sent by LCLS do not contain any payload type and also no ptime or
rtpmap fields. This also causes the following TTCN3 tests to fail:
TC_lcls_connect_break
TC_lcls_connect_clear
TC_lcls_gcr_bway_connect
TC_lcls_gcr_bway_dont_connect_csc
- Make mgcp_pick_codec() public as bsc_subscr_pick_codec()
- use bsc_subscr_pick_codec() to set codec info in osmo_bsc_lcls.c
Change-Id: I383d55fa602cda0926dd701ee517a299db578260
Closes: OS#3358
The GSCON FSM does not care about the codec information when performing
interactions with the MGW. Before upgrading the client the codec
information was hardcoded to AMR inside the client. Now the client
offers APIs to set the codec information. Since this feature is new,
osmo-bsc does not set any codec information yet, which causes many of
the TTCN3 tests to fail. So lets add some logic to pick suitable codec
info.
- Hardcode ptime to 20 (is the same for all possible codecs)
- Select a codec according to the flags in userplane
Change-Id: Ibddc3492572b39f166e3a1b8b8120813ce2dadc2
Related: OS#2728
Commit "dyn ts, bts_ipaccess_nanobts.c: init PDCH on Chan OPSTART ACK"
bf7099262a Icf6e25ff068e8a2600562d52726ead65e864ec02
introduced signal S_NM_OPSTART_ACK and passed the FOM header to identify the BTS
by. But the FOM header's BTS number is zero on each Abis/IP link, and the BTS
and TRX are actually identified by msgb->dst == e1inp_sign_link, member trx. So
the initial implementation associated *all* Channel OPSTART ACKs with BTS 0.
Pass the entire msgb as S_NM_OPSTART_ACK signal argument, implement a
abis_nm_get_ts() to retrieve the proper timeslot and use that during timeslot
init.
Related: OS#3351 OS#3205
Change-Id: I45ce5c24cb62d00f350df1af1be6c11104d74193
When we receive a RSL CONN FAIL IND, it may be that this happens
before any RLL is established (and hence a lchan->conn exists),
or after the RLLs have been shut down (and hence a lchan->conn doesn't
exist anymore).
So in this function, it is not legal to unconditionally dereference
lchan->conn.
Change-Id: I6380f5d2cd9364560ce3947517c84247cf4af0d4
Closes: OS#3182
3GPP TS 48.006 section 9.2 states clearly that any SCCP connection
release must be initiated by the MSC.
for bsc_subscr_conn_fsm, this means that even after sending the
BSSMAP CLEAR COMPLETE, we must not terminate the FSM, as this would
cause a N-DISCONNET.req to be sent to the stack for the associated
SCCP connection.
The bsc_subscr_conn_fsm instances will hence stay alive until the MSC
eventually decises to release them.
Change-Id: Iaaca220b598609b77b600fcfc2f9a78b221c1fbb
Closes: OS#3331
We use the newly-introduced logging_vty_add_deprecated_subsys() from
libosmovty to make sure old config files will still parse even after
this change.
Change-Id: Ib4f67bb00e1d5460e643717b53f6a4d81278dc5d
In Change-Id OSI6b7354f3b23a26bb4eab12213ca3d3b614c8154f we introduced
a function called osmo_ss7_asp_rx_unknown() which was supposed ot
override a weak symbol in libosmo-sigtran. However, the related change
in libosmo-sigtran (I8616f914192000df0ec6547ff4ada80e0f9042a2) was
modified later on to use explicit registration of a call-back function
instead of weak symbol override.
Let's adopt the osmo-bsc code to make use of this explict call-back
registration.
Change-Id: Id5880ec90dfa00b29cbb0ffea8c8dd50e24742bd
Related: OS#2012
In Change-Id I6b7354f3b23a26bb4eab12213ca3d3b614c8154f we removed
the "dest" vty command, but we should simply ignore it and print
a related warning during start.
Change-Id: I531825061031918bbb1380e1b485b711e81bcd75
Do not invoke OSMO_STRINGIFY() with arbitrary names, just quote instead.
The idea was that OSMO_STRINGIFY() avoids typos by ensuring well-defined names
are stringified, but this highlights that OSMO_STRINGIFY() is in fact usable
with completely arbitrary arguments and actually lacks the validation part :/
Change-Id: I458cd2cd0d6ddb0e6db3bb8d546a20336ae8c5f1
Add lchan and timeslot FSM charts to illustrate planning of how osmo-bsc should
handle lchan assignment and release.
Modify assignment, handover, lchan-release charts according to the new plan.
Change-Id: I18d60de5ee932c962aad0a532965a55d570bb936
Another small step towards being aware of the subscriber identity.
Any connection initiated by paging will subsequently log the subscriber's
identity -- of course not necessarily the IMSI, if paging was done by TMSI.
This is only for Paging, not the Paging Response; for that see, L3 Complete.
Related: OS#2969
Change-Id: I0ab7bedfe693bb4e42a04fb0585b94a730ff2d9b
This is a tiny step towards being aware of a connection's subscriber identity.
Iff the Layer 3 Complete message contains an IMSI, associate a bsc_subscr with
the conn, so that subsequent logging and possibly meas_feed contains the IMSI.
For any L3 Complete using TMSI, this has no effect whatsoever.
Related: OS#2969
Change-Id: I3b696a0c0932e3abcb682ba231db65755d8c27a6
Keep the bsc_subscr associated with the conn as long as possible, to benefit
logging, which then contains the subscriber identity (if any).
Change-Id: Ifa528b58842a02509bfe0af6915c64bd67058bcd
Instead of silently setting the use count to 1, instead increment with an
explicit bsc_subsct_get(), which then logs the event along with the place that
created the subscriber.
Change-Id: Ia72f8010b7b2e1ca44e3b005c0f2c05f3eeae8d5
The guts of bssap_speech_from_lchan() and lchan_to_chosen_channel() have been
moved to libosmocore; call those instead.
The return value of bssap_speech_from_lchan() used to be -1 on error, now the
error value is 0. The only caller did not handle -1 properly, but fed it
directly to a uint8_t.
On gsm0808_chosen_channel() error, log the error. Proper handling is missing.
Fixing the error handling in send_ass_compl() is a separate issue: currently it
is limited to logging, there is no way to return an error yet, nor any actions
to take on error.
Depends: Icca23940791f97fa64dbc3f2734270b99f9550c1 (libosmocore)
Change-Id: Ib5c940a9dae11c5e26d4b47fa9d95fef889ad2f6
In each code path within rsl_rx_chan_act_nack(), do separate logging of the
NACK to ensure proper termination of each log line.
When receiving a Chan Act NACK, we possibly mixed a LOGP() within an
unterminated other LOGP() that had not been ended with a LOGPC() yet.
Change-Id: Icd2772b21ef3a2ff5af11b7c92dff0ecb4d87ff0
When the BTS responds with a Chan Act NACK, i.e. the lchan could not be
activated, immediately signal Assignment Failure to the MSC (in
handle_chan_nack()).
In handle_chan_nack(), adjust log: instead of waiting for timeout, we now
signal Assignment Failure.
Drop misleading logging from bsc_assign_fail(): instead of transmitting the
Assignment Failure message, it actually signals an FSM event. Leave logging of
that to the FSM logging.
Change-Id: Ib204b4a5272f9b7b60ca5f932cd8a4c857316270
struct bsc_api was used to provide an abstract API for both osmo-bsc and
osmo-msc, between BSC and MSC. That's no longer needed, so get rid of it, to
prevent code turbulences it creates for no reason.
Change-Id: I3fd5888c63a0b4f95520a498320aa105a6d60579
Philipp Maier
Neels Hofmeyr
Pau Espin
Harald Welte