Re: Testing voice calls in OsmoCNI

Vadim Yanitskiy <vyanitskiy(a)sysmocom.de> wrote: Of course none exist and none can possibly exist, and... My point was (and still remains) that I see the very idea of virtual RAN as utterly pointless. Sure, it is a "cool" hack, you can feel all awesome and proud that you did it, but what in the world does it actually accomplish? *Especially* if we are talking about *voice* testing - surely voice is the one test scenario in which a virtual setup is at its *most* useless? I can kinda-sorta-see some signaling test scenarios where your virtual setup would provide some limited value: you've made some change to OsmoBSC or OsmoMSC or OsmoHLR, and while a test with an MS implementation that isn't your own is still required later, you could do a first-pass sanity check with your own MS - so I will grant you that use case. But doing this virtual exercise for voice? Just what are you actually testing then? You have no physical MS whose speaker/mic analog circuits are being tested, no MS DSP codec implementation being tested, and I don't see any way at all to listen to voice DL or speak into voice UL on the MS end in your virtual scenario. Suppose you connect two instances of your mobile app to your virtual RAN - but without any actual MS hw, what will become of "virtual speaker" and "virtual mic" voice endpoints on each end of the call? Does your mobile app now feature integration with libosmogapk and various codec libs plus ALSA, to the point where your PC speakers and mic become the speaker+mic set of the virtual MS? If the answer to that last question is yes, then I can see how you could do some voice testing (although still not replacing further testing with a standard phone) with your virtual MS *if* the other end of the test call is a PSTN gateway or a PBX with melody and echo test numbers, etc. But you were suggesting a test scenario with *two* instances of mobile app, one calling the other - just where is the actual test, *what* would be tested (and how, if both run on the same PC that has only one speaker output and only one mic input) in this specific scenario which you included? What the heck? If I used *only* my own MS implementation, then I would be no better than what I am accusing you of - instead I make a point of testing my Themyscira Wireless network (which makes heavy use of OsmoCNI components in addition to my own themwi-system-sw, and thus on-topic here) with phones other than my own FC, and ideally with phones whose chipset is not Calypso at all - I routinely test with Ericsson I888 for the oldest end of the spectrum and Nokia C3-00 for the newest end. (I invite you to look up the ages of just-named models and see how they neatly bracket almost the entire era of GSM. Neither is TI-based.) I never said that my approach makes for a simple solution in the case of someone who is not already running all of that sw for other needs. However, I was responding to this part of your original post: My approach happens to be an easy approach *for me* because I've already developed all necessary sw components, and established all needed non-sw components as well (business Internet connection with a static IP, setup with bulkvs.com for USA PSTN interface). And I consider my answer to be relevant and on-topic because voice testing is indeed one of my major objectives. Suppose I produce a new GSM MS board - how would I test its analog audio circuits, how would I tune its DSP audio settings etc? There is only one way - I need to be able to make test calls on a GSM network. And if I wish to be independent of commercial operators in this venture, then that GSM network needs to be my own - thus a need for an OsmoCNI-based network with solidly working voice. As I analyzed this problem earlier this year, I quickly concluded that building an interface to PSTN would be the best way - this way I can do tests with another human on the other end of the call, to give me feedback on how my uplink sounds - hence it is my honest and fully truthful answer that I found my PSTN interface (from an OsmoCNI network, hence on-topic here) to be the best way to test GSM voice calls, at least for me. But I think I see where I may have gone astray in my response to your post: you said "you guys", and I failed to grasp your intent behind that wording. You see, I made the innocent mistake of assuming that you said "you guys" when really meaning plural-you of all genders - but now I am thinking that I was wrong in my interpretation, you probably meant "you guys" as explicitly excluding women. Because it just so happens that at the present moment I am the only woman (to my knowledge) working on GSM in a publicly-visible manner (not counting whatever may be happening inside walls of commercial companies with no public ML interaction), limiting to men only would be a convenient way to exclude the one-and-only public GSM developer who retains her independence, who has not assimilated into the galactic empire of Osmocom. Got it! "Resistance is futile, resign and you will be assimilated..." And what exactly is wrong with it? ThemWi system sw is an add-on to OsmoCNI, it was developed specifically to work together with OsmoCNI and can't work without it, hence I argue that it should be on-topic here. Furthermore, you yourself always include links to code repositories in your own posts, even when they are Osmocom repos which everyone on this ML would be presumed to know about (e.g., your link to gapk repo in your previous follow-up) - therefore, if there is a discussion involving an area where ThemWi additions to OsmoCNI are relevant and useful, I will remind people of the existence and availability of this option. You have told me yourself in our conversations that voice is an area where pure OsmoCNI (without augmentation with non-Osmocom components) is *weak*, and furthermore, as all of your PDF manuals emphasize, FOSS lives by contribution. If the core people behind Osmocom (practically meaning Sysmocom team) are not in a position to improve OsmoCNI support for voice (because that's not what paying customers are asking for, yadda yadda yadda), then why are you complaining when *someone else* (who is not on Sysmocom payroll and who has different objectives and priorities) steps forward to implement voice functions (transcoding, PSTN interface, call waiting, more to come) which pure OsmoCNI does not provide out of the box? Oh, I know *exactly* what you don't like about me: you don't like the fact that I develop my improvements to OsmoCNI in the form of add-on components written in my own programming style (principally meaning K&R C, 1980s UNIX style, no systemd and no autotools) instead of patches to existing OsmoCNI components themselves. Well, that's life: those who do most active development get to choose how they do it. With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela