Age | Commit message (Collapse) | Author | Files | Lines |
|
The function lchan_alloc() does not exist anymore, however there is
still a prototype definition in chan_alloc.h and a comment in
abis_rsl.c. Lets remove those.
Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
|
|
There could multiple reason for OML or RSL link towards BTS to be
dropped: ctrl command, vty, new link etc. Introduce "reason" parameter
to corresponding functions and log it on link drop to simplify
troubleshooting issues with more complex setups.
Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
|
|
(requested by pespin)
Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
|
|
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
|
|
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
|
|
According to 3GPP TS 08.58 ยง8.5.1 BCCH INFORMATION:
"If the Full BCCH information element is not included this indicates that
transmission of the indicated SYSTEM INFORMATION message shall be stopped."
However, some ipaccess nanoBTS firmware versions are known to not support
some SI elements and also to dislike receiving BCCH Information for those SI,
even if received with empty BCCH Information meaning they should not be used.
Upon receival of this kind of message, nanoBTS sends a Failure Report
with following text:
Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
This kind of issue only appears with some fw versions, since it's known
to work fine in other ones, so let's not disable this kind of mesage by
default on all BTs of type "nanobts".
Instead, add a VTY command that allows disabling this kind of message in
order to be able to operate those nanoBTS units.
Fixes: OS#3707
Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
|
|
The idea is to have a base static value which is set like before "timer
t3113 [seconds]", but now have a part of this timeout calculated
dynamically based on BTS channel configuration and channel load.
This patch only implements initial support to calculate based on channel
configuration, but doesn't include code to calculate based on channel
load. To implement the later part, we probably need to keep track of BTS
paging queues per paging group, which we don't do nowadays.
Dynamic calculation is enabled by default, and default static base value
is decreased accordingly. This way, in a typical setup were the default
10 seconds were used, now the calculated final value is 11 seconds.
That's intended because it was observed experimentally in osmo-gsm-tester with
a similar channel setup that sometimes paging response can arrive slightly
later than 10 seconds.
Related: OS#3680
Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
|
|
It will be used further in follow-up patches. It also provides a place
to document its (intricate) logic around it and its possible uses.
Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
|
|
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c
|
|
It is moved prior to its user in the header file.
Change-Id: I59f52401ba37b351ba3848e8e9ffb3b24c259496
|
|
Set flag lchan->activate.immediate_assignment_sent to true when sending, and
omit a reject after that.
lchan->activate gets completely zeroed in lchan_reset(), which sets that flag
back to false whenever an lchan becomes inactive.
Related: OS#3709
Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
|
|
Add LCLS variant where the loop is closed on BTS level instead of
MGW. The main difference is the handling of connection-related
messages (we use IPA RSL instead of MGCP), the configuration and
correlation logic remains the same.
Change-Id: I7e8379f31037f2c48da69a01919701919a3066a2
Related: OS#3659
|
|
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX
generation into separate function with the ability to set destination
explicitly instead of just using the value from lchan which will be used
in follow-up patches.
Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8
Related: OS#3659
|
|
This signal can be used for tools willing to request and parse Attribute Response
and do something with the information. ipaccess-config tool will use
this signal in later patch Change-Id Ida416a969a3309868d6f4e50f34b34f224c32dd6.
Related: OS#3624
Change-Id: I9a121bbfe1b96904d4e16845abc90bb6ef20d2c9
|
|
Some nanoBTS firmwares (if not all) are known to not work properly with
SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter
available will be forwarded by nanoBTS to MS, but will still only send
SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping
of BCCH data"). As a result, some MS won't allow registering to the
network.
To avoid this kind of scenario, enable force-combined-si by default on
nanoBTS while still allowing to overwrite the feature through VTY. Other
BTS models are kept with force-combined-si disabled by default as
usually, since they seems to be working fine when SI2ter is enabled.
Related: OS#3063
Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
|
|
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
|
|
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
|
|
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
|
|
Change-Id: Ia05e0b8fe3e28aaf2b2253d018f0614e83e23caa
|
|
The function cgi_for_msc() provides an easy way to get a cell global id
for an msc/bts combination. This function is currently statically
defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly
available.
Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d
Related: OS#3645
|
|
Change-Id: I56b57936ae82984e84896228da5a83115a78bbd7
Related: OS#3659
|
|
Change-Id: Ib34c8e3fb51d067581aefa1c80f8be1f6db9512e
|
|
Change-Id: I4bc157bf296e28678de6d9c9823f91810132a58c
|
|
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
|
|
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
|
|
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
|
|
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
|
|
In networks with a couple of different BTSs it may be likely that one
accidently sets up a codec configuration (codec-support)) that will be
mutually exclusive towards the codec configuration for the MSC
(codec-list). We need a check that validates the configuration before
start to catch such configuration flaws quickly.
- Add a check that checks each MSC codec-list against each BTS
codec-support setting.
Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38
Related: OS#3625
|
|
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
|
|
The COMPLETE LAYER 3 INFORMATION message lacks the Codec List (BSS Supported)
information element. This information element is mandatory for networks
that use an IP based user plane (AoIP).
- Add function to generate the speech codec list from the current codec
settings (Available codecs)
- Generate and embed information element in L3 Compl. message
Depends: libosmocore I4e656731b16621736c7a2f4e64d9ce63b1064e98
Change-Id: Id6f2af3fdab45bf05f06aec03e222734d7a4cf70
Related: OS#3548
|
|
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to
the MS.
(The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC,
is already implemented.)
Related: OS#3043 (A5/3 encryption)
Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb
Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
|
|
Remove unused gsm_subscriber_connection.user_plane.chan_mode.
There is only one VTY command that displays it along other
parameters, but it is used no where else. Lets remove it.
It was forgotten to be removed in:
commit 31f525e7560ad13e32cfc5e0b5f1862c0efcb991
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I10049c14ea206a4daafbdad01634d57c72a79d7c
|
|
Remove unused member gsm_subscriber_connection.user_plane.full_rate.
It was forgotten to be removed in:
commit 31f525e7560ad13e32cfc5e0b5f1862c0efcb991
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I3a14efe0039ff4690e27e3b083eb23c1b2a616c3
|
|
In case a given channel combination contains a CBCH, it replaces sub-slot 2
with a CBCH, i.e. we must not attempt to allocate the same for SDCCH.
On timeslot initialization, immediately place such an lchan FSM into new state
LCHAN_ST_CBCH, so that it never appears unused and never is picked during
lchan_select(). Also set lchan->type = GSM_LCHAN_CBCH.
Verified by configuring CBCH timeslots and watching 'show lchan summary'.
Immediately after RSL and OML are up, these pchan types show lchan 2 in state
CBCH:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
With a 'phys_chan_config ccch+sdcch4+cbch' and three phones simultaneously
requesting USSD, I see:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 14 dBm RXL-FULL-dl: -53 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 1, Type SDCCH, State ESTABLISHED - L1 MS Power: 30 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 3, Type SDCCH, State ESTABLISHED - L1 MS Power: 16 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
With 'phys_chan_config SDCCH8+CBCH' and three phones simultaneously attaching,
I see:
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
i.e. in all cases the CBCH lchan remains occupied and is not allocated as
SDCCH.
Detaching and re-attaching the BTS reliably brings back the CBCH state. Also
verified that changing the osmo-bsc config from telnet vty and dropping oml
followed by the BTS re-attaching brings back the CBCH state.
Change-Id: I2bafc5f696e818e38f8907ad0c8f38494df0623d
|
|
gsm48_lchan2chan_desc_as_configured() is similar to gsm48_lchan2chan_desc(),
but uses the *configured* channel combination, rather than the currently
active one.
Change-Id: Id4043218fb770e8420f19a4ef9428680ecdfd286
Related: OS#3532
|
|
The function is defined in gsm_data.c, so it should be declared
in gsm_data.h and not in gsm_04_08_rr.h
Change-Id: I5200063fb43c857a984ea8e41a8485d796e49cde
|
|
The flag lchan->activate.concluded prevents entering the
lchan_on_fully_established()/lchan_on_activation_failure() more than once. So
far it was checked by callers, instead place in the functions themselves.
There is a potential functional change here, since during lchan_fail(), the
concluded flag was set only after entering lchan_on_activation_failure(). Now
it is already set at the start and prevents multiple re-entry beyond doubt.
This patch is not a result of an actual observed faulty behavior, just from
reading the code and seeing the slight loophole.
Change-Id: I0c906438b05442d66255203eb816453b7193a6d8
|
|
Use libosmo-mgcp-client's new X-Osmo-IGN header to indicate that CallIDs are
allowed to mismatch.
Add VTY commands 'msc' / 'mgw x-osmo-ign call-id' and 'no mgw x-osmo-ign' to
switch this behavior explicitly.
For SCCPlite MSCs, unless a specific config was issued, always send
'X-Osmo-IGN: C' by default, to ignore CallID mismatches.
Depends: Id7ae275ffde8ea9389270cfe3db087ee8db00b51 (osmo-mgw)
Change-Id: I257ad574d8060fef19afce9798bd8a5a7f8c99fe
|
|
ipaccess_drop_oml was being called inside an osmo_fd cb context, were
-EBADF must be returned if the structure holding the osmo_fd is freed.
In the middle of the path (see OS#3495 for path tree) it goes through a
signal dispatch, so it's impossible to make sure we return some value to
the osmo_fd cb. As a result, it is required to defer dropping the OML
Link from current code path and do it through a timer.
Fixes following ASan report:
20180822124927913 <0004> abis_nm.c:787 OC=RADIO-CARRIER(02) INST=(00,00,ff): CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed
20180822124927913 <0004> osmo_bsc_main.c:186 Got CHANGE ADMINISTRATIVE STATE NACK going to drop the OML links.
20180822124927913 <0015> bts_ipaccess_nanobts.c:406 (bts=0) Dropping OML link.
...
=================================================================
==17607==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e000060a68 at pc 0x7f5ea8e27086 bp 0x7ffde92b6d80 sp 0x7ffde92b6d78
READ of size 8 at 0x62e000060a68 thread T0
#0 0x7f5ea8e27085 in handle_ts1_write input/ipaccess.c:371
#1 0x7f5ea8e27085 in ipaccess_fd_cb input/ipaccess.c:391
#2 0x7f5ea9147ca8 in osmo_fd_disp_fds libosmocore/src/select.c:217
#3 0x7f5ea9147ca8 in osmo_select_main libosmocore/src/select.c:257
#4 0x555813ab79d6 in main osmo-bsc/osmo_bsc_main.c:922
#5 0x7f5ea76d02e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x555813ab84e9 in _start (/bin/osmo-bsc+0x34d4e9)
Fixes: OS#3495
Change-Id: I7c794c763481c28e8c35dc9b11d27969e16feb3c
|
|
The intention was to use the file's basename, but __BASE_FILE__ means "the root
file that is being parsed and contains #include statements".
If we had a function using __BASE_FILE__ and that was defined in an #included
file, __BASE_FILE__ would indicate the first file where the #include is, and
not the file where the function is defined. __BASE_FILE__ works for us because
we don't ever include function definitions that log something, so __BASE_FILE__
always coincides with __FILE__ for our logging; but still __BASE_FILE__ is
semantically the wrong constant.
Related: OS#2740
Change-Id: Ic6d9dafc96c9d467ae53be2cd41adcf26a4e5125
|
|
It is theoretically possible to LCLS two legs that use different
codecs. However, this requires transcoding capabilities on the
local MGW. If the local MGW lacks transcoding features such a
local circuit should be avoided. Enabeling LCLS under such
coditions should be optional (VTY)
- Add check to avoid LCLS on different codec/rate
- Add VTY-Option to optionally override the check
(MGW is able to transcode)
Change-Id: I157549129a40c64364dc126f67195759e5f1d60f
Related: OS#1602
|
|
The API of a_reset.c is currently called with a pointer to struct
reset_ctx. This puts the responsibility of checking the presence of
msc->a.reset_fsm to the caller. It would be much more effective if the
caller would check if msc->a.reset_fsm before dereferencing it.
This also fixes at least one segfault that ocurrs when gscon_timer_cb()
is called but no sccp connection is present yet. Therefore the pointer
to bsc_msc_data would not be populated. This is now detected by
a_reset.c itsself.
- minor code cleanups
- call a_reset.c functions with msc (struct bsc_msc_data)
Change-Id: I0802aaadf0af4e58e41c98999e8c6823838adb61
Related: OS#3447
|
|
In cases where a codec has no fixed (IANA) payload type number, a
dynamically coosen payload type number is used. For the route between
BSC and MSC 3GPP as designated certain payload type numbers. However,
beond that, those payload type numbers may not necessarly apply. The
RTP communication between BTS and BSC still might run on a completely
different payload type number.
libosmo-netif contains a header file which payload type numbers
shall be used. Lets use those in order to signal the same payload type
numbers as we actually use in the RTP packets to the MGW.
Change-Id: I507a1b1446c8f140b2950d73cf737797604c1ac3
Related: OS#2728
Related: OS#3384
|
|
See also I91922f557072d0fb8cfe213a8a7b50f3bb23dea0, which renames
osmo_bsc_api.c to gsm_08_08.c.
Change-Id: I7179eb27183ee213f8fc8d548895b67aa43dc6a2
|
|
Remove as much as possible from bsc_api.h. Use '#pragma once'. Tweak head
comment.
BSC_API_CONN_POL_{ACCEPT,REJECT}: only user is static complete_layer3(), just
use a bool return value instead.
msc_connected(): only used in osmo_bsc_api.c, make static there.
Instead of including gsm_data.h, declare structs opaquely, include stdint.h.
codec_pref_test.c used this as indirect gsm_data.h include via osmo_bsc.h,
include gsm_data.h there directly.
osmo_bsc.h: instead of including bsc_api.h, declare opaque structs.
gsm_04_08_rr.h: declare opaque structs to replace indirect include of
gsm_data.h.
Change-Id: Ia9c0f9828317236048e40ec9ecf9990592e2190a
|
|
gsm0808_page() is just a thin wrapper for rsl_paging_cmd(), the only caller is
page_ms() from paging.c. Directly call rsl_paging_cmd() instead.
Move gsm0808_cipher_mode() to the only caller in osmo_bsc_bssap.c, make static.
Change-Id: Ib7ce026b52d4ba3e53a8b2824e74ea92432c48c5
|
|
Change-Id: I9a078ffb781ee55c0ca114fa0d752c1b53067419
|
|
Change-Id: Ie889b8860a4a63c7c22ef65025f690d64cd7330c
|
|
If a release event is being handled, ignore other ricocheting release events
until that release handling has concluded.
For example, if an lchan is regularly released, it signals the lchan RTP FSM to
release, which then calls back to say "RTP is released" on termination -- this
should not trigger other state changes than the initial release intends.
Change-Id: Iec41e006b6ab9d0f618d36925341f9536353e5d8
|
|
Change-Id: Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb
|