IPA multiplex code in libosmo-abis? where to move gsup_client and oap_client?

[Harald Welte]

On Wed, Oct 04, 2017 at 04:31:27PM +0200, Neels Hofmeyr wrote:
> My main open question is: libosmo-abis sounds like it is specifically for the
> A-bis interface.

Correct.  And the IPA multiplex was first encountered by us on Abis, but was
later found at other places (A interface, for example) and even re-used by
us at more interfaces (GSUP).

> But GSUP, which we use to talk to the OsmoHLR, is not at all related to A-bis.

Correct.

> Does it make sense to put it in libosmo-netif? 

No.

> Or move the IPA Multiplex to libosmocore? And hence remove some
> duplication between libosmo-abis and libosmo-netif?

Actually, there is IPA multiplex related code in libosmocore,
libosmo-abis and libosmo-netif.  

* The core helpers should all be in libosmocore (I think the only
  function I would move from libosmo-abis is ipa_msg_push_header(), if
  similar doesn't alrady exist in libosmocore).

* the "stream server / client" implementation fits logically into
  libosmo-netif, where we already have a TCP and SCTP stream server,
  and where we also have the more modern "chan_abis_ipa_srv" code, both
  of which should probably be merged.

* libosmo-abis contains then only the "e1inp" integration of the IPA
  multiplex, i.e. making IPA look like an E1/T1 interface to our BSC.
  As much IPA related code should be reused here.  It uses the
  stream_server, and if that moves to libosmo-netif, we introduce
  a new dependency from libosmo-abis -> libosmo-netif.  However,
  we already have the inverse dependency in libosmo-netif/configure.ac
  where the only user seems to be two example programs that could also
  be moved.

The more interesting question is how to facilitate the related move[s]
without breaking backwards compatibility in every single program.

> Just move gsup to libosmo-abis.git and care later?

I don't like the approach of *knowingly* adding unrelated bits into
"wrong" libraries.  That's different from those cases where we have done
this at the time due to a lack of knowledge.

If the above is too complex and time-consuming (which might be the
case), then I'd rather keep two copies or even introduce a new library.

Regards,
	Harald
-- 
- 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)