This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deRecently, dexter has added this commit: http://git.osmocom.org/osmo-bsc/commit/?id=b9d3c71af347906cef2bb54be57418a948d17b14 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181016/2b6d437c/attachment.bin>