Attention is currently required from: laforge, pespin, dexter.
falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32968 )
Change subject: all models, HR1 codec: accept both TS101318 and RFC5993 formats ......................................................................
Patch Set 2:
(2 comments)
File src/common/l1sap.c:
https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/6ee397ff_481526d5 PS1, Line 1264: static bool rtppayload_validate_hr(struct msgb *msg)
The same is already the case for rtppayload_validate_{fr,efr} - those functions call osmo_{fr,efr}_s […]
Done
https://gerrit.osmocom.org/c/osmo-bts/+/32968/comment/2522598a_4f057f2d PS1, Line 1279: memmove(msg->data, msg->data + 1, GSM_HR_BYTES); : msgb_get(msg, 1);
Please read the long C comment on the 7 lines immediately preceding your highlight. […]
In my new patch series I was able to eliminate memmove and convert to pointer manipulation only in the case of plain RTP input, i.e., not Osmux. In the case of Osmux I am not able to find a way to avoid memmove for the header octet stripping operation. Can we just live with it and declare the combination of Osmux + HR1 codec + RFC 5993 input + slow CPU on the BTS to be non-recommended?
Please note that at least on sysmoBTS ARM926, the effect of misaligned l1sap header being pushed on top of a shifted-by-1 payload is much much worse than the memmove penalty - when I tried the msgb_pull() approach, the BTS is immediately brought into totally unusable state with just one active TCH, whereas a memmove approach like what I had here originally (see falconia/rtp_traulike branch) works just fine on my sysmoBTS.