legacy codecs / mixing rates and versions

historical

Today I checked the new AoIP core network using an old Nokia 1100 handset,
which confronted me with codecs.

The Nokia 1100 says it is capable of FR2, FR1, HR1:

    Channel Type - (Speech)
        Element ID: 0x0b
        Length: 5
        0000 .... = Spare bit(s): 0x00
        .... 0001 = Speech/Data Indicator: Speech (1)
        Channel Rate and Type: Full rate TCH channel Bm.  Prefer full rate TCH (8)
        1... .... = Extension: Additional Octet
        .001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11)
        1... .... = Extension: Additional Octet
        .000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01)
        0... .... = Extension: Last Octet
        .000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05)

The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I
naively thought, let's do:

  codec-list hr3 fr2 hr1

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?

Then I picked:

  codec-list hr3 hr1

That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the
BTS was configured for only TCH/F channels, so instead the Nokia actually got
assigned an FR1 channel). The call was established but no audio worked. I
believe in the OsmoNITB we used to complain in the log that we don't transcode
in such a situation, and the call was aborted...

When I pick
  codec-list hr1
then the call works between the handsets. Again both get assigned FR1 on TCH/F;
if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as
expected.

All in all an interesting situation, which appears to mean that we practically
can't allow the newer codecs alone because older handsets would not work, and
we can't allow both because each side may pick a different one.

Should we wait until we know both sides' codecs and consolidate with each other
to pick matching ones before assigning?  Is that a "late assignment" as in
issue "avoid mismatching TCH/F vs TCH/H pchan types"?
https://osmocom.org/issues/1778
But what if no match can be found? only MGW transcoding will solve all
situations I guess. Are we planning to do that, also with IuUP in mind?
https://osmocom.org/issues/1936
https://osmocom.org/issues/1937

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170717/30359714/attachment.bin>