--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tmo/CSD-tests	Mon Nov 25 07:22:43 2024 +0000
@@ -0,0 +1,181 @@
+A series of experiments seeking to test CSD on the extant network of T-Mobile
+USA, to be performed while this network is still alive.  The main objective is
+to test CSD calls between a single MS and analog (or PCMU-speaking) PSTN, rather
+than mobile to mobile.
+
+Test setup
+==========
+
+The test MS is an FCDEV3B with a legacy T-Mobile SIM.  The AT command session
+will be driven through the dedicated UART, not the usual fc-shell, to enable
+full use of data functions.  Rvinterf will still be used to capture logs; the
+following command needs to be issued in order to make the firmware emit traces
+indicating AT command activity:
+
+sp MMI TRACECLASS 800050
+
+Issue these two additional commands to trace the MMCM SAP between CC and MM
+entities of the protocol stack:
+
+sp MM DUPLICATE CC PCO
+sp CC DUPLICATE MM PCO
+
+The objective is to capture all CC protocol messages sent to and received from
+the network; tracing the exchange between CC and MM seems like the easiest way
+to accomplish this goal within our existing firmware architecture.
+
+Experiment 1
+============
+
+In this experiment several MO CSD calls were made from the test MS to
++13034944774, the number for USA taxpayer-funded NIST ACTS.  Several modes were
+tested:
+
+AT+CBST=7,0,1	-- TI GSM MS firmware default
+AT+CBST=7,0,0
+AT+CBST=6,0,0
+AT+CBST=4,0,0
+AT+CBST=2,0,0
+
+Results were surprising:
+
+* Transparent mode works beautifully at 9600 baud, as well as 4800 and 1200
+  baud.  Therefore, the previous hypothesis that CSD at 9600 baud no longer
+  works as a result of GSM quality degradation or as a result of IP-fication of
+  internal transports within USA PSTN is now disproven.
+
+* Transparent mode at 2400 baud produced a different result: successful CONNECT
+  followed by garbage and earlier disconnect, instead of 40 s of good ACTS
+  output in other baud modes.  Perhaps a defect in V.22bis implementation in
+  the network IWF?
+
+* All 3 data TCH modes were observed in L1 traces: TCH/F9.6, TCH/F4.8 and
+  TCH/F2.4, and each of these produced a perfectly good data call in at least
+  one mode.
+
+* NT mode was only tested with AT+CBST=7,0,1 default, i.e., 9600 baud and asking
+  the IWF for V.32 modem.  As revealed by L1 and CC traces, the network does
+  everything it should - but the MS returns NO CARRIER.  However, further
+  analysis of CC traces reveals that the DISCONNECT at CC level is initiated by
+  the MS and not by the network!  My current working hypothesis is that the MS
+  is unhappy about something it sees at RLP level.
+
+Additional observations:
+
+* The MS issues a single SETUP message with BC indicating ITC of 3.1 kHz and the
+  selected CSD mode.  The network responds with CALL PROCEEDING, ALERTING and
+  CONNECT in the same cadence as it would for a MO voice call.  The timing of
+  ALERTING message is consistent with my expectation of when PSTN plays the
+  ringing tone, and the timing of CC CONNECT message is consistent with my
+  expectation of when Answer Supervision occurs at PSTN level.  The CC CONNECT
+  step is reached in all tested modes, including the failing NT mode.
+
+* The AT-command CONNECT response happens significantly later than CC CONNECT
+  message.  My current working hypothesis is that the network generates CC
+  CONNECT when it gets Answer Supervision from PSTN just like it does for voice
+  calls, well before modem connection sequence can happen.  Perhaps the status
+  of modem connection is then indicated via V.110 in-band flags, and perhaps
+  the MS is using that in-band status to decide when to declare CONNECT.
+
+* At the end of each call there was a network-initiated DISCONNECT with cause
+  value 127 (interworking, unspecified) - but in this experiment there is
+  insufficient information to tell if this action is initiated by the IWF upon
+  loss of modem signal, or if it is merely passing along PSTN-level disconnect
+  signaling from the called party.  See Experiment 2.
+
+Experiment 2
+============
+
+In this experiment several MO CSD call attempts were dialed from the test MS to
+Mother Mychaela's personal voice number on ThemWi; the latter is interconnected
+with USA PSTN via BulkVS.  The objectives were: (1) to confirm the hypothesis
+about Answer Supervision on PSTN side being the criterion for signaling CC
+CONNECT to the MS, and (2) to hear what, if anything, the IWF transmits toward
+PSTN while waiting for modem connection.
+
+Results:
+
+* When I answered the call on the destination phone, I heard silence each time.
+  The calling party received CC CONNECT signaling when I made that answer.
+
+* In both tests where +CBST was set to 7,0,0 and I answered the call, the
+  network (TMO) eventually ended the call, signaling cause 127 to the calling
+  MS like in Experiment 1.  (Thus we now know that it is the IWF taking this
+  action, and not the called party hanging up at PSTN level.)  In one of these
+  two tests, there was a miraculous CONNECT response from the AT interpreter,
+  some time well after Answer Supervision, but before the IWF-initiated
+  disconnect.  In the second test, there was no CONNECT response, only
+  NO CARRIER at the time of IWF-initiated disconnect.
+
+* In the test case where I didn't answer the destination phone (let the ringing
+  time out), the calling MS received CC DISCONNECT message with cause 17 (user
+  busy), as that is how PSTN middleboxes misinterpret SIP 480 error I return
+  from ThemWi.  The AT command interface generated BUSY response.
+
+* In the final test case in this experiment series, I made the test call with
+  +CBST=7,0,1 and answered the destination phone.  The MS initiated DISCONNECT
+  4 s after receiving CC CONNECT, just like it did when calling NIST ACTS.
+
+Experiment 3
+============
+
+This experiment sought to observe how TMO GSM network handles MT calls from PSTN
+to a mobile subscriber, including the possiblity of MT CSD calls via AT+CSNS.
+An MT call was repeatedly dialed from Mother Mychaela's ThemWi phone to the test
+MS on TMO, with different AT+CSNS and AT+CBST settings established before each
+call attempt; logs were collected for subsequent analysis.
+
+Observations:
+
+* The initial SETUP message from the network to the MS contains _no_ bearer
+  capability IE; the CALL CONFIRM response from the MS does include BC IE,
+  filled with different content depending on AT+CSNS and AT+CBST settings.
+
+* The network seems to always accept the BC supplied by the MS in that response,
+  and assigns appropriate TCH type and mode.
+
+* The PSTN caller hears the standard North American ringing tone while the MS
+  emits RING messages on its AT command channel, subsequent to the MS sending
+  CC ALERTING message to the network.
+
+* When I answer the call with ATA, the MS sends CC CONNECT to the network, the
+  PSTN caller gets Answer Supervision, and I hear modem answer tones from TMO's
+  IWF.
+
+* Only Transparent modes have been tested so far; the modem answer sequence
+  heard by the PSTN caller depends on the specific modem emulation selected
+  with AT+CBST.  With AT+CBST=2,0,0 and AT+CBST=4,0,0 I heard a continuous (no
+  phase reversals) V.25 ANS tone followed by a higher-pitched tone (presumably
+  Unscramled Binary 1s signal of V.22), followed by disconnection; with
+  AT+CBST=6,0,0 and AT+CBST=7,0,0 I heard a V.25 ANS tone *with* phase
+  reversals, directly followed by disconnection (no AC tones).
+
+Further tests were aborted (I didn't get to testing NT mode) because the network
+did something that caused the MS firmware (or perhaps the SIM) to go into a
+funky state; to be investigated as its own separate problem.
+
+Experiment 4
+============
+
+In this experiment I used two of my legacy T-Mobile SIMs simulateneously: one
+in the FCDEV3B as in the preceding experiments, the other in a Pirelli DP-L10
+phone.  The Pirelli phone ran RAM-based FC Tourmaline firmware during these
+tests.  Test calls were dialed from the FCDEV3B to the Pirelli; the fw build
+running on the latter has CSD excluded, but the objective was to see the MT
+SETUP message as it arrives from the network, before destination MS firmware
+does anything with it.
+
+Observation: _no_ BC IE was ever seen in the MT SETUP message, for both voice
+and data calls dialed from the other TMO subscriber line.  It appears that all
+MO CSD calls were treated by the network in "convert to modem emulation" mode
+despite the dialed number being another T-Mobile line; the MT leg always
+received incoming voice calls.
+
+It thus appears that a change has happened in TMO's network in this regard.
+Many years ago, before I learned about T vs NT distinction and other critical
+CSD parameters set with AT+CBST, when I would blindly dial ATDnumber, I was
+sometimes able to make a data call from a proper FreeCalypso test MS to a
+Pirelli phone running its official fw: the destination phone would ring and
+display an incoming call screen, but it said "data call".  For this feat to
+have happened, there must have been a BC IE in the MT SETUP message when the
+MO leg made a data call - hence the change between past and present bahaviour.