Recently, dexter has added this commit: http://git.osmocom.org/osmo-bsc/commit/?id=b9d3c71af347906cef2bb54be57418a94...
Our osmo-gsm-tester tests fail to pass since this commit thwarts all L3 Complete.
The commit refuses to compose a Layer-3-Complete message if the speech codecs supported by the BSS cannot be included, either because none are configured, or because none remain after all the criteria of finding codecs permitted.
It may be mandatory to include the speech codecs or not, what bugs me is that we even refuse a mere attach to the network just because speech codecs are not available. Those only become interesting much much later, only for voice.
The backwards-compatibility consideration: configurations that have always worked well are suddenly likely to fail. Users will wonder what happened, and we need to avoid that.
I think instead of thwarting L3 Complete entirely, we should loudly error-log, but still send out an L3 Complete while simply omitting the speech codec list. It might be a spec violation for AoIP, but practically works fine, AFAICT. Again, the way to handle this spec violation should be to log an error, not to break all access.
The alternative would be, IMHO, to abort osmo-bsc startup right away, complaining about misconfiguration, if that is possible at all. But no.
Let's allow L3 Complete even in the absence of speech codecs that all participants support. There are USSD and SMS and GPRS that are all going to be broken just because codecs don't match.
The commit right after sets, apparently, the full list of codecs as supported by default. Is that not working? Do we override that in the osmo-gsm-tester config? Either way, even if the allowed codecs are all configured properly, but there is simply no match between MS,BTS,BSC,MSC, we would still refuse LU, right?
Hence I would like to revert above commit / replace with error logging.
@dexter, what do you think? Am I making sense, or am I missing something?
Thanks!
~N
P.S.: in that commit log, it would have been nice to mention the config items that would help solve the situation. It's not entirely clear to me yet what the misconfigured items are on the osmo-gsm-tester setup.
Hello Neels,
See 3GPP_TS_48.008, 3.2.1.32 COMPLETE LAYER 3 INFORMATION : Note 4: "Codec List (BSS Supported) shall be included, if the radio access network supports an IP based user plane interface."
See also: 3GPP_TS_48.008, 3.2.2.103 Speech Codec List "The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator. The length depends on the number and type of Speech Codec Elements to be included. The minimum length of one Speech Codec Element is 1 octet and the maximum length is 3 octets. The maximum number of Speech Codec Elements within the Speech Codec List is not defined."
I think there is no way in leaving the Codec List (BSS Supported) away. The spec is clear on this. I think the reason is because to decide one would have to look into the detap messages and check if the request is about a call or an LU, or an SMS etc.
I am not sure with 3GPP_TS_48.008, 3.2.2.103, the minimum length requirement refers to one item only. So having 0 items in the speech codec list is an allowed situation? If yes, that wold be the correct solution. Including the speech codec list, but with 0 elements. I can make a patch for libosmocore for this. It wouln't take long.
Regarding the warning I don't think that start abortion is a good idea. This could lock out users that want to configure via telnet.
Best regards, Philipp
Hello Neels,
i have checked back with pau. A codec list with 0 elekents is indeed permitted. So I will now change this. In osmo-bsc I will then remove the check, so if the config does not permit any codecs the codec list will have 0 elements.
However, we could also just interpret the spec differently. If we support 0 codecs the network wouln't be able to support an IP based user plane interface and therefore the codec list does not have to be included.
So in fact we found a solution now. I will keep you posted on this.
best regards, Philipp
Hello Neels,
I think I have now fixed the problem. There is also a ticket, please see: http://osmocom.org/issues/3657
best regards, Philipp