The member data[0] in struct osmo_ecu_state is used as an anchor to
attach private structs for a concrete ECU implementation. This works by
allocating more memory then struct osmo_ecu_state actually needs and
then using the excess memory to store the private struct of the concrete
ECU implementation.
However, this poses a problem since data[0] is at the end of the struct
it may land in an unaligned position. This also means that the struct we
store there is also unaligned.
We should fix this enclosing the public struct osmo_ecu_state into our
private struct fr_ecu_state. Then we can use container_of to cast from
osmo_ecu_state to fr_ecu_state and correct alignment is ensured as well.
Related: OS#6286
Change-Id: I28672856e8e8f47e04ffe09ee3e07b577108cdc7
The ECU API of libosmocodec is unfortunately a peculiar non-3GPP
entity: an ECU by itself, severed from Rx DTX handler functions,
which is a logical/conceptual function with no place in the standard
3GPP architecture. The closest thing that exists in the standard
architecture is the TFO spec (TS 28.062 section C.3.2.1.1) calling
for an ECU application, but not comfort noise generation, in the case
of destination leg doing DTXd - but even then it is not a totally
"pure" ECU like libosmocodec API, it is an ECU plus a SID preener,
and the SID preening transform is not possible within the constraints
of existing libosmocodec ECU API. Hence truly correct handling of
corner cases, particularly invalid SID, is sadly impossible in the
current libosmocodec ECU framework.
The only current user of this API is the UL path in osmo-bts-trx;
however, as described in OS#6040, we would like to move that ECU call
from osmo-bts-trx model-specific code to the common layer of osmo-bts.
The current osmo-bts-trx incarnation avoids the SID handling problem
by suppressing the call to ECU frame_out() after any SID (valid or
invalid) was received on the air, thus pausing the RTP stream instead
of emitting ECU output during DTXu pauses. We would like to retain
the same behavior when we move this ECU call to the common layer,
into its proper place _after_ the link quality check in l1sap - but
the current method of flagging post-SID state in osmo-bts-trx will
no longer work on the other side of that link quality check.
As a workaround, have the ECU remember via a separate Boolean flag
whether it is in post-SID state or not (was the most recent frame_in()
any kind of SID or not), and provide is_dtx_pause() method to
retrieve this flag - the relocated ECU call in osmo-bts UL path
will use this new is_dtx_pause() method call to decide if it should
call frame_out() or switch to pausing RTP output.
Related: OS#6040
Change-Id: I3857be84bba12aaca0c2cca91458b7e13c5a642a
If a network element that receives call leg A UL and is responsible
for preparing leg B DL receives a GSM-HR SID frame whose SID field
is not all 1s but which is marked as valid SID by out-of-band means
(TRAU-UL frame control bits or the FT field in RFC 5993 ToC octet),
this SID frame should be rejuvenated (SID field reset to all 1s)
prior to retransmission on call leg B DL. Provide a function
that performs this operation.
Related: OS#6036
Change-Id: Iebc0863ffcc3f8f25aeb54d4b14fac0487bc2bbb
In Iec5c1f2619a82499f61cb3e5a7cd03ff0f020ad8 we added
osmo_{fr,efr}_sid_preen() functions that apply SID classification
of GSM 06.31/06.81 section 6.1.1 (osmo_{fr,efr}_sid_classify()),
reject invalid SID, and "rejuvenate" deemed-valid SID frames by
resetting their SID code word, correcting the one bit error that
may be present in a deemed-valid SID frame. However, the last
operation (rejuvenation of a SID frame by resetting its SID field)
should also be made available as its own function, as it may be
more efficient in some applications: for example, an application
may need to call osmo_{fr,efr}_sid_classify(), apply the rejuvenation
to valid SID, but also use the classification result to drive other
logic. Factor out these functions.
Change-Id: I1d6dd867a358bdda8850cd8c959d0f361c0a5b6d
The original GSM-FR ECU implementation from 2017 exhibits a lot of
defects, as detailed in OS#6027. Replace it with a new implementation
based on Themyscira libgsmfrp (a complete Rx DTX handler for GSM-FR),
but reduced to just the ECU function, without the comfort noise
generator function. (These two functions are coupled together in the
classic GSM architecture, but not in libosmocodec ECU model.)
Related: OS#6027
Change-Id: I0200e423ca6165c1313ec9a4effc3f3047f5f032
The current FR codec ECU implementation consists of two parts:
there is a pair of functions that implement the actual functionality,
and these functions are also made public as a now-deprecated legacy
API - and there is the new ECU abstraction. If the FR ECU
implementation behind the generic ECU abstraction is to be changed
to a different one, the old implementation still has to be retained
for those public legacy osmo_ecu_fr_reset() and osmo_ecu_fr_conceal()
API functions to remain available and unbroken. Move this legacy
ECU implementation to its own C module in preparation for changing
the preferred ECU implementation.
Related: OS#6027
Change-Id: Ia169b8bcc6331227a11b78eb7ffca0c7ab838c69
Table 1 in section 6 of 3GPP TS 46.011 (FR codec, substitution and
muting of lost frames) specifies a silence frame in the form of
GSM 06.10 parameters - add a const datum to libosmocodec embodying
this GSM 06.11 silence frame in GSM-FR RTP encoding.
Related: OS#6027
Change-Id: Idf31051ea783435268944286a71d2b0ac342a4b5
Those network elements which receive a stream of codec frames that
may come from the uplink of GSM call A and which are responsible
for preparing the frame stream for the downlink of GSM call B
(OsmoMGW feeding TRAU-DL, or OsmoBTS receiving RTP and feeding DL
to its PHY) must be prepared for the possibility that their
incoming frame stream may contain corrupted SID frames, presumably
from bit errors on radio link A. Per the rules of section 6.1.1
of GSM 06.31 for FR and GSM 06.81 for EFR, SID frames with just one
errored bit are still to be accepted as valid, whereas frames with
more corrupted bits which are still recognizable as SID are classified
as invalid SID.
In the case of a TrFO call, the entity switching from leg A UL to
leg B DL is responsible for *not* transmitting invalid SID frames
on the destination leg (they should be treated like BFIs), and any
deemed-valid SID frames that are forwarded should be preened,
correcting that one bit error they may exhibit. The functions
added here provide that functionality.
Change-Id: Iec5c1f2619a82499f61cb3e5a7cd03ff0f020ad8
The existing osmo_{fr,efr}_check_sid() functions detect whether or not
the frame of bits passed to them constitutes an absolutely perfect
SID frame, with each of 95 SID code word bits set to 0 for FR or
1 for EFR. However, the rules of section 6.1.1 in GSM 06.31 & 06.81
allow up to one bit to be in error for the frame to be accepted as
valid SID, and the same rules also call out a third state (invalid SID)
in between valid SID frames and other frames that are classified as
speech. Support for these rules cannot be patched into those familiar
osmo_{fr,efr}_check_sid() functions because doing so would alter
behavior of existing programs, hence new functions need to be added.
The new functions that implement the exact rules of section 6.1.1 of
GSM 06.31 and 06.81 will need to be used if anyone needs to construct
an outgoing TRAU-UL frame (for example, as part of implementing
TS 28.062 TFO), and they are expected to be useful as part of more
sophisticated ECU implementations.
Change-Id: Ie91a52c6f04689082d8004311517d8ce0c544916
Previously existing code provides osmo_fr_check_sid() and
osmo_hr_check_sid() functions for FR1 and HR1 codecs; these functions
are used by various RTP-touching programs in the Osmocom CNI suite
when they need to differentiate between speech and SID frames.
However, there was no corresponding function of this form for EFR
codec, with the result being that the same programs that handle
speech vs SID distinction correctly for FR1 and HR1 fail to do so
for EFR.
The present change adds an osmo_efr_check_sid() function to libosmocodec
that fully mirrors previously existing osmo_fr_check_sid() and
osmo_hr_check_sid(), providing the first step toward more correct
EFR handling in programs where a SID check may be needed.
Change-Id: Iab9fb60028f4135375287bc42f5da7ca7838b5f0
config.h is created in $(top_buildir)/config.h.
Let's make sure all CPPFLAGS add correct -Ipath includes,
and that all code includes the correct file.
Change-Id: Ie9ea38bb009bc715b01cde4d66d181f7bec2e7bd
This way we have all libosmocore.so in an own subdir instead of having
lots of files in the parent dir, which also contains subdirs to other
libraries.
This also matches the schema under include/osmocom/.
Change-Id: I6c76fafebdd5e961aed88bbecd2c16bc69d580e2
According to TS 101 318, section 5.2.2, a SID frame is identified
by a SID codeword consisting of 79 bits (r34..r112) which are all 1.
Given that there are no gaps in the codeword, we don't really need
to use bitvec_get_bit_pos() and check each field individually.
This brings additional complexity and negatively affects performance.
Instead, let's use bitvec_get_bit_pos() to check all bits in a row.
Change-Id: I678f8ff92317fe87f1aca511a3a062ad898e55cc
Related: SYS#5853
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
These functions implement re-ordering of bits as per TS 06.90 / 26.101
based on the already existing tables we've had in libosmocoding.
Change-Id: Ia4ac2aea2e96f9185f082a07ca64dfc5276efb46
The table amr_len_by_ft represents the length of the raw AMR speech bits
in bytes. The table is based on the Table found in RFC 4867 §3.6, Table 1,
Column "Total speech bits". The number of bits is divided by 8 and then
rounded up to get the number of consumed octets.
An AMR SID frame (including STI and MI) takes up 39 bits, this will
result in 5 octets, not in 7. Lets correct this.
Related: OS#2978
Change-Id: Icf330450981b32be5d1cee5b10aa92bac4cb72f5
We don't want to expose the details of a given ECU implementation to
the user (e.g. osmo-bts), but have a generic abstraction layer where
an ECU implementation can simply register a few call-back functions
with the generic core.
As the developer and copyright holder of the related code, I hereby
state that any ECU implementation using 'struct osmo_ecu_ops' and
registering with the 'osmo_ecu_register()' function shall not be
considered as a derivative work under any applicable copyright law;
the copyleft terms of GPLv2 shall hence not apply to any such ECU
implementation.
The intent of the above exception is to allow anyone to combine
third party Error Concealment Unit implementations with libosmocore,
including but not limited to such published by ETSI.
Change-Id: I4d33c9c7c2d4c7462ff38a49c178b65accae1915
As stated in its own documentation, reduce_xmaxcr_all() should only
return true when ALL XMAXC fields return true. However, previous
implementation returned true when at least one of them returned true.
As a result, if any of the sections is silent (for instance because one
of the bursts was lost), the whole frame is silenced, returning a zeroed buffer.
Related: OS#2700
Fixes: 40def49ac4 ("libosmocodec: implement ECU (Error Concealment Unit) for FR")
Change-Id: I1624b7c6574f53d0593a61645d4fdc5d56cabe96
When a bad GSM voice frame is received, it's being replaced
by a silence frame. This may cause unpleasant audio effects.
This change implements a functionality to craft a replacement
frame from the last known good frame. Currently, only FR is
supported, support for other codecs may be added latter.
Change-Id: I06a21f60db01bfe1c2b838f93866fad1d53fdcd1
Let's fix some erroneous/accidential references to wrong license,
update copyright information where applicable and introduce a
SPDX-License-Identifier to all files.
Change-Id: I39af26c6aaaf5c926966391f6565fc5936be21af
Considering the various styles and implications found in the sources, edit
scores of files to follow the same API doc guidelines around the doxygen
grouping and the \file tag.
Many files now show a short description in the generated API doc that was so
far only available as C comment.
The guidelines and reasoning behind it is documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation
In some instances, remove file comments and add to the corresponding group
instead, to be shared among several files (e.g. bitvec).
Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
Especially for short descriptions, it is annoying to have to type \brief for
every single API doc.
Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes
the first sentence of an API doc as the brief description.
Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
failure to do so would prevent the compiler from catching
inconsistencies between declaration and definition.
Change-Id: I88617c97adcff328292e501fd5d254eeae96a660
Based on ETSI TS 101 318 section 5.1.2 the 95 bits SID code word
is not detected correctly due to a wrongful offset in the bits
location indexes.
Change-Id: I45d98c6edf267f313883503a65385190ffbc65ca
In tightly embedded builds (--enable-embedded), we want the ability to
replace talloc with a very simple heap allocator to avoid the complexity
of talloc without modifying all our code that assumes talloc.
This will break the hierarchical notion of the allocator, but
libosmo{core,gsm,coding,codec} don't rely on that anyway.
Change-Id: Ie341034076f242a813f081919dd09d845775ad35
* update debian/changelog
* update TODO-RELEASE
* add comments to Makefile.am and TODO-RELEASE to simplify the process
in future
* add link to libtool docs to Makefile.am to simplify LIBVERSION
maintenance
Related: OS#1861
Change-Id: I22c257e357f597519120232d742d6a61289db021
Check that RTP payload we're about to decode is not NULL and return
proper error code instead of segfaulting. Add corresponding test case.
Change-Id: Ib6cda9900a41ed16bbfbde9df3de9d38e0a7469b
Fixes the following bug:
CCLD libosmocodec.la
Undefined symbols for architecture x86_64:
"_bitvec_get_bit_pos", referenced from:
_osmo_fr_check_sid in gsm610.o
"_bitvec_get_uint", referenced from:
_osmo_hr_check_sid in gsm620.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libosmocodec.la] Error 1
Change-Id: Id7358b94e274b529a8da38a0b2ef8c892b6dd7a5
Add functions which check if given FR or HR frame (packed in RTP)
contains SID (SIlence Descriptor) and corresponding tests.
Related: OS#22
Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca
Reviewed-on: https://gerrit.osmocom.org/160
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* add functions to encode/decode various codec paramters from RTP payload with
AMR frame according to RFC 4867
* those functions are extended version based on code from osmo-bts'
amr.c by Andreas Eversberg
* add corresponding enum types and strings for logging
* add regression tests
It's useful both to replace manual parsing in osmo-bts with fuctions
covered by test suite and as a debugging helpers for issues related to
AMR.
Change-Id: Ia217679a07d3fbc970f435e20f6eac33d34bd597
Related: OS#1562
Reviewed-on: https://gerrit.osmocom.org/118
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Only the Gb library relies on having undefined references to a
symbol that needs to be provided by the host application. For
all other libraries we can link with -no-undefined.
Seems the script I used to parse those had a bug where range of
bits in the 'decreasing' direction ( like 6..0 ) were not processed
properly.
Thanks to Andreas for noticing this !
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This actually allows for the user to override the decision and at the
same time supports compilers that might not be able to use -fPIC at
all.
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
When declaring them constant, they are written on the .rodata section
instead of .data, which means that they can be mapped directly from
disk to memory.
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>