You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
…ations on the same traffic channel.
Fixed issue where sdrtrunk was not checking HDU and LDU2 encryption sequences as valid before assessing the encryption state of a call. Updated P25P1 audio module to check the valid flag for both the HDU and the LDU2 encryption segment before assigning encryption state. Now caches all LDU messages until encryption state is determined.
…ations on the same traffic channel.
Fixed issue where sdrtrunk was not checking HDU and LDU2 encryption sequences as valid before assessing the encryption state of a call. Updated P25P1 audio module to check the valid flag for both the HDU and the LDU2 encryption segment before assigning encryption state. Now caches all LDU messages until encryption state is determined.
…ations on the same traffic channel.
Fixed issue where sdrtrunk was not checking HDU and LDU2 encryption sequences as valid before assessing the encryption state of a call. Updated P25P1 audio module to check the valid flag for both the HDU and the LDU2 encryption segment before assigning encryption state. Now caches all LDU messages until encryption state is determined.
…ations on the same traffic channel. (#1995)
Fixed issue where sdrtrunk was not checking HDU and LDU2 encryption sequences as valid before assessing the encryption state of a call. Updated P25P1 audio module to check the valid flag for both the HDU and the LDU2 encryption segment before assigning encryption state. Now caches all LDU messages until encryption state is determined.
Co-authored-by: Dennis Sheirer <[email protected]>
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.
The text was updated successfully, but these errors were encountered: