Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P25P1 Missing Subsequent/Followup Call Audio On Same Traffic Channel #1994

Closed
DSheirer opened this issue Sep 29, 2024 · 0 comments · Fixed by #1995
Closed

P25P1 Missing Subsequent/Followup Call Audio On Same Traffic Channel #1994

DSheirer opened this issue Sep 29, 2024 · 0 comments · Fixed by #1995
Assignees
Labels
Milestone

Comments

@DSheirer
Copy link
Owner

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.

@DSheirer DSheirer added the bug label Sep 29, 2024
@DSheirer DSheirer added this to the Version 0.6.1 milestone Sep 29, 2024
@DSheirer DSheirer self-assigned this Sep 29, 2024
DSheirer pushed a commit that referenced this issue Sep 29, 2024

Verified

This commit was signed with the committer’s verified signature.
mkllnk Maikel
…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.
DSheirer pushed a commit that referenced this issue Sep 29, 2024
…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.
DSheirer pushed a commit that referenced this issue Sep 29, 2024
…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.
DSheirer added a commit that referenced this issue Sep 29, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant