FreeCalypso > hg > themwi-system-sw
view README @ 127:f062c32a5116
mgw: implement DTMF
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 01 Oct 2022 20:31:15 -0800 |
parents | 97317ede320a |
children | b7cd66acb123 |
line wrap: on
line source
This Hg repository contains a work-in-progress named Themyscira Wireless system software. Themyscira Wireless (ThemWi) is an experimental GSM network operated by Mother Mychaela of FreeCalypso at a semi-urban/semi-rural location in Southern California, USA; this GSM network is operated with Osmocom CNI software components, all running on a single Slackware Linux server. ThemWi system sw is a suite of daemon processes and command line tools that run on the same machine as all those Osmocom sw components and provide some additional functionality that is not provided "out of the box" by Osmocom, most important of which is outside connectivity to USA PSTN. We are currently experimenting with using bulkvs.com as our USA PSTN connectivity provider. Like most low-cost PSTN connectivity providers, they provide the interface to PSTN in the form of a SIP trunk - while I would absolutely love to get a traditional TDM trunk instead, with SS7 signaling, such a toy would be far beyond my budget, hence I have to settle for SIP. Our current status is: * We have already obtained a block of USA phone numbers (NANP, chosen numbers from an exchange area local to us) from BulkVS. * These BulkVS-sourced real NANP numbers have been entered as MSISDNs into OsmoHLR records for our test SIMs operating on ThemWi GSM. * We can successfully dial calls from one ThemWi GSM phone to another, with our themwi-mncc switch understanding all dialing formats that are considered standard for cellular phone networks in USA (full international, or 11 digits starting with '1' but no '+', or 10 digits only), as well as our own non- standard shorthand dialing method with only 4 digits. * Whenever someone dials one of our NANP numbers from the outside world, BulkVS servers send UDP SIP INVITE packets to our server. Our inbound call gateway process is themwi-sip-in; this daemon process listens on UDP port 5060, accepts SIP calls from BulkVS (ultimately coming from global worldwide PSTN) and turns them into GSM MT calls in MNCC format, going through themwi-mncc and ultimately to OsmoMSC. The following functionality remains to be implemented: * As a counterpart to themwi-sip-in, there will be another process named themwi-sip-out that will serve as a gateway for outbound calls, going from GSM MO MNCC to outside PSTN via SIP. The outbound SIP call functional part is already implemented in test prototype form in sip-manual-out. * themwi-mgw will be our transcoding RTP bridge, speaking GSM codecs (FR and EFR are currently of most interest) on the side toward Osmocom components and G.711 (PCMU or PCMA) on the PSTN side. Right now themwi-mgw is a working skeleton that allocates endpoints with RTP & RTCP UDP port pairs, but doesn't pass any traffic yet. Differences from osmo-sip-connector ----------------------------------- In the Osmocom community, the "standard" (or generally accepted) way to connect a GSM voice network to the outside world is via osmo-sip-connector, an Osmocom process that connects to OsmoMSC's MNCC socket on one end and talks SIP on the other end. Our combination of themwi-mncc, themwi-sip-in and themwi-sip-out effectively takes the place of osmo-sip-connector. Here are the principal ways in which our solution differs from osmo-sip-connector: * o-s-c is designed to connect to a local instance of a SIP PBX such as Asterisk or FreeSWITCH, as opposed to interfacing directly to an outside SIP trunk from/to a PSTN-via-SIP connectivity provider. themwi-system-sw is different in this regard: we do NOT use Asterisk or FreeSWITCH or any other similar software of "spaceship" complexity, instead our themwi-sip-in and themwi-sip-out processes interface directly to our PSTN-via-SIP connectivity provider. * o-s-c has no internal call switching function for calls from one local GSM phone to another, instead such switching is punted to the required Asterisk or FreeSWITCH etc. With o-s-c, the calling phone's MO call is converted to SIP, then Asterisk or other PBX hairpins it back to o-s-c, and then o-s-c handles the destination call leg as a separate conversion from SIP back to GSM MNCC. In our solution such local calls are switched internally inside themwi-mncc, staying native within GSM MNCC land and never turning into SIP. * o-s-c is based on Sofia-SIP, which in turn uses glib - a very unpleasant dependency in this Mother's opinion. In contrast, our implementation of SIP is 100% from scratch, written in plain C in the traditional Falconian coding style. The need for RTP voice transcoding ---------------------------------- In the context of GSM voice codecs, the term "transcoding" is used in two significantly different meanings: * Transcoding from one lossy GSM codec to another effectively constitutes two lossy speech codecs running in tandem, and is a highly undesirable condition. * Running a single GSM codec (not two in tandem), decoding from GSM to G.711 in one direction and encoding from G.711 in the other direction, is a standard required function for traditional voice gateways between GSM and PSTN. In themwi-system-sw, we need to do transcoding in the second sense above. BulkVS SIP call interface to PSTN does not support any of GSM codecs, they only support G.711 and G.729, and the same situation is expected to hold with other PSTN-via-SIP connectivity providers. We certainly don't want to use G.729 - we don't want to run two lossy speech codecs in tandem, first GSM and then G.729 - hence the only codecs we speak on the PSTN-via-SIP side of our gateway are PCMU and PCMA. Therefore, we need to perform RTP transcoding in our themwi-mgw, very similar to a traditional GSM TRAU. On the GSM side, the two codecs of most interest to us at the present time are the original FR and EFR - hence they will be the first to be supported. Note the big difference from other Osmocom-using GSM community networks which typically prefer or even strictly require AMR instead! Our reasons for focusing on FR and EFR instead of AMR are: * Our OsmoBSC time slot configuration is full rate channels only, no half rate channels. HR channels are needed only for greater capacity of simultaneous calls, but with the total number of people *on the planet* who actively want GSM/2G as opposed to LTE or 5G being no more than maybe 10, the thought of exceeding the limit of 6 simultaneous call legs per cell (meaning 6 separate GSM phone handsets talking *at the same time*) is preposterous. * Without any HR channels in OsmoBSC config, AMR means AMR-FR specifically, not AMR-HR. The highest level of AMR-FR is identical with EFR - thus if we support EFR, do we really need AMR? * The whole point of Themyscira Wireless is to provide service to *vintage* mobile phones. Our current collection of vintage phones includes models that only support FR1 and EFR (Ericsson I888, Nokia 5190) and Calypso C05 which supports FR1, EFR and HR1, but not AMR. * EFR is desirable because it gives better voice quality than FR1, but we must support FR1 too, so we can serve the very oldest of phones which support only FR1 and nothing else. Voice codec restriction (forcing GSM phones to use EFR instead of AMR, or forcing all the way down to FR1) is done in OsmoBSC config, with codec-list setting under 'msc 0'.