[M] Change in osmo-bts[master]: TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2

Attention is currently required from: pespin, dexter. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32714 ) Change subject: TCH DL, FR & EFR: reshape SIDs per 06.31/06.81 section 5.1.2 ...................................................................... Patch Set 4: (2 comments) File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/143d3069_e4e06b00 PS3, Line 1441: if (!resp_msg && lchan->tch.dtx_fr_efr.last_rtp_input_was_sid && @dexter - sure, let's factor it out. I shall prepare another patchset with two static functions factored out: one for SID analysis of just-received RTP frames, and the other for the decision & transformation logic. File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/32714/comment/6d9e7c6b_0d7e4c76 PS4, Line 1393: * until OS#5688 is resolved. */ It looks like I need to change that comment and include a longer explanation of why I am not supporting HR1 yet. OS#5688 is one part of the problem, but the other (big) part of the problem is that we don't have a function like osmo_{fr,efr}_sid_classify() for HR1. For FR and EFR I am able to make care-free use of simple osmo_{fr,efr}_check_sid() functions only because in an earlier commit we added calls to osmo_{fr,efr}_sid_preen() into the code path that happens just before the present step, and after these preening functions the codec frame can only be either non-SID speech or a perfect error-free SID - the preening functions clean up other possibilities. And those preening functions are in turn based on osmo_{fr,efr}_sid_classify(). Why can't we simply add a SID classification function for HR1 just like I did for FR and EFR? The fundamental problem is that unlike 06.31 and 06.81, the GSM 06.41 spec for HR DTX does NOT prescribe a fixed set of rules for valid and invalid SID classification - instead it is left up to the discretion of channel decoder (!) implementors. In the original E1 Abis architecture the "SID class" ternary flag would travel (as two out-of-band control bits) along with the data bits in TRAU frames, hence only the entity that does the lowest-level channel decoding gets to decide exactly which rules to apply - and all downstream entities follow what those two out-of-band bits say. In the case of TFO calls the TFO block in the downstream TRAU would look at the SID class bits passed inside TFO frames from the upstream TRAU - but with our RTP-based TrFO taking the place of T1/E1 TFO, those original SID class bits are lost. I plan on covering this topic in June OsmoDevCall. Until then we can either merge the patch adding proper FR & EFR handling while leaving HR1 as a FIXME for other/later developers, or we could postpone merging of this patch until we thoroughly talk about this entire topic in June. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32714 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5 Gerrit-Change-Number: 32714 Gerrit-PatchSet: 4 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-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 17 May 2023 15:26:51 +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> Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de> Gerrit-MessageType: comment