Keith keith@rhizomatica.org wrote:
[Keith was responding to Vadim, but the actual nature of his arguments is such that they could have been addressed to me much the same, so I am going to take the liberty of adding my response as well.]
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.
While I disagree about o-s-c being the end-all, be-all solution, a more practical problem with implementing Vadim's proposal of a test-call vty command inside OsmoMSC would be the clash with MNCC. Let's say you implement a vty command that sends an MT SETUP CC message to the named subscriber - what then? With the current code, a dialogue is established between the MS and the MNCC entity (be it internal or external), with all subsequent CC messages from the MS turning into corresponding MNCC messages. There is only one MNCC message pipe, with different calls distinguished by uint32_t callref numbers. The only way I can envision an implementation of this vty test-call proposal would be yet another internal MNCC agent inside OsmoMSC, coexisting with either the internal simple-switch MNCC or the external MNCC socket, and a routing mechanism: for every CC message arriving from an MS, the code would have to check and see if it should go to the "main" MNCC agent or to the special one for vty test-call. Seems like a lot of effort to me.
I can send a SETUP anytime I like with a random caller MSISDN via a plethora of SIP tools.
And I can do likewise using only MNCC, without SIP! In my ThemWi system sw architecture, I use Osmocom-defined MNCC as the call control interface between components. The component that connects to OsmoMSC's MNCC socket is themwi-mncc, and it is a switch/dispatcher/funnel for MNCC messages. I then have further UNIX domain sockets connecting other components to themwi-mncc, but the messages exchanged on those ThemWi sockets are exactly the same structs as those passed on the socket from/to OsmoMSC - themwi-mncc merely routes them. The use case of a test MT call is very useful to me, a simple test call from the command line to an attached MS, so I wrote the requisite test program quite early in my development - it is themwi-test-mtc. This command line program connects to themwi-mncc via mtcall_socket and sends an MNCC_SETUP_REQ message, which themwi-mncc simply forwards to OsmoMSC, initiating an MT call. But to make the whole mechanism work, themwi-test-mtc needs to stay running for the duration of that test call, and it handles all subsequent CC-turned-MNCC message exchanges: for example, if I then press keypad buttons on the test MS during the call, I see corresponding DTMF messages in the terminal window from which I run themwi-test-mtc. Disconnect and call clearing signaling is also implemented in themwi-test-mtc, and the command line program exits gracefully when the call finishes.
I haven't done the gapk trick like Vadim suggested - I could certainly do it, it would be easy to modify themwi-test-mtc to support a user-provided RTP destination instead of grabbing a dummy endpoint from themwi-mgw, but I haven't had a need to do it yet. The approach that works for me is that I can run tcpdump to capture RTP traffic, dial a test call with themwi-test-mtc, speak into the test phone, and then analyze the pcap file. (For the latter step, I first feed the pcap file to my rtp-gsmfr-extr program, then feed the extracted codec session recording to either gsmfr-decode or gsmefr-decode as appropriate - all just-named tools reside in my gsm-codec-lib repository, my alternative to gapk in a way.)
As for the calling MSISDN on these test calls, I either specify one with -f option to themwi-test-mtc, or if I run without this option, the corresponding IE is omitted in the MNCC_SETUP_REQ message and thus in the MT SETUP message going to the MS.
Maybe you want to try to keep it in osmo-* land or somehow you don't like SIP..
Speaking for myself only (not for Vadim!), I most absolutely dislike SIP! I like traditional telephony, I like TDM and SS7 and ISDN, and I use SIP for interconnection to USA PSTN only out of poverty - if I had the wealth of Jeff Bezos or Elon Musk etc, I would never bother with SIP, I would get a traditional TDM trunk, but given that I am NOT rich, I have to use SIP because it's a dirt-cheap way to connect to USA PSTN via companies like BulkVS.
For this reason, I keep my use of SIP confined to the very edge of my network, *only* for the cheap interface to PSTN, and I have implemented SIP in ThemWi as an edge interface, NOT an internal interface. My internal interface between call routing components is currently Osmocom MNCC.
(and by extension, IMS?)
Pure evil! I refuse to use or own a VoLTE phone - if T-Mobile USA kill their GSM network before I go off to Valhalla, I will have no working phone at all outside of my pirate cell coverage area.
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.
Again, not speaking for Vadim in any way, but for me personally this factor is huge too - it is far easier for me, and even more importantly, far more pleasant, to code up my own solution (in C, from scratch) according to my own philosophy and paradigm than to learn to and adapt to someone else's solution built according to someone else's philosophy and paradigm. And it is not just the ease of doing it once, the quality of the end result is very different too: if I were to adopt someone else's solution (because it's easier in the short term, faster, whatever), then I will be forever stuck in a state of paradigmatic discord, forever unhappy with That Other Party's differing philosophy and paradigm, whereas writing my own code exactly the way *I* like it solves that problem at the root. :)
It sort of reminds me of a conversation with David Burgess at the 29c3. [...] 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.
This SIP-zealotry (along with SDR-zealotry, meaning fundamental incompatibility with non-SDR implementations of GSM BTS) is among the reasons why I chose OsmoCNI over OpenBTS for the network side of GSM.
Now, I get and I'm all for replicating the original CS stuff in open source.
Given that operating any kind of GSM network is inherently an intentional retrotechnology pursuit *in itself* (at least in the so-called "first world", on soil where every square mm is already covered with super-strong 4G and 5G signals from 3 major carriers), replicating the classic GSM network architecture as closely as possible is the only proper way to go, in my opinion.
Practically, I think osmo-sip-connector could use more love
I see o-s-c as an unnecessary straightjacket that does nothing but artificially restrict ways in which additional network elements can be built to handle voice behind OsmoMSC. You know full well that the conversion from MNCC to SIP done by o-s-c is very far from lossless - what happens to "user to user info" IE from CC messages from MS? What happens to various rich GSM cause values and locations that have no 1:1 mapping to SIP? What about DTMF duration fudging? In GSM there is one CC message sent when the user presses a keypad button and another message sent when she lifts her finger, and this user finger timing is preserved in MNCC - but the INFO method hack for DTMF in SIP requires that the duration be given upfront, so you send a hard-coded number and *lose* user finger timing of DTMF. On T-Mobile's not-yet- shutdown GSM network, their DTMF generator does preserve user finger timing: I can do a test call from a GSM phone to a POTS line, and I can hear shorter or longer DTMF tones depending on how long I press and hold keypad buttons. Therefore, my Themyscira Wireless network MUST be no worse, and the o-s-c "solution" of ignoring user finger timing and always forcing 180 ms or whatever is NOT acceptable.
In my Universe, the closest counterpart to o-s-c is my pair of themwi-sip-in and themwi-sip-out. Aside from separating the two directions of call establishment (there is some significant code that is common, and there is also significant code that is highly specific to one vs other direction, thus there is no clear-cut answer whether it is "better" to unify or separate the two), the biggest diff is that my daemons are written for SIP-at-edge, rather than internal SIP. Unlike o-s-c, my daemons never propagate GSM codec details to the SIP side - instead the SIP side is expected to be PSTN, speaking G.711 instead of GSM codecs, and every call going through themwi-sip-in/out also has to go through themwi-mgw, which is a transcoding MGW. themwi-mgw is controlled by themwi-sip-in/out via an internal ad hoc protocol; operationally every TMGW endpoint has a GSM side speaking one of GSM codecs and a PSTN side speaking G.711, either PCMU or PCMA, and the MGW operation is a "soft TRAU" - doing exactly what classic E1 TRAUs once did, but doing it on RTP streams. DTMF tones are injected in-band by themwi-mgw, under control from themwi-sip-in/out, and follow user finger timing as relayed via CC messages on the GSM call leg.
(not to mention osmo-msc support for SDP and codecs)
If you are talking about Neels' codecs branch/patch, I am not too impressed with it, and if it does get merged, my only concern will be how it may break things for people like me who don't do SIP or SDP in their GSM CN. Because I never run SIP inside my CN, only at the PSTN interface, I never have any occasion to represent GSM codecs in SDP. The only codecs that ever get represented in SIP and SDP in my world are PCMU and PCMA; the requisite SDP generation and parsing is done in themwi-sip-in and themwi-sip-out (factored out into libsip), and these two daemons communicate the selection of PCMU or PCMA to themwi-mgw.
Now what we (as in GSM community, wider than just Osmocom subset thereof) do need to implement in OsmoMSC codec-wise is an ability for external MNCC agents to command TCH reassignment from one speech mode to another. Imagine this scenario: Alice uses an Ericsson I888 phone, which supports FR1 and EFR codecs but no others, and she calls Bob, who has an even older Siemens S11E phone, supporting only FR1. In this scenario, having the network transcode between EFR on leg A and FR1 on leg B would be not only a waste of CPU cycles, but also a needless degradation of voice quality: operating two different lossy codecs in tandem *always* results in worse end-to-end quality than either codec by itself. Instead in this scenario the *optimal* answer is unambiguous: Alice's call leg needs to be switched from EFR to FR1, and the call should run in FR1 end to end. But how do we make it happen if the "normal" order-of-preference logic chooses EFR for Alice's phone?
Note that I deliberately picked a scenario for the above example in which one phone is FR1+EFR and the other is FR1 only, but neither supports AMR. If one side supports AMR but the other requires either FR1 or EFR, it is debatable whether it would be "better" for the network to transcode or to force the older codec end to end: tandem transcoding will produce worse end-to-end voice quality than forcing the older codec, but keeping the "better" end in AMR would allow that call leg to benefit from AMR advantages in poor radio conditions, i.e., conditions when AMR would run in a lower mode than 12k2. But when the choice is between forcing FR1 end to end or transcoding between FR1 and EFR, without AMR anywhere in the picture, then the transcoding option *always* loses - therefore, I argue for network support for the option of forcing the lower codec end to end. And once that option is implemented, it can also be applied for the case of only one end supporting AMR, simply as a matter of saving implementation effort on the tandem transcoding mode...
There may also be a need to change TCH speech mode back and forth in call waiting scenarios. Suppose Alice is talking to Charlie (who has a "modern" phone supporting all codecs), and their call runs in EFR codec as the highest supported on both ends, or perhaps the network transcodes between EFR on Alice's end and AMR on Charlie's end - either way, Alice's call leg will be EFR. Then a call comes in from Bob (S11E phone), requiring use of FR1 codec - now any time Alice presses the "switch calls" button on her phone, switching between the EFR call with Charlie and the FR1 call with Bob, the network will need to switch her TCH back and forth too!
I don't have much hope that anyone other than me is going to implement what I am asking for any time soon, so I will quite likely end up being the one to implement this functionality in the MSC. The question then becomes one of _how_ I'm going to do it: in the form of patches to OsmoMSC that would stand some chance of merging, or in the form of a total fork. The answer, my dear friends, will depend very much on how your community is going to treat me - so the ball is in your court...
M~