legacy codecs / mixing rates and versions

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.org
Tue Jul 18 10:05:35 UTC 2017


On 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)



More information about the OpenBSC mailing list