Attention is currently required from: neels, fixeria, msuraev, dexter.
pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/31415 )
Change subject: bts_features: Add features for HR formats (TS 101813 vs. RFC5993) ......................................................................
Patch Set 8:
(1 comment)
File include/osmocom/gsm/bts_features.h:
https://gerrit.osmocom.org/c/libosmocore/+/31415/comment/d9d85e2a_9f7dfaa0 PS7, Line 39: _TX
Max, you still write "than" instead of "then" =) […]
A couple of extra points here: - The RTP format in one direction may not be necessarily the same one in the other direction. It's fine osmo-bts can receive in any format, but ofc when transmitting one specific one might be selected. - Using the "feature" bits to describe which RTP format will be used to transmit looks wrong to me imho. The "features" would be more like saying "I support sending with this and that format", but not really telling which one is selecting. - Since osmo-bsc is the one configuring its MGW, I'd expect also osmo-bsc to have the knowledge of which RTP formats each BTS supports and uses to transmit. I think for now it's just fine storing that information by default in each bts type in osmo-bsc and maybe have a VTY param in osmo-bsc to change it if needed. Ideally for ipaccess based BTSs we would extend the IPACC CRCX/MDCX to also negotiate which format is used to transmit there. But that would ofc only wrok for osmo-bts since nanobts wouldn't support that and it would need to be set hardcoded anyway.
TL;DR: Don't attemt to know which RTP HR format is to be used to transmit by the BTS using OML features. Rather either store/configure that in osmo-bsc or extend IPAC CRC/MDCX for that.