Cellular Network Infrastructure » Radio Access Network » OsmoBTS

The minimal feature set we need to support is support for transparent, asynchronous at speeds 2400/4800/9600 bps.

• one 60-bit modified V.110 frame every 5ms
  • convert each of them to a normal 80-bit V.110 frame using RA1'/RA1 (resulting intermediate rate 16kbps)
  • batch four of them togethger to get from 5ms to 20ms duration
  • perform I.460 to get from 16kbps to 64kbps
  • transmit resulting 20ms @ 64kbps as RTP payload type 120

The decode of received bursts (uplink or downlink) has been hacked up in https://gitea.osmocom.org/phone-side/osmocom-bb/src/branch/laforge/csd_decode/src/host/layer23/src/misc/burst_process.c

• handle the 22-burst deinterleave/decode (via calling gsm0503_tch_f96_deinterleave and osmo_conv_decode(gsm0503_tch_f96)) from sched_lchan_tchf.c
  • this generates 240 output bits for 20ms
• iterate over the four frames contained in those 240 bits (60 bits each)
  • call @osmo_csd_12k_6k_decode_frame() to generate decoded/abstract 80bit V.110 frames from the 60bit CSD-modified frames
  • call osmo_v110_encode_frame() to encode the abstract V.110 frame into a 80bit V.110 frame
  • feed the resulting output data (16kbps, i.e. 80bit every 5ms) as 16k rate at sub-slot 0 into an 16k I.460 mux. This generates a 64kbps output stream. As we generate output for four V.110 frames (20ms), we generate 160 bytes.
  • transmit the output as 160byte RTP (RFC4040 clear-mode)

• receive 160byte RTP clearmode packets
• feed into I.460 demux, extract only 16k sub-slot 0
  • for each of the 80-bit V.110 frames contained
    • call osmo_v110_decode_frame
    • call osmo_csd_12k_6k_encode_frame
  • encode the resulting 4x 60bit using gsm0503_tch_f96_interleave / osmo_conv_encode(gsm0503_tch_f96)
  • transmit resulting bursts

• receive 60bit every 10ms (instead of 60bit every 5ms)
• use the same osmo_csd_12k_6k_decode_frame -> osmo_v110_encode_frame chain to go from 60bit to 80bit V.110 frames
• batch two 80-bit V.110 frames (so we again have 20ms worth of data)
• feed that through an 8k I.460 mux to get 20ms worth of 64kbps data

Maybe this is something fixeria or Hoernchen would want to pick up?

Intermediate status update: so far I cleaned up the scheduler a bit, so that a) we have consistent activation/deactivation approach for all kinds of lchans (no more implicit auto-active flag), and b) the burst buffers are allocated/free()d in a single place, rather than in each lchan handler individually. This will allow us to enlarge the buffers dynamically for lchans activated/modified for CSD.

https://gerrit.osmocom.org/c/osmo-bts/+/31716 osmo-bts-trx: properly activate [CBCH/]BCCH/CCCH
https://gerrit.osmocom.org/c/osmo-bts/+/31672 osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()

Both patches have been tested by running ttcn3-bts-test, no regressions observed.

Among with that, I have a draft patch integrating the GSM 05.03 coding/interleaving API from libosmocoding, however I am unable to test it properly yet because for some reason in osmo-bts we're using the RR specific channel mode values (see `lchan->tch_mode`) instead of the RSL specific ones. The problem is that there seems to be no one-to-one mapping between the RR and RSL values, so osmo-bts needs to be migrated to use the RSL values instead. I will see if I can solve/workaround this without having to refactor lots of code.

I implemented a very simplistic testcase in ttcn3-bts-test that activates a TCH/F for CSD (RSL_CMOD_CSD_T_9k6) and then immediately deactivates it.
osmo-bts currently NACKs the CHANnel ACTIVation request, so the testcase fails:

20230322052340703 DRSL INFO (bts=0,trx=0,ts=1,pchan=TCH/F) ss=0 Rx RSL CHAN_ACTIV (rsl.c:3720)
20230322052340703 DRSL ERROR (bts=0,trx=0,ts=1,ss=0) Channel Mode IE contains unhandled transparent CSD data rate 0x10 (rsl.c:208)
20230322052340703 DRSL NOTICE (bts=0,trx=0,ts=1,ss=0): Sending Channel Activated NACK: cause = 0x68 (rsl.c:1368)

I also found and fixed a bug in Wireshark causing incorrect dissection of the Channel Mode IE:

https://gitlab.com/wireshark/wireshark/-/merge_requests/10120

I figured out the mapping between RSL Channel Mode and RR Channel Mode values:

https://gerrit.osmocom.org/c/libosmocore/+/32023 gsm_04_08: document/clarify enum gsm48_chan_mode values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32024 gsm_04_08: add more enum gsm48_chan_mode speech values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32025 gsm_04_08: add more enum gsm48_chan_mode data values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32026 gsm0808: handle new enum gsm48_chan_mode speech/data values [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/32027 rsl: rsl_handle_chan_mod_ie(): add missing GSM48_CMODE_* values [NEW]

This makes me closer to the goal of implementing the RSL CHANnel ACTIVation for CSD. Now I need to modify bts_supports_cm() to handle the new CSD related values. I see we already have BTS_FEAT_ECSD and BTS_FEAT_HSCSD, but not BTS_FEAT_CSD? I am planning to add one, since only osmo-bts-trx will be supporting CSD.

I reworked one of my old patches and addressed code review comments:

https://gerrit.osmocom.org/c/osmo-bts/+/31672 osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()
https://gerrit.osmocom.org/c/osmo-bts/+/32726 osmo-bts-trx: use direct pointer to chan_state->{ul,dl}_bursts

I also submitted a Work-in-Progress patch implementing TCH/F9.6:

https://gerrit.osmocom.org/c/osmo-bts/+/32727 [WIP] osmo-bts-trx: implement TCH/F9.6 support for CSD [NEW]

The actual channel coding logic is yet commented out, because we're missing proper burst mapping and FACCH handling.

fixeria wrote in #note-23:

I also submitted a Work-in-Progress patch implementing TCH/F9.6:

https://gerrit.osmocom.org/c/osmo-bts/+/32727 [WIP] osmo-bts-trx: implement TCH/F9.6 support for CSD [NEW]

I reworked this patch to prepare the scheduler for integrating various CSD specific TCH/F and TCH/H modes. The actual enc/dec logic is still missing - I am implementing it in libosmocore.git (new libosmocoding API). Currently running ttcn3-bts-test to see if there are any unexpected regressions caused by the associated changes.

Interestingly enough, TCH/F2.4 is somewhat special because unlike the other CSD specific modes the encoded data in this mode is interleaved over 8 consecutive bursts, so it's quite similar to regular TCH/FS (speech). For half-rate CSD we have only two channels modes: TCH/H2.4 and TCH/H4.8. Both of them are quite similar to TCH/F9.6 and employ the same interleaving algorithm, but this similarity with the full-rate CSD brings some additional complexity. One of the problems is that for half-rate CSD modes we need to perform a decoding attempt every 4th burst, while for half-rate speech we invoke the decoder every 2nd burst.

Handling of FACCH is another interesting topic. 3GPP TS 45.003 section 4.2.5 says that FACCH "disturbs" N coded bits (depending on channel mode) from the data block. So AFAIU, it does not steal the whole CSD data block, but only part of it. Not sure though what are the use cases for FACCH on CSD channels.

thanks for the update. Note that TCH/F is currently still the only mandatory feature, and
specifically only the 2.4/4.8/9.6 kBps user rates above it. Let's make sure we focus our energy
where we really need it rather than trying to implement everything else which is not needed.

laforge wrote in #note-25:

thanks for the update. Note that TCH/F is currently still the only mandatory feature, and
specifically only the 2.4/4.8/9.6 kBps user rates above it. Let's make sure we focus our energy
where we really need it rather than trying to implement everything else which is not needed.

Ack. So far I implemented TCH/F9.6, TCH/[FH]4.8, TCH/H2.4, and TCH/F14.4 in libosmocoding:

https://gerrit.osmocom.org/c/libosmocore/+/32805 coding: use GSM_MACBLOCK_LEN gsm0503_tch_fr_decode() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32806 coding: gsm0503_tch_f96_[de]interleave() not applicable to TCH/F2.4 [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32807 coding: declare gsm0503_tch_f96_[de]interleave() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32808 coding: implement TCH/F9.6, TCH/[FH]4.8, TCH/H2.4, TCH/F14.4 [NEW]

all these CSD specific modes are quite similar to each other; TCH/H4.8 is fully identical to TCH/F9.6.

What's missing is:

• TCH/F2.4, which is more similar to TCH/FS and slightly more complicated,
• FACCH/F and FACCH/H - I don't know how to implement this properly.

Yesterday I spent some time on libosmocoding adding the unit tests and fixed several problems:

• the encoding functions were overwriting all bits in the given ubit_t buffer, corrupting bits of other diagonal-interleaved blocks - this is fixed in the new patchset revisions;
• the convolutional code definition for TCH/F4.8 was incorrect, causing a buffer overrun - https://gerrit.osmocom.org/c/libosmocore/+/32986.

I also changed all encoding and decoding functions to operate on unpacked bits instead of packed bits (bytes). This gives us some additional flexibility: for transparent services we can easily feed these unpacked bits to osmo_csd_xxxx_decode_frame(); for non-transparent services we can invoke osmo_ubit2pbit_ext().

I've implemented FACCH/[FH] coding API in separate functions, as was suggested by falconia (thanks!):

https://gerrit.osmocom.org/c/libosmocore/+/33003 coding: implement dedicated codec API for FACCH/[FH] [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/33004 coding: test FACCH/[FH] bitstealing in test_csd() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/33005 coding: fix _tch_csd_burst_map(): do not overwrite FACCH [NEW]

