Attention is currently required from: jolly, laforge, fixeria, dexter.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/31417 )
Change subject: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload
......................................................................
Patch Set 8:
(3 comments)
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/df6fc162_d2a603aa
PS8, Line 1244: static bool rtppayload_is_valid(struct gsm_lchan *lchan, struct msgb *resp_msg)
if this is expected to be used only for incoming DL packets we forward to lower layers towards the MS, we should really make this function name more descriptive. Because with current name it really looks like it could be used in any direction.
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/ba4ca3e6_53682eed
PS8, Line 1274: /* BTS flags specify that RFC 5993 (and not ETSI TS 101.318) is understood by lower layers */
All this code block below you are writing can iiuc be simplified to:
if (resp_msg->len == GSM_HR_BYTES_RTP_RFC5993)
return rfc5993;
if (resp_msg->len == GSM_HR_BYTES_RTP_TS101318)
return ts101318;
return false;
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/89f8f043_35819518
PS8, Line 1952: * formats are supported (either by setting both or none of the flags), no conversion will be carried out. */
we don't care about "both formats being supported". We care about the received format being supported.
BTW, what's the point of checking the supported formats in rtppayload_is_valid() if we are anyway converting them here to whatever the supported format is? What am I missing?
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/31417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I453562da412fde5b928bd2b588129c58ec8e2a7e
Gerrit-Change-Number: 31417
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
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, 04 May 2023 16:00:34 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: jolly, laforge, fixeria, dexter.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/31417 )
Change subject: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload
......................................................................
Patch Set 8:
(1 comment)
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/83d976b8_6e0c796b
PS7, Line 1274: if (OSMO_UNLIKELY(rfc5993 && (resp_msg->len != GSM_HR_BYTES_RTP_RFC5993))) {
> (The function rtppayload_is_valid sits in the RTP receiving path) […]
>> in case both or none of the flags are set both encodings are recognized as valid formats.
Are we talking about Schrödinger's cat format here? I don't really want to enter this kind of philosophical topics when looking at code. Make it so that if the flag is set, the BTS lower layers support that format; if not set, it doesn't support it.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/31417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I453562da412fde5b928bd2b588129c58ec8e2a7e
Gerrit-Change-Number: 31417
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
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, 04 May 2023 15:51:46 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: jolly, laforge, pespin, fixeria.
dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/31417 )
Change subject: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload
......................................................................
Patch Set 8:
(7 comments)
Patchset:
PS7:
> I'm sorry but after a more detailed look, I'm really struggling with this patch. […]
I hope it is less confusing now.
It is correct that the flags refer to RTP receiving and sending but in this patch we only care about the path that receives RTP packets. The path that sends RTP packets must be handled in a follow up patch.
DL: that is correct. In addition to that we also have rtppayload_is_valid() as a gatekeeper to ensure invalid packets are not forwarded to lower layers.
UL: that is not in the scope of this patch, it will be added in a follow up patch.
File include/osmo-bts/bts.h:
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/5e5c80ee_0d292e8b
PS7, Line 69: /* Whether the BTS model uses HR GSM RTP payload in RFC 5993 format */
> To me this would be "Whether the BTS model supports sending ..." […]
(see my other comments, I hope this is clear now.)
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/b5402a08_22e74794
PS6, Line 1940: if (lchan->type == GSM_LCHAN_TCH_H && rtp_pl_len == GSM_HR_BYTES
> please break each condition into one line with uniform formatting.
The lines are much shorter now, I think we do not have to break the lines now.
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/a2faa838_ab48ec48
PS6, Line 1950: } else if (lchan->type == GSM_LCHAN_TCH_H && rtp_pl_len == GSM_HR_BYTES + 1
> The GSM_HR_BYTES_RTP_ constants should be in libosmocore. […]
Done
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/c85625da_11518e5f
PS7, Line 1271: bool rfc5993 = bts_internal_flag_get(lchan->ts->trx->bts, BTS_INTERNAL_FLAG_SPEECH_H_V1_RTP_RFC5993);
> the description said the internal flag is about "sending", but iiuc you are using it here to decide […]
As far as I am aware the flag description says only "uses". Which refers to what the hardware supports (this includes sending and receiving), however in the scope of this patch we only care about which RTP payload format the hardware understands.
The comment above says "sending" which is indeed a bit misleading. Let's better use the term "forwarding".
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/976c91a2_e9ebbf45
PS7, Line 1274: if (OSMO_UNLIKELY(rfc5993 && (resp_msg->len != GSM_HR_BYTES_RTP_RFC5993))) {
> so if the BTS supports rfc5993 (sending, receving, whatever, see previous comment), then you check t […]
(The function rtppayload_is_valid sits in the RTP receiving path)
I probably get now where the confusion is coming from. My idea about the flags was to express a preference. In case both formats are supported none of the two flags would be set. (no check would be carried out, which is probably also not so good)
That might be indeed confusing but we can fix this, in case both or none of the flags are set both encodings are recognized as valid formats. I also added a check so that we check with both length if we support both formats.
https://gerrit.osmocom.org/c/osmo-bts/+/31417/comment/6a7490ee_0531f2d6
PS7, Line 1280: LOGPLCHAN(lchan, DL1P, LOGL_NOTICE,
> There's no need for the "else" here, it is guaranteed by the early return in the previous if.
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/31417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I453562da412fde5b928bd2b588129c58ec8e2a7e
Gerrit-Change-Number: 31417
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 04 May 2023 15:43:20 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: jolly, laforge, pespin, fixeria.
Hello Jenkins Builder, jolly, laforge, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-bts/+/31417
to look at the new patch set (#8).
Change subject: l1sap: Accept RFC5993 and TS 101.318 HR GSM payload
......................................................................
l1sap: Accept RFC5993 and TS 101.318 HR GSM payload
Unfotunately there are two different RTP formats for HR GSM specified
and it is unclear which should be used with GSM networks. Also esch BTS
model may have a preference for either one or the other format.
Lets set BTS feature flags to determine the preference for each BTS model
and then lets use this information to convert incoming RTP packets into
the prefered format. Doing so we will make sure that always both formats
are accepted.
Change-Id: I453562da412fde5b928bd2b588129c58ec8e2a7e
Related: OS#5688
---
M include/osmo-bts/bts.h
M src/common/bts.c
M src/common/l1sap.c
M src/osmo-bts-lc15/main.c
M src/osmo-bts-oc2g/main.c
M src/osmo-bts-sysmo/main.c
M src/osmo-bts-trx/main.c
M src/osmo-bts-virtual/main.c
8 files changed, 102 insertions(+), 4 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/17/31417/8
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/31417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I453562da412fde5b928bd2b588129c58ec8e2a7e
Gerrit-Change-Number: 31417
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: newpatchset
dexter has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/32610 )
Change subject: l1sap: fix wording in comment
......................................................................
l1sap: fix wording in comment
The function rtppayload_is_valid() is called from the receiving RTP code
path. Lets use the word "forwarding" instead of "sending" to avoid the
impression something is sent (like sending RTP packets to the outside
world)
Change-Id: Ie7fcc53dea462b0d575b0c9ca73ba7507289eefe
---
M src/common/l1sap.c
1 file changed, 15 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/10/32610/1
diff --git a/src/common/l1sap.c b/src/common/l1sap.c
index 09e2d8c..a7eb830 100644
--- a/src/common/l1sap.c
+++ b/src/common/l1sap.c
@@ -1255,7 +1255,7 @@
if (resp_msg->len == 0)
return false;
- /* Avoid sending bw-efficient AMR to lower layers, most bts models
+ /* Avoid forwarding bw-efficient AMR to lower layers, most bts models
* don't support it. */
if (lchan->tch_mode == GSM48_CMODE_SPEECH_AMR &&
!rtppayload_is_octet_aligned(resp_msg->data, resp_msg->len)) {
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32610
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ie7fcc53dea462b0d575b0c9ca73ba7507289eefe
Gerrit-Change-Number: 32610
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: newchange
pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/libosmo-gprs/+/32608 )
Change subject: gmm: Fix false positive compilation error with gcc 13.1.1
......................................................................
gmm: Fix false positive compilation error with gcc 13.1.1
Newer gcc errors about "cause" being uninitialized, but cause is
guaranteed to be set in the "case GPRS_GMM_MS_EV_LOW_LVL_FAIL" path, it
just fails to find out.
Since the approach used previously is a bit hacky, let's simplify it.
Change-Id: I1c96b0aa92d4f9205a1d4d1760c787fe0e0ed169
---
M src/gmm/gmm_ms_fsm.c
1 file changed, 16 insertions(+), 4 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-gprs refs/changes/08/32608/1
diff --git a/src/gmm/gmm_ms_fsm.c b/src/gmm/gmm_ms_fsm.c
index 6f82815..f553ad3 100644
--- a/src/gmm/gmm_ms_fsm.c
+++ b/src/gmm/gmm_ms_fsm.c
@@ -102,7 +102,7 @@
static void st_gmm_ms_registered_initiated(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
struct gprs_gmm_ms_fsm_ctx *ctx = (struct gprs_gmm_ms_fsm_ctx *)fi->priv;
- uint8_t cause;
+ uint8_t cause = GMM_CAUSE_MAC_FAIL;
int rc;
struct gprs_gmm_ms_fsm_attach_ctx att;
@@ -120,9 +120,6 @@
memcpy(&att, &ctx->attach, sizeof(att));
gmm_ms_fsm_state_chg(fi, GPRS_GMM_MS_ST_DEREGISTERED);
- if (event == GPRS_GMM_MS_EV_LOW_LVL_FAIL)
- cause = GMM_CAUSE_MAC_FAIL;
-
if (att.explicit_att) {
/* Submit GMMREG-ATTACH-REJ as per TS 24.007 Annex C.1 */
rc = gprs_gmm_submit_gmmreg_attach_cnf(ctx->gmme, false, cause);
--
To view, visit https://gerrit.osmocom.org/c/libosmo-gprs/+/32608
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-gprs
Gerrit-Branch: master
Gerrit-Change-Id: I1c96b0aa92d4f9205a1d4d1760c787fe0e0ed169
Gerrit-Change-Number: 32608
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange