Attention is currently required from: neels, fixeria, msuraev, dexter.
1 comment:
File include/osmocom/gsm/bts_features.h:
In a correctly configured setup we should always see the same format in both directions.
If you say so... I don't think that's really stated anywhere in the spec, and sounds like a personal expectancy of what a "correctly configured setup" is imho 😊
I thought the OML feature flags were introduced for things like this
Yes, to know that a BTS supports a given feature. Not to indicate which of the several supported is to be used.
BTS model is a PHY based model with TS 101318 support or an osmo-trx based model with RFC 5993 support.
So our osmo-bts-sysmo is transmitting different RTP type than our osmo-bts-trx? what a mess! 😮
The BSC knows that it talks to an osmo-bts, but it does not know if this BTS model
My point is only that you still need to store that in osmo-bsc hardcoded somehow for other types of BTS, like nanobts, etc. so you could simply do the same for osmobts (you will need this for older versions of osmo-bts anyway). Maybe that's actually done using this set of features?
BTS model is a PHY based model with TS 101318 support or an osmo-trx based model with RFC 5993 support.
So our osmo-bts-sysmo is transmitting different RTP type than our osmo-bts-trx? what a mess! :O
> Extending IPACC can be also a way, here we can at least be sure that osmo-bts type BTSs will support the extension but we will have to make sure that older osmo-bts versions will tolerate/ignore the extensions.
Yes, have a look if adding the new IE is really a problem for old versions (I think it won't be an issue). If it was, then you could add a new BTS feature stating whether the BTS supports this new IE and then only send it based on it.
To view, visit change 31415. To unsubscribe, or for help writing mail filters, visit settings.