TTCN-3 testcases:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33071 BTS_Tests: f_TC_speech_rtp(): run TCH and SACCH loops [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33072 BTS_Tests: add TC_data_rtp_tch* for CSD [NEW]

Thanks to them, I fixed several problems and segfaults in both osmo-bts and osmocom-bb. One of the major problems was in rx_tchf_fn():

/* shift the buffer by 4 bursts leftwards */
if (bi->bid == 0) {
    memmove(&bursts_p[0], &bursts_p[4 * BPLEN], 18 * BPLEN);
    memset(&bursts_p[18 * BPLEN], 0, 4 * BPLEN);
    *mask = *mask << 4;
}

/* ... */

/* copy burst to end of buffer of 22 bursts */
burst = bursts_p + (bi->bid + 18) * BPLEN;
if (bi->burst_len > 0) {
    memcpy(burst, bi->burst + 3, 58);
    memcpy(burst + 58, bi->burst + 87, 58);
} else
    memset(burst, 0, BPLEN);

The problem can be visualized as follows:

  00  01  02  03  04  05  06  07  08  09  10  11  12  13  14  15  16  17  18  19  20  21 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   | a | b | c | d |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   |   |   |   |   | a | b | c | d | e | f | g | h |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   | a | b | c | d | e | f | g | h | i | j | k | l |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | a | b |  <-- we lost bursts 'a' and 'b'
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^
|--- decoding attempt happens here every bid==3

If we allocate a buffer which can fit up to 22 bursts and memcpy() new bursts at (bi->bid + 18) * BPLEN, after shifting the buffer we end decoding bursts at incorrect offset and thus getting unexpected results. I changed the code to allocate buffers which can fit up to 24 bursts and memcpy() new bursts at (bi->bid + 20) * BPLEN.

So far I managed to get working only TCH/F9.6 and TCH/F4.8; it needs to be investigated why other channel modes are not working.

fixeria wrote in #note-29:

So far I managed to get working only TCH/F9.6 and TCH/F4.8; it needs to be investigated why other channel modes are not working.

I managed to get the TCH/F14.4 working, the problem was using uint8_t for the TCH.ind prim length parameter, which obviously cannot represent values like 290:

https://gerrit.osmocom.org/c/osmo-bts/+/33585 scheduler: use size_t for data_len in sched_compose*_ind() [NEW]

While debugging this, I also submitted several more fixes and improvements:

https://gerrit.osmocom.org/c/osmo-bts/+/33581 scheduler: fix wrong union field in sched_compose_tch_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33582 scheduler: use msgb_hexdump_l2() in _sched_compose_tch_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33583 scheduler: unify argument names/order for _sched_compose*_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33584 scheduler: constify data pointer in sched_compose_ind() [NEW]

Now let's see what makes the TCH/H tests unhappy.

fixeria wrote in #note-33:

Now let's see what makes the TCH/H tests unhappy.

Turns out it's a primitive management problem in trxcon. With a few hacks I got both TCH/H4.8 and TCH/H2.4 passing.
This proves that the implementation of all CSD channels types in osmo-bts.git is correct, except the TCH/F2.4, which is still missing.

All patches have been merged, so the only missing part is the rate adaptation.

fixeria wrote in #note-38:

https://gerrit.osmocom.org/c/osmo-bts/+/33832 l1sap: proper rate adaptation for CSD (RFC4040 'clearmode') [NEW]

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.

The best way to do this validation would be to set up a CSD call between two MS and take a pcap file of the V.110 data in RTP CLEARMODE. I do have existing V.110 code for decoding such captures, which I validated against ISDN equipment doing V.110. So if the same tools can decode the V.110 in RTP clearmode, we can be satisfied with it.

Note that I intentionally did not use the existing I.460 code from libosmocore.git for the sake of simplicity.

I hope the latter really only applies to the I.460. The V.110 to "CSD specific V.110" conversion is present in libosmocore (with unit tests) and should definitely be used.

laforge wrote in #note-39:

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.

The best way to do this validation would be to set up a CSD call between two MS and take a pcap file of the V.110 data in RTP CLEARMODE. I do have existing V.110 code for decoding such captures, which I validated against ISDN equipment doing V.110. So if the same tools can decode the V.110 in RTP clearmode, we can be satisfied with it.

Ok, will do! I'll also add unit tests as was suggested by Oliver during code review.

Note that I intentionally did not use the existing I.460 code from libosmocore.git for the sake of simplicity.

I hope the latter really only applies to the I.460. The V.110 to "CSD specific V.110" conversion is present in libosmocore (with unit tests) and should definitely be used.

Ack. I am using libosmocore's API for the RA1'/RA1 conversion, but my own implementation for the RA1/RA2 only.

Found and fixed a NULL pointer dereference while testing a modem-to-modem data call:

https://gerrit.osmocom.org/c/osmo-bts/+/33858 osmo-bts-trx: tx_tch[fh]_fn(): fix NULL pointer dereference [NEW]

(Note to myself) I am seeing lots of messages like this one while testing a modem-to-modem call (#6110):

DLMIB NOTICE osmo_ortp.c:0 ortp: rtp_session_avpf_enabled(): payload type not set, unreliable result returned.

It needs to be investigated why and how we end up with the RTP payload not being set.

Using two Calypso based SE K200 phones I tested the following data rates:

• TCH/F14.4 (AT+CBST=75,0,0, 14400 bps) -- fail (missing rate adaptation)
• TCH/F9.6 (AT+CBST=71,0,0, 9600 bps) -- works
• TCH/F4.8 (AT+CBST=70,0,0, 4800 bps) -- works
• TCH/F2.4 (AT+CBST=68,0,0, 2400 bps) -- works
• TCH/F2.4 (AT+CBST=66,0,0, 1200 bps) -- works
• TCH/F2.4 (AT+CBST=65,0,0, 300 bps) -- works

I think we can close this ticket once I'm done with the ortp related warnings.

fixeria wrote in #note-44:

(Note to myself) I am seeing lots of messages like this one while testing a modem-to-modem call (#6110):

[...]

Here is a backtrace:

(gdb) bt
#0  my_ortp_logfn (domain=0x7ffff7ee4144 "ortp", lev=BCTBX_LOG_WARNING, 
    fmt=0x7ffff7ee56d0 "rtp_session_avpf_enabled(): payload type not set, unreliable result returned.", args=0x7fffffffd2b0)
    at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:109
#1  0x00007ffff7ee05b3 in bctbx_logv () from /usr/lib/libortp.so.15
#2  0x00007ffff7ecd4ed in ?? () from /usr/lib/libortp.so.15
#3  0x00007ffff7ecd60a in rtp_session_avpf_enabled () from /usr/lib/libortp.so.15
#4  0x00007ffff7ecc9d4 in compute_rtcp_interval () from /usr/lib/libortp.so.15
#5  0x00007ffff7eccbec in rtp_session_run_rtcp_send_scheduler () from /usr/lib/libortp.so.15
#6  0x00007ffff7ed3782 in __rtp_session_sendm_with_ts () from /usr/lib/libortp.so.15
#7  0x00007ffff7f3350a in osmo_rtp_send_frame_ext (marker=false, duration=160, payload_len=160, payload=0xa0 <error: Cannot access memory at address 0xa0>, 
    rs=0x5555558d45c0) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:554
#8  osmo_rtp_send_frame_ext (rs=0x5555558d45c0, 
    payload=payload@entry=0x7fffffffd550 "????\377\177", '\377' <repeats 14 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "0\326\377\377\377\177", payload_len=payload_len@entry=160, duration=160, marker=marker@entry=false) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:538
