More efficient RTP transport for CSD

Dear Osmocom community, Those of you who had occasion to work with CSD probably noticed that the standard RTP payload format prescribed for AoIP by 3GPP Rel8+ (64 kbit/s CLEARMODE) is extremely wasteful: 160 bytes of payload every 20 ms (compared to a maximum of 33 bytes every 20 ms for voice calls), and most of that 160-byte CLEARMODE payload is constant filler. The actual information content for CSD channels traveling across A interface (data bits plus all metadata preserved, strictly lossless conversion) fits into 16 bytes for CSD modes up to 4.8 kbit/s, 32 bytes for 9.6 kbit/s or 37 bytes for 14.4 kbit/s - much more compact than the 160-byte standard! Because my non-profit org in USA (American 2G Cooperative) will soon be operating a public GSM/2G network as a membership co-op, we have a legal and ethical obligation to provide all services strictly at cost. Radio resource usage is exactly the same between voice and data calls, while CPU load on tw-border-mgw machines in the CN will often be even less with CSD than with EFR or AMR speech transcoding - hence there is no legitimate reason for CSD calls to be more expensive than voice. Yet the bloated RTP format prescribed by 3GPP Rel8+ artificially increases the cost of IP transport within the network. My solution to the problem: yet another TW-TS, specifying a modified version of AoIP interface with compressed CSD. Here is the spec: https://www.freecalypso.org/specs/tw-ts-007-v010001.txt An updated version of TW-TS-003 (BSSMAP extension spec) spells out how the MSC requests the use of compressed CSD instead of standard TS 48.103 on AoIP by adding RTPext IE to ASSIGNMENT REQUEST or HANDOVER REQUEST, with the right bit set to request TW-TS-007 RTP format. In terms of implementation of this newly defined feature in Osmocom, my plan is as follows: * Within the past couple of years I extended osmo_trau2rtp() and osmo_rtp2trau() to support CSD on E1 BTS, using standard CLEARMODE format on RTP side. I plan to extend these functions to support TW-TS-007 as well. * Combination of mainline OsmoBSC plus tw-e1abis-mgw has fully working CSD with E1 BTS, already tested with Nokia InSite. If my idea for representing TW-TS-007 compressed CSD format in MGCP/SDP is acceptable (please see chapter 9 and Annex A in the spec linked above), I would like to extend OsmoBSC to be able to command tw-e1abis-mgw via MGCP/SDP to emit either standard CLEARMODE or TW-TS-007 per request from MSC. The above points are for E1 BTS. With IP-native OsmoBTS, we have two options: 1) We could add more logic to OsmoBTS to emit either standard CLEARMODE or TW-TS-007, just like we already do for TW-TS-001/002 carrying TRAU-UL metadata bits for FR/HR/EFR. 2) We could leave OsmoBTS completely unchanged, speaking only standard CLEARMODE format for CSD, and have OsmoBSC-associated OsmoMGW convert on the fly (we are dealing with strictly lossless conversion here, not bringing back extra metadata as with other TW-TS) if the MSC asked for TW-TS-007 compressed RTP format. Option 2 seems easier to implement, and I am leaning toward this option. Of course this option only makes sense when osmo-bsc, osmo-mgw and osmo-bts-trx run on the same SBC next to or inside SDR-based BTS, or when the link between the BSC and the BTS is a local Ethernet cable, while A interface travels across public Internet or other networks where bandwidth matters. What does the community think? For my own operation E1 BTS is a higher priority (I still plan on using surplus Ericsson RBS6k gear), hence there is plenty of time for Osmocom community to provide feedback on how y'all would like to see this mechanism working with IP-native OsmoBTS. In terms of upcoming Gerrit patches related to TW-TS-007, I plan to work on libosmo-abis next, implementing lossless conversion functions and extending osmo_trau2rtp() and osmo_rtp2trau() for efficient, native support of compressed CSD. GSM/2G Forever, Mother Mychaela P.S. If anyone has constructive criticism regarding chapter 9 or Annex A in the TW-TS-007 spec linked above (AoIP and SDP aspects), it is not too late to revise those parts.