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.

All experiments detailed in the following sections were performed in 2024-11
at the Mother's home base.

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.  [See further updates in
  Experiment 6.]

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.

Experiment 5
============

In this experiment I sought to capture TCH DL bits from the DSP in CSD modes in
the same way how we do it in non-AMR speech modes.  I added what seemed like
the necessary support in FC Tourmaline fw (Hg commit 304:58c7961bd0b0) and in
fc-shell TCH handling code (freecalypso-tools Hg commit 1014:961efadd530a), and
made captures of CSD call sessions with +CBST set to (7,0,0), (6,0,0) and
(2,0,0).  However, as soon as I looked at the captured recordings, I was
immediately disappointed: while the beginning of each capture shows what look
like DL bits constituting idle frames (mostly all 1s, except where disturbed by
FACCH stealing), as soon as the IDS block kicks in, we read nothing but all 0s.
Is the IDS part of DSP ROM code overwriting the buffer with zeros after it groks
those bits?

Also in this experiment session I tried setting AT+CBST=14,0,0 to see if TMO
supports TCH/F14.4.  The network responded to SETUP with CALL PROCEEDING, but
whereas in other modes channel assignment happens almost immediately afterward,
here it stayed on SDCCH for several seconds, and then the network sent CC
DISCONNECT message with cause 34.  This cause value means "No circuit/channel
available" - so it looks like TMO's unloved GSM network does not support
TCH/F14.4.

Experiment 6
============

As I was writing up notes regarding what seemed like non-working state of NT
mode while all Transparent modes up to 9600 bps work great, I decided to test
with an older version of FC firmware, namely Magnetite l1reconst.  In the
earlier years of FreeCalypso, I would frequently make CSD calls just for fun,
calling NIST ACTS, and it would always work - and being ignorant of T vs NT
and other mode settings, I never set AT+CBST and just dialed ATDnumber.  Since
we now know that TI's firmware default is AT+CBST=7,0,1 and has always been
this way, we know that I was unknowingly exercising NT mode in those happy
years - hence I decided to try an older fw version from those years just to see
if it would have working NT mode.  Tested - it worked!

But then things got more interesting.  I tested with Magnetite hybrid instead
of l1reconst - using the new source-enabled version of G23M PS.  Result: it
seemed a little flaky, but it worked.  Then I went back to current Tourmaline
fw, the same with which I started in Experiment 1.  Did a call with
AT+CBST=7,0,0 serving as a control - it worked.  Tried AT+CBST=7,0,1 - got a
NO CARRIER response; subsequent log analysis shows that the MS initiated CC
DISCONNECT just like in Experiment 1.  Then I made another attempt, still with
AT+CBST=7,0,1 - and this time it worked beautifully: I got CONNECT followed by
the full 40 s of ACTS output.

Thus we now know that NT mode working or not is not a question of firmware
version, but some kind of law of chance: time of day, space weather, phase of
the moon...

NT mode: need for further debugging
===================================

The flaky nature of NT mode calls for further debugging: since we see
MS-initiated DISCONNECT on those tries when it fails, we really need to know
exactly what is making the MS unhappy.  But this debugging is made difficult by
the misfeature of TI's DSP: in Experiment 5 I tried capturing TCH DL bits, but
all we get is zero fill once the IDS block is active.  As next steps, we will
need to study the code that interfaces with this IDS block, and see what we can
observe at that interface level.

T vs NT mode: utility vs complexity
===================================

Consider the IWF provided by the network, speaking CSD frame formats toward GSM
RAN and emulating analog modem signals toward 64 kbit/s PSTN, and consider the
work it has to do in T vs NT modes.  It should be evident that NT mode is much
more complex: all of the work implementing V-series modulations is still needed
for both T and NT, but whereas T mode provides a direct path between the
emulated-modem "bit pump" and CSD V.110 frame bits, in NT mode the IWF has to
implement RLP on the GSM side, V.42 on the analog modem side, and make a high-
level data connection between these two engines of reliable transmission based
on acks, retries etc.  Hence the "bug surface", the number of things that can
go wrong, is much greater for IWF in NT mode.

OTOH, utility considerations traditionally called for NT mode.  There are
*some* applications for which non-buffering, fixed-delay Transparent mode is
the right choice: precision time distribution as in NIST ACTS, train engine
communication in GSM-R etc - but such applications are more on the boutique
side.  Instead consider the more typical application of a business user dialing
into his/her mainframe or UNIX minicomputer etc account while on the go: here
you have a user with a text terminal, and a server/service somewhere that prints
text for the user to read and expects text commands.  In this case the user
would certainly appreciate if his/her session is *not* disturbed by dropouts or
garbage insertions from radio errors, from handover events or from line noise
on the PSTN leg - such users would certainly benefit from NT mode.  Outside of
railways or other special environments, considering ordinary public GSM networks
intended for consumers and business users, in the days when CSD was a feature
of real user significance, NT mode was likely the more desired one for reasons
just explained.  Yet it is the one which is much more onerous to implement...

