Description
sdrtrunk Version
master - nightly.
Describe the bug
On p25 phase 1 traffic channels when there is a primary call followed by one or more subsequent call responses on the same traffic channel (ie no channel teardown between conversants) sdrtrunk is sometimes failing to capture the subsequent call audio.
This was specifically noticed on a Harris VHF system.
On investigation, it appears that the Harris system may be tearing down the traffic channel between transmissions and partiallay transmitting what sdrtrunk is interpreting as a malformed Header Data Unit (HDU) which should indicate the start of the next call sequence. However, sdrtrunk was processing that HDU and not checking the CRC valid flag and the HDU indicated the next call sequence is encrypted. This causes the audio module to ignore all of the (assumed to be encrypted) voice message frames.
Note: sdrtrunk holds the traffic channel for up to one second waiting for subsequent audio calls to occur which was long enough to capture the subsequent audio sequences, but unfortunately they were erroneously flagged as encrypted.