Actions
Bug #6217
openBearer Capability mismatch in MT SETUP
Start date:
10/10/2023
Due date:
% Done:
0%
Resolution:
Spec Reference:
Description
While investigating #6216, I noticed that the Bearer Capability in MT SETUP looks weird and does not match such in the MO SETUP.
[frame 9] MO Setup (from SE K800):
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
[frame 22] MT Setup (from osmo-msc):
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 5
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
osmo-msc.git 1792ba92c1f939fb232e25ae1124eda7bb11983f (1.11.1)
libosmocore.git 435856be518c9d3531ae5b8cbadac1474d521f3a
Files
Updated by fixeria 7 months ago
- Status changed from New to In Progress
The MT Setup is crafted in gsm48_cc_tx_setup(). I created a breakpoint and AFAICS, the sdp_audio_codecs_to_bearer_cap() yields weird results:
(gdb) p (int)memset(&bearer_cap, 0, sizeof(bearer_cap))
$19 = 2135729648
(gdb) p bearer_cap.speech_ver[0] = -1
$20 = -1
(gdb) p bearer_cap
$21 = {transfer = 0, mode = 0, coding = 0, radio = 0, speech_ctm = 0, speech_ver = {-1, 0, 0, 0, 0, 0, 0, 0}, data = {rate_adaption = GSM48_BCAP_RA_NONE, sig_access = 0, async = 0, nr_stop_bits = 0, nr_data_bits = 0,
user_rate = 0, parity = GSM48_BCAP_PAR_ODD, interm_rate = 0, transp = GSM48_BCAP_TR_TRANSP, modem_type = GSM48_BCAP_MT_NONE}}
(gdb) p sdp_audio_codecs_to_bearer_cap(&bearer_cap, &trans->cc.local.audio_codecs)
$22 = 4
(gdb) p bearer_cap
$23 = {transfer = 0, mode = 0, coding = 0, radio = 0, speech_ctm = 0, speech_ver = {4, 5, 11, 0, -1, 0, 0, 0}, data = {rate_adaption = GSM48_BCAP_RA_NONE, sig_access = 0, async = 0, nr_stop_bits = 0, nr_data_bits = 0,
user_rate = 0, parity = GSM48_BCAP_PAR_ODD, interm_rate = 0, transp = GSM48_BCAP_TR_TRANSP, modem_type = GSM48_BCAP_MT_NONE}}
Updated by fixeria 7 months ago
Hm, things starting to make sense after reading the source code. So we have the following input:
(gdb) p trans->cc.local.audio_codecs
$39 = {count = 2, codec = {{payload_type = 112, subtype_name = "AMR", '\000' <repeats 12 times>, rate = 8000, fmtp = "octet-align=1", '\000' <repeats 50 times>}, {payload_type = 3, subtype_name = "GSM", '\000' <repeats 12 times>,
rate = 8000, fmtp = '\000' <repeats 63 times>}, {payload_type = 111, subtype_name = "GSM-HR-08\000\000\000\000\000\000", rate = 8000, fmtp = '\000' <repeats 63 times>}, {payload_type = 111,
subtype_name = "GSM-HR-08\000\000\000\000\000\000", rate = 8000, fmtp = '\000' <repeats 63 times>}, {payload_type = 0, subtype_name = '\000' <repeats 15 times>, rate = 0,
fmtp = '\000' <repeats 63 times>} <repeats 12 times>}}
(gdb) p trans->cc.local.audio_codecs.codec[0]
$40 = {payload_type = 112, subtype_name = "AMR", '\000' <repeats 12 times>, rate = 8000, fmtp = "octet-align=1", '\000' <repeats 50 times>}
(gdb) p trans->cc.local.audio_codecs.codec[1]
$41 = {payload_type = 3, subtype_name = "GSM", '\000' <repeats 12 times>, rate = 8000, fmtp = '\000' <repeats 63 times>}
Basically AMR and FR. We pass this to sdp_audio_codecs_to_bearer_cap(), which calls sdp_audio_codec_add_to_bearer_cap() for each codec:
/* Try to convert the SDP audio codec name to Speech Versions to append to Bearer Capabilities.
* Return the number of Speech Version entries added (some may add more than one, others may be unknown/unapplicable and
* return 0). */
int sdp_audio_codec_add_to_bearer_cap(struct gsm_mncc_bearer_cap *bearer_cap, const struct sdp_audio_codec *codec)
{
const struct codec_mapping *m;
int added = 0;
foreach_codec_mapping(m) {
int i;
if (strcmp(m->sdp.subtype_name, codec->subtype_name))
continue;
/* TODO also match rate and fmtp? */
for (i = 0; i < m->speech_ver_count; i++)
added += bearer_cap_add_speech_ver(bearer_cap, m->speech_ver[i]);
}
return added;
}
In the codec mapping we do have several AMR related entries:
{
.sdp = {
.payload_type = 112,
.subtype_name = "AMR",
.rate = 8000,
/* AMR is always octet-aligned in 2G and 3G RAN, so this fmtp is signalled to remote call legs.
* So far, fmtp is ignored in incoming SIP SDP, so an incoming SDP without 'octet-align=1' will
* match with this entry; we will still reply with 'octet-align=1', which often works out. */
.fmtp = "octet-align=1",
},
.mgcp = CODEC_AMR_8000_1,
.speech_ver_count = 1,
.speech_ver = { GSM48_BCAP_SV_AMR_F },
.mncc_payload_msg_type = GSM_TCH_FRAME_AMR,
.has_gsm0808_speech_codec = true,
.gsm0808_speech_codec = {
.fi = true,
.type = GSM0808_SCT_FR3,
.cfg = GSM0808_SC_CFG_DEFAULT_FR_AMR,
},
.perm_speech = GSM0808_PERM_FR3,
.frhr = CODEC_FRHR_FR,
},
{
/* Another entry like the above, to map HR3 to AMR, too. */
.sdp = {
.payload_type = 112,
.subtype_name = "AMR",
.rate = 8000,
.fmtp = "octet-align=1",
},
.mgcp = CODEC_AMR_8000_1,
.speech_ver_count = 2,
.speech_ver = { GSM48_BCAP_SV_AMR_H, GSM48_BCAP_SV_AMR_OH },
.mncc_payload_msg_type = GSM_TCH_FRAME_AMR,
.has_gsm0808_speech_codec = true,
.gsm0808_speech_codec = {
.fi = true,
.type = GSM0808_SCT_HR3,
.cfg = GSM0808_SC_CFG_DEFAULT_HR_AMR,
},
.perm_speech = GSM0808_PERM_HR3,
.frhr = CODEC_FRHR_HR,
},
Updated by fixeria 7 months ago
- Status changed from In Progress to Feedback
- Assignee changed from fixeria to neels
So AFAIU, the MT Bearer Capability does not necessarily need to match the MO Bearer Capability. But:
- we need to take what the BSS supports into account, right?
- for instance, osmo-bts does not support V6 (OHR-AMR, 8-PSK modulated);
- given that we don't do transcoding, we're limited to what the MO side supports;
- V6 (OHR-AMR) is clearly not reported as supported by SE K800i, so why do we include it in MT Setup?
neels does that make sense to you?
Updated by fixeria 7 months ago
- File osmo_msc_codec_mo_success.pcapng.gz osmo_msc_codec_mo_success.pcapng.gz added
- File osmo_msc_codec_mt_fail.pcapng.gz osmo_msc_codec_mt_fail.pcapng.gz added
As was requested in the IRC, adding MO + MT PCAPs with gsmtap logging included.
Actions
