Attention is currently required from: fixeria, neels, nt2mku.
falconia has posted comments on this change. (
https://gerrit.osmocom.org/c/libosmocore/+/36784?usp=email )
Change subject: gsm48_encode_bearer_cap(): omit octet 3a if only GSM-FR/GSM-HR v1 is
supported
......................................................................
Patch Set 7:
(3 comments)
Patchset:
PS7:
Though, we may still want this patch to be merged,
I am mostly neutral on this part (if others are in agreement with the principal idea, I
would need to take a closer look at the actual patch), but:
since it's making encoding of the MO SETUP more
in-line with 3GPP TS 24.008.
It is not - see my other comment.
PS7:
I always thought that including the Bearer Capability
IE in MO SETUP for a voice call allows to negotiate the resulting voice codec, and the
called MS can include an alternative Bearer Capability IE in MO CALL CONFIRMED message,
but this does not seem to be the case
No, it is not the case. The speech version list is defined in the MS->network direction
only; if a network sends it in the other direction, that behavior is a bug in itself.
While the spec does not directly tell network-side to not do it, it does say that the MS
*shall* ignore these bits on receipt. Of course there may be broken MS that do something
with these bits other than ignore them (if received from network which "shouldn't
ever happen"), but having the MSC send them in the hope of "negotiation"
can only make things worse (on those hypothetical broken MS), never better.
and only applies to data calls?
Even with data calls it isn't negotiation per se: the MS needs to know that it is a
data call and not speech, and the exact type of data call is set by the source.
File tests/gsm0408/gsm0408_test.err:
https://gerrit.osmocom.org/c/libosmocore/+/36784/comment/bd043b16_cd9ce168
PS7, Line 4:
According to 3GPP TS 24.008, section 10.5.4.5.1, octet
3a etc. shall be
included only if the mobile station supports CTM text telephony
or if it
supports at least one speech version for GERAN other than V1 (FR or HR).
Except that this language (with "shall") does not actually appear anywhere in
the spec, or at least I don't see it. If you see it in the spec, can you please cite
the exact spec version, PDF page number and location on the page of this supposed
wording?
In the MS to network direction, the spec merely allows the MS both options, and tells the
network how to decode both. Old MS, those that predate EFR, will only send the short form,
but newer MS will typically transmit the long form even if you configure them (AT%SPVER)
to disable the newer codecs.
--
To view, visit
https://gerrit.osmocom.org/c/libosmocore/+/36784?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ia09abb32a8458384151a6ae28744835ea440fc5b
Gerrit-Change-Number: 36784
Gerrit-PatchSet: 7
Gerrit-Owner: nt2mku <degrunert.web(a)googlemail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-CC: falconia <falcon(a)freecalypso.org>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: nt2mku <degrunert.web(a)googlemail.com>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 28 May 2024 22:36:37 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: falconia <falcon(a)freecalypso.org>
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment