Cellular Network Infrastructure » Radio Access Network » OsmoBTS

reducing priority as trxcon + osmo-bts-trx support voice.

There are already GSMTAP channel type enum values for TCHF and TCHH. They have just not been used so far in any of the related programs (Osmocom, wireshark, ...) - at least not that I know of.

We could simply put the RTP codec payload in those frames and use the length to determine the type (33 bytes for FR, 31 bytes for EFR, ...). However, I think that's a bit ugly.

• HR
• FR
• AMR (including AMR frame type like SID_FIRST, SID_UPDATE, ...)

followed by the actual payload in exactly the same order/length as we would have it in the payload of RTP frames. This way we can easily convert between RTP and GSMTAP-voice frames by siply stripping the GSMTAP header and pushing the RTP header or vice-versa.

I was wondering a bit if it made sense to include other parts of the RTP header, but sequence number or timestamp are already expressed in some form as the GSM frame number...

Actually, we cannot use the exsiting TCHF/TCHH types, as those are already used [without further discrimination] for FACCH + SACCH Data on those channels.

Instead, we will introduce a new GSMTAP_CHANNEL_VOICE type, which then will have the first byte for specifyng the payload. My current proposal looks like this:

diff --git a/include/osmocom/core/gsmtap.h b/include/osmocom/core/gsmtap.h
index 35ba71e5..21b94433 100644
--- a/include/osmocom/core/gsmtap.h
+++ b/include/osmocom/core/gsmtap.h
@@ -82,8 +82,8 @@
 #define GSMTAP_CHANNEL_SDCCH   0x06
 #define GSMTAP_CHANNEL_SDCCH4  0x07
 #define GSMTAP_CHANNEL_SDCCH8  0x08
-#define GSMTAP_CHANNEL_TCH_F   0x09
-#define GSMTAP_CHANNEL_TCH_H   0x0a
+#define GSMTAP_CHANNEL_TCH_F   0x09    /* Actually, it's FACCH/F (signaling) */
+#define GSMTAP_CHANNEL_TCH_H   0x0a    /* Actually, it's FACCH/H (signaling) */
 #define GSMTAP_CHANNEL_PACCH   0x0b
 #define GSMTAP_CHANNEL_CBCH52  0x0c
 #define GSMTAP_CHANNEL_PDTCH   0x0d
@@ -91,6 +91,7 @@
 #define GSMTAP_CHANNEL_PDCH    GSMTAP_CHANNEL_PDTCH
 #define GSMTAP_CHANNEL_PTCCH   0x0e
 #define GSMTAP_CHANNEL_CBCH51  0x0f
+#define GSMTAP_CHANNEL_VOICE   0x10    /* voice codec payload (HR/FR/EFR/AMR) */

 /* GPRS Coding Scheme CS1..4 */
 #define GSMTAP_GPRS_CS_BASE    0x20
@@ -318,3 +319,26 @@ struct gsmtap_osmocore_log_hdr {
                uint32_t line_nr;/*!< line number */
        } src_file;
 } __attribute__((packed));
+
+/*! First byte of type==GSMTAP_TYPE_UM sub_type==GSMTAP_CHANNEL_VOICE payload */
+enum gsmtap_um_voice_type {
+       /*! 1 byte TOC + 112 bits (14 octets) = 15 octets payload;
+        *  Reference is RFC5993 Section 5.2.1 + 3GPP TS 46.030 Annex B */
+       GSMTAP_UM_VOICE_HR,
+       /*! 33 payload bytes; Reference is RFC3551 Section 4.5.8.1 */
+       GSMTAP_UM_VOICE_FR
+       /*! 31 payload bytes; Reference is RFC3551 Section 4.5.9 + ETSI TS 101 318 */
+       GSMTAP_UM_VOICE_EFR,
+       /*! 1 byte TOC + 5..31 bytes = 6..32 bytes payload; RFC4867 octet-aligned */
+       GSMTAP_UM_VOICE_AMR,
+       /* TODO: Revisit the types below; their usage; ... */
+       GSMTAP_UM_VOICE_AMR_SID_BAD,
+       GSMTAP_UM_VOICE_AMR_ONSET,
+       GSMTAP_UM_VOICE_AMR_RATSCCH,
+       GSMTAP_UM_VOICE_AMR_SID_UPDATE_INH,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_P1,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_P2,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_INH,
+       GSMTAP_UM_VOICE_AMR_RATSCCH_MARKER,
+       GSMTAP_UM_VOICE_AMR_RATSCCH_DATA,
+};

pushed the patch as https://gerrit.osmocom.org/c/libosmocore/+/17289

I doubt I'll have time to work on it any time soon, assigning to neels to take over

https://gerrit.osmocom.org/c/libosmocore/+/17289
https://gerrit.osmocom.org/c/osmo-bts/+/17377

also related:
https://gerrit.osmocom.org/c/osmocom-bb/+/17380