Changes

MGCP extension: add parameters for TW-TS-001 & TW-TS-002

TW-TS-001 and TW-TS-002 are enhanced RTP transport formats for
GSM FR/HR/EFR codecs that restore the lost semantics of GSM 08.60
and 08.61 TRAU-UL frames.

TW-TS-003 BSSMAP extension provides a way for a core network to
ask the BSS to use these TRAU-like enhanced RTP formats instead of
those specified in 3GPP TS 48.103; OsmoBSC already supports this
mechanism when the BSS is comprised of IP-native OsmoBTS.

However, in order to achieve the same effect when using E1-based
legacy BTS hardware, the task of generating TW-TS-001/002 RTP
packets for UL and accepting them for DL moves from OsmoBTS to
the E1-Abis-interfacing MGW.  osmo_trau2rtp() is already capable
of generating these extended RTP formats on request, but until now
there was no mechanism to signal from OsmoBSC to its associated
E1 Abis MGW whether and when these extensions should be used.

Considering that MGCP as it is used in Osmocom is essentially a
private interface between OsmoBSC or OsmoMSC masters and OsmoMGW
slaves, while the externally defined and generally interoperable
interface is 3GPP TS 48.008, possibly extended with TW-TS-003,
the sensible solution is to make a private extension to the way
FR, EFR and HR codecs are described in SDP in the context of
Osmocom-MGCP.

The SDP extension birthed in the present patch consists of an fmtp
parameter for GSM, GSM-EFR and GSM-HR-08 codecs that is structured
just like the already implemented octet-align parameter for AMR.
TW-TS-001 for FR and EFR shall be described as follows:

m=audio 1234 RTP/AVP 3 110
a=rtpmap:3 GSM/8000/1
a=fmtp:3 tw-ts-001=1
a=rtpmap:110 GSM-EFR/8000/1
a=fmtp:110 tw-ts-001=1

TW-TS-002 for HR codec shall be described as follows:

m=audio 1234 RTP/AVP 111
a=rtpmap:111 GSM-HR-08/8000/1
a=fmtp:111 tw-ts-002=1

The present patch affects two areas:

* Experimental support for the newly defined extension is added to
  OsmoMGW-E1.  This support is deemed experimental (not for
  production use) because even with this extension added, OsmoMGW-E1
  is still unable to satisfy ThemWi requirements: neither ThemWi
  RTP endpoint library nor the TFO transform of TS 28.062 section
  C.3.2.1.1 are currently available in the repertoire of libraries
  whose use is allowed in mainline OsmoCNI components, yet both are
  required.

* Support is added to libosmo-mgcp-client whereby OsmoBSC will be
  able to issue CRCX and MDCX commands to E1 Abis MGW endpoints
  with TW-TS-001 and/or TW-TS-002 enabled.  Adding the necessary
  support to OsmoBSC will allow a complete working system to be
  deployed using OsmoBSC plus tw-e1abis-mgw, a replacement for
  OsmoMGW-E1 that works by using both Osmocom and ThemWi libraries.

Related: OS#6614
Change-Id: I0d58e6d84418f50670c8ab7cf8490af3bc2f5c26

E1: change dummy fill frame generation method

In the absence of a proper TFO transform (TS 28.062 section
C3.2.1.1), OsmoMGW-E1 inserts constant fill frames when there is
no RTP input, or when RTP input fails conversion to TRAU-DL and
thus does not enqueue anything to the I.460 mux.  (We accept
TW-TS-001 and TW-TS-002 from RTP side, but bad frames cannot be
converted to TRAU-DL without a TFO transform.)

Prior to the present change, this idle fill of the DL was done
using fully hard-coded frames, i.e., the operation of converting
the desired fill to TRAU-DL bit format was done once externally
and the raw bit frames were hard-coded.  Change this approach:
use fill frames in RTP format provided by libosmocodec, and
execute osmo_rtp2trau() followed by osmo_trau_frame_encode() in
the fill frame output path just like we do for regular RTP to DL.

Depends: libosmocore.git I2c510ac62a0786c137115c45eee7a48b9736265f
Change-Id: I123f77295c56d61ff9aac5f5d64b25eca01e0d63

E1: implement dummy fill for HRv1 codec

In the absence of a proper TFO transform (TS 28.062 section
C3.2.1.1), OsmoMGW-E1 inserts constant fill frames when there is
no RTP input, or when RTP input fails conversion to TRAU-DL and
thus does not enqueue anything to the I.460 mux.

This dummy fill was previously implemented for FR and EFR codecs,
but not for HRv1.  Fix this omission.

With this change and with a fix to OsmoBSC to select 8k subslot
endpoints for TCH/H instead of 16k, OsmoMGW-E1 now supports HR
codec to the same degree to which it supports FR and EFR: far from
perfect, but mostly usable, especially if DTXu is disabled
and there is no TrFO interworking with a far end that does DTXu.

Change-Id: I188bc0a0468b19126281016f45e36f1de617e9ee