Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

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.

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.

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.

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

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.

Quick summary with updates from last week:

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

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

• 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)

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.

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.

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.

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.

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.

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.

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.

• 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??

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.

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.