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/.
Peter Stuge peter at stuge.seLabs wrote: > Am I missing something? Sorry for saying that but it looks like to > me that it is an appliance. I understand your reasoning. Some points come to mind: * An appliance is an integrated system and not only a software package OpenBSC can certainly be part of something larger, but it is "just" a software package, even if a very comprehensive one. So far I don't know about any open source appliances using OpenBSC. One thing that might be interesting to make the very first testing easier would be a preconfigure VM image that could be started to have an OpenBSC running in seconds, for when the environment being used is not so convenient for downloading and building the source, and configuring network interfaces. We had some tangential discussions at 28c3 in Berlin between X-mas and NYE, where we last ran an OpenBSC test network. * The OpenBSC software may be integrated in many different ways OpenBSC does not neccessarily run only on Linux operating systems (maybe this is actually a requirement now, but I don't think it needs to be, and generally it is good to have software be portable across many different operating systems) - this is significant because any interface configuration is always highly system specific, and every integration will have different processes here. Following the UNIX principle, this is outside the scope of OpenBSC. Ie. interface configuration is one step considered belonging to the base system, while software configuration to use those interfaces is a separate step which needs to match the system base configuration. I actually don't think it is such a bad idea to also have OpenBSC be involved in, or even take responsibility for, some interface configuration, but this may well require some significant changes in the source code, so it will not happen very quickly. If it happens I would argue that OpenBSC should configure only those interfaces which are related to GSM, and that they be kept separate from the "regular" interfaces used by the system. Such a change will tie OpenBSC more strongly to the particular operating systems it runs on, which is generally considered a bad thing. However, I agree with you that there is a certain value to indeed have all GSM-network-related configuration, including IP, in the configuration file. Also note that I'm not really a core developer, so even if I kindof like the idea that does not have to mean very much. :) > I didn't install yet the OpenBSC but as I said in a previous email > I will have it done by the end of next week and check all configs. You should be able to do it rather quickly, also without being a programmer. The dependencies are not very many. > I was thinking that you already have everything implemented in OpenBSC > (BSC/MSC/VLR/HLR/AuC/EIR/SGSN/GGSN) and the only interfaces out are Abis > (IP or E1) and another ethernet for management of OpenBSC box. > So from my assumption above it started the idea with all-in-one > config and GUI for the mentioned pieces of this puzzle. > > I guess I am wrong here... GUI or CLI is a matter of (sometimes strong) taste. I think it's fine to have different types of user interfaces, but this will possibly require re-engineering of the existing CLI config interface a bit, so that other types of interfaces can be integrated seamlessly. Of course it's also possible to build a GUI which in fact just uses the CLI and has nice buttons to click on. All relevant information must be available through CLI anyway. > I will/can write documentation based on my tests and real life > experience. We need to discuss more on this topic. All contributions are valuable, and you absolutely don't have to be a programmer to be able to contribute. Documentation contributions, in particular from real life experience, are indeed very welcome! //Peter