lists.osmocom.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

gerrit-log

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
gerrit-log@lists.osmocom.org

March 2025

  • 1 participants
  • 1378 discussions
[M] Change in osmo-bsc[master]: nokia_site: add function to unlock and reset TRXes
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: csaba.sipos. laforge has posted comments on this change by csaba.sipos. ( https://gerrit.osmocom.org/c/osmo-bsc/+/39652?usp=email ) Change subject: nokia_site: add function to unlock and reset TRXes ...................................................................... Patch Set 5: Code-Review+1 (1 comment) Commit Message: https://gerrit.osmocom.org/c/osmo-bsc/+/39652/comment/a336befb_eb6b8ffd?usp… : PS5, Line 15: confgiured locked configured -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/39652?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I9042a1e24f0932a23a26185181481db2ceddbb7c Gerrit-Change-Number: 39652 Gerrit-PatchSet: 5 Gerrit-Owner: csaba.sipos <metro4(a)freemail.hu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Attention: csaba.sipos <metro4(a)freemail.hu> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:15:27 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes
1 0
0 0
[S] Change in libosmo-sigtran[master]: default_lm_fsm: Trigger ASP restart by disconnecting the stream
by pespin 03 Mar '25

03 Mar '25
pespin has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/39635?usp=email ) ( 1 is the latest approved patch-set. No files were changed between the latest approved patch-set and the submitted one. )Change subject: default_lm_fsm: Trigger ASP restart by disconnecting the stream ...................................................................... default_lm_fsm: Trigger ASP restart by disconnecting the stream Previous behavior was to restart the ASP top-to-bottom in the stack, which doesn't play well with the disconnect_cb(). For instance, upon LM FSM timer callback, osmo_ss7_asp_restart() would call osmo_stream_cli_open() which in turn would call osmo_stream_close(). As a result, in that code path events were being sent to the LM FSM itself notifying the disconnection of the SCTP conn, which in turn would call osmo_ss7_asp_restart() again, and everything ended up in a weird state where it couldn't create sockets properly. The better approach is to, from LM FSM, trigger disconnection of the SCTP conn, which will in turn, through disconnect_cb(), send the SCTP disconnect notification up the stack, which should then trigger re-establishment of the SCTP conn in the SCTP client case. Change-Id: I21ebc3cd716a0bcc74da0a789032570f038e119d --- M src/xua_default_lm_fsm.c 1 file changed, 6 insertions(+), 6 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, approved laforge: Looks good to me, but someone else must approve osmith: Looks good to me, but someone else must approve diff --git a/src/xua_default_lm_fsm.c b/src/xua_default_lm_fsm.c index 7c27b19..fc01605 100644 --- a/src/xua_default_lm_fsm.c +++ b/src/xua_default_lm_fsm.c @@ -207,7 +207,7 @@ /* we have been waiting for the ASP to come up, but it * failed to do so */ LOGPFSML(fi, LOGL_NOTICE, "Peer didn't send any ASP_UP in time! Restarting ASP\n"); - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); break; case SS7_ASP_LM_T_WAIT_NOTIFY: if (lmp->asp->cfg.quirks & OSMO_SS7_ASP_QUIRK_NO_NOTIFY) { @@ -226,7 +226,7 @@ as = find_first_as_in_asp(lmp->asp); if (!as) { LOGPFSML(fi, LOGL_ERROR, "Unable to find AS!\n"); - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); return 0; } /* Fill in settings from first AS (TODO: multiple AS support) */ @@ -237,11 +237,11 @@ case SS7_ASP_LM_T_WAIT_NOTIY_RKM: /* No AS has reported via NOTIFY even after dynamic RKM * configuration */ - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); break; case SS7_ASP_LM_T_WAIT_RK_REG_RESP: /* timeout of registration of routing key */ - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); break; } return 0; @@ -285,12 +285,12 @@ oxp = data; if (oxp->u.rk_reg.status != M3UA_RKM_REG_SUCCESS) { LOGPFSML(fi, LOGL_NOTICE, "Received RKM_REG_RSP with negative result\n"); - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); } else { unsigned long timeout_sec; rc = handle_reg_conf(fi, oxp->u.rk_reg.key.l_rk_id, oxp->u.rk_reg.key.context); if (rc < 0) - restart_asp(fi); + ss7_asp_disconnect_stream(lmp->asp); /* RKM registration was successful, we can transition to WAIT_NOTIFY * state and assume that an NOTIFY/AS-INACTIVE arrives within * T_WAIT_NOTIFY_RKM seconds */ -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/39635?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: libosmo-sigtran Gerrit-Branch: master Gerrit-Change-Id: I21ebc3cd716a0bcc74da0a789032570f038e119d Gerrit-Change-Number: 39635 Gerrit-PatchSet: 3 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
1 0
0 0
[XS] Change in libosmo-netif[master]: cosmetic: add .gitignore to utils
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: falconia, pespin. laforge has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39653?usp=email ) Change subject: cosmetic: add .gitignore to utils ...................................................................... Patch Set 1: Code-Review-1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39653?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: I5fd24c19b00f3ea3a18d30d6ee1ccb621c28434c Gerrit-Change-Number: 39653 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:14:45 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes
1 0
0 0
[XS] Change in libosmo-netif[master]: cosmetic: add .gitignore to utils
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: falconia, pespin. laforge has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/libosmo-netif/+/39653?usp=email ) Change subject: cosmetic: add .gitignore to utils ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > I would like to raise the concern here that we usually put everything in the . […] I agree with pau here. -- To view, visit https://gerrit.osmocom.org/c/libosmo-netif/+/39653?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: libosmo-netif Gerrit-Branch: master Gerrit-Change-Id: I5fd24c19b00f3ea3a18d30d6ee1ccb621c28434c Gerrit-Change-Number: 39653 Gerrit-PatchSet: 1 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: falconia <falcon(a)freecalypso.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:14:38 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
1 0
0 0
[XS] Change in libosmo-abis[master]: rtp2trau FR & EFR: disallow BFI in DL
by laforge 03 Mar '25

03 Mar '25
laforge has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39625?usp=email ) Change subject: rtp2trau FR & EFR: disallow BFI in DL ...................................................................... rtp2trau FR & EFR: disallow BFI in DL osmo_rtp2trau() accepts TW-TS-001 extended RTP payload format for FR and EFR, converting to either TRAU-DL or TRAU-UL. This extended format is required for TRAU-UL/TFO frame output, but it is also accepted for conversion to TRAU-DL in order to support the current form of OsmoMGW-E1 that has no TFO transform between RTP input and TDM-timed calls to osmo_rtp2trau(). TW-TS-001 can represent not only good frames, but also bad ones - however, bad frames on Abis are valid only in UL, not in DL. Prior to the present patch, if a BFI-marked frame were fed to osmo_rtp2trau() for conversion to TRAU-DL, the Bad Frame Indicator was dropped and the garbage payload bits were emitted as if they were a good frame - bad choice. Reject BFI frames in TRAU-DL mode, return -EINVAL. Change-Id: Ic63943d4bde9902b27e4d8fe9a5fb6ccecbf36c6 --- M src/trau/trau_rtp_conv.c 1 file changed, 9 insertions(+), 0 deletions(-) Approvals: laforge: Looks good to me, but someone else must approve Jenkins Builder: Verified pespin: Looks good to me, approved diff --git a/src/trau/trau_rtp_conv.c b/src/trau/trau_rtp_conv.c index 158a555..d795947 100644 --- a/src/trau/trau_rtp_conv.c +++ b/src/trau/trau_rtp_conv.c @@ -586,6 +586,10 @@ if ((data[0] & 0xF0) != 0xD0) return -EINVAL; + /* bad frames are only allowed in UL */ + if (bfi && tf->dir != OSMO_TRAU_DIR_UL) + return -EINVAL; + tf->type = OSMO_TRAU16_FT_FR; /* FR Data Bits according to TS 48.060 Section 5.5.1.1.2 */ @@ -1002,6 +1006,10 @@ if ((data[0] & 0xF0) != 0xC0) return -EINVAL; + /* bad frames are only allowed in UL */ + if (bfi && tf->dir != OSMO_TRAU_DIR_UL) + return -EINVAL; + tf->type = OSMO_TRAU16_FT_EFR; /* FR Data Bits according to TS 48.060 Section 5.5.1.1.2 */ @@ -1674,6 +1682,7 @@ * - RTP payload formats of RFC 5993, TW-TS-001 and TW-TS-002 are accepted * by the function - however, all metadata flags carried by the header octet * of these extended formats are ignored/dropped in the DL direction. + * BFI frames are not allowed in DL. * * - The most native RTP input formats for conversion to TRAU-DL are those * defined in ETSI TS 101 318 for FR, HR and EFR; the ones for FR and EFR -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39625?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ic63943d4bde9902b27e4d8fe9a5fb6ccecbf36c6 Gerrit-Change-Number: 39625 Gerrit-PatchSet: 3 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>
1 0
0 0
[S] Change in libosmo-abis[master]: rtp2trau HR to DL: validate ToC octet of RFC 5993
by laforge 03 Mar '25

