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. |
