[S] Change in osmo-bts[master]: all models, HR1 codec: accept both TS101318 and RFC5993 formats

Attention is currently required from: laforge, pespin, dexter. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32968 ) Change subject: all models, HR1 codec: accept both TS101318 and RFC5993 formats ...................................................................... Patch Set 3: (1 comment) File src/common/rtp_input_preen.c: https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/03dd81c6_2277301b PS3, Line 93: return PL_DECISION_STRIP_HDR_OCTET; When a GSM MS generates a SID frame during DTXu silence, or when a network transcoder configured to prepare a frame stream for DTXd does the same, that 112-bit frame begins its life as a perfect or pristine SID: 79 bits of the SID marker field set to all ones, plus 33 bits of comfort noise parameters. However, per GSM 06.41 (DTX spec for HR) receivers are required to recognize not only such perfect error-free SID frames, but also ones that have been corrupted with some bit errors, classifying them as either valid or invalid SID. A frame classified as valid-SID is used as a source of CN params; if a received frame is classified as invalid SID, no CN params are taken from it, but knowing that it was meant to be SID, the prescribed Rx DTX handler treats it differently from regular BFI conditions (total absence of a frame). In the classic E1 Abis architecture the BTS performs ternary SID classification (valid SID, invalid SID or non-SID) of received UL frames and sends the resulting classification decision to the TRAU in out-of-band bits, outside the 112-bit frame itself. All 3 TS 101 318 RTP formats (FR, EFR and HR) got rid of TRAU-frame-like out-of-band flag bits, causing pain and misery for those who like the classic architecture and seek to fully recreate it over IP RAN. With FR and EFR the workaround is to have the RTP packet recipient reconstruct SID classification status from the payload using osmo_{fr,efr}_sid_classify() - the computation rules are fixed in the DTX specs for FR and EFR. But the DTX spec for HR differs in that the exact rules for classifying a received radio frame as valid SID, invalid SID or non-SID are left up to BTS implementation - hence we really need to have the UL handler in the BTS make this determination and then propagate it out-of-band. The ToC octet of RFC 5993 brings back this E1 Abis-originating out-of-band SID indication, albeit with a defect: the official word of this RFC disallows invalid SID frames, only valid SID or non-SID. In the E1 Abis world SID=0 means non-SID speech, SID=1 means invalid SID and SID=2 means valid SID. RFC 5993 defines FT=0 as non-SID speech, FT=2 as SID (implied valid), and leaves FT=1 as reserved. When I reach the point of implementing this functionality (as part of OS#6036, *after* the present patch series has been merged), I am thinking of extending "rtp hr-format" vty option to allow a third state of rfc5993-ext beyond rfc5993 and ts101318; rfc5993-ext will allow sending out "obvious" but non-standard extensions to RFC 5993 such as FT=1 meaning invalid SID. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32968 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e Gerrit-Change-Number: 32968 Gerrit-PatchSet: 3 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Thu, 25 May 2023 18:26:23 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <falcon(a)freecalypso.org> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment