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