Changes

E1 cosmetic: reduce white space in hard-coded TRAU-DL frames

By changing the white space structure of these hard-coded frames
to only have one leading tab on each line of 8 frame bits, we make
it easier to replace these hard-coded frames with different versions
that are programmatically generated, as will be done in the following
patches.

Change-Id: I3d0c931d4dc3d916ba4c5eb081bea22d9c7144de

E1: replace idle_tf_efr[] with a better version

The only truly correct way to pass FR/HR/EFR traffic from an
incoming RTP stream to TRAU-DL frames is to apply the transform
of TS 28.062 section C.3.2.1.1, originally specified for TFO
but also necessary in the non-3GPP-specified case of GSM TrFO
as it happens here.  However, no FOSS or even published-source
implementation of TFO transform for EFR exists at the present time
(no implementations at all are known outside of TRAU DSP firmware),
hence the general architectural approach of OsmoMGW-E1, flawed
as it is, has to remain for now.  This flawed architecture consists
of passing through unaltered all valid codec frames that are
received in RTP, and inserting fixed dummy TRAU-DL frames when no
RTP-derived ones are available.

The original dummy TRAU-DL frame for EFR exhibited the following
defects:

* D1 bit was set to 0, even though TS 48.060 section 5.5.1.1.2
  states it shall be 1;

* All 5 EFR frame CRCs were invalid: each 3-bit CRC was 000, even
  though the correct TS 48.060 section 5.5.1.1.2 CRC from an
  all-zeros payload would be 111;

* Even if the 5 CRCs were fixed, transmitting an EFR frame of all
  zero bits to the MS won't produce good results - it is a bad
  choice of dummy filler;

* The setting of C-bits (defined in TS 48.060 section 5.5.1.1.1)
  was a mish-mash between TRAU-UL and TRAU-DL frame formats,
  thereby not matching the standard TRAU-DL C-bits fill produced
  by osmo_rtp2trau().

The replacement fill frame introduced here differs as follows:

* The payload bit content is the decoder homing frame (DHF) of
  TS 46.060 section 8.2 Table 7 - the best we can do in the absence
  of a proper TFO transform for EFR;

* The full TRAU-DL frame (C-bits, CRC etc) was generated by passing
  said EFR DHF through osmo_rtp2trau(), using this ad hoc tool:

https://gitea.osmocom.org/themwi/dummy-dl-frames

Change-Id: I5a33a1c9ddf1372f91870d61b5eafac4729ee458

E1: replace idle_tf_fr[] with a better version

The only truly correct way to pass FR/HR/EFR traffic from an
incoming RTP stream to TRAU-DL frames is to apply the transform
of TS 28.062 section C.3.2.1.1, originally specified for TFO
but also necessary in the non-3GPP-specified case of GSM TrFO
as it happens here.  Unlike the situation with EFR, a FOSS
implementation of TFO transform for FRv1 does exist in Themyscira
libgsmfr2 - however, making these Themyscira codec libraries
usable from mainline Osmocom programs by way of a proposed
libosmocore DSO plugin mechanism, followed by a major redesign
of OsmoMGW-E1 to pass all DL traffic through this TFO transform,
would be a major project, difficult to justify prior to development
of a proper TFO transform for EFR to complement the one for FRv1.
Hence no change is being made currently to the arguably flawed
general architecture of OsmoMGW-E1, which consists of passing
through unaltered all valid codec frames that are received in RTP,
and inserting fixed dummy TRAU-DL frames when no RTP-derived ones
are available.

The original dummy TRAU-DL frame for FRv1 exhibited the following
defects:

* The payload frame transmitted to the MS consisted of all zero
  bits.  Standard type-approved GSM MS would interpret this bit
  pattern as a SID frame, even though the BTS is told via C16 bit
  "this frame is not a SID".  Passing a SID is not inherently bad
  in itself in this context, but a SID with all LARc parameters
  set to 0 is a strange/poor choice.

* The setting of C-bits (defined in TS 48.060 section 5.5.1.1.1)
  was a mish-mash between TRAU-UL and TRAU-DL frame formats,
  thereby not matching the standard TRAU-DL C-bits fill produced
  by osmo_rtp2trau().

The replacement fill frame introduced here differs as follows:

* The payload bit content is the silence frame of GSM 46.011
  Table 1: certainly better than a SID with all LARc parameters
  set to 0, and arguably better than any SID at all.

* The full TRAU-DL frame (C-bits pattern, peculiar ordering of
  D-bits) was generated by passing said silence frame through
  osmo_rtp2trau(), using this ad hoc tool:

https://gitea.osmocom.org/themwi/dummy-dl-frames

Change-Id: I995824586058e4e4ed77e900d4b57e5113f9eff6