Vadim Yanitskiy vyanitskiy@sysmocom.de wrote:
The problem is I wanted to highlight is that there is currently no *easy* way to test voice calls,
See below for my thoughts, but:
especially when running a virtual OsmoRAN setup (fake_trx.py + trxcon or virtphy).
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?
Currently with the new post-NITB stack I see the following options:
a) run a virtual BTS, attach two mobiles, and setup a call between them; b) run a real BTS, attach two phones, and setup a call between them; c) run some PBX, talking to osmo-msc via osmo-sip-connector.
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.
a) requires running two instances of the mobile app (from osmocom-bb.git). I know one can run two and even more MS instances in one mobile process, but this is still not handy.
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.
b) requires running a real BTS and interacting with real phones. This is what I usually do, but it takes more time than running everything virtually.
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.
c) requires setting up a PBX (e.g. Freeswitch, Asterisk), which in its turn requires digging into the new world of configuration files. I do have a repository with a know-to-work Freeswitch configuration [2], but installing it (even from packages) is not trivial.
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 would be great to have an easy-to-use echo service, be it attached to osmo-msc via the MNCC socket, or be it built-in part of osmo-msc itself.
It should be not-too-difficult to integrate such function into ThemWi MNCC architecture.
If anyone likes this approach, I could implement a 'test-call' command which would be like a silent call, but sending an MT SETUP message with a random calling MSISDN. This way it would work for real phones too.
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~