03 Mar '25
laforge has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39626?usp=email ) Change subject: rtp2trau HR to DL: validate ToC octet of RFC 5993 ...................................................................... rtp2trau HR to DL: validate ToC octet of RFC 5993 This validation serves two purposes: * Payloads that just happen to be 15 bytes long but aren't valid RFC 5993 should be rejected; * Super-5993 extensions of TW-TS-002 are valid only in UL, not in DL - catch and block them. Change-Id: Ibbaa1e1e12254eaf75a999dd1b58e2145eff158c --- M src/trau/trau_rtp_conv.c 1 file changed, 26 insertions(+), 1 deletion(-) Approvals: laforge: Looks good to me, but someone else must approve pespin: Looks good to me, approved Jenkins Builder: Verified diff --git a/src/trau/trau_rtp_conv.c b/src/trau/trau_rtp_conv.c index d795947..8307112 100644 --- a/src/trau/trau_rtp_conv.c +++ b/src/trau/trau_rtp_conv.c @@ -660,6 +660,27 @@ case GSM_HR_BYTES: break; case GSM_HR_BYTES_RTP_RFC5993: + /* Require RFC 5993 valid frame, i.e., no BFIs etc. + * The ToC octet which we need to check has this format: + * + * +----+----+----+----+----+----+----+----+ + * |0x80| 0x70 |0x08|0x04|0x02|0x01| hex mask + * +----+----+----+----+----+----+----+----+ + * | F | FT | R | R | R | R | meaning + * +----+----+----+----+----+----+----+----+ + * (RFC 5993 Figure 3, converted from big-endian bit numbers + * to hex masks) + * + * We would like to enforce this condition: + * + * (F==0 && (FT==0 || FT==2)) + * + * Masking with 0xD0 is the most efficient way to perform + * the desired check: we accept either 0x00 or 0x20 in the + * upper nibble, and anything in the lower nibble. + */ + if (data[0] & 0xD0) + return -EINVAL; data++; data_len--; break; @@ -815,6 +836,10 @@ case GSM_HR_BYTES: break; case GSM_HR_BYTES_RTP_RFC5993: + /* Require RFC 5993 valid frame, i.e., no BFIs etc. + * See rtp2trau_hr16() above for explanation. */ + if (data[0] & 0xD0) + return -EINVAL; data++; data_len--; break; @@ -1688,7 +1713,7 @@ * defined in ETSI TS 101 318 for FR, HR and EFR; the ones for FR and EFR * are also duplicated in RFC 3551. In the case of HR codec, RFC 5993 input * is also appropriate as specified in 3GPP TS 48.103 - as long as the user - * remembers that the extra header octet is ignored. + * remembers that the extra header octet is ignored beyond validation check. * * - The only correct way to implement TrFO for GSM, accepting FR/HR/EFR from * call leg A uplink in TW-TS-001 or TW-TS-002 format and generating TRAU-DL -- To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/39626?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ibbaa1e1e12254eaf75a999dd1b58e2145eff158c Gerrit-Change-Number: 39626 Gerrit-PatchSet: 4 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>
1 0
0 0
[M] Change in libosmo-abis[master]: rtp2trau: remove broken acceptance of 0-length payloads
by laforge 03 Mar '25

03 Mar '25
laforge has submitted this change. ( https://gerrit.osmocom.org/c/libosmo-abis/+/39624?usp=email ) 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(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, but someone else must approve laforge: Looks good to me, approved diff --git a/src/trau/trau_rtp_conv.c b/src/trau/trau_rtp_conv.c index 867a4e4..158a555 100644 --- a/src/trau/trau_rtp_conv.c +++ b/src/trau/trau_rtp_conv.c @@ -580,18 +580,11 @@ data_len--; } - /* now we must have either standard FR or no-data input */ - switch (data_len) { - case GSM_FR_BYTES: - if ((data[0] & 0xF0) != 0xD0) - return -EINVAL; - break; - case 0: - bfi = true; - break; - default: + /* with or without TW-TS-001 TEH, we require 260-bit GSM-FR payload */ + if (data_len != GSM_FR_BYTES) return -EINVAL; - } + if ((data[0] & 0xF0) != 0xD0) + return -EINVAL; tf->type = OSMO_TRAU16_FT_FR; @@ -606,34 +599,20 @@ tf->c_bits[3] = 1; tf->c_bits[4] = 0; } else { /* DL */ - if (data_len == 0) { - /* C1 .. C5: idle speech */ - tf->c_bits[0] = 0; - tf->c_bits[1] = 1; - tf->c_bits[2] = 1; - tf->c_bits[3] = 1; - tf->c_bits[4] = 0; - } else { - /* C1 .. C5: FR DL */ - tf->c_bits[0] = 1; - tf->c_bits[1] = 1; - tf->c_bits[2] = 1; - tf->c_bits[3] = 0; - tf->c_bits[4] = 0; - } + /* C1 .. C5: FR DL */ + tf->c_bits[0] = 1; + tf->c_bits[1] = 1; + tf->c_bits[2] = 1; + tf->c_bits[3] = 0; + tf->c_bits[4] = 0; } memset(&tf->c_bits[5], 0, 6); /* C6 .. C11: Time Alignment */ if (tf->dir == OSMO_TRAU_DIR_UL) { tf->c_bits[11] = bfi; /* C12: BFI */ - if (data_len == 0) { - tf->c_bits[12] = 0; /* C13: SID=0 */ - tf->c_bits[13] = 0; /* C14: SID=0 */ - } else { - /* SID classification per GSM 06.31 section 6.1.1 */ - sidc = osmo_fr_sid_classify(data); - tf->c_bits[12] = (sidc >> 1) & 1; /* C13: msb */ - tf->c_bits[13] = (sidc >> 0) & 1; /* C14: lsb */ - } + /* SID classification per GSM 06.31 section 6.1.1 */ + sidc = osmo_fr_sid_classify(data); + tf->c_bits[12] = (sidc >> 1) & 1; /* C13: msb */ + tf->c_bits[13] = (sidc >> 0) & 1; /* C14: lsb */ tf->c_bits[14] = taf; /* C15: TAF (SACCH or not) */ tf->c_bits[15] = 1; /* C16: spare */ tf->c_bits[16] = dtxd; /* C17: DTXd applied or not */ @@ -648,12 +627,6 @@ memset(&tf->c_bits[17], 1, 4); /* C18 .. C21: spare */ memset(&tf->t_bits[0], 1, 4); - if (!data_len) { - /* idle speech frame if DL, BFI speech frame if UL */ - memset(&tf->d_bits[0], 1, 260); - return 0; - } - /* reassemble d-bits */ i = 0; /* counts bits */ j = 4; /* counts input bits */ @@ -686,9 +659,6 @@ data++; data_len--; break; - case 0: - /* accept no-data input */ - break; default: return -EINVAL; } @@ -715,10 +685,7 @@ memset(tf->c_bits+17, 1, 4); /* C18..C21: spare */ memset(&tf->t_bits[0], 1, 4); tf->ufi = 1; /* spare bit in TRAU-DL */ - if (data_len) - osmo_pbit2ubit(tf->d_bits, data, GSM_HR_BYTES * 8); - else - memset(tf->d_bits, 0, GSM_HR_BYTES * 8); + osmo_pbit2ubit(tf->d_bits, data, 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); @@ -847,9 +814,6 @@ data++; data_len--; break; - case 0: - /* accept no-data input */ - break; default: return -EINVAL; } @@ -884,10 +848,7 @@ memset(&tf->t_bits[0], 1, 2); - if (data_len) - osmo_pbit2ubit(tf->d_bits, data, GSM_HR_BYTES * 8); - else - memset(tf->d_bits, 0, GSM_HR_BYTES * 8); + osmo_pbit2ubit(tf->d_bits, data, 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); @@ -1035,52 +996,30 @@ data_len--; } - /* now we must have either standard EFR or no-data input */ - switch (data_len) { - case GSM_EFR_BYTES: - if ((data[0] & 0xF0) != 0xC0) - return -EINVAL; - break; - case 0: - bfi = true; - break; - default: + /* with or without TW-TS-001 TEH, we require 244-bit GSM-EFR payload */ + if (data_len != GSM_EFR_BYTES) return -EINVAL; - } + if ((data[0] & 0xF0) != 0xC0) + return -EINVAL; tf->type = OSMO_TRAU16_FT_EFR; /* FR Data Bits according to TS 48.060 Section 5.5.1.1.2 */ /* set c-bits and t-bits */ - if (data_len == 0 && tf->dir == OSMO_TRAU_DIR_DL) { - /* C1 .. C5: idle speech */ - tf->c_bits[0] = 0; - tf->c_bits[1] = 1; - tf->c_bits[2] = 1; - tf->c_bits[3] = 1; - tf->c_bits[4] = 0; - } else { - /* C1 .. C5: EFR */ - tf->c_bits[0] = 1; - tf->c_bits[1] = 1; - tf->c_bits[2] = 0; - tf->c_bits[3] = 1; - tf->c_bits[4] = 0; - } - + /* C1 .. C5: EFR */ + tf->c_bits[0] = 1; + tf->c_bits[1] = 1; + tf->c_bits[2] = 0; + tf->c_bits[3] = 1; + tf->c_bits[4] = 0; memset(&tf->c_bits[5], 0, 6); /* C6 .. C11: Time Alignment */ if (tf->dir == OSMO_TRAU_DIR_UL) { tf->c_bits[11] = bfi; /* C12: BFI */ - if (data_len == 0) { - tf->c_bits[12] = 0; /* C13: SID=0 */ - tf->c_bits[13] = 0; /* C14: SID=0 */ - } else { - /* SID classification per GSM 06.81 section 6.1.1 */ - sidc = osmo_efr_sid_classify(data); - tf->c_bits[12] = (sidc >> 1) & 1; /* C13: msb */ - tf->c_bits[13] = (sidc >> 0) & 1; /* C14: lsb */ - } + /* SID classification per GSM 06.81 section 6.1.1 */ + sidc = osmo_efr_sid_classify(data); + tf->c_bits[12] = (sidc >> 1) & 1; /* C13: msb */ + tf->c_bits[13] = (sidc >> 0) & 1; /* C14: lsb */ tf->c_bits[14] = taf; /* C15: TAF (SACCH or not) */ tf->c_bits[15] = 1; /* C16: spare */ tf->c_bits[16] = dtxd; /* C17: DTXd applied or not */ @@ -1096,12 +1035,6 @@ memset(&tf->c_bits[17], 1, 4); /* C18 .. C21: spare */ memset(&tf->t_bits[0], 1, 4); - if (data_len == 0) { - /* idle speech frame if DL, BFI speech frame if UL */ - memset(&tf->d_bits[0], 1, 260); - return 0; - } - /* reassemble d-bits */ tf->d_bits[0] = 1; for (i = 1, j = 4; i < 39; i++, j++) @@ -1753,17 +1686,6 @@ * frames for call leg B, is to apply the TFO transform of TS 28.062 section * C.3.2.1.1, then feed the output of that transform to the present function. * - * - The provision whereby a zero-length RTP payload is not treated as an error - * like other invalid RTP inputs, but is converted to an idle speech frame - * in TRAU-DL output should be considered a bogon. This condition never - * occurs when the just-mentioned TFO transform is applied immediately prior - * to TRAU-DL output, nor does it ever occur in the original GSM architecture - * where the TRAU either free-runs a speech encoder or applies the same TFO - * transform - hence it is unlikely to be handled well by real E1 BTSes. - * Furthermore, this code path in libosmotrau is currently broken (the - * intended idle speech frame gets turned into a "regular" but invalid FR/EFR - * speech frame) and should be considered for removal. - * * Considerations for TRAU-UL output: * * - For FR and EFR codecs, the only correct RTP format for conversion to -- 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: merged Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee Gerrit-Change-Number: 39624 Gerrit-PatchSet: 3 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>
1 0
0 0
[M] Change in libosmo-abis[master]: rtp2trau: remove broken acceptance of 0-length payloads
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: dexter, falconia, fixeria, pespin. laforge 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 3: Code-Review+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: comment Gerrit-Project: libosmo-abis Gerrit-Branch: master Gerrit-Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee Gerrit-Change-Number: 39624 Gerrit-PatchSet: 3 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: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:13:48 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes
1 0
0 0
[M] Change in libosmo-sigtran[master]: Make sure to NOTIFY current state to peer after ASP UP ACK / REG RESP
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: pespin. laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/39640?usp=email ) Change subject: Make sure to NOTIFY current state to peer after ASP UP ACK / REG RESP ...................................................................... Patch Set 5: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/39640?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: I3dffa2e9c554f03c7c721b757ff33a89961665b5 Gerrit-Change-Number: 39640 Gerrit-PatchSet: 5 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:13:06 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes
1 0
0 0
[S] Change in libosmo-sigtran[master]: xua_rkm: Make sure existing AS gets added in list to receive ASP-INAC...
by laforge 03 Mar '25

03 Mar '25
Attention is currently required from: pespin. laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/libosmo-sigtran/+/39639?usp=email ) Change subject: xua_rkm: Make sure existing AS gets added in list to receive ASP-INACTIVE.ind event ...................................................................... Patch Set 3: Code-Review+1 -- To view, visit https://gerrit.osmocom.org/c/libosmo-sigtran/+/39639?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: I85948ab98623a8a53521eb2d2e84244011b39a93 Gerrit-Change-Number: 39639 Gerrit-PatchSet: 3 Gerrit-Owner: pespin <pespin(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Mon, 03 Mar 2025 16:12:04 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • ...
  • 138
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.