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....@googlemail.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanits...@sysmocom.de> Gerrit-Reviewer: neels <nhofm...@sysmocom.de> Gerrit-CC: falconia <fal...@freecalypso.org> Gerrit-CC: pespin <pes...@sysmocom.de> Gerrit-Attention: neels <nhofm...@sysmocom.de> Gerrit-Attention: nt2mku <degrunert....@googlemail.com> Gerrit-Attention: fixeria <vyanits...@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 <fal...@freecalypso.org> Comment-In-Reply-To: neels <nhofm...@sysmocom.de> Comment-In-Reply-To: fixeria <vyanits...@sysmocom.de> Gerrit-MessageType: comment
