Project

General

Profile

Feature #2289

implement AoverIP (OsmoMSC side)

Added by neels 6 months ago. Updated about 18 hours ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
05/24/2017
Due date:
% Done:

80%

Resolution:

Description

Our standalone OsmoMSC marks the future of the Osmocom core network implementation.
So far it does only IuCS (3G). Also add AoverIP to talk to a standalone BSC (OsmoBSC).
This is closely related to implementing AoverIP in OsmoBSC.


Related issues

Related to OpenBSC - Feature #1846: Implement AoverIP specific procedures, message extensions and information elements Closed 11/18/2016
Related to OsmoMSC - Bug #2265: OsmoMSC must DLCX after a voice call is done Closed 05/16/2017
Related to OsmoMSC - Bug #2279: osmo-mgcp-gw: Fix: cleanup of transaction IDs aka port numbers to be used by the MGCP gw Closed 05/22/2017
Related to OsmoMSC - Feature #2260: "next generation" osmo-bsc_mgcp New 05/16/2017
Related to OsmoMSC - Feature #2281: allow multiple MGCP-GW per MSC Rejected 05/22/2017
Related to OsmoMSC - Feature #2290: drop the '#if BEFORE_MSCPLIT' disabled code Closed 05/24/2017
Related to OpenBSC - Feature #2396: Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-msc Closed 07/24/2017
Related to libosmo-sccp + libosmo-sigtran - Bug #2333: osmo_sock_init2() called from osmo_sccp_simple_client() may never return New 06/20/2017
Related to OpenBSC - Feature #2397: let osmo-msc record location area from location update for LAC wide paging New 07/24/2017
Related to libosmo-sccp + libosmo-sigtran - Bug #2351: unify sccp instance configuration Closed 07/06/2017

History

#1 Updated by neels 6 months ago

  • Related to Feature #1846: Implement AoverIP specific procedures, message extensions and information elements added

#2 Updated by neels 6 months ago

  • Related to Bug #2265: OsmoMSC must DLCX after a voice call is done added

#3 Updated by neels 6 months ago

  • Related to Bug #2279: osmo-mgcp-gw: Fix: cleanup of transaction IDs aka port numbers to be used by the MGCP gw added

#4 Updated by neels 6 months ago

  • Related to Feature #2260: "next generation" osmo-bsc_mgcp added

#5 Updated by neels 6 months ago

#6 Updated by neels 6 months ago

  • Related to Feature #2290: drop the '#if BEFORE_MSCPLIT' disabled code added

#7 Updated by neels 6 months ago

  • Subject changed from implement AoverIP to implement AoverIP (OsmoMSC side)

#8 Updated by neels 4 months ago

@dexter, since this issue is assigned to you, could you update please? It looks like it hasn't even started, yet we've made tremendous progress.

#9 Updated by dexter 4 months ago

  • Related to Feature #2396: Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-msc added

#10 Updated by dexter 4 months ago

  • Related to Bug #2333: osmo_sock_init2() called from osmo_sccp_simple_client() may never return added

#11 Updated by dexter 4 months ago

  • Related to Feature #2397: let osmo-msc record location area from location update for LAC wide paging added

#12 Updated by dexter 4 months ago

  • Related to Bug #2351: unify sccp instance configuration added

#13 Updated by dexter 4 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

I did not update this ticket because I thought it would just serve as an umbrella for the issues listed under related issues. I have now added new pending tickets that are related.

#14 Updated by dexter 4 months ago

Quick summary with updateds from last two weeks:

  • Removed the need to send a DLCX when creating a new MGCP connection
  • Added functionality to check SCCP addresses for plausibility to libosmo-sigtran.
  • Prevent mixing of addresses from different CS7 instances in osmo-bsc
  • Fixed cosmetic bug in osmo-msc to prevent confusing name usage for sccp instances.

#15 Updated by dexter 3 months ago

Quick summary with updates from last week:

  • Improved autoconfiguration of both osmo-msc and osmo-bsc. For osmo-bsc there is now a restriction. Only one MSC can be configured automatically, for more, the user must supply a valid configuration (very rare case anyway)
  • Improved logging, we now use osmo_sccp_addr_name() instead of osmo_sccp_addr_dump() since _name() displays the pointcodes in human readable form, which is simpler to debug.
  • The forced reallocation in the MGCP-GW is now configurable via VTY, so we will not break legacy setups with that.
  • In an ASP application, the default route is now always automatically configured and the VTY command is locked down.

#16 Updated by laforge 3 months ago

do we really think this is still at 30% completion?

