Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-05T09:25:36ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://projects.osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://projects.osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> Cellular Network Infrastructure - Bug #6122 (New): remove big endian supporthttps://projects.osmocom.org/issues/61222023-07-31T09:46:32Zosmith
<p>Follow-up to <a class="external" href="https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/">https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/</a></p> Core testing infrastructure - Bug #5919 (New): osmo-python-tests: Update/fix README or setup processhttps://projects.osmocom.org/issues/59192023-02-22T18:25:53Zarehbein
<p><code>osmo-python-tests/README</code> states three ways of installation. Two of these failed for me:</p>
<pre>
$ pip3 install --verbose --user -e .
...
Installing collected packages: osmopython
Running setup.py develop for osmopython
Running command /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix=
running develop
running egg_info
error: [Errno 13] Permission denied
ERROR: Command errored out with exit status 1: /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix= Check the logs for full command output.
Exception information:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 223, in _main
status = self.run(options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/cli/req_command.py", line 180, in wrapper
return func(self, options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/commands/install.py", line 421, in run
installed = install_given_reqs(
File "/usr/lib/python3/dist-packages/pip/_internal/req/__init__.py", line 82, in install_given_reqs
requirement.install(
File "/usr/lib/python3/dist-packages/pip/_internal/req/req_install.py", line 800, in install
install_editable_legacy(
File "/usr/lib/python3/dist-packages/pip/_internal/operations/install/editable_legacy.py", line 49, in install_editable
call_subprocess(
File "/usr/lib/python3/dist-packages/pip/_internal/utils/subprocess.py", line 261, in call_subprocess
raise InstallationSubprocessError(proc.returncode, command_desc)
</pre>
<p>Seems like the command is throwing an error, because the prefix option is passed with an empty argument, but I don't know.</p>
<p>For checkinstall, the Debian package isn't built if one leaves the default value for version (<code>test</code>), since it hast to begin with a digit:</p>
<pre>
dpkg-deb: error: parsing file '/var/tmp/tmp.6EyaipPJOV/package/DEBIAN/control' near line 7 package 'osmo-python':
'Version' field value 'tests-1': version number does not start with digit
</pre>
<p>Outputs for each command are attached.</p> libosmo-sccp + libosmo-sigtran - Bug #5899 (New): ttcn3-sccp-test-latest is actually running code...https://projects.osmocom.org/issues/58992023-02-09T16:40:05Zosmith
<p>In jenkins.sh:</p>
<pre>
# Always require osmo-stp-master since is the only with sccp_demo_user installed
docker_images_require \
"osmo-stp-master" \
"ttcn3-sccp-test"
</pre>
<p>A way to resolve this would be packaging the demo programs sccp_demo_user (and _server?) in a -demos subpackage.</p>
<p>We only have one test in the testsuite, so this doesn't have much of an impact, just noting for future reference.</p> Cellular Network Infrastructure - Bug #5887 (New): coverity: build everything in docker container...https://projects.osmocom.org/issues/58872023-02-01T10:25:23Zosmith
<p>Currently the coverity scripts are not automatically tested before merging, and when they fail it is quite some effort to reproduce the errors as one has to manually install all dependencies (and missing ones only show up half-way through the build when something fails). Also libusrp requires sdcc 3, while e.g. on this system I have sdcc 4 installed.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://projects.osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> OsmoMSC - Bug #5568 (Stalled): SMPP socket doesn't use TCP_NODELAYhttps://projects.osmocom.org/issues/55682022-05-17T18:33:30Zlaforge
<p>The SMPP socket uses sockets directly (without relying on libosmo-netif/stream) and fails to setsockopt(TCP_NODELAY). This is not critical (SMS is sloooow), but it does add unintended latency to all SMPP messages sent.</p>
<p>The quick fix is to add the setsockopt for every socket we accept(). The clean-up would be to use libosmo-netif/stream...</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://projects.osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a> any ideas?</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://projects.osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://projects.osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></p> Cellular Network Infrastructure - Bug #4069 (New): Implement IPA PING/PONG mechanism everywherehttps://projects.osmocom.org/issues/40692019-06-21T14:44:02Zlaforge
<p>As was seen in <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Prolonged remaining in state with RSL link gone, OML link open (Closed)" href="https://projects.osmocom.org/issues/4061">#4061</a>, we're not doing a good job in closing connections if they're dead. Let's improve this situation by implementing an IPA PING sender / PONG receiver which closes+reconnects (client) or simply closes (server) the respective connection.</p>
<p>I recently added ipa_keepalive_fsm_start to libosmo-abis. It's used only in osmo-remsim,<br />but should probably be used by virtually any of our programs that implement IPA<br />multiplex, starting from BTS (Abis), BSC (Abis), MSC (SCCPlite, GSUP), HLR (GSUP),<br />all our CTRL interfaces, ... - but anything beyond RSL+OML in BTS+BSC is out of scope for this<br />ticket. I'll add separate tickets about this.</p>
<p>Whether or not that specific FSM is used: The IPA PING/PONG logic should exist everywhere.</p> Cellular Network Infrastructure - Feature #3982 (Feedback): osmo-depcheck.py: set dependency hash...https://projects.osmocom.org/issues/39822019-05-07T13:48:30Zosmith
<p>Right now, osmo-depcheck.py (from osmo-ci.git) always uses the versions of the dependencies that are specified in configure.ac of the Osmocom project that is being tested.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> was just using the script and wanted to check if a project builds against a specific commit of a dependency. He said, it would be nice to have something like:</p>
<pre>
./osmo-depcheck.py -b osmo-msc:7231edb7321a238851387479df0ee16d6c936de0[libosmocore:aa98c481fa7888e2bcd9d5c9ae1993744ee47f33]
</pre>
<p>(so after the project:hash, add [] with a list of dependencies)</p> Cellular Network Infrastructure - Feature #3477 (New): add a wiki page explaining interconnection...https://projects.osmocom.org/issues/34772018-08-20T09:21:37Zneelsnhofmeyr@sysmocom.de
<p>The <a class="wiki-page" href="https://projects.osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box">Osmocom Network In The Box</a> wiki page explains running components on the same machine.<br />As soon as this is split up between several boxes, numerous config items become necessary to set bind-addresses and remote addresses.<br />Each user manual should explain this, but it would also be nice to have a common wiki page guiding through this process.</p> Cellular Network Infrastructure - Feature #3386 (New): Generate man pages at build time from adoc...https://projects.osmocom.org/issues/33862018-07-06T10:24:03Zpespin
<p>Once we have documentation being build in each project repository separately (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Move project specific manuals from osmo-gsm-manuals to each respective git repository (Resolved)" href="https://projects.osmocom.org/issues/3385">#3385</a>), we want to generate man pages for each repository.</p>
<p>The idea here is to have an .adoc file with all the required content to be used in the man pag, and which is already included in the user manual. Then we need to scripts/makefile to transform this .adoc file into man source format and make it be build and installed when --enable-man is passed. Then, install it in the debian packages (which means we in turn need to modify dh_configure or similar to pass the --enable-man flag, and somehow include the common osmo-gsm-manuals.git in there when sending to OBS).</p> Cellular Network Infrastructure - Bug #3382 (New): Investigate and fix lintian issues listed by D...https://projects.osmocom.org/issues/33822018-07-05T11:37:34Zpespin
<p>This web page lists a list of warnings which we may want to fix: <a class="external" href="https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html">https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html</a></p> OsmoBSC - Feature #3330 (New): osmo-bsc: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://projects.osmocom.org/issues/33302018-06-08T12:14:49Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>It's probably more useful to implement it in osmo-bts (see <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDED (New)" href="https://projects.osmocom.org/issues/3329">#3329</a>), but we may still want to support it in osmo-bsc if we connect to non osmo-bts which don't craft IMMEDIATE ASSIGNMENT EXTENDED from regular IMMEDIATE ASSIGNMENT on their own. I imagine for instance an scenario osmo-bsc<->nanobts.</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> OsmoBTS - Feature #3329 (New): osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://projects.osmocom.org/issues/33292018-06-08T12:02:32Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>So we don't need to support IMMEDIATE ASSIGNMENT EXTENDED in osmo-bsc, we can already craft them in osmo-bts (bts.c) in a way similar to what we already do with IMMEDIATE ASSIGNMENT REJECT commands (we couple up to 4 messages in one in there).</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> Cellular Network Infrastructure - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://projects.osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://projects.osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoMSC - Bug #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://projects.osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</p> OsmoMSC - Bug #2928 (New): OsmoMSC doesn't do BSSMAP ASSIGNMENT if no MNCC_RTP_CREATE is receivedhttps://projects.osmocom.org/issues/29282018-02-11T10:35:23Zlaforge
When operating OsmoMSC with external MNCC handler, it seems that it "forgets" to
<ul>
<li>perform BSSMAP ASSIGNMENT procedure</li>
<li>perform CRCX/MDCX on MGW endpoint for RAN side<br />if the eternal MNCC handler is not sending the MNCC_RTP_CREATE.</li>
</ul>
<p>This is wrong and indicates the state machines have some trouble.</p>
<p>The voice call should be established towards MS/RAN/MGW as usual, no matter if and when an external MNCC handler decides to actually connect to the MSC-located MGW. The MNCC_RTP_{CREATE,MODIFY} should only be translated to CRCX/MDCX of the mncc-side connection to OsmoMGW, and not anything on the RAN side.</p> libosmo-abis - Bug #2571 (New): libosmo-abis API documentation missing (doxygen)https://projects.osmocom.org/issues/25712017-10-11T08:07:35ZlaforgeOsmoBSCNAT - Feature #2545 (Stalled): OsmoBSCNAT misses 3GPP AoIPhttps://projects.osmocom.org/issues/25452017-10-06T12:27:03Zlaforge
<p>osmo-bsc_nat in its current form was written strictly for SCCPlite / IPA multiplex.</p>
<p>It hence doesn't understand the 3GPP AoIP protocol variant, and doesn't use libosmo-sigtran for interfacing with either BSCs or MSCs</p>
In order to be able to use it also with 3GPP AoIP, we will probably need to
<ul>
<li>make sure SCCPlite/IPA support in libosmo-sigtran is complete + validated</li>
<li>port osmo-bscnat over to use libosmo-sigtran as transport interface on both BSC and MSC facing interfaces</li>
<li>run an instance of osmo-mgw next to osmo-bsc_nat for handling RTP and OSMUX media streams to/from BSC and RTP to the (3rd party) MSC</li>
</ul> OsmoHLR - Feature #2542 (Stalled): have subscriber create-on-demandhttps://projects.osmocom.org/issues/25422017-10-06T02:52:42Zneelsnhofmeyr@sysmocom.de
<p>Especially communal networks that allow 3rd party SIM cards to camp on the network would<br />greatly benefit from a subscriber create-on-demand feature in the osmo-hlr. A new subscriber<br />could be rejected from the network at first, but has then left its IMSI and IMEI in the db.</p>
<p>This implies the ability to disable subscribers even though they are present in the HLR,<br />otherwise anyone showing up would be authorized immediately, which is usually not desirable.</p>
<p>Clarify whether nam_ps/nam_cs or purge_ps/purge_cs are suitable for this purpose,<br />otherwise we'd need another flag per subscriber saying 'authorized', which could be false<br />by default for subscriber create-on-demand.</p> OsmoBTS - Feature #2356 (New): have per-SAPI logging in OsmoBTS DL1P / DL1Chttps://projects.osmocom.org/issues/23562017-07-10T18:31:22Zlaforge
<p>the L1 logging is inherently verbose, particularly for L1P.</p>
<p>It would be nice if one could enable logging only for specific L1 SAPIs, such as SACCH, TCH, FACCH, or the like.</p>
<p>Having different log subsystems is overkill, but maybe the 'log filter' framework can be used for this?</p> OsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://projects.osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://projects.osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> OsmoBSC - Feature #1605 (In Progress): logging / ring buffer for ALERT messages from A-bis OML fr...https://projects.osmocom.org/issues/16052016-02-23T15:59:17Zlaforge
<p>OML ALERT messages are currently not really used much. They should be used more from the BTS side, and the BSC component in the NITB should not only log them somewhere but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.</p> OsmoPCU - Feature #1558 (New): Generate BSSGP LLC Discarded messages on TBF/MS freehttps://projects.osmocom.org/issues/15582016-02-23T15:15:01Zlaforge
<p>If a TBF is freed (e.g. caused by timeout or replacement), the dropped (unsent/unacknowledged) RLC frames are silently dropped. If an MS object is freed (TBF creation failed during the timeout interval), the dropped LLC frames are also not reported. At least counters should be implemented for these cases.</p>
<p>It's a violation of the spec. OsmoSGSN doesn't care, but if you interface with other SGSNs, they might expect to receive such messages in order to optimize their flow control and/or QoS.</p>