Lack of data-call indication from one T-Mobile MS to another
============================================================

Looking at the specs for GSM CSD, the intent of the original Creators seems
clear: they intended CSD to run between an MS and services on the fixed network,
perhaps going through an IWF.  In contrast, the case of mobile-to-mobile CSD
calls was NOT the canonical configuration - it was probably considered, but only
as a rather contrived and unlikely use case.  But if someone does make a CSD
call addressed to another mobile, how should it work?

In order for a CSD call to be directly through-connected from Alice to Bob,
Osmocom-style, without complex conversions and translations in the middle, two
conditions would have to be met:

1) The connection element setting would have to be Transparent;
2) ISDN/UDI mode would need to be selected, rather than 3.1 kHz modem emulation.

In this case the MO call will be turned into V.110 by the TRAU, no further IWF
would be applied at the MSC, the ISDN call would connect from Alice to Bob, the
destination MSC serving Bob would see that it's a data call, and it would
indicate so to Bob's MS.  So far, so good.  But the moment you add NT mode or
analog modem emulation, the above pass-through model breaks down:

1) If the bearer cap IE on the MO call indicates ITC of 3.1 kHz audio instead
   of UDI, Alice's MSC is supposed to pass the call through an IWF that does
   modem emulation.  Once that modem emulation is applied, the call going out
   on ISDN is in 3.1 kHz audio mode, not digital data!

2) NT mode does not seem to have ever been intended to carry from mobile user
   Alice to mobile user Bob - instead it appears to have been intended to run
   between a single MS and a network IWF only.  The IWF then converts to V.42
   in the case of 3.1 kHz modem emulation, or to V.1xx/X.75/etc protocols in
   the case of ISDN UDI, with or without V.42-like reliability through acks and
   retransmissions.

However, the above considerations stem from the architectural model _assumed_
in ETSI GSM specs - whereas the question of what real-world GSM networks have
actually implemented needs to be asked separately.  In the case of T-Mobile USA,
the behavior of the network upon own-subscriber Alice making a CSD call to own-
subscriber Bob appears to have changed over the years:

* In my earlier years of FreeCalypso work, when I made CSD calls from FC GSM MS
  just for fun while being ignorant of T vs NT modes and other +CBST settings,
  I would call NIST ACTS to get a truly successful session.  But I also
  experimented a little with mobile-to-mobile CSD.  Unfortunately, I never put
  together a proper setup with two FC GSM MS boards powered up and connected to
  my laptop at the same time, fitted with two active T-Mobile SIMs, one calling
  the other - but I did dial CSD a few times from a single "proper" GSM MS
  (probably FCDEV3B, although I don't remember exactly) to my main personal-use
  T-Mobile line whose SIM sat in a Pirelli DP-L10 running its official fw.
  I don't remember if I got this degree of success reliably every time or if it
  was intermittent - but I did get an incoming call indication on the Pirelli
  that said "incoming data" or something to that effect.  I don't remember
  exactly what happened afterward, but my vague recollection (subject to the
  caveats about wetware memory after many years of attention being shifted in
  very different directions) is that the phone would ring with this "incoming
  data" indication on the screen, but once I pressed the Answer button, the
  call attempt would drop - and curiously enough, turn into a "missed call"
  indication.  I don't have good memory of what the call-originating FC GSM MS
  would show: I seem to recall it going directly to NO CARRIER upon me pressing
  Answer on the Pirelli, but I also seem to recall at least once getting a
  CONNECT response, presumably followed by NO CARRIER shortly afterward.

* In terms of memory reliability, the only part I do remember for certain is
  that the call-receiving Pirelli phone (running its official fw) _did_ display
  a "ringing" screen that said something along the lines of "incoming data" -
  IOW, it very clearly indicated the presence of an incoming call that was data
  rather than voice, even though of course this phone has no official Terminal
  Adaptor Function and no ability to meaningfully accept such calls.  This
  indication implies that the MT SETUP message from the network must have
  included a bearer cap IE that indicated non-speech - although unfortunately
  I have no logs (back then I wasn't looking at CC or any other air interface
  messages), thus we don't know if it was a pass-through of BC from the MO leg
  or altered in some way.  The remaining memories of everything else that
  happened after this logically-deduced MT SETUP should be treated as
  unreliable.

* When I tried replicating in the present time (2024-11) the just-described
  result from many years ago, I had no success: see description of Experiment 4
  above.  Now when I dial a CSD call from one of my legacy T-Mobile SIMs to
  another, the receiving MS gets an MT SETUP message that contains no BC IE at
  all, same as with calls coming from outside PSTN, the call rings as voice,
  and gets assigned TCH/AHS like other speech calls.  And because the modem-
  emulating CSD IWF in the MO direction initially emits silence while waiting
  for the answering modem, silence is what the receiving phone hears in this
  errant setup.