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/.
Holger Freyther zecke at selfish.orgOn Monday 29 March 2010 04:25:02 Harald Welte wrote: Hi LaF0rge, > As far as I can understand the implications of your approach, I > completely agree with it. We need that BSC/MSC split and the resulting > split of bsc-side lchan and msc-side structure. thanks. > > This would involve queuing of messages... > > can you illustrate why that is required? I don't doubt it, but I can't > seem to figure out why... I see why you are wondering. All the messages seem to work with sending a request and then getting an ack. So besides queuing the one message that starts transmitting on a new SAPI in theory we should not need to queue. I have a queue in the on-waves/bsc-master branch just because I have a MSC that was sending more commands even when something like ASSIGNMENT, CIPHER MODE, or SAPI establishment was not yet completed. > So once we really have separate BSC and MSC executables, I'd appreciate > if their naming would also somehow include the osmocom/osmo prefix in > them. I see no issue in putting a osmo_ in front of the executable names and joining all of the different GSM subsystems into the "osmocom" umbrella.