#9  0x000055555559df8e in send_ul_rtp_packet_data (data_len=<optimized out>, data=<optimized out>, fn=1127737, lchan=0x7ffff6b87df8)
    at ../../../../src/osmo-bts/src/common/l1sap.c:1843
#10 l1sap_tch_ind (tch_ind=0x5555558da1b0, l1sap=0x5555558da198, trx=<optimized out>) at ../../../../src/osmo-bts/src/common/l1sap.c:1979
#11 l1sap_up (trx=<optimized out>, l1sap=l1sap@entry=0x5555558da198) at ../../../../src/osmo-bts/src/common/l1sap.c:2184
#12 0x00005555555748b7 in _sched_compose_tch_ind (l1ts=l1ts@entry=0x555555884c70, fn=fn@entry=1127737, chan=<optimized out>, data=data@entry=0x7fffffffd730 "\001", 
    data_len=data_len@entry=240, ber10k=ber10k@entry=0, rssi=-76.1363602, ta_offs_256bits=66, link_qual_cb=73, is_sub=0 '\000')
    at ../../../../src/osmo-bts/src/common/scheduler.c:826
#13 0x000055555556c8a3 in rx_tchf_fn (l1ts=l1ts@entry=0x555555884c70, bi=bi@entry=0x7fffffffdbc0) at ../../../../src/osmo-bts/src/osmo-bts-trx/sched_lchan_tchf.c:333
#14 0x0000555555575cb3 in trx_sched_ul_burst (l1ts=0x555555884c70, bi=<optimized out>) at ../../../../src/osmo-bts/src/common/scheduler.c:1601
#15 0x0000555555568bed in trx_sched_route_burst_ind (trx=<optimized out>, bi=<optimized out>) at ../../../../src/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:372
#16 0x0000555555564ee2 in trx_data_read_cb (ofd=<optimized out>, what=<optimized out>) at ../../../../src/osmo-bts/src/osmo-bts-trx/trx_if.c:1104
#17 0x00007ffff7bd2faf in poll_disp_fds (n_fd=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:419
#18 _osmo_select_main (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:457
#19 0x00007ffff7bd308e in osmo_select_main (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:496
#20 0x00005555555a3834 in bts_main (argc=3, argv=<optimized out>) at ../../../../src/osmo-bts/src/common/main.c:429
#21 0x00007ffff7827cd0 in ?? () from /usr/lib/libc.so.6
#22 0x00007ffff7827d8a in __libc_start_main () from /usr/lib/libc.so.6
#23 0x0000555555562805 in _start ()

As can be seen, the problem is triggered by the Uplink path. The UE sent us an IDLE V.110 frame:

(gdb) frame 11
#11 l1sap_up (trx=<optimized out>, l1sap=l1sap@entry=0x5555558da198) at ../../../../src/osmo-bts/src/common/l1sap.c:2184
2184                    rc = l1sap_tch_ind(trx, l1sap, &l1sap->u.tch);
(gdb) p (char *)msgb_hexdump(l1sap->oph.msg)
$31 = 0x7ffff6c38aa4 "[L2]> 01 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01"...

which gets converted to 80-bit V.110 frame and then mapped to 160 bytes long RTP CLEARMODE payload.

It needs to be investigated why and how we end up with the RTP payload not being set.

As far as I can see, the payload type is actually set:

(gdb) frame 8
#8  osmo_rtp_send_frame_ext (rs=0x5555558d45c0, 
    payload=payload@entry=0x7fffffffd550 "????\377\177", '\377' <repeats 14 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "0\326\377\377\377\177", payload_len=payload_len@entry=160, duration=160, marker=marker@entry=false) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:538
