P25: Add SVC OPT decoding on Applicable Voice Grants; Allow User to Toggle Following Encrypted Calls;

[lwvmobile]

For P25 systems, many (but sadly not all) channel grants have service options much like the usual link control information, and I am adding the extra decoding for these grants and going to include a toggle for users to select if they want to follow or not follow any encrypted p25 channel grants (most would probably not want to by default, but the toggle will be turned on by default for reasons below)

The only issue with this, is that some abbreviated/implicit/mfid90 grants do not have available service options, so the option is to either not allow trunking on those particular ones when the toggle is turned off, or allow it and also allow some encrypted calls to be trunked. Currently, I am unsure if this may or may not affect tuning to channel grants that aren't enc just by excluding them when attempting to not tune to encrypted channel grants. I've seen some systems use multiple forms of channel grants (initial and updates) so its possible that it may still tune fine, or that it may not tune clear voice channel grants when toggled. it really just depends on the system setup and manufacturer.

Anyways, its just going to be an option to the user (sadly, I don't see any other format) that has the service options (or similar) available in the call grants, so we can't preemptively filter those out. Users will need to use a group.csv file with blocking if they wish to filter those groups out from tuning.

[lwvmobile]

Well, This may be more of a challenge, or fool's errand, than I originally though. I just went to test my code, and found the first system I tested it on has two sets of svc options, like they just randomly change between 0x46 and 0x06, and that's the only part of the PDU that is different. Same opcode, same standard MFID 0, different svc bits, but still encrypted. The SVC bits must just be more of a 'suggestion' on the channel grant or its not programmed correctly on this system?

09:40:30 Sync: +P25p1  nac: [ 233] src: [       0] tg: [    0]  TSBK MFID = 0
 Encrypted Circuit Priority 6 Group Voice Channel Grant Update
  SVC [46] CHAN [0090] Group [3031] Source [xxxxxx]
  Frequency [xxxxxxxx] MHz
 P25 PDU Payload
  [07][40][46][00][90][0B][D7][7C][83][66][00][00]
  [00][00][00][00][00][00][00][00][00][00][00][00] 

09:40:30 Sync: +P25p1  nac: [ 233] src: [       0] tg: [    0]  TSBK MFID = 0
 Circuit Priority 6 Group Voice Channel Grant Update
  SVC [06] CHAN [0090] Group [3031] Source [xxxxxxx]
  Frequency [xxxxxxxx] MHz
 P25 PDU Payload
  [07][40][06][00][90][0B][D7][7C][83][66][00][00]
  [00][00][00][00][00][00][00][00][00][00][00][00] 

[lwvmobile]

After doing some more testing on a few other P25 systems, the code seems to do better on those than the aforementioned system with the alternating SVC options. One cavaet to using this toggle though, is that initial voice grants could be missed when tuning back and forward, and the 'grant update' may not carry the svc opt, and with the toggle on, we don't tune anything we can't verify via svc opts, so calls could be missed in this manner. So, its coded, it works, but calls can be missed, or calls may still fail to be excluded if the svc opts aren't set correctly, or behave in the manner shown in the previous post.

If users are still tuning randomly to enc groups, or missing clear calls, then using a group import with blocked groups is still a better, more full proof way to prevent tuning.

I will close as completed now.