mirror of https://gerrit.osmocom.org/libosmocore
Neels Hofmeyr
d2d44883ac
Deprecate gsm0808_sc_cfg_from_gsm48_mr_cfg() and gsm48_mr_cfg_from_gsm0808_sc_cfg(), and add new functions gsm0808_sc_cfg_from_amr_modes() and gsm0808_sc_cfg_get_best_amr_modes() to fix the behavior as follows: When the mr_cfg enables a specific rate, do not include all AMR configurations that feature this rate. Instead, enable only those configurations that are a subset of the mr_cfg. For example, in the old functions, setting only m4_75 = 1 would result in enabling all of S0, S8, S9, S10, S12, S14. S14 would allow all of 4.75k, 5.9k, 7.95k, 12.2k, instead of limiting to 4.75k only. In the new functions, do not modify the .version and .icmi members, act only on the AMR rates. Changes from old behavior to new behavior is clearly shown in tests/gsm0808/gsm0808_test.ok. Keep the deprecated functions unchanged, yielding incorrect behavior, and let the API users decide when and how to upgrade to the more sane behavior. For example, changing the behavior of existing functions in-place would have repercussions on osmo-bsc installations, where now only those AMR modes listed in the config would be used -- we are becoming stricter. Possibly this would deteriorate or break sites alone from upgrading libosmocore -- i.e. those sites that fail to list an essential AMR rate for matching with peers, but where that essential AMR rate was erratically allowed by the old behavior. The old behavior, by example of osmo-bsc: - Picking rates in osmo-bsc.cfg has non-obvious effects, often including rates that are configured as 'forbidden'. - If any of 4.75, 5.90, 7.40, 12.2 is enabled in osmo-bsc.cfg, the configuration S1 ends up enabled in s15_s0 (gsm0808_sc_cfg_from_gsm48_mr_cfg()). - In gsm48_mr_cfg_from_gsm0808_sc_cfg() used during channel activation, if S1 is present, the four rates from S1 are returned. - In summary, in the vast majority of cases, the S1 set will be used -- even if only one of its AMR rates is originally present in mr_cfg. - Configurations above S7 are ignored. The new behavior, assuming osmo-bsc moved to the more sane implementation introduced in this patch: - Only one of the rate combinations defined by S0..S15 is going to be used. This is mainly because AMR rate selections are sent to the MSC and back from the MSC in the somewhat limited S0..S15 bit form. Enabling one or more of these combinations of rates in osmo-bsc.cfg makes sense: - 4.75, 5.90, 7.40, 12.2 (S1) - 4.75, 5.90 (S8) - 4.75, 5.90, 6.70 (S9) - 4.75, 5.90, 6.70, 7.40 (S10) - 4.75, 5.90, 6.70, 10.2 (S12) - 4.75, 5.90, 7.95, 12.2 (S14) - e.g. if only 4.75 is enabled, only 4.75 is used (S0). - e.g. in case of 6.70=allowed + 7.75=allowed + 10.2=allowed, we have to choose between "only 6.70", "only 7.75", "only 10.2". On FR we'd pick S6 = "only 10.2", because it is the highest rate. So osmo-bsc.cfg should rather choose rates exactly matching a specific Sn bit, e.g. all rates of S12, to obtain a flexible variety of AMR rates. 3GPP TS 48.008 3.2.2.103 'Speech Codec List' says to this: NOTE: One of these Codec Configurations, "Config-NB-Code 1" = S1, is recommended for TrFO [Transcoder Free Operation]. S14 also seems a good choice, it is like S1 but with 7k95 instead of 7k40; 7k95 is the highest possible AMR-HR rate. It is not clear at this point why S1 seems to be preferred over S14. Ironically, the old behavior would usually end up selecting exactly S1 in almost every case, which is what 3GPP TS 48.008 3.2.2.103 recommends. This is, however, not obvious to the caller / the site admin. Related: SYS#5066 Change-Id: I900fda192742fa8f6dd54e9131ef1704b14cc41a |
||
|---|---|---|
| .. | ||
| osmocom | ||
| Makefile.am | ||