February 2025 - gerrit-log - lists.osmocom.org

[M] Change in libosmo-abis[master]: TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE

by laforge

Attention is currently required from: falconia. laforge has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39643?usp=email ) Change subject: TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39643?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ibcc9e8628a56c6f089264c9d6b0dd27a1d5a7b60 Gerrit-Change-Number: 39643 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Fri, 28 Feb 2025 08:54:22 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k

by laforge

Attention is currently required from: falconia. laforge has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email ) Change subject: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: I1c19592967e7c6becc710990f512da5dee5043d2 Gerrit-Change-Number: 39642 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Fri, 28 Feb 2025 08:54:08 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE

by falconia

falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39643?usp=email ) Change subject: TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE ...................................................................... TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE GSM 08.60 sections 3.4 and 3.5.5 (renumbered to 5.4 and 5.5.5 in 3GPP TS 48.060) define a special frame type called Idle Speech Frame. It is not clear if any historical BSS vendor actually implemented these special frames - Nokia documentation explicitly mentions how they were deemed unnecessary and omitted from implementation - but libosmotrau includes support for this frame type. Looking at the referenced spec sections, we can see the designers' intent: the idle speech frame is just like FRv1 speech frames, but with different UL/DL frame type codes in C1..C5 and with all Dn bits replaced with constant-1 filler. Following this design intent on the part of GSM spec authors, the philophically correct behavior for osmo_trau_frame_encode() with regard to this frame type should be to handle it exactly the same as OSMO_TRAU16_FT_FR (support both DL and UL output, timing alignment in DL, possibility of changing C6..C21 and T-bits), but don't look at fr->d_bits[], fill constant 1s in their place instead. However, the behavior of the encoding function for this frame type prior to the present change was not like this at all: instead it would emit a constant (once and for all) frame of 320 bits that was always for DL no matter which direction was requested, would not allow time alignment, and would not allow any C-bits to be controlled by upper layers. At the present time there is no code anywhere in Osmocom that feeds OSMO_TRAU16_FT_IDLE to osmo_trau_frame_encode() - thus we don't have to maintain backward bug compatibility, and we can fix this design bug. Change-Id: Ibcc9e8628a56c6f089264c9d6b0dd27a1d5a7b60 --- M src/trau/trau_frame.c 1 file changed, 23 insertions(+), 44 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmo-abis refs/changes/43/39643/1 diff --git a/src/trau/trau_frame.c b/src/trau/trau_frame.c index fb98247..74f4526 100644 --- a/src/trau/trau_frame.c +++ b/src/trau/trau_frame.c @@ -522,52 +522,31 @@ return 0; } -static struct osmo_trau_frame fr_idle_frame = { - .type = OSMO_TRAU16_FT_IDLE, - .dir = OSMO_TRAU_DIR_DL, - .t_bits = { 1, 1, 1, 1 }, -}; -#define TRAU_FRAME_BITS (40*8) -static ubit_t encoded_idle_frame[TRAU_FRAME_BITS]; -static int dbits_initted = 0; - -/*! \brief return pointer to global buffer containing a TRAU idle frame */ -static ubit_t *trau_idle_frame(void) -{ - /* only initialize during the first call */ - if (!dbits_initted) { - /* set all D-bits to 1 */ - memset(&fr_idle_frame.d_bits, 0x01, 260); - - memset(&fr_idle_frame.c_bits, 0x01, 25); /* spare are set to 1 */ - /* set Downlink Idle Speech Frame pattern */ - fr_idle_frame.c_bits[0] = 0; /* C1 */ - fr_idle_frame.c_bits[1] = 1; /* C2 */ - fr_idle_frame.c_bits[2] = 1; /* C3 */ - fr_idle_frame.c_bits[3] = 1; /* C4 */ - fr_idle_frame.c_bits[4] = 0; /* C5 */ - /* set no Time Alignment pattern */ - fr_idle_frame.c_bits[5] = 0; /* C6 */ - fr_idle_frame.c_bits[6] = 0; /* C7 */ - fr_idle_frame.c_bits[7] = 0; /* C8 */ - fr_idle_frame.c_bits[8] = 0; /* C9 */ - fr_idle_frame.c_bits[9] = 0; /* C10 */ - fr_idle_frame.c_bits[10] = 0; /* C11 */ - /* already set to 1, but maybe we need to modify it in the future */ - fr_idle_frame.c_bits[11] = 1; /* C12 (UFE), good frame */ - fr_idle_frame.c_bits[15] = 1; /* C16 (SP), no DTX */ - - encode16_fr(encoded_idle_frame, &fr_idle_frame, false); - dbits_initted = 1; /* set it to 1 to not call it again */ - } - return encoded_idle_frame; -} - /* TS 08.60 Section 3.4 */ static int encode16_idle(ubit_t *trau_bits, const struct osmo_trau_frame *fr) { - memcpy(trau_bits, trau_idle_frame(), 40*8); - return 40 * 8; + const ubit_t *cbits5; + + if (fr->dir == OSMO_TRAU_DIR_UL) + cbits5 = ft_idle_up_bits; + else + cbits5 = ft_idle_down_bits; + + encode_sync16(trau_bits); + + /* C1 .. C5 */ + memcpy(trau_bits + 17, cbits5 + 0, 5); + /* C6 .. C15 */ + memcpy(trau_bits + 17 + 5, fr->c_bits + 5, 15 - 5); + /* all 1s in the place of D-bits */ + memset(trau_bits + 32, 1, 310 - 32); + /* C16 .. C21 */ + memcpy(trau_bits + 310, fr->c_bits + 15, 6); + /* T1 .. T4 */ + memcpy(trau_bits + 316, fr->t_bits, 4); + + /* handle timing adjustment */ + return encode16_handle_ta(trau_bits, fr); } /* TS 08.60 Section 3.3.1 */ @@ -1276,12 +1255,12 @@ case OSMO_TRAU16_FT_EFR: case OSMO_TRAU16_FT_HR: case OSMO_TRAU16_FT_AMR: + case OSMO_TRAU16_FT_IDLE: /* timing alignment may happen: increased space requirement */ if (n_bits < 2 * 40 * 8 - 1) return -ENOSPC; break; case OSMO_TRAU16_FT_OAM: - case OSMO_TRAU16_FT_IDLE: case OSMO_TRAU16_FT_DATA_HR: case OSMO_TRAU16_FT_DATA: case OSMO_TRAU16_FT_D145_SYNC: -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39643?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ibcc9e8628a56c6f089264c9d6b0dd27a1d5a7b60 Gerrit-Change-Number: 39643 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org>

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: rtp2trau: remove broken acceptance of 0-length payloads

by pespin

Attention is currently required from: dexter, falconia, fixeria, laforge. pespin has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39624?usp=email ) Change subject: rtp2trau: remove broken acceptance of 0-length payloads ...................................................................... Patch Set 2: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39624?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee Gerrit-Change-Number: 39624 Gerrit-PatchSet: 2 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Thu, 27 Feb 2025 23:04:15 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k

by pespin

Attention is currently required from: falconia. pespin has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email ) Change subject: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k ...................................................................... Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: I1c19592967e7c6becc710990f512da5dee5043d2 Gerrit-Change-Number: 39642 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Comment-Date: Thu, 27 Feb 2025 23:02:48 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: rtp2trau: remove broken acceptance of 0-length payloads

by falconia

Attention is currently required from: dexter, falconia, fixeria, laforge. Hello Jenkins Builder, dexter, fixeria, laforge, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/libosmo-abis/+/39624?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Code-Review+1 by laforge, Verified+1 by Jenkins Builder Change subject: rtp2trau: remove broken acceptance of 0-length payloads ...................................................................... rtp2trau: remove broken acceptance of 0-length payloads Since the beginning of osmo_rtp2trau() in 2020, this API accepted 0-length RTP payloads for FR, HR and EFR, for both TRAU-DL and TRAU-UL output. However, this "support" never worked correctly: * For FR & EFR in DL direction, previous patch 1d42fcd4ea40 attempted to emit the idle speech frame of TS 48.060 section 5.4, following sections 6.5.2 and 6.5.3 of the same spec. However, the actual combination of osmo_rtp2trau() followed by osmo_trau_frame_encode() resulted in an invalid FR/EFR TRAU-DL frame being emitted, rather than the intended special idle speech frame. * For FR & EFR in UL direction, the same previous patch would turn 0-length payload input (or TW-TS-001 No_Data input with later patches) into BFI with a peculiar fill pattern. The fill pattern was all-1s in the case of FR or all-1s plus bad CRC in the case of EFR. (The 5 CRCs of EFR TRAU frame format just happen to come out bad when all Dn bits are set to 1 - not intentional CRC inversion.) TRAU-UL output is not currently used anywhere in Osmocom; there is a plan to implement TFO in ThemWi software using Osmocom libraries, but that plan does NOT include No_Data input to osmo_rtp2trau(). * For HR speech to TRAU-DL conversion, the effect of 0-length payload input was emission of a TRAU-DL frame that looks valid, but has all 112 bits of payload set to 0, with correct CRC. All-zeros is a poor choice of LPC parameter fill for dummy GSM-HR codec frames, but the bigger issue is consistency with FR/EFR: while it would be trivial to change the fill pattern to the recently added osmo_gsm620_silence_frame[], if we are removing support for NULL input to osmo_rtp2trau() in the case of FR and EFR, it would be pointless to support such operation just for HR. Because fixing the case of NULL or No_Data input for {FR,EFR}->TRAU would entail more complexity and rather arbitrary decision-making in the library that better belongs in applications (see below), let's take the Alexandrian solution to this Gordian Knot: simply remove all bogo-support for 0-length RTP payload input to osmo_rtp2trau() in the case of speech codecs, and return -EINVAL just like for all other types of invalid RTP input. Effect on OsmoMGW-E1: the only time when OsmoMGW could pass a 0-length payload to osmo_rtp2trau() would be if the RTP stream comes from OsmoBTS (not from another leg on OsmoMGW-E1) with vty option 'rtp continuous-streaming' enabled. Prior to the present patch, the resulting effect would be bogus output on Abis DL; after this patch, the MGW behavior will be the same as with no RTP input - the MGW will insert fixed fill frames at the application level, going directly to I.460 mux. Further notes: * If someone does wish to emit the idle speech frame of TS 48.060 section 5.4 on Abis DL, despite the observation that historical TRAUs never emit such frames and the uncertainty of how E1 BTS would handle such strangeness, they can use osmo_trau_frame_encode() directly, without going through osmo_rtp2trau() - trivial as there is no payload in need of conversion. * In the realm of TRAU-UL output (TFO or emulation of E1 BTS), every time a BFI frame is emitted, _some_ payload bit pattern is required: there is no provision for No_Data frames in FR/EFR TRAU/TFO frame format. Selecting one particular fill bit pattern to be "special" in that the library fills it in when the application passed NULL or No_Data is philosophically wrong: no one bit pattern is any more special than any other in this situation. Historical E1 BTS most commonly use the buffer method: they maintain an internal buffer into which new channel-decoded frames are written, and during No_Data conditions (FACCH stealing), the previous buffer content is repeated, perhaps corrupted in some peculiar way. The same approach is recommended for applications that need to transform from RTP to TRAU-UL/TFO output - but this buffer clearly belongs in the application, not in the library. * For HR codec, there is currently no fully working support for it in Osmocom - or more precisely, the combination of OsmoBSC+OsmoMGW has no working HR support with E1 BTS. Therefore, there are no backward compatibility concerns, and we still have the freedom to change the behavior of TRAU<->RTP library functions to make it more sensible. Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee --- M src/trau/trau_rtp_conv.c 1 file changed, 30 insertions(+), 108 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmo-abis refs/changes/24/39624/2 -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39624?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee Gerrit-Change-Number: 39624 Gerrit-PatchSet: 2 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de>

4 months

1
0
0 0

[M] Change in libosmo-abis[master]: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k

by falconia

falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email ) Change subject: rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k ...................................................................... rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k GSM 08.61 defines two TRAU frame formats for HRv1 codec, using either 16 kbit/s or 8 kbit/s submultiplexing. The 8k format is the one actually implemented in legacy E1 BTS hardware, and is also needed for global interoperability in TFO - whereas HR-16k TRAU frame format appears to be a paper-only spec that was never implemented in any hardware. Despite the lack of hardware implementations, support for TRAU-16k format for GSM-HR is already present in libosmotrau, originally implemented along with FR and EFR. Removing this support from Osmocom would look bad (there is always that off-chance that perhaps some BSS vendor did implement this format after all), hence let us do the next best thing: bring TRAU-16k support into alignment with the actually working TRAU-8k support for the same codec. Thanks to previous clean-up patches in this area, rtp2trau support for GSM-HR TRAU-DL output was already fully consistent between 16k and 8k formats, but TRAU-UL output code was wildly inconsistent. TRAU-8k-UL output code is new, takes TW-TS-002 input and can be used to implement TFO (primary intended use) or emulate an E1 BTS. However, previous TRAU-16k-UL output code dates back to the initial creation of TRAU<->RTP code in 2020, has never been updated until now, and is woefully inadequate for the task of emulating an E1 BTS. (Because TFO always uses 8k format for HRv1, software emulation of an E1 BTS is the only remaining plausible application for GSM-HR TRAU-16k-UL output.) With the present patch, the behavior of osmo_rtp2trau() for OSMO_TRAU16_FT_HR UL changes drastically: TS 101 318 input is no longer accepted, RFC 5993 input is still accepted but is not functionally complete, and the proper/expected input format becomes TW-TS-002, of which RFC 5993 is a subset. However, the detailed behavior of osmo_rtp2trau() for HRv1 codec is now exactly the same between 8k and 16k formats, in both DL and UL directions. Change-Id: I1c19592967e7c6becc710990f512da5dee5043d2 --- M src/trau/trau_rtp_conv.c 1 file changed, 128 insertions(+), 47 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmo-abis refs/changes/42/39642/1 diff --git a/src/trau/trau_rtp_conv.c b/src/trau/trau_rtp_conv.c index d5ac1fa..867a4e4 100644 --- a/src/trau/trau_rtp_conv.c +++ b/src/trau/trau_rtp_conv.c @@ -676,7 +676,7 @@ return 0; } -static int rtp2trau_hr16(struct osmo_trau_frame *tf, const uint8_t *data, size_t data_len) +static int rtp2trau_hr16_dl(struct osmo_trau_frame *tf, const uint8_t *data, size_t data_len) { /* accept both TS 101 318 and RFC 5993 payloads */ switch (data_len) { @@ -695,57 +695,26 @@ tf->type = OSMO_TRAU16_FT_HR; - if (tf->dir == OSMO_TRAU_DIR_UL) { - /* C1 .. C5 */ - tf->c_bits[0] = 0; - tf->c_bits[1] = 0; - tf->c_bits[2] = 0; - tf->c_bits[3] = 1; - tf->c_bits[4] = 1; - } else { - /* C1 .. C5 */ - tf->c_bits[0] = 1; - tf->c_bits[1] = 1; - tf->c_bits[2] = 1; - tf->c_bits[3] = 0; - tf->c_bits[4] = 1; - } + /* C1 .. C5 */ + tf->c_bits[0] = 1; + tf->c_bits[1] = 1; + tf->c_bits[2] = 1; + tf->c_bits[3] = 0; + tf->c_bits[4] = 1; /* C6.. C11: Time Alignment */ memset(tf->c_bits + 5, 0, 6); - if (tf->dir == OSMO_TRAU_DIR_UL) { - /* BFI */ - if (data_len == 0) - tf->c_bits[11] = 1; - else - tf->c_bits[11] = 0; - if (osmo_hr_check_sid(data, data_len)) { - /* SID=2 is a valid SID frame */ - tf->c_bits[12] = 1; - tf->c_bits[13] = 0; - } else { - tf->c_bits[12] = 0; - tf->c_bits[13] = 0; - } - /* FIXME: C15: TAF */ + tf->c_bits[11] = 1; /* C12: UFE */ + tf->c_bits[12] = 1; /* C13: spare */ + tf->c_bits[13] = 1; /* C14: spare */ + tf->c_bits[14] = 1; /* C15: spare */ + if (osmo_hr_check_sid(data, data_len)) tf->c_bits[15] = 0; /* C16: SP */ - tf->c_bits[16] = 0; /* C17: DTXd shall not be applied */ - } else { - tf->c_bits[11] = 1; /* C12: UFE */ - tf->c_bits[12] = 1; /* C13: spare */ - tf->c_bits[13] = 1; /* C14: spare */ - tf->c_bits[14] = 1; /* C15: spare */ - if (osmo_hr_check_sid(data, data_len)) - tf->c_bits[15] = 0; /* C16: SP */ - else - tf->c_bits[15] = 1; /* C16: SP */ - tf->c_bits[16] = 1; /* C17: spare */ - } + else + tf->c_bits[15] = 1; /* C16: SP */ + tf->c_bits[16] = 1; /* C17: spare */ memset(tf->c_bits+17, 1, 4); /* C18..C21: spare */ memset(&tf->t_bits[0], 1, 4); - if (tf->dir == OSMO_TRAU_DIR_UL) - tf->ufi = 0; - else - tf->ufi = 1; + tf->ufi = 1; /* spare bit in TRAU-DL */ if (data_len) osmo_pbit2ubit(tf->d_bits, data, GSM_HR_BYTES * 8); else @@ -756,6 +725,118 @@ return 0; } +static int rtp2trau_hr16_ul(struct osmo_trau_frame *tf, const uint8_t *data, size_t data_len) +{ + uint8_t ft; + enum osmo_gsm631_sid_class sidc; + bool data_bits_req, bfi; + + /* In TRAU-UL direction we require/expect TW-TS-002 RTP payload format; + * RFC 5993 is also accepted because it is a subset of TW-TS-002. + * TS 101 318 input is not supported for TRAU-UL output! */ + if (data_len < 1) + return -EINVAL; + ft = data[0] >> 4; + switch (ft) { + case FT_GOOD_SPEECH: + bfi = false; + sidc = OSMO_GSM631_SID_CLASS_SPEECH; + data_bits_req = true; + break; + case FT_INVALID_SID: + /* There are 3 possible BFI/SID combinations in TRAU-16k-UL + * format for GSM-HR that all collapse to the same + * "invalid SID" code in TRAU-8k-UL and TW-TS-002 formats. + * Here we arbitrarily choose BFI=1 SID=1: compared to the + * other two options, this one has the greatest Hamming + * distance (in C-bits) to good speech or valid SID codes. + */ + bfi = true; + sidc = OSMO_GSM631_SID_CLASS_INVALID; + data_bits_req = false; + break; + case FT_GOOD_SID: + bfi = false; + sidc = OSMO_GSM631_SID_CLASS_VALID; + data_bits_req = true; + break; + case FT_BFI_WITH_DATA: + bfi = true; + sidc = OSMO_GSM631_SID_CLASS_SPEECH; + data_bits_req = true; + break; + case FT_NO_DATA: + bfi = true; + sidc = OSMO_GSM631_SID_CLASS_SPEECH; + data_bits_req = false; + break; + default: + return -EINVAL; + } + /* If the frame type is one that includes data bits, the payload length + * per RFC 5993 and TW-TS-002 is 15 bytes. If the frame type is one + * that does not include data bits, then the payload length per the + * same specs is only 1 byte - but we also accept 15-byte payloads + * in this case to make life easier for applications that pass the + * content of a buffer. + * + * When we make a TRAU-UL frame from FT=1 or FT=7, we fill all Dn bits + * with zeros if we got a short (1 byte) payload. However, if the + * application passed us a long (15 byte) payload despite FT being + * 1 or 7, we fill Dn bits with application-provided payload. + */ + switch (data_len) { + case GSM_HR_BYTES_RTP_RFC5993: + break; + case 1: + if (data_bits_req) + return -EINVAL; + break; + default: + return -EINVAL; + } + + tf->type = OSMO_TRAU16_FT_HR; + + /* C1 .. C5 */ + tf->c_bits[0] = 0; + tf->c_bits[1] = 0; + tf->c_bits[2] = 0; + tf->c_bits[3] = 1; + tf->c_bits[4] = 1; + /* C6.. C11: Time Alignment */ + memset(tf->c_bits + 5, 0, 6); + tf->c_bits[11] = bfi; /* C12: BFI */ + tf->c_bits[12] = (sidc >> 1) & 1; /* C13: SID msb */ + tf->c_bits[13] = (sidc >> 0) & 1; /* C14: SID lsb */ + tf->c_bits[14] = data[0] & 0x01; /* C15: TAF */ + tf->c_bits[15] = 1; /* C16: spare */ + tf->c_bits[16] = (data[0] & 0x08) >> 3; /* C17: DTXd */ + memset(tf->c_bits+17, 1, 4); /* C18..C21: spare */ + memset(&tf->t_bits[0], 1, 4); + tf->ufi = (data[0] & 0x02) >> 1; + if (data_len > 1) + osmo_pbit2ubit(tf->d_bits, data + 1, GSM_HR_BYTES * 8); + else + memset(tf->d_bits, 0, GSM_HR_BYTES * 8); + /* CRC is *not* computed by TRAU frame encoder - we have to do it */ + osmo_crc8gen_set_bits(&gsm0860_efr_crc3, tf->d_bits, 44, tf->crc_bits); + + return 0; +} + +static int rtp2trau_hr16(struct osmo_trau_frame *tf, const uint8_t *data, size_t data_len) +{ + switch (tf->dir) { + case OSMO_TRAU_DIR_DL: + return rtp2trau_hr16_dl(tf, data, data_len); + case OSMO_TRAU_DIR_UL: + return rtp2trau_hr16_ul(tf, data, data_len); + default: + return -EINVAL; + } +} + static int rtp2trau_hr8_dl(struct osmo_trau_frame *tf, const uint8_t *data, size_t data_len) { /* accept both TS 101 318 and RFC 5993 payloads */ -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39642?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: I1c19592967e7c6becc710990f512da5dee5043d2 Gerrit-Change-Number: 39642 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org>

4 months

1
0
0 0

[S] Change in libosmo-sigtran[master]: xua_rkm: Fix dynamic AS destroyed when multiple ASPs are associated

by pespin

Attention is currently required from: daniel, laforge, osmith. pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/39630?usp=email ) Change subject: xua_rkm: Fix dynamic AS destroyed when multiple ASPs are associated ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > can we please also add a (TTCN3?) test case for this scenario? Yes, I'm currently adding some tests to validate dynamic ASP/AS/RKM in osmo-stp. For now, this will be needed in osmo-ttcn3: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/39641 -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/39630?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-sigtran Gerrit-Branch: master Gerrit-Change-Id: I986044944282cea9a13ed59424f2220fee6fe567 Gerrit-Change-Number: 39630 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: daniel <dwillmann(a)sysmocom.de> Gerrit-Comment-Date: Thu, 27 Feb 2025 18:39:55 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge(a)osmocom.org>

4 months

1
0
0 0

[L] Change in libosmo-sigtran[master]: AS loadsharing: Introduce combined_linkset

by pespin

pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/38731?usp=email ) Change subject: AS loadsharing: Introduce combined_linkset ...................................................................... Patch Set 7: (1 comment) Patchset: PS7: Marking ASP/AS loadsharing patchset as WIP since I'm still doing some testing, and I submitted another patchset with fixes for unrealted (to the feature) issues I found during setting up a test env. -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/38731?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-sigtran Gerrit-Branch: master Gerrit-Change-Id: I500ec74ba975e3c93071771027e4e5fe6000e6f3 Gerrit-Change-Number: 38731 Gerrit-PatchSet: 7 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Comment-Date: Thu, 27 Feb 2025 18:37:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

4 months

1
0
0 0

[M] Change in osmo-ttcn3-hacks[master]: stp: Allow setting up different m3ua_config list by test

by pespin

Attention is currently required from: daniel, fixeria, laforge, osmith. pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/39641?usp=email ) Change subject: stp: Allow setting up different m3ua_config list by test ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: I'm already using this for a couple new tests I'm still pollishing which allow testing dynamic ASP/AS/RKM in STP_Tests_M3UA -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/39641?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I0a875bac5e9506be9140d5afa28da25bdc99a5a6 Gerrit-Change-Number: 39641 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de> Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-CC: Jenkins Builder Gerrit-Attention: osmith <osmith(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: daniel <dwillmann(a)sysmocom.de> Gerrit-Comment-Date: Thu, 27 Feb 2025 18:35:24 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

4 months

1
0
0 0

2025

2024

2023

2022

gerrit-log February 2025