aboutsummaryrefslogtreecommitdiffstats
path: root/include/osmocom/bsc/gsm_data.h
AgeCommit message (Collapse)AuthorFilesLines
2020-05-09stats: Export connected OML/RSL links count per BTS.Alexander Chemeris1-0/+2
Change-Id: I88c8025940a0eecb034b1c70f76ea17937fa0325
2020-05-09stats: report a number of configured BTS to a stats gauge.Alexander Chemeris1-0/+7
It's useful to know how many BTS are actually configured to compare it to a number of connected BTS's. Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
2020-05-09gsm_data: Update trx_is_usable for ericsson BTSSylvain Munaut1-0/+12
There is no bb_transc oject. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I34bb808cd21575ff25d36e6df028b140935a008f
2020-05-08stats: Report per channel type load to statsd counters.Alexander Chemeris1-0/+16
Change-Id: I2eac4c93061204aeb8f3d223f7e78158c61c7156
2020-05-08om2k: Add support for MCTR configurationSylvain Munaut1-0/+4
Currently only supports a single MCTR with fixed configuration Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
2020-05-08om2k: Add option to limit OML version during negotiationSylvain Munaut1-0/+4
Starting from G12R13 the MCTR swiches to BSC controlled mode. And although we think we know how to configure it (via MCTR Conf Req), something doesn't work right and the timeslot configuration is not accepted. (TS Conf Result shows "Data not according to request"). So as a workaround for now, we use this version of the protocol where we don't configure the MCTR (it's in "BTS controlled mode") and with this protocol, the BTS accepts our timeslot config and we can bring the system up. This commit add a generic option to limit either OML or RSL IWD version to any value. It also keeps track of the actual negotation version so we can react to it in other places of the code. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65 better version limit Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
2020-05-08bts_nokia_site: Fix LAPD segfault during reset procedureHarald Welte1-1/+1
The existing Nokia *Site code destroyed the LAPD SAP instance for OML while processing an OML message. Once the stack frame returned back to the LAPD code, the LAPD SAP was gone -> segfault. Let's work around this by moving deletion of the LAPD SAP out-of-line by starting a timer 0ms in the future. Not particularly nice, but effective. Change-Id: I6270c7210f600e53f845561898245d2fd30a368d Closes: OS#1761
2020-05-04gsm_data.h: Comment the 'nokia' BTS fieldsHarald Welte1-6/+6
Change-Id: I5e3eaf3dee97e2edcd80b20c3acf85bd89b40cdc
2020-04-14vty: clarify EGPRS Packet Channel Request message supportVadim Yanitskiy1-1/+1
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE contains two parameters related to 11 bit Access Burst support: - ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be used in the PACKET CHANNEL REQUEST message, the PTCCH/U block, PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS messages on the PRACH (if present). - EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF establishment on the RACH or on the PRACH (if present). The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may be hard to understand this from its name and description. This patch is actually a group of tightly related changes: - deprecate 'gprs 11bit_rach_support_for_egprs (0|1)': - update its description to avoid any possible confusion, - print a warning if it's used in non-EGPRS mode, - print a warning if it's still used; - introduce '[no] gprs egprs-packet-channel-request': - ensure that it can only set / printed in the EGPRS mode; - take a chance to clean-up / rename the related struct members: - 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request', - remove 'supports_egprs_11bit_rach' from 'gprs_cell_options' because we already have 'ext_info.use_egprs_p_ch_req' there. Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
2020-03-27VTY: add show bts failure reportOliver Smith1-0/+8
Save OML failure reports from each BTS. Add a VTY command to display them conveniently and optionally clear the list. OsmoBSC> show bts 0 fail-rep [2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY [2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY Related: OS#1605 Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
2020-03-19main: exit on mutually exclusive codecs settingsOliver Smith1-0/+3
Refuse to start with mutually exclusive codec settings, unless allow-unusable-timeslots is set in the network section of the config. The checks were already implemented and fill the error log if the config is invalid. Related: OS#3739 Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
2019-11-19bsc: Adapt maximum MS Power Ctrl level based on band and MS Power classPau Espin Pedrol1-0/+6
Related: OS#4244 Change-Id: I6bff440b7797e710bca5af94fae546e5d55e6972
2019-11-13Fix some typosMartin Hauke1-8/+8
Fix typos and common misspellings in code comments and in the manual. Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-11-02osmo_bsc_main.c: verify the physical channel mapping at startupVadim Yanitskiy1-0/+2
As per 3GPP TS 45.002, section 3.3.2.3, and table 3 of clause 7, the following limitations apply mapping of CCCH/BCCH channels: - TS0/C0 shall be configured as CCCH/BCCH (optionally combined); - combined CCCH (CCCH+SDCCH4) can only be used on TS0; - additional CCCHs can be on TS2, TS4, and TS6; - additional CCCHs are not allowed if TS0 is combined. Let's make sure that OsmoBSC is properly configured before starring. Change-Id: I758ef80f7884ba35cdf59d671ee30222ffb9d68b
2019-10-31gsm_data.h: Remove unused func declarationsPau Espin Pedrol1-3/+0
Change-Id: I189d34b6db78de749e1901733d0df35411e0d583
2019-10-31gsm_data.h: Remove unused field classmark from gsm_subscriber_connectionPau Espin Pedrol1-3/+0
Change-Id: If2826a8f334afabfa3a0198a0bc1eed009962c81
2019-10-31Remove unused API classmark_is_r99()Pau Espin Pedrol1-2/+0
Furthermore, similar API already exist in libosmocore: osmo_gsm48_classmark_is_r99() Change-Id: I6763d8c894f0a0555a9801bddbc0a12c2b945599
2019-09-08SMSCB: Send ETWS Primary Notifiation via RSL to BTSHarald Welte1-0/+1
In addition to transmission of the ETWS Primary Notification via all dedicated channels, we also need to send it to the BTS for transmission via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH transmission. Change-Id: I7e45b0373458a4348b12b92dd92861062532548b
2019-09-02Cell Broadcast: CBSP and CBCH scheduling supportHarald Welte1-0/+53
This adds code to handle CBSP (Cell Broadcast Service Protocol) from the CBC (Cell Broadcast Centre), as well as BSC-internal data structures for scheduling the various SMSCB on the CBCH of each BTS. There are currently one known shortcoming in the code: We don't yet verify if keepalives are received within repetition period. Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7
2019-07-13comment and VTY doc tweaksNeels Hofmeyr1-1/+1
Clarify some in-code comments. Fix descriptions of some handover timers, which still talked of "MO" and "MT" handover -- which we now call "inter-BSC out" or "inter-BSC in" instead. Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
2019-05-26Allow VTY to set the CCCH Load Indication ThresholdHarald Welte1-0/+3
Add a new VTY command "ccch load-indication-threshold <0-100>" by which the user can configure the threshold after which the BTS shall send CCCH LOAD IND. It used to be hard-coded to a default value of 10. Change-Id: I059fe4627438e26a06e00d84e342b736ab7af440
2019-05-24keep per-BTS stat_items about RACH busy / RACH access percentageHarald Welte1-0/+2
Change-Id: I3ad0cc4866d6210181cbafbab876e8028ad27540
2019-05-19bssap: Parse Osmux CID on BSSAP Assign Req recv and use it in MGCPPau Espin Pedrol1-0/+3
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW to configure the MSC-side MGW conn of a call leg. Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
2019-05-03assignment_fsm: Properly support assigning signalling mode TCH/xSylvain Munaut1-7/+10
To support the 3 possible preferences, the changes needed were: - Replace 'full_rate' bool with a 3 option enum to represent the channels types for signalling - Switch from _pref/_alt to using an array sorted in preference order Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3, reverted because the change broke voice calls. Re-submitting with the fix: don't forget to set conn->assignment.requires_voice_stream. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
2019-04-30move mgw endpoint FSM to osmo-mgw.gitNeels Hofmeyr1-7/+8
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example I92a9944acc96398acd6649f9c3c5badec5dd6dcc. Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
2019-04-23use libosmocore osmo_tdefNeels Hofmeyr1-2/+2
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API and use libosmocore's osmo_tdef* API instead. The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be able to use it in osmo-msc for inter-MSC handover. When adding osmo_tdef, the new concept of timer groups was added to the API. It would make sense to apply group names here as well, but do not modify the VTY configuration for timers. The future might bring separate groups (or not). Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore) Change-Id: I66674a5d8403d820038762888c846bae10ceac58
2019-04-17gsm_data.h: Remove unused variable from OpenBSC timesDaniel Willmann1-1/+0
This variable does not seem to be used anywere in OsmoBSC, seems to be a remnant from OpenBSC times. Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
2019-04-08Handover Request: also parse Chosen Algorithm IE, pass to lchan activationNeels Hofmeyr1-0/+4
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the Handover Request message. Actually parse this Chosen Encryption Algorithm IE. Place the chosen algorithm and the CK into lchan_activate_info->encr so that the new lchan will use the same ciphering on this new BSS as it did on the old BSS. Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
2019-04-08lchan activation: add explicit encryption info to activationNeels Hofmeyr1-0/+1
For intra-BSC handover, the previous encryption is copied from the old lchan, which of course is not available during inter-BSC handover. Hence the lchan activation info needs to include an explicit encryption information, and we must not rely on the presence of the previous lchan to copy encryption information from. Add struct lchan_activate_info.encr to allow passing encryption info through lchan_activate() without requiring a previous struct gsm_lchan to be present. Instead of copying from the old lchan, always copy encryption info to lchan_activate_info, and during activation, just before sending the Channel Activation, copy the lchan_activate_info.encr to the new lchan. This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which obtains the encryption information from an intra-BSC-incoming Handover Request message. Related: OS#3842 Related: I5b269f50bd2092516bfdf87746196983d3ac49d1 Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
2019-03-14Revert "assignment_fsm: Properly support assigning signalling mode TCH/x"Neels Hofmeyr1-10/+7
This commit breaks voice channel assignment. It results in the Assignment Complete sent to the MSC for a voice lchan lacking AoIP Transport Layer Address, Speech Version and Speech Codec. Hence the MSC cannot complete the Assignment for a voice call. Let's revisit this patch, test thoroughly and re-merge later. This reverts commit 4d3a21269b25e7164a94fa8ce3ad67ff80904aee. Reason for revert: <INSERT REASONING HERE> Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
2019-03-14Move msc related code from gsm_data to bsc_mscPau Espin Pedrol1-2/+0
This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-14assignment_fsm: Properly support assigning signalling mode TCH/xSylvain Munaut1-7/+10
To support the 3 possible preferences, the changes needed were: - Replace 'full_rate' bool with a 3 option enum to represent the channels types for signalling - Switch from _pref/_alt to using an array sorted in preference order Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-03-04cosmetic: drop unused struct mgcp_ctx shadowNeels Hofmeyr1-1/+0
Change-Id: If9c705e9fe6dba9225f7dec045e790af7a875ee8
2019-02-21assignment_fsm: fix channel allocator preferencesPhilipp Maier1-3/+19
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may ask for a TCH/H and a TCH/F at the same time and tell which of the two types it prefers. The process of channel allocation currently selects, based on the BTS, MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H) and then tries to allocate it. If that allocation fails, there is no way to try the second choice and the assignment fails. For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the channel allocator will try TCH/F and if it fails (all TCH/F are currently in use), then TCH/H is never tried. Since the BSC currently only trys the first best codec/rate that is supported it also ignores the preference. Lets fix those problems by including the preference information and both possible codec/rate settings into the channel allocation decision. Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51 Related: OS#3503
2019-02-06comments: clarify usage of conn.assignment and .handover scopesNeels Hofmeyr1-2/+13
Change-Id: I7ef602c3ce086aecbc3ae3ae6d3fd33ad2b9f85c
2019-02-06handover_fsm: do not access conn->assignment.req, it may be outdatedNeels Hofmeyr1-0/+2
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current lchan's AMR configuration. However, conn->assignment.* values are only valid during an ongoing assignment. Those values may be overwritten by any failed Assignment attempt, at any time, and hence do not reflect the currently assigned conn->lchan. Those realms must be kept separate. The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most sense to store these values in struct gsm_lchan once the lchan activation succeeded. Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during lchan_activate(). In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*. Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
2019-02-05Implement CSFB "Fast Return" Handling at RR RELEASEHarald Welte1-0/+3
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE, it lets us know that the to-be-released connection related to a CSFB call. We as the BSC then subsequently should include the "Cell Selection Indicator after release of all TCH and SDCCH" IE in the RR RELEASE message sent to the MS/UE. This IE contains the LTE neighbor cells that we're configured to broadcast in si2quater. That in turn will make sure the MS/UE can return very quickly to the LTE cell. Closes: OS#3777 Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755 Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646 Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07 Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
2019-02-05gsm_data: Add gsm_bts_name() just like we have gsm_{trx,ts,lchan}_name()Harald Welte1-0/+1
Change-Id: Icd7fd6273396026c5fe2da600f35631b1bac1614
2018-12-21comments: describe some lchan detailsNeels Hofmeyr1-0/+3
(requested by pespin) Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr1-5/+14
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
2018-12-18LCLS: update parameter representationMax1-2/+2
* use osmo_lcls struct from libosmocore * use enum values instead of magic numbers Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858 Related: OS#3659
2018-12-14Add VTY option to avoid sending empty Full BCCH Info for disabled SIPau Espin Pedrol1-0/+3
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
2018-12-05paging: Add VTY options to calculate T3113 timeout dynamicallyPau Espin Pedrol1-0/+1
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
2018-12-05bsc: Add define for ts_as_pchan_for_each_lchan with ts->pchan_on_initPau Espin Pedrol1-0/+13
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
2018-11-29bsc: ts_for_each_lchan: Improve documentationPau Espin Pedrol1-2/+4
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c
2018-11-29bsc: ts_as_pchan_for_each_lchan: reorder and improve documentationPau Espin Pedrol1-9/+12
It is moved prior to its user in the header file. Change-Id: I59f52401ba37b351ba3848e8e9ffb3b24c259496
2018-11-27send Immediate Assignment Reject only before Immediate AssignmentNeels Hofmeyr1-0/+1
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
2018-11-20bsc: Enable force-combined-si on nanoBTS by defaultPau Espin Pedrol1-0/+4
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
2018-11-14cosmetic: lchan: introduce sub-struct lchan->release.*Neels Hofmeyr1-15/+17
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
2018-11-14lchan release: always Deact SACCHNeels Hofmeyr1-1/+0
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-27 09:46:56 +0000