6 Dec
2022
6 Dec
'22
7:13 p.m.
Vadim Yanitskiy <vyanitskiy(a)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~