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 holger at freyther.de> On 21 Feb 2016, at 11:16, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote: > > Not that late really, I looked at bsc_api briefly but saw that it wasn't > helping for IuCS, so I postponed dissecting the (numerous) details of it > to another day. It should come naturally when the A-interface is created. > But in fact my foggy vision so far is that the struct bsc_api will not > actually survive, since the A-interface rx, like IuCS rx, will call > functions directly instead of keeping a struct of function pointers... > IMHO A clearly structured header file would do a nicer job at highlighting > the MSC<->BSC entry points. I am also presuming that we will drop > osmo-nitb as such and replace it with "please run osmo-bsc plugged into > osmo-cscn", BTW. The initial idea was that at the "MSC" the "Complete Layer3 message" (the initial message) would arrive. The MSC would then create an instance of a msc_subscriber_connection (and add a backpointer to the gsm_subscriber_connection which then probably should be called bsc_subscriber_connection). The MM, CC and other code should then refer to the msc_subscriber_connection. In case of osmo-cscn the msc_subscriber_conn would point to the "Iu" definition and for osmo-nitb it would still have the gsm_subscriber_conn backpointer. The other part was that there should be something like msc_api inside the MM/CC code that either directly maps to the BSC code or in case of osmo-cscn send it to the HNBGW. anyway, you will come up with something that makes sense too holger