comparison doc/Calypso-TCH-downlink @ 475:e512f0d25409

doc/Calypso-TCH-downlink: document gsm[e]fr-dlcap-sync
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 18 May 2024 00:13:26 +0000
parents 03b0702f4463
children 5e2d849a4fbc
comparison
equal deleted inserted replaced
474:285381a001fc 475:e512f0d25409
115 including fc-vm2hex output in the case of VM recordings made in DTX mode. 115 including fc-vm2hex output in the case of VM recordings made in DTX mode.
116 However, if the objective is to play that VM recording and not just look at 116 However, if the objective is to play that VM recording and not just look at
117 parsed bits, the correct approach is to convert the VM file to gsmx with 117 parsed bits, the correct approach is to convert the VM file to gsmx with
118 fc-vm2gsmx, and then decode with gsmfr-decode. Using fc-vm2hex followed by 118 fc-vm2gsmx, and then decode with gsmfr-decode. Using fc-vm2hex followed by
119 gsmfr-dlcap-gsmx instead of fc-vm2gsmx won't work! 119 gsmfr-dlcap-gsmx instead of fc-vm2gsmx won't work!
120
121 Catching the output of the network-side speech encoder
122 ======================================================
123
124 The set of FR1 test sequences included with later versions of GSM 06.10 specs
125 and the set of EFR test sequences in GSM 06.54 include special synchronization
126 sequences that can be fed to the G.711 PCMA or PCMU input of the TRAU in the
127 downlink direction, and the set of 160 possible speech encoder outputs for each
128 codec that can result from the TRAU processing that DL input, depending on the
129 alignment between the input and the location of 20 ms frame boundaries for the
130 encoder. In the case of EFR, there is a second dimension of uncertainty when
131 experimenting with GSM networks that aren't your own: in addition to the unknown
132 alignment of G.711 input (160 possibilities), there is the unknown of whether
133 the network transcoder implements classic EFR or an AMR-EFR hybrid - see our
134 AMR-EFR-philosophy and AMR-EFR-hybrid-emu articles. However, thanks to the work
135 we did in vband-misc Hg repository, we now have a fully backward-compatible
136 extended version of ETSI's seqsync[au].inp TRAU DL inputs (the last frame of
137 160 samples that isn't EHF is simply repeated twice) that allows us to
138 distinguish between two possible styles of EFR implementation in the network
139 transcoder, producing 320 possible outputs on GSM Um DL for 160 possible
140 alignments times two possible EFR implementation options.
141
142 However, tools are still needed on the GSM MS side of the test setup, reading
143 the TCH DL capture produced with FreeCalypso tools and detecting which of the
144 possible 160 (FR1) or 320 (EFR) encoded frames have been produced. (320 or
145 even 160 possible frames is too many to check by hand!) These tools are
146 provided in gsmfr-dlcap-sync and gsmefr-dlcap-sync, added to Themyscira GSM
147 codec libraries and utilities suite as of gsm-codec-lib-r3. Each of these
148 utilities takes two command line arguments: the name of TCH DL capture file to
149 read and analyze, and an "alaw" or "ulaw" keyword argument selecting the match
150 table to use. Specify alaw if you are feeding seqsynca.inp to a PCMA-native
151 TRAU or other GSM network speech transcoder, or ulaw if you are feeding
152 seqsyncu.inp to a PCMU-native network. The program will read the entire TCH DL
153 capture, looking for matches, and will report any matches it finds.
154
155 Both gsmfr-dlcap-sync and gsmefr-dlcap-sync implement the logic of looking for
156 the respective codec's DHF followed by one of 160 (FR1) or 320 (EFR) distinct
157 encoded frames. In the case of EFR, if the network transcoder implements
158 AMR-EFR and the alignment shift happens to be in the [120,159] range, there
159 will also be an MR122 DHF sandwiched between the standard EFR DHF and the
160 distinct encoded frame (unique for each of the 40 possible alignments in this
161 range) if the AMR-EFR hybrid is implemented like our amr_dhf_subst_efr2()
162 function, matching the network of T-Mobile USA. gsmefr-dlcap-sync looks for
163 both EFR and MR122 DHF; in the case of matches to AMR-EFR offset [120,159], the
164 tool's indication whether the unique frame was preceded by EFR or MR122 DHF
165 indicates how the alien network transcoder implements its DHF transformation;
166 in the case of other matches, seeing MR122 DHF is an unexpected error condition,
167 and it is reported as such.
168
169 These tools cover just one step in the workflow of reverse-engineering an alien
170 GSM network's speech transcoder and confirming if it matches standard EFR or
171 the AMR-EFR hybrid as currently found in the wild. The complete workflow in
172 the GSM downlink direction will typically be as follows:
173
174 1) Using sipout-test-voice utility from the sipout-test-utils suite, establish
175 a test call from IP-PSTN to a test MS served by the GSM network under study.
176 AT%SPVER will typically need to be used to cause the network to assign the
177 desired codec on this call.
178
179 2) While making a TCH DL recording on the FreeCalypso MS used in this test,
180 play seqsync[au].inp (or the extended version with the last frame sent twice)
181 into the G.711 PCM stream from IP-PSTN side, using 'play' command of
182 sipout-test-voice.
183
184 3) Run gsmfr-dlcap-sync or gsmefr-dlcap-sync on the DL recording from the
185 previous step, as appropriate.
186
187 4) Once the alignment is known, use 'play-offset' command in sipout-test-voice
188 to play a longer test sequence into the same call, and have another TCH DL
189 recording running on the test MS.
190
191 5) If the longer test sequence begins with the same seqsync[au].inp preamble
192 (which is recommended), playing it with the correct offset from IP-PSTN side
193 should result in gsm[e]fr-dlcap-sync reporting zero offset on the new DL
194 recording. However, gsm[e]fr-dlcap-sync on this second DL capture should
195 indicate the line number where the interesting part begins.
196
197 6) Extract the part of interest identified in the previous step, convert it to
198 gsmx format with gsm[e]fr-dlcap-gsmx, and compare it against the expected
199 encoded frame sequence.