osmo-bsc does not send the correct S0-S15 bits for AMR in the Assignment Compl Message.
AMR supports a variety of fine rates and settings. Those are set via S0-S15 in the speech codec list that is sent by the MSC to the BSC. the BSC may then choose a configuration and return it back via the ASSIGNMENT COMPLETE message.
In the documented case the S0-S15 were set to 0x0200, but we return 0xFF57. This looks problematic and when checking the source code one can see in assignment_fsm.c:send_assignment_complete() that the speech codec element is computed using gsm0808_speech_codec_from_chan_type(). This function only has perm_spc as input which is an integer and basically only sets the codec type and S0-S15 are populated with standard values. This is presumably not enough, we should take the S0-S15 from the speech codec list in the ASSIGNMENT REQUEST and work with it.
- File 01_COMPLETE_LAYER_3_INFO.png 01_COMPLETE_LAYER_3_INFO.png added
- File 02_ASSIGNMENT_REQUEST.png 02_ASSIGNMENT_REQUEST.png added
- File 03_ASSIGNMENT_COMPLETE.png 03_ASSIGNMENT_COMPLETE.png added
- Status changed from New to In Progress
- % Done changed from 0 to 70
The S0-S15 for AMR are no longer hardcodec in osmo-bsc. We now take the configuration bits from the ASSIGNMENT REQUEST and do an intersection between our BSS capabilities. This intersected bits are then returned with the ASSIGNMENT COMPLETE message in speech codec (choosen).
Attached one finds the wireshark screenshots of the speech codec data as they look now. One can see, we first advertise a variety of options, then the MSC limits the options and we agree. However, in this particular example the 0x0200 looks suspicious. I checked the bit ordering against the spec multiple times and I am confident that our endieness is correct, but 0x0200 does not make much sense to me. We probably need to discuss this next week.
See also: https://gerrit.osmocom.org/#/c/osmo-bsc/+/11060 codec_pref: handle S0-S15 in ASSIGNMENT REQUEST