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.