In the classic E1-based GSM architecture the counterpart condition to OsmoBTS lacking RTP input for DL would be the E1-based BTS receiving an idle speech frame of TS 48.060 section 5.4 (further detail in section 5.5.5) in the place of a valid speech frame (section 5.1) on Abis DL. TRAUs normally don't allow this condition to happen, even in TFO, at least per the spec. In the case of TFO (the codec frame stream ultimately comes from UL of call leg A that will contain BFIs) TS 28.062 section C.3.2.1.1 tells TRAU implementors to essentially replicate the logic of the Rx DTX handler, including both ECU and comfort noise generator parts, but I am very uncertain if real TRAU implementations actually do what that spec section says. (I repeat my solicitation for someone to connect a real historical T1/E1 TRAU to OCTOI so I can experiment with it remotely.) I am so uncertain about real TRAUs implementing the rules of C.3.2.1.1 in their entirety because although they are relatively easy to implement for FR and HR, doing the same for EFR seems insanely difficult to me. Hence I wonder if perhaps real implementations relax those rules a little at least for EFR, or maybe even for all 3 codecs. My idea of "relaxed" implementation is to forward non-DTX-related (not after SID) BFIs to call leg B by inducing a deliberate BFI condition on the DL (send an idle speech frame of TS 48.060 section 5.4), and in the case of SIDs in input do what I did in just-merged I924ab21952dcf8bb03ba7ccef790474bf66fc9e5. The advantage of this approach is that it's very easy to implement and works exactly the same for all 3 non-AMR codecs.
OK, so what does the BTS part of E1-based GSM architecture do when it receives an idle speech frame (missing frame indicator) on Abis DL? The answer to this question is also what our BTS models should do when they receive empty TCH.req from l1sap - our l1sap-to-model internal interface is logically equivalent to E1 Abis. Not having any E1 BTS hw to experiment with, I'll go with my intuition, which tells me that we should transmit a bit pattern that will not cause any errors in the MS at the level of convolutional decoding, but will induce a BFI condition in the Rx DTX handler. In the case of FR, HR and EFR codecs the easiest way to do so is to transmit a speech frame with inverted CRC3 at the GSM 05.03 encoding level, and this approach is also what sysmoBTS PHY does. I have a patch in review that implements this behavior in osmo-bts-trx:
https://gerrit.osmocom.org/c/osmo-bts/+/33069
I will be updating that patch to resolve the recently arisen merge conflict and to address review suggestions from fixeria, but the principal idea remains the same.
Please note, however, that my solution addresses FR, HR and EFR codecs only. What is the correct solution for AMR? Answer: I don't know. In case you haven't already figured out, I am the kind of developer who believes in doing things right, not a quick hack, and my current thorough understanding of FR, HR and EFR codecs is a result of having spent months studying the subject and getting hands-on experience implementing codec libraries, debug tools and a network edge transcoder to G.711 PSTN. I do not currently have the cycles to study AMR to the same level of depth, and thus my stance on AMR specifics will, for now, be to not initiate any behavioral changes to any Osmocom components in AMR modes and abstain from comment on AMR-specific parts of changes proposed by other developers.
