Heads-Up on ongoing libosmo-sccp SIGTRAN work

Dear all, so far libosmo-sccp had some code with a partial SCCP implementation that date back to the earliest day of OsmoBSC in 2009, done by Holger. It also contained a SUA implementation which (mostly) I did last year in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support. The latter code is already more 'modern' and uses the osmocom primitives (osmo_prim) between the SCCP User (the application) and the SCCP Provider (the library). Those primitives are modelled after the related specifications. What I'm now wokring on is to get those last SUA related patches finally merged in master, and to * add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in a generic way that they can be shared by all SIGTRAN xUA variants * add M3UA while sharing more code between SUA and M3UA * introduce a MTP SAP based on osmo_prim that can be used on top of M3UA * wrap the existing sccp.c code to use the MTP SAP on the lower end and the SCCP User SAP on the upper edge In the above implementations, I am aiming for implementing SGW, ASP and IPSP roles. However, primary focus is on ASP. In the end, we will be able to stack M3UA and SCCP code using primitives, and interact with the SCCP using the exact same primitives and API as we interact with SUA currently. This will give us: * true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin of their code * a way towards 3GPP compliant AoIP, by using the SCCP User SAP from OsmoBSC. This means that we'll also have to add that SCCP User SAP to the SCCPlite/IPA code that OsmoBSC is using for now. While all of the above sounds great, it somehow hurts me that we have already some (partial?) implementations of M3UA in cellmgr-ng (particularly the osmo-stp application). It hurts me that I'm not able to use the code that Holger wrote in recent years, but I still think it's worth-while to do an implementation centered around osmo_prim for layer-boundaries and osmo_fsm for state machines. So my apologies to Holger on this. It's not "Not Invented Here" syndrome, but I think there are reasons to take a different route than the existing code. I'm of course also looking forward to hearing other opinions on that. [... and while I'm working on this, I also think about introducing some generic inter-layer primitive logging code, so we can enable logging of the primitives at a given SAP without the specific SAP implementation having to implement anything, like we do in terms of osmo_fsm logging] Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)