FreeCalypso > hg > gsm-codec-lib
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. |