falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/33081 )
Change subject: HR1 codec: validate ToC header in RFC5993 RTP input
......................................................................
HR1 codec: validate ToC header in RFC5993 RTP input
osmo-bts-trx always accepted (and previously required) HR1 codec RTP
input in RFC 5993 format; currently we accept this RTP format as
input for all BTS models, but no longer require it. However, we
have never applied any checks to this format's ToC header, even
when we previously required it in osmo-bts-trx. Check this header
and reject invalid payloads that just happen to have the same octet
length as valid ones.
Change-Id: If16d38641913bb46bcd7cc11685407ed17136bfe
---
M src/common/rtp_input_preen.c
1 file changed, 31 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/81/33081/1
diff --git a/src/common/rtp_input_preen.c b/src/common/rtp_input_preen.c
index e5cef6f..dd526fd 100644
--- a/src/common/rtp_input_preen.c
+++ b/src/common/rtp_input_preen.c
@@ -89,6 +89,20 @@
/* RTP input matches our internal format - we are good */
return PL_DECISION_ACCEPT;
case GSM_HR_BYTES_RTP_RFC5993:
+ /* Validate ToC octet: for payload of this length to be valid,
+ * the F bit must be 0 and the FT field must be either 0 (good
+ * speech) or 2 (good SID). */
+ switch (rtp_pl[0] & 0xF0) {
+ case 0x00:
+ break;
+ case 0x20:
+ /* TODO (next patch): signal this SID to the
+ * fr_hr_efr_dtxd_input() handler in l1sap. */
+ break;
+ default:
+ /* invalid payload */
+ return PL_DECISION_DROP;
+ }
/* Strip ToC octet, leaving only "pure" TS 101 318 payload. */
return PL_DECISION_STRIP_HDR_OCTET;
default:
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/33081
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: If16d38641913bb46bcd7cc11685407ed17136bfe
Gerrit-Change-Number: 33081
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-MessageType: newchange
falconia has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-bts/+/33082 )
Change subject: HR1 codec: act on SID indication in RFC5993 RTP input
......................................................................
HR1 codec: act on SID indication in RFC5993 RTP input
Suppose we receive RTP from the uplink of another BTS, and the
UL-handling BTS has channel-decoded an HR1 frame which it deems
(per GSM 06.41 section 6.1.1) to be a valid SID, even though it is
not a perfect, error-free SID. How will this SID frame be
represented in RFC 5993 transport? My reading of the RFC tells me
that the UL-handling BTS will need to apply an operation like our
osmo_hr_sid_reset() to the payload before sending it out in RTP -
but because the text of the RFC does not explicitly address this
scenario, others may have interpreted it differently.
If we receive an RFC 5993 RTP payload in which FT is set to 2,
indicating good SID, but the actual HR payload is not a perfect SID
(the SID field is not all 1s), the only reasonable interpretation
of such occurrence is that the sender of this payload was another
BTS whose implementors interpreted the RFC as not requiring them
to rejuvenate the SID codeword prior to RTP output. Therefore, let's
treat such payloads as valid SID for our DTXd logic, and rejuvenate
the SID codeword ourselves.
Change-Id: Ife00de6220a8ca7cc180a61734497f1acb7f5b83
---
M include/osmo-bts/msg_utils.h
M include/osmo-bts/rtp_input_preen.h
M src/common/l1sap.c
M src/common/rtp_input_preen.c
4 files changed, 52 insertions(+), 10 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/82/33082/1
diff --git a/include/osmo-bts/msg_utils.h b/include/osmo-bts/msg_utils.h
index 7ddbe88..fb8e11a 100644
--- a/include/osmo-bts/msg_utils.h
+++ b/include/osmo-bts/msg_utils.h
@@ -22,6 +22,9 @@
/* Access 3rd part of msgb control buffer */
#define rtpmsg_ts(x) ((x)->cb[2])
+/* Access 4th part of msgb control buffer */
+#define rtpmsg_is_rfc5993_sid(x) ((x)->cb[3])
+
/**
* Classification of OML message. ETSI for plain GSM 12.21
* messages and IPA/Osmo for manufacturer messages.
diff --git a/include/osmo-bts/rtp_input_preen.h b/include/osmo-bts/rtp_input_preen.h
index 822ee4a..744ae2a 100644
--- a/include/osmo-bts/rtp_input_preen.h
+++ b/include/osmo-bts/rtp_input_preen.h
@@ -17,4 +17,4 @@
enum pl_input_decision
rtp_payload_input_preen(struct gsm_lchan *lchan, const uint8_t *rtp_pl,
- unsigned rtp_pl_len);
+ unsigned rtp_pl_len, bool *rfc5993_sid_flag);
diff --git a/src/common/l1sap.c b/src/common/l1sap.c
index 75177a5..9d824e3 100644
--- a/src/common/l1sap.c
+++ b/src/common/l1sap.c
@@ -1314,9 +1314,17 @@
* directly coupled to the GSM 05.03 channel decoder,
* and cannot be reconstructed downstream from frame
* payload bits. The only kind of SID we can detect
- * here is the perfect, error-free kind. */
- is_sid = osmo_hr_check_sid(msgb_l2(resp_msg),
- msgb_l2len(resp_msg));
+ * here is the perfect, error-free kind. However,
+ * if we received RFC 5993 payload and the sender
+ * told us it is valid SID, honor that indication
+ * and rejuvenate the SID codeword. */
+ if (rtpmsg_is_rfc5993_sid(resp_msg)) {
+ is_sid = true;
+ osmo_hr_sid_reset(msgb_l2(resp_msg));
+ } else {
+ is_sid = osmo_hr_check_sid(msgb_l2(resp_msg),
+ msgb_l2len(resp_msg));
+ }
}
break;
case GSM48_CMODE_SPEECH_EFR:
@@ -2152,6 +2160,7 @@
{
struct gsm_lchan *lchan = rs->priv;
struct msgb *msg;
+ bool rfc5993_sid = false;
/* if we're in loopback mode, we don't accept frames from the
* RTP socket anymore */
@@ -2159,7 +2168,7 @@
return;
/* initial preen */
- switch (rtp_payload_input_preen(lchan, rtp_pl, rtp_pl_len)) {
+ switch (rtp_payload_input_preen(lchan, rtp_pl, rtp_pl_len, &rfc5993_sid)) {
case PL_DECISION_DROP:
return;
case PL_DECISION_ACCEPT:
@@ -2184,6 +2193,8 @@
rtpmsg_seq(msg) = seq_number;
/* Store RTP header Timestamp in control buffer */
rtpmsg_ts(msg) = timestamp;
+ /* Store RFC 5993 SID flag likewise */
+ rtpmsg_is_rfc5993_sid(msg) = rfc5993_sid;
/* make sure the queue doesn't get too long */
lchan_dl_tch_queue_enqueue(lchan, msg, 1);
diff --git a/src/common/rtp_input_preen.c b/src/common/rtp_input_preen.c
index dd526fd..c418e80 100644
--- a/src/common/rtp_input_preen.c
+++ b/src/common/rtp_input_preen.c
@@ -82,7 +82,8 @@
}
static enum pl_input_decision
-input_preen_hr(const uint8_t *rtp_pl, unsigned rtp_pl_len)
+input_preen_hr(const uint8_t *rtp_pl, unsigned rtp_pl_len,
+ bool *rfc5993_sid_flag)
{
switch (rtp_pl_len) {
case GSM_HR_BYTES:
@@ -96,8 +97,7 @@
case 0x00:
break;
case 0x20:
- /* TODO (next patch): signal this SID to the
- * fr_hr_efr_dtxd_input() handler in l1sap. */
+ *rfc5993_sid_flag = true;
break;
default:
/* invalid payload */
@@ -113,7 +113,7 @@
enum pl_input_decision
rtp_payload_input_preen(struct gsm_lchan *lchan, const uint8_t *rtp_pl,
- unsigned rtp_pl_len)
+ unsigned rtp_pl_len, bool *rfc5993_sid_flag)
{
/* If rtp continuous-streaming is enabled, we shall emit RTP packets
* with zero-length payloads as BFI markers. In a TrFO scenario such
@@ -132,7 +132,7 @@
if (lchan->type == GSM_LCHAN_TCH_F)
return input_preen_fr(rtp_pl, rtp_pl_len);
else
- return input_preen_hr(rtp_pl, rtp_pl_len);
+ return input_preen_hr(rtp_pl, rtp_pl_len, rfc5993_sid_flag);
case GSM48_CMODE_SPEECH_EFR:
return input_preen_efr(rtp_pl, rtp_pl_len);
case GSM48_CMODE_SPEECH_AMR:
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/33082
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ife00de6220a8ca7cc180a61734497f1acb7f5b83
Gerrit-Change-Number: 33082
Gerrit-PatchSet: 1
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/33069 )
Change subject: trx TCH DL: transmit invalid speech frames instead of dummy FACCH
......................................................................
Patch Set 2:
(1 comment)
File src/osmo-bts-trx/sched_lchan_tchf.c:
https://gerrit.osmocom.org/c/osmo-bts/+/33069/comment/b91a508f_5ab629a6
PS1, Line 500: what is the correct BTS Tx behavior for frame
: * gaps in TCH/AFS
> I just suggested a possible solution seeing a FIXME comment in your patch. […]
I hear you - I just don't have the needed AMR expertise to implement proper BFI transmission for AMR like I just did for FR/HR/EFR. Given that no other developers are stepping up right this minute to fix the issue for AMR, it looks like we need to leave it as a FIXME, to be revisited by later developers who care about AMR and have the necessary work-queue priority for it. It could even be me at a much later time, if and when I have the time allocation to get into AMR.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/33069
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I78106802a0aa4af39859c75d29fe0e77037899fe
Gerrit-Change-Number: 33069
Gerrit-PatchSet: 2
Gerrit-Owner: falconia <falcon(a)freecalypso.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Mon, 29 May 2023 19:26:16 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: falconia <falcon(a)freecalypso.org>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment