Changes

CSD: implement half-rate modes correctly

TCH/H4.8 and TCH/H2.4 modes are different from all other TCH in that
the channel coder runs (statistically) every 40 ms instead of the usual
20 ms.  However, the standard RTP interface of TS 48.103 still requires
20 ms packets for all CSD modes; furtherfore, this requirement is not
just a matter of 3GPP spec being obstinent, but is highly useful for
interoperability, both between FR and HR and between OsmoBTS and E1 BTS.

The handling of CSD HR was totally broken in this regard: wrong RA2
packing mode, RTP clock model was violated, and even an internal
mismatch with l1sap sending TCH.req prims at twice the rate
at which the PHY expects them.

With this patch CSD HR handling becomes correct for TCH/H2.4 and for
TCH/H4.8 transparent; fully correct handling for TCH/H4.8 NT will
appear in a follow-up patch.

The packet/frame rate mismatch (40 ms Rx/Tx times while each RTP packet
carries 20 ms worth of data) is reconciled by emitting two RTP packets
directly back-to-back for UL, and pulling two RTP packets at a time
from the Rx jitter buffer at the needed times for DL.

Note: due to bug OS#6604, TTCN3 tests for CSD half-rate transparent modes
will start failing once this patch is merged; to make them pass again,
TTCN3 test code will need to be reworked to fix that bug.

Related: OS#6577
Change-Id: Ib35e910df263743cd243f51fb0bd6551ddfcf4c5

csd_v110: set E2 bit correctly for TCH/[FH]4.8 NT

In all classic NT modes below 14.5 kbit/s, V.110 frame bits E2 and E3
are repurposed to indicate the alignment whereby a single 240-bit RLP
frame is composed of 4 pseudo-V.110 frames in switching transport.
(TS 48.020 section 15.1.)  In the case of TCH/F9.6, setting both E2
and E3 is easy because all 4 pseudo-V.110 frames go out in the same
clearmode RTP packet as a result of a single channel decoding
operation.  However, in the case of TCH/F4.8 there are two separate
channel decoding operations producing two separate RTP packets
20 ms apart.  Furthermore, GSM 05.03 section 3.4.1 specifies which
TDMA frame positions hold which half of the RLP frame - therefore,
the correct emission of bit E2 needs to be based on the TDMA frame
number at which the block was received.

A similar situation occurs with TCH/H4.8 NT: we receive a single
block from the 05.03 decoder every 40 ms, containing a full RLP frame,
but we emit it as two separate RTP packets, each carrying 20 ms worth
of bits.  These RTP packets also require correct setting of E2 bit.

Related: OS#6579
Change-Id: I485af5e01ea87c1721a298a486cd344a17884200

CSD RTP: verify alignment of V.110 frames

Since the beginning of CSD implementation, OsmoBTS has operated
with an implicit (unstated) policy that V.110 frames must be
perfectly aligned within received clearmode RTP packets - a requirement
which is NOT set anywhere in TS 48.103 or any of the other specs
it references.  This design policy is sensible from the standpoint
of implementation complexity (both OsmoBTS and osmo_trau2rtp emit
such perfectly aligned packets; if someone is building a gateway
between an Osmocom GSM network and ISDN-style external networks,
that gateway can act as the aligner), but it should be explicit
rather than implicit.

Check V.110 frame alignment in received clearmode RTP packets,
and reject packets that fail this alignment check.

Change-Id: Icd704dc7fa02e60074efc8a29ad7e42ebdf63783

csd_v110_rtp_decode: preserve E2 & E3 bits for RLP alignment

Modify CSD RTP input path code so incoming bits E2 & E3 from V.110
frames reach the TCH-RTS.ind handler in l1sap.  These bits will be
used in the next patch to ensure proper alignment of DL RLP frames
in non-transparent CSD modes.

Related: OS#6579
Change-Id: I43b97caa6030b9401779998ca5dddc4cfe636e2f

cosmetic: eliminate else-after-return in gsmtap_csd_rlp_process()

The code in this function used else-after-return constructs, which
are now rejected by the linter for newly committed code.  This
function needs to be moved to a new source file, which will cause
it to be treated as new code by the linter - hence fix this code
style issue first.

Change-Id: Ide00e819222bb0173eca42ee3714db7f7e1a6d1e

cosmetic: move gsmtap_csd_rlp_process() to csd_rlp.c

The next patch in the series will add code for alignment of downlink
RLP frames in CSD NT modes; that code will go into new file csd_rlp.c.
RLP GSMTAP code logically belongs in the same place - hence move it
there in preparation.

Change-Id: I824ce6614c8591cccc5f6bcdde767fe49d551378

CSD NT modes: transmit properly aligned RLP frames on DL

There are two levels of alignment inside clearmode RTP packets
carrying CSData per TS 48.103 section 5.6:

1) Alignment of 2 or 4 V.110 (T) or pseudo-V.110 (NT) frames within
   one RTP packet of 160 octets of an imaginary ISDN B channel;

2) For NT modes only, alignment of 4 pseudo-V.110 frames to form
   a single 240-bit RLP frame.

Per previous patch, alignment 1 is to be treated as mandatory for
RTP transport inside an Osmocom network.  Alignment 2 _could_ be
made mandatory for TCH/F9.6 NT, but the same is not possible for
TCH/[FH]4.8 NT: in the best case of half-alignment, alternating
RTP packets will carry alternating halves of RLP frames.

Implemented solution: allow arbitrary state of alignment 2
(aligned or misaligned) in the incoming RTP stream for all CSD NT
modes, and perform the necessary alignment internally.

This approach is consistent with the world of E1 BTS: a TRAU in
data mode is responsible for alignment 1 (with 20 ms TRAU frames
taking the place of our clearmode RTP packets), but only the BTS can
perform alignment 2, as the TRAU is agnostic to T vs NT distinction.

Related: OS#6579
Change-Id: Idaebfce6da13b23ba265a197502712d83991873e