libosmocore/BSC/MSC: MO voice calls rejected from Siemens S11E (patch included)

Hi,

I had a problem placing MO GSM calls from a Siemens S11E: The calls
were dropped immediately; Osmo-MSC reports "Cannot compose Channel
Type from bearer capabilities"

After investigating the SETUP request from the S11E, the phone does
not use octet 3a (no extension bit set in IE 3). Wireshark decodes the
radio channel requirement as "Full rate support only MS/fullrate
speech version 1 supported", so I added a condition to the gsm48_ie.c
function of libosmocore to include at least GSM FR in the list of
available speech_ver in case octet 3 has no extension.

Attached to this message are the Abis-IP PCAP traces of MO calls, and
the patch for gsm48_ie.c.


Regards,
Lennart

Hi Lennart,

First of all, thank you for being another person who cares about
supporting vintage GSM phones!  As to your proposed patch to gsm48_ie.c
in libosmocore, I have a counterproposal - please see attachment.
Instead of patching gsm48_decode_bearer_cap(), I feel that it would be
more philosophically correct to patch the logic in
mncc_bearer_cap_to_channel_type() in OsmoMSC - I feel that IE encoding
and decoding functions should do just that, perform bit-level encoding
and decoding without higher-level interpretation of the data they
operate on, whereas the desired change is in the interpretation of the
condition of MS not having sent any speech version numbers.

Right now I don't have any phones that are old enough to support only
FR1 codec and not EFR.  As of right now, the oldest working phone in
my collection is Ericsson I888, and even though it's a very old design
(older, higher-voltage internal components than market-release-date
contemporary Nokia DCT3 phones of the famed monitor mode variety), it
already supports both FR1 and EFR.  (Interestingly enough, it does not
support HR codec - but then perhaps I shouldn't be surprised, as I
heard that HR1 is computationally intensive, and whatever ancient DSP
this phone has in it could easily lack the needed horsepower.)

Back to the topic of fixing Osmocom CNI software to work with ancient
FR1-only phones that don't send any octet 3a in their bearer cap IE, I
would appreciate it if someone with more seniority in Osmocom could
weigh in as to the most proper way to do it: would it be Lennart's
proposed patch to libosmocore, or my proposed patch to osmo-msc, or
some other, altogether different approach?

In solidarity for continued preservation and support for GSM/2G,

Lady Mychaela Nadezhda Falconia,
Mother of FreeCalypso,
Dame of the Order of 2G,
Champion of Published Source Code

Hi Lennart and Mychaela,

I think it is indeed best to apply a fix to libosmocore, where the parser
is.  The functional split is a bit ... arbitrary ... there.

The best way to handle this would be to also add a test caes, probably
easiest in terms of a unit test (in libosmocore/tests), showing that
both the longer/later version and the shorter/older version parse
with the correct expectations.  That's not required, but it's the only
way to really ensure it won't break in the future.

Is either of you going to submit the patch (with or without unit test)
via gerrit?
https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

Thanks again,
	Harald

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.

Hi all,

On 7/3/22 01:04, Mychaela Falconia wrote:
> 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.

as was suggested by Harald, I added a testcase (IE LV from PCAP):

https://gerrit.osmocom.org/c/libosmocore/+/28506 gsm0408_test: add a 
testcase for gsm48_decode_bearer_cap()

and submitted Mychaela's gsm48_ie.c.patch2:

https://gerrit.osmocom.org/c/libosmocore/+/28508 gsm48_ie: fix parsing 
of Bearer capability IE without octet 3a

I changed this patch a bit to make our linter happy about coding style.

Best regards,
Vadim.

After studying the SETUP request, it is obvious that octet three lacks an extension bit, mainly for deciphering blunders in Wireshark. To resolve this, I've changed the gsm48_ie.C feature in libosmocore, ensuring GSM FR is protected even if octet three lacks an extension. This enhancement should rectify the Cannot Compose Channel Type from the bearer talents blunders.  Please permit me to create my essay in this successful troubleshooting process.
Visit here : https://bestessaywriter.co.uk/make-my-essay

Wow, these generative AI-backed spambots are getting better every time, I almost started trying to understand what it tried to say.
Eventually we will need to run our own AI that detects these, right? Haha.

Cheers,
Domi

> 2024. jan. 31. dátummal, 8:49 időpontban rokj42540@gmail.com írta:
> 
> After studying the SETUP request, it is obvious that octet three lacks an extension bit, mainly for deciphering blunders in Wireshark. To resolve this, I've changed the gsm48_ie.C feature in libosmocore, ensuring GSM FR is protected even if octet three lacks an extension. This enhancement should rectify the Cannot Compose Channel Type from the bearer talents blunders.  Please permit me to create my essay in this successful troubleshooting process.
> Visit here : https://bestessaywriter.co.uk/make-my-essay