# HG changeset patch # User Mychaela Falconia # Date 1678396111 28800 # Node ID b259e2722485008b4fe056f0b785b7c93c2638a3 # Parent a851bde42d8286ea12c3420c3bf23d0997a9880a README: update for current status diff -r a851bde42d82 -r b259e2722485 README --- a/README Fri Feb 17 19:05:05 2023 -0800 +++ b/README Thu Mar 09 13:08:31 2023 -0800 @@ -34,25 +34,62 @@ and turns them into GSM MT calls in MNCC format, going through themwi-mncc and ultimately to OsmoMSC. -* These inbound calls per the previous bullet point also include fully working - voice path, with our themwi-mgw transcoding the two RTP streams (one in each - direction) between the original GSM 06.10 codec on the GSM side and G.711 - PCMU or PCMA on the PSTN-via-SIP side. This voice call gateway includes - working DTMF support: START DTMF and STOP DTMF commands from GSM phones pass - through OsmoMSC, themwi-mncc and themwi-sip-in to themwi-mgw, and the latter - process injects in-band DTMF tones into the G.711 RTP stream that is otherwise - generated by transcoding from GSM voice codecs. +* Our outbound call gateway is themwi-sip-out, serving as a counterpart to + themwi-sip-in. All GSM MO calls are initially handled by themwi-mncc, which + decides (based on the dialed number) whether to switch the call locally + (calling another ThemWi GSM phone) or to pass it to themwi-sip-out. The + latter process turns outbound calls into SIP and sends them to BulkVS, and we + are successfully able to call any PSTN destination anywhere in the +1 country + code. (themwi-sip-out has provisions for international routes too, but we + haven't set up any yet.) + +* These inbound and outbound calls per the previous two bullet points also + include fully working voice path, with our themwi-mgw transcoding the two RTP + streams (one in each direction) between the original GSM 06.10 codec or + GSM 06.60 EFR codec on the GSM side and G.711 PCMU or PCMA on the PSTN-via-SIP + side. This voice call gateway includes working DTMF support: START DTMF and + STOP DTMF commands from GSM phones pass through OsmoMSC, themwi-mncc and + themwi-sip-{in,out} to themwi-mgw, and the latter process injects in-band DTMF + tones into the G.711 RTP stream that is otherwise generated by transcoding + from GSM voice codecs. 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. +* The only GSM codecs currently supported are the original FR (GSM 06.10) and + EFR (GSM 06.60). At some point it would be nice to add support for AMR and + maybe even HR1, purely for demonstration of its poor voice quality. + +* The Presiding High Priestess of Themyscira Wireless has a desire to implement + in-band GSM 08.62 TFO inside our G.711 RTP interface to outside PSTN. Right + now if a call is connected between a ThemWi GSM phone on one end and another + GSM phone on some other network anywhere else in the world, an undesirable + tandem transcoding takes place: two lossy GSM speech codecs run in tandem, + one on the ThemWi GSM leg of the call and another on the distant GSM network's + leg, with a G.711 64 kbps connection in between. If we implement GSM 08.62 + TFO inside our G.711 RTP interface which we present to the outside world, we + shall achieve TFO calls at least between ThemWi and any other community GSM + networks using our software, and maybe even between ThemWi and some legacy + commercial GSM networks, if any still remain in parts of the world that are + accessible to us. -* Right now themwi-mgw supports only the original FR1 codec (GSM 06.10) on the - GSM side; the Mother's desire is to also support EFR codec as a high priority, - and maybe some time later AMR as a lower priority. +* No work whatsoever has been done on SMS as of yet - all of our ThemWi work so + far has been in support of voice call functionality only. Adding SMS support + will require 3 major areas of work: + +1) We will need to climb the learning curve and assess the current state of SMS + support in Osmocom CNI software. + +2) We'll have to find a USA PSTN connectivity provider who supports P2P SMS: if + we are operating a GSM network and providing mobile phone service to human + end users, any SMS usage in such scenario MUST be classified as P2P rather + than A2P. However, gaining access to P2P SMS in USA telecom environment is + currently very difficult (every major provider forcibly imposes A2P + misclassification with no option of P2P correct classification), in stark + contrast to very easy and cheap access to voice PSTN with NANP phone numbers. + +3) When and if we find that necessary USA PSTN connectivity provider with P2P + SMS provision, we will need to implement whatever software will be needed to + interconnect it with an OsmoCNI GSM network, likely a custom SMSC. Differences from osmo-sip-connector -----------------------------------