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/