- retronet-discuss - lists.osmocom.org

RetroNetCall on Sept 4, 2024: Interactive DIVF testing
by Harald Welte 03 Sep '24

03 Sep '24

Dear Osmocom community, we're happy to announce the next incarnation of RetroNetCall[1], the retronetworking oriented spin-off of OsmoDevCall[2]. when: Sept 4, 2024 at 20:00 CEST where: https://osmocom.org/RetroNetCall This time, we won't have a presentation but intead a joint, collaborative session where we're analyzing and debugging any potentially remaining (or new?) issues with divf.retronetworking.org, our central soft-switch of the OCTOI community TDMoIP network. Participants are invited to try making certain calls and we will look at logs/traces and see what we can fix or improve. This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [3] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about RetroNetCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/retronetworking/wiki/RetroNetCall Looking forward to meeting you soon! Best regards, Harald [1] https://osmocom.org/projects/retronetworking/wiki/RetroNetCall [2] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall [3] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

RetroNetCall on Aug 8, 2024: classic PCM30 trunks with CAS signaling
by Harald Welte 10 Aug '24

10 Aug '24

Dear Osmocom community, we're happy to announce the next incarnation of RetroNetCall[1], the retronetworking oriented spin-off of OsmoDevCall[2]. when: Aug 8, 2024 at 20:00 CEST where: https://osmocom.org/RetroNetCall This time, @laforge will be presenting on *classic PCM30 trunks with channel-associated signaling* followed by a discussion how to potentially implement this using the icE1usb (See also: #6526 [4]). This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [3] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about RetroNetCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/retronetworking/wiki/RetroNetCall Looking forward to meeting you soon! Best regards, Harald [1] https://osmocom.org/projects/retronetworking/wiki/RetroNetCall [2] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall [3] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. [4] https://osmocom.org/issues/6526 -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

RetroNetCall on Aug 7, 2024: classic PCM30 trunks with CAS signaling
by Harald Welte 10 Aug '24

10 Aug '24

[My apologies, I misread the calendar. It's August 7, not August 8] Dear Osmocom community, we're happy to announce the next incarnation of RetroNetCall[1], the retronetworking oriented spin-off of OsmoDevCall[2]. when: Aug 7, 2024 at 20:00 CEST where: https://osmocom.org/RetroNetCall This time, @laforge will be presenting on *classic PCM30 trunks with channel-associated signaling* followed by a discussion how to potentially implement this using the icE1usb (See also: #6526 [4]). This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [3] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about RetroNetCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/retronetworking/wiki/RetroNetCall Looking forward to meeting you soon! Best regards, Harald [1] https://osmocom.org/projects/retronetworking/wiki/RetroNetCall [2] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall [3] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. [4] https://osmocom.org/issues/6526 -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Using RPi5 with icE1usb, 2xE1
by Mychaela Falconia 22 Jun '24

22 Jun '24

Hello fellow retronetworkers, I am now looking into possibly using icE1usb to talk to my Nokia TRAU. My original was to use a Digium PCI card, but I ran into issues: a) The only machine I have with a PCI slot is a production machine; b) My naive hope that DAHDI would "just work" did not pan out; c) Deeper troubleshooting would require subjecting this production machine to more downtime than allowable. Hence I am looking at the alternative of using icE1usb instead. There is one sticking point though: unlike a BTS, playing with a TRAU requires a minimum of two E1 circuits, one for A i/f and one for Ater. And I know that few host systems can drive icE1usb with both interfaces in terms of USB limitations. However, this page says that Raspberry Pi 5 should do the trick: https://osmocom.org/projects/e1-t1-adapter/wiki/Isochronous_USB_Issues I am thinking about getting an RPi5 specifically for the purpose of driving icE1usb with both E1 interfaces active. The requirement of having no other USB devices will be easy to satisfy: the whole RPi5 will be just for this purpose and no other. But I would like to confirm: a) Does anyone here have actual experience with RPi5 driving both E1 interfaces on an icE1usb? b) RPi5 has two kinds of USB host ports: some USB2 and some USB3. Which would be better to use for icE1usb? TIA for any leads, M~

1 0

Nokia TRAU update
by Mychaela Falconia 12 Jun '24

12 Jun '24

