Feature #2289
closedimplement AoverIP (OsmoMSC side)
100%
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
Updated by neels almost 7 years ago
- Related to Feature #1846: Implement AoverIP specific procedures, message extensions and information elements added
Updated by neels almost 7 years ago
- Related to Bug #2265: OsmoMSC must DLCX after a voice call is done added
Updated by neels almost 7 years ago
- Related to Bug #2279: osmo-mgcp-gw: Fix: cleanup of transaction IDs aka port numbers to be used by the MGCP gw added
Updated by neels almost 7 years ago
- Related to Feature #2260: "next generation" osmo-bsc_mgcp added
Updated by neels almost 7 years ago
- Related to Feature #2281: allow multiple MGCP-GW per MSC added
Updated by neels almost 7 years ago
- Related to Feature #2290: drop the '#if BEFORE_MSCPLIT' disabled code added
Updated by neels almost 7 years ago
- Subject changed from implement AoverIP to implement AoverIP (OsmoMSC side)
Updated by neels over 6 years 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.
Updated by dexter over 6 years ago
- Related to Feature #2396: Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-msc added
Updated by dexter over 6 years ago
- Related to Bug #2333: osmo_sock_init2() called from osmo_sccp_simple_client() may never return added
Updated by dexter over 6 years ago
- Related to Feature #2397: let osmo-msc record location area from location update for LAC wide paging added
Updated by dexter over 6 years ago
- Related to Bug #2351: unify sccp instance configuration added
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years ago
Quick summary with updates from last week:
- Focussed on osmo-mgw, see also #2454
- Minor fix for osmo-msc
Updated by dexter over 6 years 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)
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by dexter over 6 years 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.
Updated by neels over 6 years 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??
Updated by dexter over 6 years 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.
Updated by dexter over 6 years ago
Quick summary with updates from last 7 days:
- We now use osmo-mgw also on the osmo-msc side. This means that the osmo-bsc_mgcp and its quirks are longer in use.
- There was a protocol problem with osmo-mgw, the mgw has to assign the connection IDs, not the call agent. This is now fixed.
Updated by laforge over 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100