Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-24T09:43:35ZOpen Source Mobile Communications
Redmine pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> OsmoMGW - Feature #6171 (In Progress): mgcp-client API: there should be a separate mgcp_codec_par...https://osmocom.org/issues/61712023-09-08T15:21:26Zdexter
<p>This was previously discussed in ticket #5723, which got deleted due to an error.</p>
<p>There is a problem we face with the mgcp_client API. mgcp_client_fsm in particular.</p>
<p>The problem is that we are not able to assign different payload type numbers for the same codec. So it is not possible to have the following configuration:</p>
<p>codec: AMR, payload-type: 112<br />codec: AMR, payload-type: 113</p>
<p>However, this would be necessary in case we want to define AMR once in octet-aligned and once in bandwith-efficient configuration, which brings us to the second problem. Since there is only one mgcp_codec_param struct member "param", which only lets us to define exactly one set of codec parameters we cannot even define two different configurations.</p>
<p>Also in some cases it would be also convenient to circumvent the SDP parsing/generation of osmo-mgcp-client and use a user defined SDP string directly.</p> OsmoBSC - Bug #6159 (New): use paging queue for PAGING messages that come from the BSC co-located...https://osmocom.org/issues/61592023-08-30T12:38:17Zdexter
<p>When a BSC co-located PCU sends a PAGING message to the BSC via PCUIF, then this message is forwarded immediately via RSL as RSL PAGING COMMAND. This illegally circumvents the paging queue of OsmoBSC. The PAGING messages from the PCU should take the route through the paging queue like any other paging does.</p> OsmoPCU - Feature #6150 (New): PCUIF: Use unique identifiers instead of the TLLI as msg_id.https://osmocom.org/issues/61502023-08-25T14:05:40Zdexter
<p>When the PCUIF sends a MAC block for PCH (or AGCH) it may request a conformation when the MAC block is sent. For the conformation an uint32_t message id (msg_id) is used. At the moment we use the TLLI as message identifier. However, on the one hand side the TLLI may not be unique, and on the other hand the TBF may not have a TLLI assigned yet. This is in particular the case when the MS is just attaching to the network and has not completed the GMM attach phase yet.</p>
<p>A solution would be to somehow generate a truly unique identifier inside the PCU and use it when sending MAC blocks through the PCUIF. When the receiving end responds with the confirmation we will have to match the identifier back to the TBF to which it belongs.</p> OsmoSGSN - Feature #6139 (New): test mobility between GERAN (OsmoPCU) and EUTRAN (Open5GS) end to...https://osmocom.org/issues/61392023-08-22T09:55:50Zdexter
<p>The mobility features that we recently added to Open5GS and OsmoPCU were developed and tested against TTCN3 testsuites, but we didn't confirm the functionality on real hardware yet.</p>
<p>To do this we need to create a setup with an OsmoBTS/OsmoPCU based GERAN cell and an appropriate EUTRAN ENB that is controlled by Open5GS. In order to be able to trigger the cell change it may be required to equip the transmittig antennas of both radios with variable attenuators.</p> OsmoBSC - Bug #6059 (New): negotiate GSM-HR RTP packet format explicitlyhttps://osmocom.org/issues/60592023-06-13T10:38:00Zdexter
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-sysmo and osmo-bts-trx use different GSM-HR RTP packet format (Resolved)" href="https://osmocom.org/issues/5688">#5688</a> we have solved the problem that, depending on the BTS model, the BTS may use a different HR-GSM format (RFC5993 vs. TS 101.318. Now the user can chose via a VTY option which format the BTS should emit. This improves the situation a lot.</p>
<p>However if conversion is still needed for some reason, OsmoMGW will still blindly convert TS 101.318 to RFC5993 and vice versa. This means that there is a problem in case there is one BTS That speaks TS 101.318 and another one that speaks RFC5993 on the same MGW. OsmoMGW can already be explicitly instructed via SDP (similar to AMR BWE/OE) which format to use. We should add a VTY option to osmo-bsc so that we can specify the format we want to use on the link pointing to the core network side. Doing so, the MGW would accept any format on the leg pointing to the BTS and emit the specified format on the leg pointing towards the core network.</p>
<p>Unfortunately osmo-mgcp-client does not yet have the API to specify the format. #5723 already deals with the problem but this also means that this ticket is blocked by #5723</p> OsmoSGSN - Feature #6050 (Closed): Add missing testcase to test GERAN originated RIM RAN informat...https://osmocom.org/issues/60502023-06-02T15:08:09Zdexter
<p>At the moment we only have a testcase for an EUTRAN originated RAN information request that targets a GERAN cell (TC_rim_eutran_to_geran). We have no testcase that tests the reverse direction, which is equally important. (We also have no testcase for requests that go from EUTRAN to EUTRAN.)</p>
<p>We should add those two missing testcases to the testsuite in order to be sure that RIM message forwarding is working correctly.</p> OsmoPCU - Feature #6044 (Resolved): Extend osmo-pcu and related TTCN3 tests so that PacketCellCha...https://osmocom.org/issues/60442023-05-25T10:18:53Zdexter
<p>At the moment we only test PacketCellChangeNotification (which triggers the RAN information request cascade) with 2G cells. Also osmo-pcu is currently only able to understand PacketCellChangeNotification requests that contain 2G cells as well.</p>
<p>In order to improve NACC/CCO support towards 3G and most importantly 4G we must extend the TTCN3 tests and osmo-pcu. On the TTCN3 testsuite this essentially means to complete the missing bits in the message records of RLCMAC_CSN1_Types.ttcn. Once that is done we can complete the testcases and use those to complete osmo-pcu. There we mainly have to take care that the 3G/4G target cell information is properly encapsulated in RIM messages. There may also be missing bits in the reverse path when the cell information is encapsulated in PacketNeighbourCellData messages and passed back to the MS/UE.</p> OsmoPCU - Bug #6015 (New): osmo-pcu (with ericsson RBS) is unable to keep TRAU frames in sync https://osmocom.org/issues/60152023-04-25T08:59:55Zdexter
<p>The problem is observed with an RBS installation that uses a DUG20 but a different (presumably older, RRUS 01?) transceiver. The symptom is that the PCU is unable to get a reliable sync on the TRAU frames coming from the CCU (transceiver unit). The CCU eventually closes the channel.</p>
<p>we see the following messages:</p>
<pre>
Mon Apr 24 09:34:08 2023 <0010> trau/trau_sync.c:519 trau_sync(trau-sync){FRAME_ALIGNED}: state_chg to FRAME_ALIGNMENT_LOST
</pre>
The reasons for this could be:
<ul>
<li>Unreliable E1 connection (the setup uses icE1usb+osmo-e1d)</li>
<li>The transceiver module has a slightly different TRAU frame format (unlikely)</li>
<li>Bug in the TRAU synchronizer of libosmo-abis</li>
</ul> pySim - Feature #5976 (New): pySim-prog: do not program linked files multiple timeshttps://osmocom.org/issues/59762023-03-27T16:05:01Zdexter
<p>In the card file system there are files that exist in DF.GSM and in ADF.USIM. In case the files share the same content there may be one physical file and one that is a link to that physical file. At the momen pySim-prog does not care about this. It just programs all files or it programs the file intentionally only in one of the two locations, the latter one is a problem in case the specification of one of the files evolves so that the link has to be removed for newer card revisions and two individual files have to be created. Then one of the two is no longer programmed.</p>
<p>This can be handled smarter. The FCP should tell if the file is a linked file or not. So we should check if the file in question is a linked file and if so, we would skip programming it. In case the file is a physical file we would program it. This would mean we would have to visit all files in all locations but we would be on the safe side in case we have to break up links in future card revisions.</p>
<p>(The topic came up while fixing <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: pySim-prog.py --mnclen=3 buggy / broken (Resolved)" href="https://osmocom.org/issues/5830">#5830</a>)</p> OsmoPCU - Feature #5930 (New): handle multiple BTSs with one PCUhttps://osmocom.org/issues/59302023-03-02T09:07:50Zdexter
<p>OsmoPCU has been used so far in BTS co-located scenario only. This scenario always consists of exactly one BTS instance and exactly one PCU instance. When the PCU is used on a BSC colocated scenario one PCU may serve multiple BTSs. OsmoPCU already manages a list with BTSs and the PCU socket protocol already supports multiple BTSs as well but it is unclear how mature this is. At least the code/API that is used to handle the direct PHY access is not able to distinguish between different BTSs.</p> OsmoBTS - Feature #5927 (Resolved): use "Direct TLLI" method to confirm IMMEDIATE ASSIGNMENT mess...https://osmocom.org/issues/59272023-02-28T10:42:39Zdexter
<p>To assign downlink TBFs, the PCU sends an IMMEDIATE ASSIGNMENT MAC block through the PCU SOCK interface to the BTS. The BTS confirms the sending of this IMMEDIATE ASSIGNMENT to the PCU by sending the MAC block back to the PCU. The MAC block essentially serves as a reference for the confirmation message. This method has some disadvantages so we decided to replace it.</p>
<p>The new method attaches a TLLI (and a paging group field) to the MAC block when it send to the BTS. The BTS then uses the TLLI instead of the MAC block as an identifier to confirm the sending of the IMMEDIATE ASSIGNMENT. The OsmoPCU already supports the method but OsmoBTS still have to be upgraded.</p>
<p>The related PCU/BTS TTCN3 tests also require an update.</p> OsmoMGW - Feature #4841 (Stalled): TC_e1_crcx_and_dlcx_ep does not pass - move the IPA code out o...https://osmocom.org/issues/48412020-11-02T23:27:39Zdexter
<p>The testcase TC_e1_crcx_and_dlcx_ep can not be executed correctly because it requires a running osmo-e1d but in order to have this available in jenkins this would mean that we need to build the related debian packages with osmo-e1d support, which then creates an impractical dependency to osmo-e1d.</p>
<pre>
The proper solution is to move the IPA code out of libosmo-abis. Historically that made sense,
as the IPA multiplex was first encountered in Abis. But then it was also present in SCCPlite,
we started using it for GSUP, and most recently for RSPRO in osmo-remsim.
This now means that virtually all osmocom projects depend on libosmo-abis, while all they want
is the IPA abstraction.
Adding osmo-e1d support to libosmo-abis creates another dependency, and I rally do not want
to have to exlpain to an osmo-remsim user why he needs to install an E1 interface driver
if he wants to have remote sim functionality.
So my plan was to see if we can untangle this somehow without spending two weeks of time on it,
and then re-enable the dependency of libosmo-abis to osmo-e1d once nobody (except osmo-mgw
and osmo-bsc) depend on libosmo-abis anymore.
</pre>
<p>See also <a class="issue tracker-2 status-3 priority-3 priority-high3 closed behind-schedule" title="Feature: Add E1/T1 endpoint type to osmo-mgw (Resolved)" href="https://osmocom.org/issues/2547">#2547</a></p> OsmoGSMTester - Feature #3916 (Rejected): Format TTCN3 log output https://osmocom.org/issues/39162019-04-11T08:16:02Zdexter
<p>The TTCN3 log output that the tester currently delivers is not formatted. This means one has to format it manually before it can be viewed. Since we already do the logmerge directly on jenkins we could do the formatting as well. Then inspection of the build artifacts would be a lot easier.</p>
<p>Example commandline:<br />ttcn3_logformat ./MSC_Tests.TC_lu_and_mt_call.merged > formatted.log</p>
<p>(Attached one finds the two files from the example)</p> OsmoBTS - Support #3863 (Stalled): setup testing of osmo-bts-oc2g on real hardware with ttcn3 and...https://osmocom.org/issues/38632019-03-26T16:21:06Zdexter
<p>In order to be able to debug problems with automatic interop testing a local instance of an osmocom-bb phone and BTS is required. TRXCONT/FAKETRX are exchanged with a real BTS/PHONE.</p> OsmoMGW - Bug #3849 (New): race condition problem in rtp flow tests of the ttcn3 testsuitehttps://osmocom.org/issues/38492019-03-18T16:53:06Zdexter
<p>The TTCN3 tests that test actual RTP flow behavior through the MGW are prone to fail due to a race condition. The problem occurs when the RTP receiver in the test suite is switched off while at least one packet is still in the loop. When the packet eventually arrives the follwing error is generated:</p>
<pre>
RTP packets received while RX was disabled
MGCP_Test.ttcn:1424 MGCP_Test control part
MGCP_Test.ttcn:1364 TC_ts101318_rfc5993_rtp_conversion testcase
</pre>
<p>The problem is presumably more likely to occur when the test slave is under high load. Since all RTP tests are using the same API and work by the same principle all of those tests are prone to fail from time to time:</p>
<p>TC_one_crcx_loopback_rtp<br />TC_one_crcx_receive_only_rtp<br />TC_rtpem_selftest<br />TC_ts101318_rfc5993_rtp_conversion<br />TC_two_crcx_and_one_mdcx_rtp_ho<br />TC_two_crcx_and_rtp<br />TC_two_crcx_and_rtp_bidir<br />TC_two_crcx_and_unsolicited_rtp<br />TC_two_crcx_diff_pt_and_rtp<br />TC_two_crcx_diff_pt_and_rtp_bidir<br />TC_two_crcx_mdcx_and_rtp</p> OsmoBTS - Feature #3530 (Rejected): merge PRIM_INFO_MEAS into PRIM_PH_DATA and PRIM_TCHhttps://osmocom.org/issues/35302018-09-06T16:07:43Zdexter
<p>At the moment measurement indication primitives are handed to the upper layers separately. However, they could also be integrated into the primitives that carry the actual data block to which the measurement belongs. This would make things a lot easier to handle and understand since whenever one gets data from the phy, there must be a measurement report attached to it.</p>
<p>When lookint into l1sap.c we can see that PRIM_INFO_MEAS is sent along in an PRIM_INFO_MEAS. PRIM_INFO_MEAS only carries the measurement indication and the time indication. We may decide to flatten this once the measurement indication is settled.</p>
<p>PRIM_PH_DATA and PRIM_TCH carry data and voice. Thats where we need to integrate the measurement indication.</p> OsmoMGW - Feature #3352 (Feedback): osmo-mgw does not allow multiple codecs in LCOhttps://osmocom.org/issues/33522018-06-18T08:11:19Zdexter
<p>The osmo-mgw does not allow multiple codecs in LCO yet (e.g. a:GSM;AMR) The second codec will be ignored then. This is presumably no problem on the BSS side.</p>
<p>(I am not entirely sure, but I think by the time when the switching on the MGW happens the codec is already decided by the BSS? However, I think for the side pointing to the PBX this might be a problem when some PBX wants to negotiate multiple codecs with the CRCX?.)</p>
<p>However: One work-around can always be just to negotiate one codec via LCO first and then update the codec list with the MDCX via SDP.</p> OsmoMGW - Feature #3334 (Resolved): use proper sdp in libosmo-mgcp-clienthttps://osmocom.org/issues/33342018-06-11T19:30:18Zdexter
<p>libosmo-mgcp-client currently uses hardcoded SDP with fixed values. It also uses a payload type 255, which is illegal.</p>
<p>- Add new struct members to allow setting of ptime, payload type and rtpmap if needed.<br />- Generate proper SDP and use it when communicating to the MGW<br />- Decode the SDP responses from osmo-mgw.<br />- Update both, the normal mgcp_client and mgcp_client_fsm</p> osmo-sip-connector - Feature #2950 (Resolved): create OE-Package for osmo-sip-connectorhttps://osmocom.org/issues/29502018-02-16T15:20:42Zdexter
<p>It appears to be that osmo-sip-connector is not built as OE package, so it is not available for easy install on sysmoBTS or sysmoNITB. However, having osmo-sip-connector available on those platform would make sense.</p>
<p>Dependencies:<br />SOFIASIP, sofia-sip-ua-glib >= 1.12.0</p> OsmoBSC - Feature #2918 (New): Implement a function to properly test connection clearing in MSC_C...https://osmocom.org/issues/29182018-02-09T17:11:45Zdexter
<p>BSC_ConnectionHandler.ttcn implements a function to test proper connection clearing: f_expect_clear()</p>
<p>We should have an inverse pendant in MSC_ConnectionHandler.ttcn for the BSC tests as well. Here we will probably have two scenarios, the first is when the BSC asks the MSC to clear the connection and the second will be when the MSC instructs the BSC to clear the connection (regular case)</p> OsmoMSC - Feature #2822 (Closed): work out MSC test scenarioshttps://osmocom.org/issues/28222018-01-08T20:43:22Zdexter
<p>We plan to test osmo-msc with TTCN3 as well. In Preparation of this we have to collect Ideas for test-cases.</p> libosmocore - Feature #2587 (Closed): helper function to finde the right interface for a remote I...https://osmocom.org/issues/25872017-10-20T14:48:40Zdexter
<p>In some cases (mgcp-gw) it is important to know the IP-Address of the interface through which a remote IP-Address is reachable. This can be done using the syscalls connect() and getsockname(). Implement a helper function in socket.c that takes a remote ip-address as input and outputs the coresponding local interface</p> OsmoMGW - Feature #2580 (New): implement timeout/resend mechanism for mgcp_clienthttps://osmocom.org/issues/25802017-10-17T16:28:03Zdexter
<p>At the moment mgcp_client sends the the message out and waits for the response, when the response is received, then a the result is returned through a callback. If no response is received (e.g. packet loss), then simply nothing happens. It would be very helpful if the message gets resend after some time.</p>
<p>Each mgcp_message has a unique ID-Number and osmo-mgw is able to handle resend messages. So if the message was received osmo-mgw, but the response got lost on its way to the client, a resend would not hurt. We only need to upgrade the mgcp_client to resend messages after some timeout in case no response is received.</p> OsmoMGW - Feature #2517 (Resolved): use libosmocore counters for packet/byte counting (statistics)https://osmocom.org/issues/25172017-09-22T07:37:31Zdexter
<p>use any of the libosmocore counters, rather than having hand-coded counters. A rate counter would have the benefit that it would come with free CTRL interface access to the counters.</p>
<p>(see also the SGSN/PDP-Context per direction packet and byte counting)</p> OsmoMGW - Feature #2516 (Resolved): automatic testing of osmo-mgw / jenkins integrationhttps://osmocom.org/issues/25162017-09-18T21:45:01Zdexter
<p>Currently we test osmo-mgw with unit tests. It might make sense to run some more realistic tests. The idea is to start osmo-mgw in a testrig that then makes test connections and sends test data. The testrig could be a python program or even a TTCN3 test.</p>
Some ideas:
<ul>
<li>Send command (e.g. CRCX) and inspect resulting internal states via VTY also check response for plausibility</li>
<li>Send odd command sequences, check if the expected error codes are generated.</li>
<li>Send malformed messages or incomplete messages, check if the expected error codes are generated</li>
<li>Create a full connection, send RTP packets through, check if the RTP packets take the right path</li>
<li>Create a loopback connection, send RTP packets, check if the packets are reflected correctly</li>
</ul> OpenBSC - Feature #2515 (Closed): integrate osmo-mgw in osmo-bschttps://osmocom.org/issues/25152017-09-18T15:48:17Zdexter
<p>osmo-mgw has reached a development state, where it makes sens to try out how it performs in a real life situation. Osmo-bsc seems like a good test target for that and requires mgcp features anyway to support handover. The complexity can be limited by leaving osmo-msc on the legacy mgcp, while performing changes only to osmo-bsc. When done, osmo-bsc should not behave any different on the A-Interface.</p> libosmo-sccp + libosmo-sigtran - Feature #2417 (Closed): function to check sccp-addresseshttps://osmocom.org/issues/24172017-08-01T10:37:29Zdexter
<p>sccp-addresses consist of a number of components. A presence bitmask denotes if a component has a valid value or not. Add a function that checks the presence field against a given value. Also check if the values fall into the correct range, so that a malformed sccp-address is detected early.</p> OsmoMSC - Feature #2397 (Resolved): let osmo-msc record location area from location update for LA...https://osmocom.org/issues/23972017-07-24T20:13:10Zdexter
<p>The MSC is responsible to issue the paging commands to the BSS (BSC), it should know which BSC has which location area under its control in order to support LAC wide paging at some point. Since we automatically discover the BSCs we also need to discover automatically which location are is behind which MSC. The location area becomes known with the first location update a random phone is doing. We could just update a list with location areas we have got location area updates from. This list can than be used to find out which BSC, handles which location area.</p> OpenBSC - Feature #2396 (Closed): Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-mschttps://osmocom.org/issues/23962017-07-24T19:54:54Zdexter
<p>osmo-msc and osmo-bsc currently lack important SS7 related VTY configuration features. Add proper VTY configuration commands to both applications</p>