Bug #3238
closedipacc style dyn TS become unusable after first voice call
100%
Description
TCH/F_PDCH timeslots work fine for data, and then work fine for the first voice call.
But after that, neither data nor another voice call will go through.
Reproduce: one sysmoBTS and a TS config of
timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F_PDCH timeslot 3 phys_chan_config TCH/F_PDCH timeslot 4 phys_chan_config SDCCH8 timeslot 5 phys_chan_config SDCCH8 timeslot 6 phys_chan_config SDCCH8 timeslot 7 phys_chan_config SDCCH8
At first, both TS are used as PDCH. When placing a voice call, this switches both to TCH/F and works fine.
After the call, the RSL signalling and PCU log look as though switching back to PDCH was perfectly fine as well.
But no data will go through anymore. Switching GPRS off and on on a phone will also then cease to show a GPRS icon.
Also placing another voice call looks like switching the TS back to TCH/F works fine, but the call will abort early.
In contrast, Osmocom style dynamic timeslots (TCH/F_TCH/H_PDCH) switch back and forth fine any number of times.
That doesn't really make sense, since the only difference is the RSL messaging used to switch to/from PDCH.
(Osmocom style tested with a TS config like above, but only a single TCH/F_TCH/H_PDCH yielding two TCH/H, instead of the two TCH/F_PDCH ts;
so I guess another difference is that two timeslots are switched in close succession, which I believe not to be the cause.)
In attached pcap, two phones attach, one phone browses osmocom.org, then the first voice call is started at packet 10548.
After the voice call, one phone detaches and re-attaches and fails to re-establish GPRS, from packet 14798.
The second voice call is initiated from packet 16660, which fails to be established; followed by another failing call attempt.
Files