FreeCalypso > hg > themwi-system-sw

comparison README @ 88:97317ede320a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
README: update for current status
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 21 Sep 2022 07:58:16 -0800
parents dffcae9bc8a3
children b7cd66acb123
comparison
equal deleted inserted replaced
87:9e9034ef476c 88:97317ede320a
1 This Hg repository contains a work-in-progress named Themyscira Wireless system 1 This Hg repository contains a work-in-progress named Themyscira Wireless system
2 software. Themyscira Wireless (ThemWi) is an experimental GSM network operated 2 software. Themyscira Wireless (ThemWi) is an experimental GSM network operated
3 by Mother Mychaela of FreeCalypso at a semi-urban/semi-rural location in 3 by Mother Mychaela of FreeCalypso at a semi-urban/semi-rural location in
4 Southern California, USA; this GSM network is operated with Osmocom CNI software 4 Southern California, USA; this GSM network is operated with Osmocom CNI software
5 components, all running on a single Slackware Linux server. ThemWi system sw 5 components, all running on a single Slackware Linux server. ThemWi system sw
6 is going to be a suite of daemon processes and command line tools that run on 6 is a suite of daemon processes and command line tools that run on the same
7 the same machine as all those Osmocom sw components and provide some additional 7 machine as all those Osmocom sw components and provide some additional
8 functionality that is not provided "out of the box" by Osmocom, most important 8 functionality that is not provided "out of the box" by Osmocom, most important
9 of which is outside connectivity to USA PSTN. 9 of which is outside connectivity to USA PSTN.
10
11 Right now we have a themwi-mncc daemon process that connects to OsmoMSC via the
12 MNCC socket interface provided by the latter and takes the place of OsmoMSC's
13 mncc_builtin. themwi-mncc switches local calls (from one GSM subscriber to
14 another) just like mncc_builtin, but it also provides a hook (mtcall_socket)
15 for routing externally originated calls to GSM (which then become MT calls),
16 and it will later have a similar interface for routing MO calls to the outside
17 world. Additional daemon processes that will interface with USA PSTN via SIP
18 (one process accepting SIP INVITEs from bulkvs.com servers, turning them into
19 MNCC and sending the calls toward GSM, and another process going the other way)
20 remain to be implemented.
21 10
22 We are currently experimenting with using bulkvs.com as our USA PSTN 11 We are currently experimenting with using bulkvs.com as our USA PSTN
23 connectivity provider. Like most low-cost PSTN connectivity providers, they 12 connectivity provider. Like most low-cost PSTN connectivity providers, they
24 provide the interface to PSTN in the form of a SIP trunk - while I would 13 provide the interface to PSTN in the form of a SIP trunk - while I would
25 absolutely love to get a traditional TDM trunk instead, with SS7 signaling, 14 absolutely love to get a traditional TDM trunk instead, with SS7 signaling,
26 such a toy would be far beyond my budget, hence I have to settle for SIP. 15 such a toy would be far beyond my budget, hence I have to settle for SIP.
27 Our current status is: 16 Our current status is:
28 17
29 * We have already obtained a block of USA phone numbers (NANP, chosen numbers 18 * We have already obtained a block of USA phone numbers (NANP, chosen numbers
30 from an exchange area local to us) from bulkvs.com; 19 from an exchange area local to us) from BulkVS.
31 20
32 * These bulkvs-sourced real NANP numbers have been entered as MSISDNs into 21 * These BulkVS-sourced real NANP numbers have been entered as MSISDNs into
33 OsmoHLR records for our test SIMs operating on ThemWi GSM; 22 OsmoHLR records for our test SIMs operating on ThemWi GSM.
34 23
35 * We can successfully dial calls from one ThemWi GSM phone to another, with 24 * We can successfully dial calls from one ThemWi GSM phone to another, with our
36 themwi-mncc understanding all dialing formats that are considered standard 25 themwi-mncc switch understanding all dialing formats that are considered
37 for cellular phone networks in USA (full international, or 11 digits starting 26 standard for cellular phone networks in USA (full international, or 11 digits
38 with '1' but no '+', or 10 digits only), as well as our own non-standard 27 starting with '1' but no '+', or 10 digits only), as well as our own non-
39 shorthand dialing method with only 4 digits; 28 standard shorthand dialing method with only 4 digits.
40 29
41 * Whenever someone dials one of our NANP numbers from the outside world, bulkvs 30 * Whenever someone dials one of our NANP numbers from the outside world, BulkVS
42 servers send UDP SIP INVITE packets to our server, and by dumping them with 31 servers send UDP SIP INVITE packets to our server. Our inbound call gateway
43 our sip-udp-dump utility, we can see exactly what we have to work with; 32 process is themwi-sip-in; this daemon process listens on UDP port 5060,
33 accepts SIP calls from BulkVS (ultimately coming from global worldwide PSTN)
34 and turns them into GSM MT calls in MNCC format, going through themwi-mncc
35 and ultimately to OsmoMSC.
44 36
45 * The rest remains to be implemented. 37 The following functionality remains to be implemented:
38
39 * As a counterpart to themwi-sip-in, there will be another process named
40 themwi-sip-out that will serve as a gateway for outbound calls, going from
41 GSM MO MNCC to outside PSTN via SIP. The outbound SIP call functional part
42 is already implemented in test prototype form in sip-manual-out.
43
44 * themwi-mgw will be our transcoding RTP bridge, speaking GSM codecs (FR and
45 EFR are currently of most interest) on the side toward Osmocom components and
46 G.711 (PCMU or PCMA) on the PSTN side. Right now themwi-mgw is a working
47 skeleton that allocates endpoints with RTP & RTCP UDP port pairs, but doesn't
48 pass any traffic yet.
49
50 Differences from osmo-sip-connector
51 -----------------------------------
52
53 In the Osmocom community, the "standard" (or generally accepted) way to connect
54 a GSM voice network to the outside world is via osmo-sip-connector, an Osmocom
55 process that connects to OsmoMSC's MNCC socket on one end and talks SIP on the
56 other end. Our combination of themwi-mncc, themwi-sip-in and themwi-sip-out
57 effectively takes the place of osmo-sip-connector. Here are the principal ways
58 in which our solution differs from osmo-sip-connector:
59
60 * o-s-c is designed to connect to a local instance of a SIP PBX such as Asterisk
61 or FreeSWITCH, as opposed to interfacing directly to an outside SIP trunk
62 from/to a PSTN-via-SIP connectivity provider. themwi-system-sw is different
63 in this regard: we do NOT use Asterisk or FreeSWITCH or any other similar
64 software of "spaceship" complexity, instead our themwi-sip-in and
65 themwi-sip-out processes interface directly to our PSTN-via-SIP connectivity
66 provider.
67
68 * o-s-c has no internal call switching function for calls from one local GSM
69 phone to another, instead such switching is punted to the required Asterisk
70 or FreeSWITCH etc. With o-s-c, the calling phone's MO call is converted to
71 SIP, then Asterisk or other PBX hairpins it back to o-s-c, and then o-s-c
72 handles the destination call leg as a separate conversion from SIP back to
73 GSM MNCC. In our solution such local calls are switched internally inside
74 themwi-mncc, staying native within GSM MNCC land and never turning into SIP.
75
76 * o-s-c is based on Sofia-SIP, which in turn uses glib - a very unpleasant
77 dependency in this Mother's opinion. In contrast, our implementation of SIP
78 is 100% from scratch, written in plain C in the traditional Falconian coding
79 style.
80
81 The need for RTP voice transcoding
82 ----------------------------------
83
84 In the context of GSM voice codecs, the term "transcoding" is used in two
85 significantly different meanings:
86
87 * Transcoding from one lossy GSM codec to another effectively constitutes two
88 lossy speech codecs running in tandem, and is a highly undesirable condition.
89
90 * Running a single GSM codec (not two in tandem), decoding from GSM to G.711 in
91 one direction and encoding from G.711 in the other direction, is a standard
92 required function for traditional voice gateways between GSM and PSTN.
93
94 In themwi-system-sw, we need to do transcoding in the second sense above.
95 BulkVS SIP call interface to PSTN does not support any of GSM codecs, they only
96 support G.711 and G.729, and the same situation is expected to hold with other
97 PSTN-via-SIP connectivity providers. We certainly don't want to use G.729 - we
98 don't want to run two lossy speech codecs in tandem, first GSM and then G.729 -
99 hence the only codecs we speak on the PSTN-via-SIP side of our gateway are PCMU
100 and PCMA. Therefore, we need to perform RTP transcoding in our themwi-mgw,
101 very similar to a traditional GSM TRAU.
102
103 On the GSM side, the two codecs of most interest to us at the present time are
104 the original FR and EFR - hence they will be the first to be supported. Note
105 the big difference from other Osmocom-using GSM community networks which
106 typically prefer or even strictly require AMR instead! Our reasons for focusing
107 on FR and EFR instead of AMR are:
108
109 * Our OsmoBSC time slot configuration is full rate channels only, no half rate
110 channels. HR channels are needed only for greater capacity of simultaneous
111 calls, but with the total number of people *on the planet* who actively want
112 GSM/2G as opposed to LTE or 5G being no more than maybe 10, the thought of
113 exceeding the limit of 6 simultaneous call legs per cell (meaning 6 separate
114 GSM phone handsets talking *at the same time*) is preposterous.
115
116 * Without any HR channels in OsmoBSC config, AMR means AMR-FR specifically, not
117 AMR-HR. The highest level of AMR-FR is identical with EFR - thus if we
118 support EFR, do we really need AMR?
119
120 * The whole point of Themyscira Wireless is to provide service to *vintage*
121 mobile phones. Our current collection of vintage phones includes models that
122 only support FR1 and EFR (Ericsson I888, Nokia 5190) and Calypso C05 which
123 supports FR1, EFR and HR1, but not AMR.
124
125 * EFR is desirable because it gives better voice quality than FR1, but we must
126 support FR1 too, so we can serve the very oldest of phones which support only
127 FR1 and nothing else.
128
129 Voice codec restriction (forcing GSM phones to use EFR instead of AMR, or
130 forcing all the way down to FR1) is done in OsmoBSC config, with codec-list
131 setting under 'msc 0'.