Hi Neels, On Thu, Feb 18, 2016 at 12:56:20PM +0100, Neels Hofmeyr wrote: If you look at the aper code I took from OpenAirInterface and re-based, you will see that it does not look 100% complete and would probably not yet qualify for submitting it to the upstream asn1c project. The situation is not made better by my hackish way to implement the type prefixing on top of it by means of an environment variable. Specifically, it * contains commented-out code which might just have been a work-around of some buggy code, rather than fit for removal in general * contains TODO comments like "/* TODO: act upon NOTE in #18.7 for canonical PER */" which hints that it is not properly implementing parts of the PER specification * contrary to the rest of asn1c, it does not come with a comprehensive test suiet for the APER encoding and decoding routines of all types Any help in cleaning this code up (it could be done for the type prefixing independent of the APER support) would be much appreciated. The goal is to get this merged in asn1c, after all. It might also be worth to contact the OpenAirInterface guys about their thoughts on moving this code forward. I fear there might be none, as they are using an ancient version of asn1c to begin with. But they are a much larger project and might be convinced to put some resources on doing this properly? Unless we think something is ready for pushing to upstream asn1c, we should keep it out of our local master, too. I pushed one of the two commits to master. However, commit 89118114972d587f623305e410d45eb934900e81 basically just prints some messages to the log file in case there are association state changes like UP and LOST. This is clearly not the intended behavior. The application should be notified accordintly in such events, particularly in 'connection lost' events that can be communicated in the same way as they can for e.g. TCP sockets. Only after that is resolved, we can merge it to master. My main problem with this patch set is naming. We are creating an 'SCCP User SAP' which should look the same no matter what the underlying transport protocol stacking is. Whether it's SUA/SCTP/IP or SCCP/M3UA/SCTP/IP or SCCP/MTP3/M2UA/SCTP/IP or SCCP/MTP3/MTP2/E1 or SCCP/MTP3/MTP2/M2PA/SCTP/IP should not matter to the application. The sccp_sap.h data structures still follow that rule. However the sua.h code (creating a SUA client or server, 'struct osmo_sua_user / struct osmo_sua_link' directly reference SUA. In terms of the function names I don't care really too much, as inevitably an application will somehow need to specify the protocol stacking it would like to use. Either explicitly or implicitly via system-level configuration of the signalling stack. However, the application should not have to keep an 'osmo_sua_user' pointer or an 'osmo_sua_link' pointer in its own data structures. It should be an opaque osmo_sccp_user / osmo_sccp_link structure, so once we change from one underlying stacking to another, the data structures of the application do not have to change. -- - 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)