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)