538     int osmo_rtp_send_frame_ext(struct osmo_rtp_socket *rs, const uint8_t *payload,
(gdb) p (int)rtp_session_get_recv_payload_type(rs->sess)
$32 = 120
(gdb) p (int)rtp_session_get_send_payload_type(rs->sess)
$33 = 120

Below is an extract from the source code of ortp v5.2.73:

/**
 *
 *      Gets the payload description of the payload type \a index in the profile.
 *
 *@param prof an RTP profile (a #_RtpProfile object)
 *@param idx    the payload type number
 *@return the payload description (a PayloadType object)
**/
static ORTP_INLINE PayloadType * rtp_profile_get_payload(const RtpProfile *prof, int idx){
        if (idx<0 || idx>=RTP_PROFILE_MAX_PAYLOADS) {
                return NULL;
        }   
        return prof->payload[idx];
}

bool_t rtp_session_avpf_enabled(RtpSession *session) {
        PayloadType *pt = rtp_profile_get_payload(session->snd.profile, session->snd.pt);
        if (!pt){
                ortp_warning("rtp_session_avpf_enabled(): payload type not set, unreliable result returned.");
        }   
        return pt && (payload_type_get_flags(pt) & PAYLOAD_TYPE_RTCP_FEEDBACK_ENABLED);
}

From gdb we know that session->snd.pt is set to 120:

(gdb) p *rs->sess.snd.profile
$41 = {name = 0x7ffff6b0a6c0 "AV profile", payload = {0x7ffff7ef5640 <payload_type_pcmu8000>, 0x7ffff7ef5460 <payload_type_lpc1016>, 0x0, 
    0x7ffff7ef5400 <payload_type_gsm>, 0x7ffff7ef5340 <payload_type_g7231>, 0x0, 0x0, 0x7ffff7ef53a0 <payload_type_lpc>, 0x7ffff7ef55e0 <payload_type_pcma8000>, 
    0x7ffff7ef44a0 <payload_type_g722>, 0x7ffff7ef54c0 <payload_type_l16_stereo>, 0x7ffff7ef5520 <payload_type_l16_mono>, 0x0, 0x7ffff7ef52e0 <payload_type_cn>, 0x0, 
    0x0, 0x0, 0x0, 0x7ffff7ef5280 <payload_type_g729>, 0x0 <repeats 12 times>, 0x7ffff7ef4e60 <payload_type_h261>, 0x7ffff7ef4ec0 <payload_type_mpv>, 0x0, 
    0x7ffff7ef4e00 <payload_type_h263>, 0x0 <repeats 61 times>, 0x7ffff6b0a1a0, 0x7ffff6b0a0f0, 0x7ffff7ef4b00 <payload_type_amr>, 0x0 <repeats 29 times>}}

(gdb) p rs->sess.snd.profile->payload[120]
$44 = (PayloadType *) 0x0

So the problem is that there seems to be no matching profile for the CLEARMODE (120). The error message printed by ortp is rather confusing.

fixeria wrote in #note-49:

So the problem is that there seems to be no matching profile for the CLEARMODE (120). The error message printed by ortp is rather confusing.

With this patch applied, I no longer see ortp emitted warnings in the logs:

https://gerrit.osmocom.org/c/libosmo-abis/+/34223 osmo_ortp: register a PayloadType for RTP_PT_CSDATA

Adding some more things, for which we may want to create separate tickets:

• update/rework TTCN-3 testcases and get them merged (see https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33072);
• fix Uplink measurement aggregation for data channels (problem described below);
• implement the missing TCH/F14.4 mode (low priority).

Regarding the Uplink measurements, currently the logging is spammed with:

DMEAS ERROR measurement.c:683 (bts=0,trx=0,ts=3,ss=0) Incorrect number of SUB measurements detected! (1 vs exp 2)

For the record, I found a problem while working on #4396 and submitted several patches fixing it:

https://gerrit.osmocom.org/c/osmo-bts/+/34990 osmo-bts-trx: tx_tch[fh]_fn(): use BUFPOS macro everywhere [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34991 osmo-bts-trx: tx_tch[fh]_fn(): rework generation of dummy FACCH [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34992 osmo-bts-trx: tx_tch[fh]_fn(): fix sending idle CSD frames [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/34993 trxcon/l1sched: tx_tch[fh]_fn(): fix sending idle CSD frames [NEW]