Hello fellow retronetworkers, For those of you who enjoyed my TRAU presentation last week, I got a very positive update. :) Today I got this TRAU powered up (after getting the right crimp connector parts from Digi-Key and assembling the necessary wiring harness for -48 VDC power to the box), and while I still don't have the additional hw that brings out E1 circuits, the management interface I got on the RS-232 port shows that this unit has everything we'll need to have lots of fun once those E1 connections are made: * No password lock: the mgmt interface password is the factory default that's documented in the manual. * There are 3 DSP fw images installed on the TRCO (the maximum it can hold per the docs), covering circuit types A, B and F. Circuit type F (the one it came configured with) is AMR, which is not of much interest to me (and apparently Nokia never implemented TFO for AMR in any of their TRAUs), but cfg A is 16 kbit/s FR/EFR/CSD and cfg B is 8 kbit/s HR - these are the ones I look forward to playing with. * TFO feature is present, i.e., NOT excluded or blocked by "premium feature" schemes - yay! Obviously I won't be able to confirm it actually working until I get A & Ater E1 interfaces brought out and connected to my test rig, but the option to enable/disable TFO is present and accessible in the mgmt interface, and when I set it to enabled, it shows up as such in config readback. The next step is for me to buy an ET2E module and the ET1TC chassis that holds it from shields-e (the same people from whom I bought the parts I already got), and then make my own cable with DIN 41612 connectors to connect the two backplanes - that's how we'll get the two E1 interfaces (A and Ater) out of this baby. Until then, if you are curious to see what the management i/f for the TRAU looks like, here is a log of my RS-232 session talking to the box, from power-up: https://www.freecalypso.org/members/falcon/trau/tcsm2-boot.log and here is the manual that describes this interface: https://www.freecalypso.org/pub/GSM/Nokia_TCSM/tcsm2-command.pdf Happy hacking, Mother Mychaela

1 0

TRAU presentation tomorrow: slides ahead of time
by Mychaela Falconia 05 Jun '24

05 Jun '24

Hello retronetworking community, As Harald already announced, tomorrow (or later today in Eurasian time zones) I will be giving my first installment in what will be a series of presentation on my adventures with Nokia TRAU hardware, specifically TCSM2. In order to make better use of time during the actual RetroNetCall, I am posting my slides ahead of time: https://www.freecalypso.org/members/falcon/presentations/trau-pres1.txt https://www.freecalypso.org/members/falcon/presentations/trau-pres1.ps https://www.freecalypso.org/members/falcon/presentations/trau-pres1.pdf (Plain text -> Postscript -> PDF is my generation chain; I write in plain text, but PDF is needed for upload into BigBlueButton.) Anyone who is interested in this TRAU topic, I recommend that you read these slides ahead of time - this way I can spend less time reading the slides (or pausing for people to read them in real time), and we can have more time for the fun parts of looking at the hardware (I will be pointing my webcam at the hw) and discussing the still-outstanding challenges. See y'all tomorrow, after my sleep cycle. :) M~

1 0

RetroNetCall on Jun 5, 2024: Nokia TCSM2 Initial examination
by Harald Welte 04 Jun '24

04 Jun '24

Dear Osmocom community, we're happy to announce the next incarnation of RetroNetCall[1], the retronetworking oriented spin-off of OsmoDevCall[2]. when: Jun 5, 2024 at 20:00 CEST where: https://osmocom.org/RetroNetCall This time, @falconia will be presenting on Nokia TCSM2, a bank of TRAUs with E1 interfaces: Part 1, initial examination of the hardware This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [3] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about RetroNetCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/retronetworking/wiki/RetroNetCall Looking forward to meeting you soon! Best regards, Harald [1] https://osmocom.org/projects/retronetworking/wiki/RetroNetCall [2] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall [3] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Update on my quest for a GSM E1 TRAU
by Mychaela Falconia 29 Apr '24

29 Apr '24

Hello fellow retronetworkers, For a long time I've been looking to get my hands on a traditional GSM TRAU, a hardware converter from 16 kbit/s (or 8 kbit/s in the case of HR) speech channels going to a traditional T1/E1 BTS to full 64 kbit/s PCM channels, complete with speech transcoding functions per classic GSM specs. I started this search about this time last year, but now I am getting a little closer: I just sent a payment to Shields Environmental, a surplus telecom equipment dealer recommended to me by Harald, for a set of old Nokia parts that should be enough to put together a minimal Nokia TCSM2 system. There will be some more waiting (they still need to pack and ship my order, and then I will need to wait for it to arrive), but it looks like I will have a new toy soon! TCSM stands for Transcoder and Submultiplexer, which is Nokia's term for the bank of TRAUs that sits between the MSC and the BSC in the traditional E1-based architecture. Apparently there were 3 generations of Nokia TCSM, with TCSM2 being the middle one. For each of these 3 generations, a "proper" TCSM installation was a giant cabinet full of units, which is obviously *not* what I am going for in my lab - instead I ordered just enough parts to put together the most minimal config that is possible in TCSM2 architecture: one TC1C chassis (coming in the present order) and one ET1TC chassis (to be ordered later). A single "unit" of TCSM2 handles one E1 line on the Ater interface, the i/f between the transcoding site and the BSC. If this one-E1 Ater is used to its full capacity, it expands to 4 E1s toward the MSC with full rate channels, or to 7 E1s with HR channels. In theory the maximal expansion is one E1 on Ater to 8 E1s on A with HR, but TCSM2 supports a maximum of 7 A-interface E1s for each "unit" handling a single Ater E1. However, for lab hackers like me who aren't interested in maximum capacity, the minimal config for TCSM2 is one E1 on Ater, one E1 on A, two TR16 transcoder cards, and a maximum of 30 simultaneous call legs. For this one "unit" of TCSM2, there is one TC1C chassis that hosts one TRCO card (the main controller), from 2 to 14 TR16 cards (I am getting the minimal two), and the power supply that takes in -48 VDC. There is also the ET1TC chassis that holds "exchange terminal" T1/E1 cards; I will later need to buy this chassis and one 2xE1 card from the same dealer. According to the docs I found, the TRCO card (the head of a TCSM2 unit) has an RS-232 port for local management, and supposedly it is possible to configure the unit autonomously in this manner. It normally "wants" to be controlled from the BSC via some LAPD-based proprietary protocol on an Ater timeslot, but it looks like Nokia also provided for "test" operation with neither BSC nor MSC present, for which all basic settings can be configured via that local RS-232 port. This latter mode of operation is what I seek, as I don't have any T1/E1 MSC or BSC hardware, nor do I seek to acquire any currently. My intent is to connect both one-E1 A and one-E1 Ater interfaces to a "play" machine with a dual E1 interface (either icE1usb or a Digium card, TBD), and bring individual TRAU channels to life by feeding TRAU-UL frames of the desired codec type (as if coming from a freshly-brought-up TCH on a BTS) to sub-timeslots on the Ater interface. Then see what comes out on the A interface, feed some PCM input to A and observe Ater DL output, etc. One big uncertainty is TFO, the in-band bit-stealing protocol inside 64 kbit/s PCM speech channels defined in GSM 08.62, later 3GPP TS 28.062. I *really* want to play with TFO, and the hope of getting a TFO-capable one is the main reason I just spent a ton of money on this TRAU gear. However, it appears that TFO was an "optional" feature on TCSM2, along with several other "optional" features like AEC and voice AGC - features that go beyond ETSI- or 3GPP-specified standard functionality for TRAUs. It appears that "back in the day" customers had to pay a little extra to Nokia to get these "optional" features, but it is not clear to me how the restriction was implemented. Did they have different firmware versions with these features included or excluded? Or was it some kind of license key entry system? In any case, I *really* hope that the TRCO and TR16-S cards I just paid a ton of money for will arrive with TFO-capable firmware in them, such that the actual feature can then be enabled or disabled with configuration commands on the RS-232 management port as documented... To be continued, Mother Mychaela

1 0

My interconnection with USA PSTN
by Mychaela Falconia 08 Mar '24

08 Mar '24

Hello fellow retronetworkers, In the USSE portion of this week's RetroNetCall (approximately 2 days ago, depending on how you look at time zones) I made some mentions about my SIP setup for interfacing with the outside world, and I got the impression that my attempts at explanation in that RetroNetCall weren't so great - so let me try explaining it better by way of the written word. Why connect to real PSTN? ------------------------- It appears that most retronetworkers other than me connect their retro phone systems to separate "not real" networks like C*NET, rather than real live PSTN. Why am I different in this regard? Answer: my main objective in this entire retronetworking venture is to use my choice of retro phone (in my case, GSM/2G) as my primary daily driver phone for real human communication. I know that other people somehow keep those sides of life separate, i.e., they will play with retronet toys for fun, but use some modern iPhone for everyday communication - but that is NOT me. I refuse to own or use or touch an iPhone, to the point that if I were to get into a horrible accident on a highway, I would rather bleed out to death on the side of the road than use an iPhone to call for help. Being able to use a retro GSM/2G phone as my main personal phone, and do so without depending on the fickle whim of T-Mobile, requires operating my own GSM network - that's what Osmocom CNI is for - and connecting said network to real live PSTN, as opposed to "toy" networks like C*NET. For my interconnection with real live PSTN in USA, I currently use the services of BulkVS and AnveoDirect, as well as Sopranica Telecom (jmp.chat) for SMS interconnection. More specifically, I rent real phone numbers from BulkVS, I receive all inbound calls to these numbers through BulkVS, and I use both BulkVS and Anveo as outbound routes. I use BulkVS as the outbound route for calls going to North America +1 destinations, and Anveo for calls going to any other country code destination. How inbound calls work ---------------------- I have a public-facing SIP server listening on standard port 5060; this server is located at DNS name sip-gw.sandiego2g.org. More specifically, on the time scale of years the actual IP address may change if I have to change ISPs or move the server from my home to some datacenter hosting when San Diego 2G Association expands (hopefully), but it will always be some static and public IP address (like it is now), and DNS will be updated in the case of any moves. (Right now I am hosting the server at my home on a business-grade Internet connection, but that's an implementation detail that can change without affecting the architecture or the public interface.) I have my BulkVS service configured to send inbound calls via SIP to this sip-gw.sandiego2g.org server, to the same IP to which this DNS name points. There is _no_ SIP registration or authentication or any of that complexity - instead BulkVS servers simply send a SIP INVITE to port 5060 at my static & public business IP address whenever an inbound call comes in to any of the phone numbers I rent from them. USA phone numbers cost only 6 cents per number per month with BulkVS, hence I have a bunch of them, many more than just my own personal phone number. However, my inbound SIP gateway (meaning themwi-sip-in process, all written by me, running on this sip-gw.sandiego2g.org server) is happy to accept inbound calls from anyone, not just from BulkVS servers. In other words, I fully support the principle of settlement-free peering in public phone interconnection. USA is a huge country, whereas the scope of San Diego 2G Association is explicitly limited to the named locality. Suppose someone else, somewhere else in USA, decides to mimic what we are doing and set up their own community-based GSM/2G network. Suppose that other community network (e.g., Keene NH) then wishes to peer with SD2G, such that SD2G routes calls to Keene-owned numbers directly to Free Keene network, and FKnet likewise routes calls to SD2G-owned numbers directly to SD2G, without paying BulkVS or Anveo or any other carrier to ferry those calls - from my side I will always warmly welcome any such peering arrangements! The technical implication of this "open arms" policy is that my public- facing SIP server is wide open to the world, receiving junk "probing" SIP packets from script kiddies 24x7x365. But all that junk is statelessly rejected without wasting server resources. In order for my gateway to do anything with an incoming SIP INVITE other than just toss it, that INVITE would have to be directed to one of NANP numbers that specifically belong to my network and not to someone else - and if someone is actually calling one of my numbers, then my gateway is happy to accept that call and route it to the respective GSM subscriber, no matter which IP or party or entity that SIP call came from. How outbound calls work ----------------------- My outbound gateway (themwi-sip-out) routes each outbound call to either BulkVS or Anveo, depending on E.164 destination country code - or more precisely, I can set up any number of routes, matching on any desired E.164 prefixes. But the mechanism is once again plain SIP INVITE packets only, no registration or authentication or any other complexity. Like every other reasonable wholesale SIP trunk provider, both BulkVS and Anveo support IP-based authentication: I simply go into my customer portal with each of these companies, and list in there that any SIP calls coming from my IP address are to be billed to my account. When I tried to explain this last part in RetroNetCall USSE, I was met with derision, people saying something about security holes etc. But I still stand by this architecture: we are NOT talking about a consumer or personal VoIP user connecting from their nomadic personal IP that will likely change all the time, this is a production deployment of SD2G (a long-term-established business entity) sending wholesale traffic to its contracted carriers. Whatever servers SD2G uses, these servers will always have static IP addresses - so what's wrong with simply whitelisting them? In that RetroNetCall USSE, I seem to have heard someone say something about IP spoofing - but how would such spoofing help any would-be attacker in my case? Suppose that someone wishes to impersonate SD2G, i.e., send a rogue call out to BulkVS or Anveo, but make it look like their call is coming from SD2G. A successful SIP call establishment requires a 3-way handshake: the caller sends INVITE to the callee, the callee responds with 200, and the caller follows up with ACK. Suppose an attacker sends a spoofed UDP packet to BulkVS or Anveo, with the source IP forged to indicate my SD2G server, and the packet content being a SIP INVITE which BulkVS/Anveo would accept as valid. The SIP carrier would then sends SIP responses to my IP address, hence those responses will go to my server and not to the attacker. The attacker will never learn the To tag assigned by BulkVS/Anveo to this call, and they will thus not be able to construct a valid ACK. And without that ACK, they won't get a successful call - so where is the problem? IP telephony carriers mucking with RTP -------------------------------------- I still don't understand why enterprise-oriented, business-serving (NOT consumer or end-user oriented) ITSPs modify SDP to make the RTP stream pass through their nodes, as opposed to letting it pass directly end to end. Suppose Alice Enterprises, a customer of ITSP-A, sends a SIP call to Bob Enterprises, a customer of ITSP-B. When BobEnterp receives the SIP INVITE addressed to them, they will see SDP pointing at some carrier nodes owned by unclear-whom (maybe ITSP-A, maybe ITSP-B, maybe some other "shared" party in that ecosystem), but not the original SDP from AliceEnterp pointing to AliceEnterp servers. Why??? In the RetroNetCall USSE I was told something about customer privacy, removing customer IP addresses. I totally understand doing that practice for consumer-oriented VoIP services, but why in the heck do they do it in the _wholesale_ SIP trunking business? It is my understanding that wholesale carriers like BulkVS work only with enterprise-level business entities - and surely a business entity of the latter type will have no need to hide their production servers? BulkVS say that they *don't* proxy RTP traffic, i.e., supposedly my RTP traffic does not pass through BulkVS servers, only SIP does. But then BulkVS is primarily a reseller of even bigger wholesale carriers like Bandwidth and/or Inteliquent, and it appears those parties then do proxy RTP, i.e., SDP blurbs I get from BulkVS (incoming INVITEs and answers to my outbound calls) are probably pointing to those carriers. I was also told in that RetroNetCall USSE that these carriers "don't want" to be transcoding my RTP traffic, at least domestically within USA, that doing so costs them CPU cycles etc. But who is then denying me the ability to talk AMR directly to the other party when calling or receiving a call from a VoLTE user on any of the 3 national carriers? All mobile phone users in USA, other than hard-core 2G holdouts like me, are on VoLTE: AT&T and Verizon only have VoLTE networks, they don't have any circuit-switched networks at all; T-Mobile has GSM only for "grandfathered" customers like me, and they push like hell to get these users to "upgrade" - hence mainstream, not hard-code-rebel T-Mobile users are also 100% VoLTE. And although I am no VoLTE expert, it is my understanding that VoLTE phones don't speak G.711 directly - instead they speak either AMR-WB (their preference) or AMR-NB as fallback. Yet whenever I receive a call from a VoLTE user, the SDP offer from BulkVS only lists PCMU, PCMA and G729 in this order - no AMR. In the other direction, if I send a call to BulkVS addressing the number of a VoLTE user, I can offer AMR and/or GSM codecs until I am blue, but only PCMU will be accepted in the answer - and if I send an offer that includes only AMR and/or GSM codecs, without PCMU, the call is rejected. Thus the result is that someone somewhere is transcoding between the PCMU they speak with me and the (presumed) AMR codec on the VoLTE leg. Who is doing this forced transcoding, and why? What is their perverse justification for denying non-transcoded AMR in outside calls to/from VoLTE carriers, and why is it so important to them to effect this denial that they gladly expend CPU cycles to do it? Still bewildered, Mother Mychaela

