--- 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
 -----------------------------------