Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> wrote: See below for my thoughts, but: Ahmm, how would you deploy a virtual setup if the MS vendor is someone other than Osmocom? Oh, you are not interested in interoperability with non-Osmocom MS vendors, are you? Your ideal Universe is one where absolutely all components on both network *and* mobile sides of Um interface are made by Osmocom, right? If so, why bother with GSM at all, why not invent some completely new "standard" of your own liking? d) run a real BTS plus standard OsmoCNI sw components, plus my ThemWi add-ons for outside PSTN connectivity: themwi-mncc, themwi-sip-in, themwi-sip-out and themwi-mgw. (The latter suite connects to OsmoMSC via MNCC and *takes the place* of osmo-sip-connector.) Connect only *one* mobile phone to the test GSM network (don't need two), and make a test call to some number on PSTN, such as a time-of-day service or an automated road traffic information line, some number that doesn't mind getting lots of test calls. Useless when the desire is to test some GSM MS made by someone other than Osmocom, e.g., a Nokia or Ericsson phone from 1990s, or a FreeCalypso device. This approach is what I started with when I initially got my OsmoCNI network up and running, but needing *two* phones was a very definite inconvenience from the start. ThemWi system sw add-ons to OsmoCNI, attaching to OsmoMSC and connecting the local network to USA PSTN, solve this problem. Yes, having to learn Yet Another software suite with its own philosophy and paradigm, and the fear of investing into one particular sw choice (be it Asterisk or FreeSwitch) only to conclude later that I picked the wrong one, is the reason why I wrote my ThemWi system sw instead. Also conveniently eliminates osmo-sip-connector with its quite unpleasant library dependencies - matters to a Slackware-using old hag (think Baba Yaga :) like me. It should be not-too-difficult to integrate such function into ThemWi MNCC architecture. Why does the calling MSISDN have to be random, why not either omit the Calling Number IE altogether (it's an optional IE in the MT SETUP message), or make it an optional command line argument? I already have a function in my ThemWi suite that works just like you describe, it is themwi-test-mtc command (CLI utility, connects to themwi-mncc daemon), and it will either send the Calling Number given on its command line or omit that IE altogether if no calling number was given. All non-Osmocom (independently-branded add-on to OsmoCNI) software I mentioned in this reply lives here: https://www.freecalypso.org/hg/themwi-system-sw/ M~

On 12/7/22 11:37, Mychaela Falconia wrote: As I already mentioned, the existing silent-call command is a bit special in a way that it allows to select a specific TCH rate (full or half) and a specific codec (if needed). The test-call command I proposed can by implemented on top of the existing silent-call logic. Just to clarify: currently when you invoke the silent-call command, no Call Control signalling is happening at all. Only paging and then the RR Assignment procedure. Strictly speaking it's not really a "call", just a channel assignment without any further commands. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On 12/8/22 09:18, Mychaela Falconia wrote: The primary goal for me would be making the phone activate its microphone and speaker, so that the associated RTP stream would carry valid Uplink voice frames. I assume sending a CC SETUP message and pressing the green button on the phone would be enough for that. The subsequent Alerting and Connect messages from the MS can simply be ignored for now. This is not a complete solution, rather a quick hack that should be relatively easy and quick to implement without touching the MNCC logic. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On 12/7/22 07:13, Mychaela Falconia wrote: I am not aware of any other solutions for running OsmoRAN virtually and connecting a virtual MS to it, so I have no idea what kind of interoperability with non-Osmocom MS vendors you're talking about. If this is again "use my FreeCalypso", then let's avoid this discussion. I am not saying this is not an option, but... I want a *simple* solution. And you suggest running 4 additional components, and connecting to PSTN for that? This is definitely an overkill. Because I don't care what MSISDN should be displayed on the phone's screen during a test MT call. Omitting the Calling Number IE would also work for me. Yes, we know. It's not the first time you're advertising it here. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On 12/8/22 01:26, Mychaela Falconia wrote: Quick answer: testing. Back in 2017 fake_trx.py was just a hack to test trxcon against OsmoRAN/OsmoCNI stack, while ptrkrysik was independently working on the gr-gsm based PHY. At some point Sysmocom started writing conformance tests for osmo-bts-trx based on fake_trx.py + trxcon, which eventually evolved into a decent testsuite (260 test cases) [1][2]. In 2018 Harald gave a talk about "the state Osmocom TTCN-3 Test Suites" [3], where among the other testsuites he covered ttcn3-bts-test. The virtual setup was also useful for testing voice calls because recently I worked on integrating GAPK I/O into the mobile app. This is a part of the SDR PHY project we are currently working on. I did some tests with a Motorola C1xx, but I actually needed to make sure that voice works when using trxcon. [1] https://cgit.osmocom.org/osmo-ttcn3-hacks/tree/bts [2] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/ [3] https://media.ccc.de/v/UGHHW3 Yes, it does [4][5]. Some patches are still in Gerrit waiting for code review, but in general it's already in a good shape. As I said above, I needed to make sure that trxcon handles TCH stuff properly. [4] https://osmocom.org/issues/3400 [5] https://cgit.osmocom.org/osmocom-bb/commit/?id=df7fa3e296d97332161ed78be95c… No, I don't really care about genders here. All I wanted to discuss is voice testing, not limiting nor discriminating potential participants in any way. I am not a native English speaker, but reading the Internet I see there is no consensus on whether "guys" is gender-neutral. Maybe "you folks" would have been a better fit. Because you're known to hijack threads on this (and not only this) mailing list and turn them into propaganda of your projects. Even in this thread I see lengthy description of what your software is capable of, which components exist, how they talk to each other, and why e.g. osmo-sip-connector is not as good as your alternatives... I was not following FreeCalypso mailing lists from the beginning, but I don't remember seeing anybody from Osmocom joining there and saying: "hey, your approach is not as good as mine, look at our alternatives". Of course, valid criticism is always welcome, as well as patches are. And I love to see people sharing here what they are working on, but IMO it should not be that aggressively advertised as you do sometimes. I am not entitled to teach you how to behave in mailing lists nor I am given the right to force any rules here. I could simply ignore your lengthy mails and focus on feedback from the other participants, but I would rather be explicit here. All in all, it's not about whoever likes or dislikes you, whoever likes or dislikes your development preferences, and not about gender discrimination. Let's stay close to the topic and be nice to each other. Thanks for your understanding! -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On 06/12/2022 17:21, Vadim Yanitskiy wrote: It sort of feels like you want to put functionality into osmo-msc that is already there via osmo-sip-connector and other programs beyond that. I can send a SETUP anytime I like with a random caller MSISDN via a plethora of SIP tools. Maybe you want to try to keep it in osmo-* land or somehow you don't like SIP.. (and by extension, IMS?) Which is why for you, forking and hacking on LCR is fine, and using osmo-gapk to do a convoluted RTP loopback is fine, but the really simple solution with SEMS is "overkill" :-) As I muttered before, I wonder if this has less to do with the merit of any of those solutions, rather it has to do with your own personal familiarity with the tools and capabilities as a C programmer. It sort of reminds me of a conversation with David Burgess at the 29c3. At that time I wasn't working close with rhizomatica, (i don't think rhizomatica existed) - but somebody had mentioned to me that the fledgling project in Oaxaca was abandoning openBTS is favour of openBSC and I said this to David. I remember him responding something to the effect of how osmo was all fine, but was stuck in the old telephony land (not his words) and that the future was in SIP, and that the advantage of openBTS was that every MS just becomes de facto, a SIP endpoint. Now, I get and I'm all for replicating the original CS stuff in open source. Practically, I think osmo-sip-connector could use more love (not to mention osmo-msc support for SDP and codecs) and this would be time better spent than hacking functionality that already is possible into osmo-msc just to avoid what you personally find to be overkill, maybe because a few freeswitch xml config files are a daunting task, but compiling LCR isn't - for you :-) Of course, maybe there is a reason to have this testing possibility self-contained in the minimum number of daemons that I am not aware of. Thanks! k/

On 07/12/2022 15:21, Neels Hofmeyr wrote: I used some setup a long time ago with the various virtual components, but it was mainly for SMS, I remember I had some problems with paging that was a show stopper, and I never looked at it again. Well, You can add some delay with rtp jitter-buffer on the bts. It accepts up to 10 seconds, but stops working for me with smaller values than that, I start to get: DLMIB DEBUG <0014> ../../git/src/trau/osmo_ortp.c:205 osmo_rtp_socket_poll(209920): No message received DLMIB NOTICE <0014> ../../git/src/trau/osmo_ortp.c:0 rtp_putq: Queue is full. Discarding message with ts=2870320 but 1500 works and gives you enough delay to be able to say something and hear it back. What did you think of https://osmocom.org/projects/cellular-infrastructure/wiki/Simple_Echo_Server ? I don't see that the SEMS echo app has a param for buffer size, unfortunately, I don't think the delay time is variable. If I find a way, I'll add it to the wiki page. K/

Keith &lt;keith(a)rhizomatica.org&gt; wrote: [Keith was responding to Vadim, but the actual nature of his arguments is such that they could have been addressed to me much the same, so I am going to take the liberty of adding my response as well.] While I disagree about o-s-c being the end-all, be-all solution, a more practical problem with implementing Vadim's proposal of a test-call vty command inside OsmoMSC would be the clash with MNCC. Let's say you implement a vty command that sends an MT SETUP CC message to the named subscriber - what then? With the current code, a dialogue is established between the MS and the MNCC entity (be it internal or external), with all subsequent CC messages from the MS turning into corresponding MNCC messages. There is only one MNCC message pipe, with different calls distinguished by uint32_t callref numbers. The only way I can envision an implementation of this vty test-call proposal would be yet another internal MNCC agent inside OsmoMSC, coexisting with either the internal simple-switch MNCC or the external MNCC socket, and a routing mechanism: for every CC message arriving from an MS, the code would have to check and see if it should go to the "main" MNCC agent or to the special one for vty test-call. Seems like a lot of effort to me. And I can do likewise using only MNCC, without SIP! In my ThemWi system sw architecture, I use Osmocom-defined MNCC as the call control interface between components. The component that connects to OsmoMSC's MNCC socket is themwi-mncc, and it is a switch/dispatcher/funnel for MNCC messages. I then have further UNIX domain sockets connecting other components to themwi-mncc, but the messages exchanged on those ThemWi sockets are exactly the same structs as those passed on the socket from/to OsmoMSC - themwi-mncc merely routes them. The use case of a test MT call is very useful to me, a simple test call from the command line to an attached MS, so I wrote the requisite test program quite early in my development - it is themwi-test-mtc. This command line program connects to themwi-mncc via mtcall_socket and sends an MNCC_SETUP_REQ message, which themwi-mncc simply forwards to OsmoMSC, initiating an MT call. But to make the whole mechanism work, themwi-test-mtc needs to stay running for the duration of that test call, and it handles all subsequent CC-turned-MNCC message exchanges: for example, if I then press keypad buttons on the test MS during the call, I see corresponding DTMF messages in the terminal window from which I run themwi-test-mtc. Disconnect and call clearing signaling is also implemented in themwi-test-mtc, and the command line program exits gracefully when the call finishes. I haven't done the gapk trick like Vadim suggested - I could certainly do it, it would be easy to modify themwi-test-mtc to support a user-provided RTP destination instead of grabbing a dummy endpoint from themwi-mgw, but I haven't had a need to do it yet. The approach that works for me is that I can run tcpdump to capture RTP traffic, dial a test call with themwi-test-mtc, speak into the test phone, and then analyze the pcap file. (For the latter step, I first feed the pcap file to my rtp-gsmfr-extr program, then feed the extracted codec session recording to either gsmfr-decode or gsmefr-decode as appropriate - all just-named tools reside in my gsm-codec-lib repository, my alternative to gapk in a way.) As for the calling MSISDN on these test calls, I either specify one with -f option to themwi-test-mtc, or if I run without this option, the corresponding IE is omitted in the MNCC_SETUP_REQ message and thus in the MT SETUP message going to the MS. Speaking for myself only (not for Vadim!), I most absolutely dislike SIP! I like traditional telephony, I like TDM and SS7 and ISDN, and I use SIP for interconnection to USA PSTN only out of poverty - if I had the wealth of Jeff Bezos or Elon Musk etc, I would never bother with SIP, I would get a traditional TDM trunk, but given that I am NOT rich, I have to use SIP because it's a dirt-cheap way to connect to USA PSTN via companies like BulkVS. For this reason, I keep my use of SIP confined to the very edge of my network, *only* for the cheap interface to PSTN, and I have implemented SIP in ThemWi as an edge interface, NOT an internal interface. My internal interface between call routing components is currently Osmocom MNCC. Pure evil! I refuse to use or own a VoLTE phone - if T-Mobile USA kill their GSM network before I go off to Valhalla, I will have no working phone at all outside of my pirate cell coverage area. Again, not speaking for Vadim in any way, but for me personally this factor is huge too - it is far easier for me, and even more importantly, far more pleasant, to code up my own solution (in C, from scratch) according to my own philosophy and paradigm than to learn to and adapt to someone else's solution built according to someone else's philosophy and paradigm. And it is not just the ease of doing it once, the quality of the end result is very different too: if I were to adopt someone else's solution (because it's easier in the short term, faster, whatever), then I will be forever stuck in a state of paradigmatic discord, forever unhappy with That Other Party's differing philosophy and paradigm, whereas writing my own code exactly the way *I* like it solves that problem at the root. :) This SIP-zealotry (along with SDR-zealotry, meaning fundamental incompatibility with non-SDR implementations of GSM BTS) is among the reasons why I chose OsmoCNI over OpenBTS for the network side of GSM. Given that operating any kind of GSM network is inherently an intentional retrotechnology pursuit *in itself* (at least in the so-called "first world", on soil where every square mm is already covered with super-strong 4G and 5G signals from 3 major carriers), replicating the classic GSM network architecture as closely as possible is the only proper way to go, in my opinion. I see o-s-c as an unnecessary straightjacket that does nothing but artificially restrict ways in which additional network elements can be built to handle voice behind OsmoMSC. You know full well that the conversion from MNCC to SIP done by o-s-c is very far from lossless - what happens to "user to user info" IE from CC messages from MS? What happens to various rich GSM cause values and locations that have no 1:1 mapping to SIP? What about DTMF duration fudging? In GSM there is one CC message sent when the user presses a keypad button and another message sent when she lifts her finger, and this user finger timing is preserved in MNCC - but the INFO method hack for DTMF in SIP requires that the duration be given upfront, so you send a hard-coded number and *lose* user finger timing of DTMF. On T-Mobile's not-yet- shutdown GSM network, their DTMF generator does preserve user finger timing: I can do a test call from a GSM phone to a POTS line, and I can hear shorter or longer DTMF tones depending on how long I press and hold keypad buttons. Therefore, my Themyscira Wireless network MUST be no worse, and the o-s-c "solution" of ignoring user finger timing and always forcing 180 ms or whatever is NOT acceptable. In my Universe, the closest counterpart to o-s-c is my pair of themwi-sip-in and themwi-sip-out. Aside from separating the two directions of call establishment (there is some significant code that is common, and there is also significant code that is highly specific to one vs other direction, thus there is no clear-cut answer whether it is "better" to unify or separate the two), the biggest diff is that my daemons are written for SIP-at-edge, rather than internal SIP. Unlike o-s-c, my daemons never propagate GSM codec details to the SIP side - instead the SIP side is expected to be PSTN, speaking G.711 instead of GSM codecs, and every call going through themwi-sip-in/out also has to go through themwi-mgw, which is a transcoding MGW. themwi-mgw is controlled by themwi-sip-in/out via an internal ad hoc protocol; operationally every TMGW endpoint has a GSM side speaking one of GSM codecs and a PSTN side speaking G.711, either PCMU or PCMA, and the MGW operation is a "soft TRAU" - doing exactly what classic E1 TRAUs once did, but doing it on RTP streams. DTMF tones are injected in-band by themwi-mgw, under control from themwi-sip-in/out, and follow user finger timing as relayed via CC messages on the GSM call leg. If you are talking about Neels' codecs branch/patch, I am not too impressed with it, and if it does get merged, my only concern will be how it may break things for people like me who don't do SIP or SDP in their GSM CN. Because I never run SIP inside my CN, only at the PSTN interface, I never have any occasion to represent GSM codecs in SDP. The only codecs that ever get represented in SIP and SDP in my world are PCMU and PCMA; the requisite SDP generation and parsing is done in themwi-sip-in and themwi-sip-out (factored out into libsip), and these two daemons communicate the selection of PCMU or PCMA to themwi-mgw. Now what we (as in GSM community, wider than just Osmocom subset thereof) do need to implement in OsmoMSC codec-wise is an ability for external MNCC agents to command TCH reassignment from one speech mode to another. Imagine this scenario: Alice uses an Ericsson I888 phone, which supports FR1 and EFR codecs but no others, and she calls Bob, who has an even older Siemens S11E phone, supporting only FR1. In this scenario, having the network transcode between EFR on leg A and FR1 on leg B would be not only a waste of CPU cycles, but also a needless degradation of voice quality: operating two different lossy codecs in tandem *always* results in worse end-to-end quality than either codec by itself. Instead in this scenario the *optimal* answer is unambiguous: Alice's call leg needs to be switched from EFR to FR1, and the call should run in FR1 end to end. But how do we make it happen if the "normal" order-of-preference logic chooses EFR for Alice's phone? Note that I deliberately picked a scenario for the above example in which one phone is FR1+EFR and the other is FR1 only, but neither supports AMR. If one side supports AMR but the other requires either FR1 or EFR, it is debatable whether it would be "better" for the network to transcode or to force the older codec end to end: tandem transcoding will produce worse end-to-end voice quality than forcing the older codec, but keeping the "better" end in AMR would allow that call leg to benefit from AMR advantages in poor radio conditions, i.e., conditions when AMR would run in a lower mode than 12k2. But when the choice is between forcing FR1 end to end or transcoding between FR1 and EFR, without AMR anywhere in the picture, then the transcoding option *always* loses - therefore, I argue for network support for the option of forcing the lower codec end to end. And once that option is implemented, it can also be applied for the case of only one end supporting AMR, simply as a matter of saving implementation effort on the tandem transcoding mode... There may also be a need to change TCH speech mode back and forth in call waiting scenarios. Suppose Alice is talking to Charlie (who has a "modern" phone supporting all codecs), and their call runs in EFR codec as the highest supported on both ends, or perhaps the network transcodes between EFR on Alice's end and AMR on Charlie's end - either way, Alice's call leg will be EFR. Then a call comes in from Bob (S11E phone), requiring use of FR1 codec - now any time Alice presses the "switch calls" button on her phone, switching between the EFR call with Charlie and the FR1 call with Bob, the network will need to switch her TCH back and forth too! I don't have much hope that anyone other than me is going to implement what I am asking for any time soon, so I will quite likely end up being the one to implement this functionality in the MSC. The question then becomes one of _how_ I'm going to do it: in the form of patches to OsmoMSC that would stand some chance of merging, or in the form of a total fork. The answer, my dear friends, will depend very much on how your community is going to treat me - so the ball is in your court... M~

Neels Hofmeyr &lt;nhofmeyr(a)sysmocom.de&gt; wrote: I don't know whether anything will break or not - I will need to take a closer look at your branch - but as a general question, have you given a thought to the possibility of external MNCC agents other than o-s-c that might not wish to deal with SDP? Here is how I currently handle RTP when talking MNCC to OsmoMSC: * When I receive an MNCC_RTP_CREATE message from OsmoMSC, I expect to find RTP UDP connection info in the addr member of struct gsm_mncc_rtp, I expect to find GSM_TCHF_FRAME etc in the payload_msg_type member, telling me which codec ended up being selected, and I expect to find the right value for the 'payload type' field in RTP packets in the payload_type member. Will all these struct members still be there, so I can get all this info without parsing SDP? * To complete the RTP connection, I send an MNCC_RTP_CONNECT message to OsmoMSC, with only the addr member filled in, giving my side of RTP UDP - will your new version still accept such "bare minimum" MNCC_RTP_CONNECT messages without SDP? * I never send MNCC_RTP_CREATE to OsmoMSC - reading o-s-c code, I see that it sends such, but I never bothered, because the only effect is to initiate channel assignment, and the same trigger already happens as part of "main" MNCC signaling message handling. I will need to allocate some time to review your branch a little closer, and hopefully also test it. M~

Hi Keith, well, we already have some basic Call Control functionality in osmo-msc, the internal MNCC handler, which is enough for basic call operation in a lab environment. Having a test call functionality in addition to that would be ideal for me, yes. It's not just me saying that using SEMS is an overkill. In the wiki page I linked you also wrote "it is quite some overkill" :P You're right, I [personally] don't really like SIP. I am not saying it's bad or does not do its job properly, it's just a separate galaxy to me in which I have a very little expertise. And generally I am not a big fan of text based protocols, even though in this case all string manipulations are done by some SIP library (e.g. sofia-sip). Hacking on LCR is not a simple way to achieve the goal either. I just have some warm memories associated with it (during the 34c3 talk we used it to demonstrate basic voice call functionality, by calling 995), so I tried to get my hands on it again. For the sake of nostalgia. Ack. Exactly. The less additional components it involves, the better. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte