On 06/12/2022 17:21, Vadim Yanitskiy wrote:
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.
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/