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 07:48:01 UTC 2017


Hi Neels,

On Mon, Jul 17, 2017 at 10:09:27PM +0200, Neels Hofmeyr wrote:
> Today I checked the new AoIP core network using an old Nokia 1100 handset,
> which confronted me with codecs.

what you are observing is the de-facto situation for the NITB for many
years. Unfortunately nobody has investigated this thoroughly and
implemented a solution.

In classic/commercial GSM networks a call is always transcoded, so
basically at the level between MSCs there is PCM audio, and somewhere
(typically already at the BSC) the voice is transcoded for each of the
two call legs.

There's a convoluted mechanism called "tandem free operation" (TFO) in
which the two transcoders can use the LSB of the PCM audio samples to
implement a "covert channel" by which they can detect their presence
and simultaneously switch both transcoders off.  This is to avoid the
speech quality degradation that happens by transcoding twice,
particularly with HRv1.

None of the above is implemented, as we take a "we don't transcode in
OsmoNITB" attitude.  The problem (or rather difficulty) with that is
that in a mobile-to-mobile call, we don't yet know the least common
denominator of the codecs supported by both the MO call leg and the MT
call leg until very late (after having paged the subscriber,
authenticated him and performed the first couple of CC message
exchange). Please note that we actually need to take the codec
restrictions of all elements into consideration, i.e.
* capabilities of the phone(s)
* capabilities of the BTS(s)
* capabilities + policy of the BSC(s)
* capabilities + policy of the MSC(s)

Where it becomes even more interesting in the new post-NITB world is
once we have calls between two subscribers at different MSCs, where the
codec capabilities / negotiation will have to be forwarded between them
e.g. by means of SIP :)

"It just needs to be implemented"  There should be open tickets about
this for about a decade now.  Sadly it seems nobody has had a
significant enough interest or need to actually get it done.

> 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.

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