Support of AoverIP (AOIP) in osmo-bsc

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/.

Harald Welte laforge at gnumonks.org
Wed Mar 16 09:51:20 UTC 2016


Hi Bindhu,

On Wed, Mar 16, 2016 at 08:16:44AM +0000, Bindhu Anjaneya wrote:

> We went through the OsmoSS7 Erlang code base and the webpage "
> https://projects.osmocom.org/news/30", we see no activity done on
> osmo-ss7 for 3 years.

This is correct.  There are some users that use the code as-is, and
there are some other users we know who have unfortunately still not
found the time to contribute their changes back.  They might even read
this very e-mail...

> Considering the use of osmo-ss7 as the signaling gateway for SUA to
> SCCP/M3UA translation, we have following concerns: 
>
> a. Is osmo-ss7 compliant to latest specifications of SCCP and M3UA?

I would never make such a claim, as it has never been formally tested
against the test suites.  I know for SCCP there are comprehensive tests
in the ITU specs.  In the Osmocom project, with almost no resources
(look at the size of the team and the wide area of tasks we work on), we
never had a chance to neither implement those tests nor to verify the
implementation against those tests.

> b. Does osmo-ss7 implement the complete functionality of the signaling gateway.

It probably depends on what you consider the "complete functionality".

> c. Is osmo-ss7 inter-op tested with 3rd party 3GPP compliant MSC and osmo-BSC.

It has been used in production with several 3rd-party STP and SIGTRAN
implementation.  Specifically, I remember Yate interop with M2PA,
Zynetix interop with SUA, as well as several constellations involving
Cisco ITP.  There were some others, but in that use case, it was never
disclosed what the equipment was that we talk to at the other end.
Those use cases all related to the MAP/CAP over TCAP over SCCP stackings
on the core network interfaces, and never related to the A interface.

How can it be tested with Osmo-BSC, if Osmo-BSC has no SIGTRAN interface
so ar?

> d. After upgrading SUA and the BSSAP, can the osmo-bsc be tested with
> 3rd party MSC by using the osmo-ss7 as signaling gateway? Do you see
> some changes on OsmoSS7 codebase?

This configuration should be possible.  There might be some issues or
bug fixes to osmo-ss7.

The configuration of osmo_ss7 currently also happens in erlang, so there
are no external configuration files or the like.  Basically you use a
erlang 'main' program to stitch together the respective parts of the 

> e. If osmo-ss7 does the complete functionality of the signaling
> gateway  that is translation from SUA to SCCP/M3UA then why to upgrade
> the SCCP and implement M3UA in osmo-bsc  even in future.

Because you complained in your last message about the fact that this
introduces an extra hop and you prefer M3UA inside OsmoBSC.  I
personally don't see the need for that, as I don't mind the one extra
hop.

My primary focus is to have as much functionality within the limited
resources available.  Implementing M3UA yet another time doesn't seem
like a good use of those limited resources.  Using the existing
C-language SUA code and the Erlang-language SUA/SG/SCCP/M3UA/M2PA/M2UA
code sounds like a more efficient use - even if there still might be
bugs or interoperability issues in this code that might need to be
resolved.

For "urgent" users, they might simply meanwhile use an existing non-free
SG to translate SUA to whatever other flavor of CS7 or SIGTRAN they
prefer.

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)



More information about the OpenBSC mailing list