Attention is currently required from: laforge, pespin, dexter.
2 comments:
File src/common/l1sap.c:
Patch Set #1, 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
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.
To view, visit change 32968. To unsubscribe, or for help writing mail filters, visit settings.