Bug #2763
closedOsmoBSC refuses configuration with both FR and HR codecs
100%
Description
Error occurred during reading the below line: codec-list fr1 hr1 fr2 hr3 fr3 Can not have full-rate and half-rate codec. <0005> bsc_init.c:552 Failed to parse the config file: 'osmo-bsc.cfg'
I don't really understand why. There's no restriction in the GSM specs that would mean a BSC can only support either HR or FR codecs. In fact, I would expect most BSCs support any of the codecs our there.
Related issues
Updated by zecke over 6 years ago
There is no limit from the GSM specification point of view. When I implemented osmo-bsc there was no budget/time to make the end-to-chain work with mixed codecs. To reduce possibilities of creating configs that are reasonable but would not work, I tried to reject a mixed mode.
Full mixed mode would probably need to take used resources into account, classmarks of the device. E.g. when on a SDCCH.. go to fullrate or halfrate? Make it depend on load? Maybe another dynpdch mode to go from TCH/F to TCH/H on load. Luckily the first step is (almost)/was taken to have MGCP GW and BSC communicate with each other.
Updated by neels over 6 years ago
I also noticed/hit this before. AFAICT the only restriction is the VTY configuration condition preventing multiple codecs. I think in the osmo-nitb we even allowed that already; at least I remember that I managed to get mixed calls (one HR and one FR trying to talk to each other) which I guess will only work with both codecs allowed. The lchan_alloc function is quite adept at picking lchans of various types, and OsmoBSC uses the same one OsmoNITB had.
So I think we should just lift the restriction in the VTY and test it, chances are it will just work.
The restriction is in 'codec-list .LIST' in osmo-bsc/src/osmo-bsc/osmo_bsc_vty.c,
it is the setting for bsc_msc_data->audio_support.
if (saw_hr && saw_fr) {
vty_out(vty, "Can not have full-rate and half-rate codec.%s",
VTY_NEWLINE);
return CMD_ERR_INCOMPLETE;
}
I note in bsc_vty.c, there is a different set of commands to set bts->codec:
codec-support fr (hr|efr|amr) (hr|efr|amr) (hr|efr|amr) (hr|efr|amr)
I'm not entirely familiar with the semantic differences between the two. Looks like one says what codecs the BTS supports and what codecs the MSC allows? So why would the BSC want to limit the codecs that the MSC supports?
Loosely related: the load based handover that's in the pipeline does some advanced lchan picking, choosing TCH/F or TCH/H depending on config preferences.
Updated by laforge over 6 years ago
Hi Neels,
On Sun, Dec 17, 2017 at 01:10:11PM +0000, neels [REDMINE] wrote:
So I think we should just lift the restriction in the VTY and test it, chances are it will just work.
ok, I cold help with some automatic test cases, at least to ensure that
the signalling on the A and Abis side are consistent for each of the
supported/enabled codecs.
I note in bsc_vty.c, there is a different set of commands to set bts->codec:
> codec-support fr (hr|efr|amr) (hr|efr|amr) (hr|efr|amr) (hr|efr|amr) >I'm not entirely familiar with the semantic differences between the
two. Looks like one says what codecs the BTS supports and what codecs
the MSC allows?
The per-BTS configuration is mainly due to the fact that we don't have
extensive compiled-in tables for different BTS models. Even for
OsmoBTS, we still are not signalling codec capabilities over A-bis OML
in a way that would allow the BSC to automatically pick up which codecs
are suppored by a given BTS. So here we are normally configuring the
actual capabilities of the BTS hardware used.
On the BSC side, the codec configuration is mostly about policy. It
could also be a restriction of what the media gateway (which may not
always have to be osmo-mgw) supports.
So why would the BSC want to limit the codecs that the MSC supports?
- only the BSC knows its MGW (or is supposed to know) and its
capabilities - only the BSC knows the details of the A-bis transport, which may be
RTP or E1/T1 based
What I find a bit odd is the different syntax between the codec-support
on the per-BTS level. It's odd that on the BTS side we call it
hr/efr/amr, while on the BSC/MSC level we call it hr1/fr2/...
This syntax should probably be unified to avoid confusion
Updated by laforge over 6 years ago
- Due date set to 01/05/2018
- Start date changed from 12/15/2017 to 01/05/2018
- Follows Feature #2817: extend TTCN-3 test with testing of each different voice codec added
Updated by laforge about 6 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
this is meanwhile fully supported, and we have TTCN-3 tests to verify assignment with all 5 codec types.