1 0

GSM module inside Possio Greta fax machines
by Mychaela Falconia 06 Mar '24

06 Mar '24

Hello fellow retronetworkers, Today I received a pair of Possio Greta GSM fax machines from Harald. I haven't powered up either of them yet, as I have no CSD-capable BTS up and running currently (sysmoBTS sadly does not support CSD, and I have yet to tackle the project of trying to bring my ebay-sourced UmTRX to life with osmo-bts-trx), but as I was examining these devices visually, I noted that they are a lot more "modern" than I thought they were. The CE mark on the label sports year 2009, and the IMEI begins with 35368104. The 04 in the FAC field told me right away that it must be a "late GSM era" device, NOT early GSM era, but then I tried looking it up in the IMEIDB leak I once found on Scribd: https://www.freecalypso.org/pub/GSM/IMEI/186248059-Tac.pdf And sure enough, it is right there on page 667: this IMEI belongs to Cinterion MC55i module! So now we know exactly which GSM MS engine these fax machines have inside. :-) And here is the best part: as the IMEIDB entry says and searches for MC55i datasheets confirm, this GSM module and hence the GSM fax machine built around it is quadband! Prior to this discovery, I feared that I would have to not only get a CSD-capable BTS up and running, but also operate it in an EU band for this gear to work - but since it is quadband, I now know that once I do get a CSD-capable BTS, I can run it in whichever band makes the most sense given the spectrum-political situation in my neck of the woods. Needless to say, I look forward to tomorrow's presentation by Harald, where we will hopefully learn how ISDN fax differs from analog and GSM kinds. :-) M~

1 0

2025

2024

2023

2022

retronet-discuss