This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn Tue, Jul 18, 2017 at 11:58:58AM +0200, Neels Hofmeyr wrote:
> On Tue, Jul 18, 2017 at 09:48:01AM +0200, Harald Welte wrote:
> > > But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is
> > > that a hard limitation? I'm not at all familiar with the reasons. Will we never
> > > be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
> >
> > I'm not sure why the BSC would ever say something like that. The BSC
> > normally simply picks a codec from the codecs that the MSC permits for
> > the given call. The MSC should be in charge of requesting a specific
> > codec if it wants a specific one.
>
> Been there since late in 2010:
> http://git.osmocom.org/openbsc/commit/?id=7bf66c5a6ee085bb84e5f1de12725d7006cf6a3c
>
> It sounds a bit like this belongs in the MSC instead. So far it's in the
> BSC config's 'msc' item, i.e. telling the BSC the remote MSC's config.
I completely understand that there is a point to having a policy that
can be configured at the BSC to restrict its supported codecs for
whatever local policy/configuration reason. This makes complete sense.
I however don't understand why we should enforce that this policy does
not include both a restriction for which codecs to use on TCH/H and also
which codecs to use on TCH/F.
Holger, do you remember?
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)