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.
gsm48_ie.c.patch2
Description: Binary data
