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/.
Ivan Kluchnikov ivan.kluchnikov at fairwaves.coHi Harald, Thank you for detailed clarification. As I understood from your description, the following changes should be also implemented on osmo-nitb/osmo-sgsn side: * authentication policy handling will be moved from osmo-nitb/osmo-sgsn side to osmo-gsup-hlr * osmo-nitb/osmo-sgsn will not be able to work independently (without connection with osmo-gsup-hlr). Are these points correct? 2016-04-28 22:24 GMT+03:00 Harald Welte <laforge at gnumonks.org>: > Hi Ivan, > > On Thu, Apr 28, 2016 at 06:18:14PM +0300, Ivan Kluchnikov wrote: > > I want to discuss this topic in mailing list, because I think we should > > coordinate our efforts when we work on the same part of project. > > sure. > > > As I found out from Alex, several important points were discussed at > > osmodevcon: > > * reuse gsup protocol for implementing location and authentication > > interface for osmo-nitb > > * get rid of using internal osmo-nitb database and use only subscriber > list > > on osmo-nitb side > > this is correct. > > > Could you please confirm and/or enhance this list? > > The goals of my current work are as follows: > > 1) get rid of synchronous database access from OsmoNITB, which can cause > various problems in loaded setups, or with slow disk: > http://projects.osmocom.org/issues/1592 > > 2) get rid of libdbi, which is buggy and slow: > http://projects.osmocom.org/issues/1591 > > 3) improve concurrent accesses to the database > http://projects.osmocom.org/issues/30 > > 4) UMTS AKA support (can be used over 2G) > http://projects.osmocom.org/issues/1593 > > At the same time, I aim for reducing code differences and code > duplication between the "VLR part" that is effectively inside both the > OsmoNITB/CSCN as well as OsmoSGSN. So basically, SGSN, NITB and CSCN > should all link + use a new "libvlr", which includes the GSUP client and > takes care of SendAuthInfo/UpdateLocation/InsertSubscriberData on the > MSC/SGSN. > > > I see that you moved all gsup related code from openbsc to libosmocore in > > laforge/pending branches. > > correct. > > > Do you have any further plans to continue this development? > > yes, I'm working on it every day since just before OsmoDevCon. > > > As you know, we implemented interface based on gsup for exporting LU from > > osmo-nitb (fairwaves/sup branch), but in our implementation we didn't get > > rid of using internal database. > > Unfortunately there are many features in some branches that have never > been pushed to the mailing list for review. As a result, it is hard to > know what is going on, and also not clear in which status certain code > is. Yes, there's the commitlog mailing list, but that doesn't answer > the question about the status of the code :/ > > > Despite this I guess that our code could be updated and reused for this > > implementation. > > This would indeed be great. > > So far, my work has been focussing on: > > * moving GSUP message parsing to libosmocore > * extending GSUP with code for UMTS AKA > * removing openbsc dependency from GSUP client code > * implementing GSUP server code > * using GSUP server code to implement minimal osmo-gsup-hlr (for historic > reasons still in osmo-auc.git, will probbably be moved eventually). > AUC part (SendAuthInfo) has been implemented for 2G+3G, > UpdateLocation, UpdateLocationGPRS and InsertSubscriberData is still > pending. > > So as you can see, this is so far completely outside the NITB, so I > haven't yet touched that side. If you can propose a set of changes that > removes the existing related code in the NITB and introduces the > asynchronous-ness of the thre relevant operations, I would appreciate > that. Also, any patches related to unification between the 'VLR-like' > functionality on NITB and CSCN would be appreciated. > > If you have any modifications/improvements on the GSUP protocol or > related encode/decode/client functions, please also send them by all > means. Thanks! > > Regards, > Harlad > > -- > - Harald Welte <laforge at gnumonks.org> > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160429/d3bf07be/attachment.htm>