Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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.

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.

this is meanwhile fully supported, and we have TTCN-3 tests to verify assignment with all 5 codec types.