#17 Updated by dexter 3 months ago

  • % Done changed from 30 to 80

#18 Updated by dexter 3 months ago

Quick summary with updates from last week:

  • Bugfixes in the VTY, we had problems reading back config files, because in some cases we got "(null)" strings. This now fixed.
  • Added VTY commands in osmo-bsc to trigger the handover procedure manually.
  • Handover tests, after some bugfixes the signalling part of the handover works. Now we need to extend the mgw to support support the switching capablilities we need to handover the rtp stream
  • First experiments with osmo-mgw. Reading through the sourcecode in order to find out how the needed extensions could be implemented.

#19 Updated by dexter 3 months ago

Quick summary with updates from last week:

  • Focussed on osmo-mgw, see also #2454
  • Minor fix for osmo-msc

#20 Updated by dexter 2 months ago

Quick summary with updates from last two weeks:

  • Focussed on osmo-mgw, see also #2454
  • Fixed memory leaks (except for one!) in osmo-msc, see also #2476

#21 Updated by dexter 2 months ago

  • we are now ready to integrate osmo-mgw/mgcp into osmo-bsc (see #2454)
  • integrated the mgcp-client into osmo-bsc
  • implemented sending of CRCX and MDCX for the BTS side. (We have to do the same for the net side and must not forget DLCX for both sides when the call is done)

#22 Updated by dexter about 2 months ago

Quick summary with updates from last week:

  • Fixed review comments for osmo-mgw
  • Moved on with the integration of osmo-mgw into osmo-msc, got some single direction voice transmission functioning today.

#23 Updated by dexter about 2 months ago

Quick summary with updates from last 9 days:

  • Fixed review comments for osmo-mgw
  • Moved on with the integration of osmo-mgw into osmo-msc, the FSM is basically finished, it should by now also handle exceptional cases, but that needs to be tested.

#24 Updated by dexter about 1 month ago

Quick summary with updates from last 12 days:

  • Fixed review comments for osmo-mgw and libosmocore
  • Fixed broken sccp-lite parts in openbsc (was broken because of problems with libosmo-mgcp looks ok now, however one test still does not compile)
  • Debugging and testing of the FSM, now using the new mgcp client API to generate the messages.

#25 Updated by dexter 28 days ago

Quick summary with updates from last 7 days:

  • Fixed review comments for osmo-mgw and libosmocore
  • Tested the implementation against NG40 tester, one segfault and one logic bug fixed, problems transmitting the right IP-address back to receive the voice stream.
  • Implemented a function to find the correct ip-address in libosmocore. Will integrate this as soon as possible into osmo-mgw. (see also #2587)
  • patches for osmo-bsc are now in review process.

#26 Updated by dexter 21 days ago

Quick summary with updates from last 7 days:

  • Got a lot of review comments for the osmo-bsc patches. I have worked through all of them, there were some good ideas (cause codes for the error handler, early termination when mgsp_client responds with an error etc...)
  • Also started to integrate on the automatic ip/interface selection in osmo-mgw. I think it will work out, but only when the CRCX already carries the IP of the receiving entity, which luckily matches our case. In all other cases we must do it the way we already do.

#27 Updated by dexter 14 days ago

Quick summary with updates from last 7 days:

  • The automatic ip/interface selection seems to work fine. During my normal tests there were no problems with that. Also when testing with NG40 it looks fine. At least the signalling is not the reason why there is no hearable audio.
  • Tested osmo-bsc under some odd circumstances (mgw down, differen phones etc.) Fixed some bugs/segfaults in the FSM that controls the MGCP.
  • The FSM that controls the MGW now also supports handover, which means on the bsc side we feature complete from the MGCP point of view. We could now move on and update osmo-msc to the new MGW.

#28 Updated by dexter 7 days ago

Quick summary with updates from last 7 days:

  • osmo-mgw generated oversized RTP packets, the beginning of the packet was valid RTP data, so it was not immediately obvious. This is now fixed
  • Successfully tested against NG40 tester, MO/MT calls work, voice works and MO/MT SMS works.
  • Started integrating osmo-mgw into osmo MSC. The FSM is outlined and partially implemented.

#29 Updated by neels 1 day ago

  • osmo-mgw generated oversized RTP packets, the beginning of the packet was valid RTP data, so it was not immediately obvious. This is now fixed

Does osmo-mgw generate RTP??

#30 Updated by dexter about 18 hours ago

Does osmo-mgw generate RTP??

I expressed this probably a bit misleading. Of course it does not generate the packets itself. It just forwards them. The problem here was just that it appended spurious data to the packets making all packets 4k in size.

Also available in: Atom PDF