-
-
Notifications
You must be signed in to change notification settings - Fork 195
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
Allow talkgroups to match a range of values #852
base: master
Are you sure you want to change the base?
Conversation
Let me go dig into this more... it seems like Phase 2 should be flagging encrypted message in the control stream. Maybe I am not processing something correctly. It seems like a huge pain to have to flag all the encrypted talkgroups manually. |
Could you try setting the
|
The calls are from grants on patched groups. Phase 2 traffic is not being flagged as encrypted in trunking messages for (what seems like) all of the P2 calls I receive, but I've not exhaustively checked how they're being setup. Relevant log messages:
|
I tried adding parsing of voice service options for
These calls are now correctly flagged as encrypted.
Somewhat confusing, I appreciate, given its a manufacturer specific variant of an Whether the call is phase 1 or 2 doesn't seem to be the issue here. I've seen calls exhibiting the issue using either. I do also receive |
And as expected Perhaps it would make sense for the recorder to abort with an error when encrypted data is received rather than attempt to decode it and return an empty/gibberish audio file? |
I like that idea of just having a recorder Stop when it receives encrypted - the call would have to stick around and change from being in Record mode to Monitor mode, otherwise it would just start back up again when the next UPDATE message comes through. One other thought - how about setting the recordUknown key to false in the system section of the config file? That way only the defined talkgroups will be recorded. The only downside is that you would miss any new talkgroups that pop up.
Ultimately adding support for ranges might be the best option... I am just trying to keep the code base simple as possible and seeing if it is possible to address the root problem. |
Could you add a PR for handling MOTOROLA_OSP_PATCH_GROUP_CHANNEL_GRANT? Nice detective work! |
#869 for It's straightforward to check whether encryption can/does succeed or not by checking the return state of |
This change allows talkgroups in
talkgroups.csv
to be defined as a range<min>:<max>
(inclusive) as well as by a single value.This is useful as a P25 phase 2 system that I receive has 'many' active talkgroups numbered 100-4000, all encrypted, for which I have no further details. Adding each one manually when it is discovered (phase 2 encrypted calls aren't flagged as such in trunking messages) is frustrating, and adding 4000 or so talkgroups, all with a name of 'unknown' and a priority of -1 seems rather inelegant.
This change seeks to remedy this. I had considered adding wildcard/regex matching, but this seems like the simplest solution.