Hi Harald,
I think it is indeed best to apply a fix to
libosmocore, where the parser
is. The functional split is a bit ... arbitrary ... there.
If we are going to put this logic inside gsm48_decode_bearer_cap(),
then we have to do it fully by the spec, decoding not only the FR1-only
possibility, but also the two possibilities of both FR1 and HR1
supported, with the order of preference determined by the radio channel
requirement bits. Please see attached patch for a rough first-order
implementation.
In my other proposal (putting the logic in mncc_bearer_cap_to_channel_type()
in OsmoMSC) I was able to "cheat" in terms of omitting HR1 support -
but only because that function already has pre-existing logic that
actively suppresses HR1 as a matter of policy. But if we are patching
the generic bearer cap IE decoding function, then I argue that we must
not cheat in such manner.
Is either of you going to submit the patch (with or
without unit test)
via gerrit?
I don't have a time budget to do all that formal process right now [1],
but if no one else beats me to it, I will come back to this issue at
some later time. If Lennart or Harald or anyone else would like to
use the patch attached to this email as a starting point (or even to
submit it exactly as-is), please have at it.
M~
[1] In relation to Osmocom CNI, my current work consists of implementing
a voice call gateway between an Osmocom-based GSM network and USA PSTN,
the latter accessed via a wholesale SIP trunk service provider such as
bulkvs.com. I shall discuss this work in another thread.