Encryption Modification in DB

[Nasby]

Any chance for perhaps a new Mode classifiaction for encrpypted T/G's?

In my area, there are numerous T/G's that are classified as Digital Encryption (DE in the DB).

Many software programs will ignore them on download if the user chooses.

However, many of the T/G's in my area use only partial encryption where dispatch is in the clear and only the cars / portables are encrypted.

Many users would probably like to hear even parts of the traffic rather than nothing at all.

A notation of partial encryption would show that some monitoring is possible as opposed to full encryption where nothing can be heard.

[KevinC]

It looks like it's already there...

[mciupa]

Originally Posted by Nasby

Any chance for perhaps a new Mode classifiaction for encrpypted T/G's?

In my area, there are numerous T/G's that are classified as Digital Encryption (DE in the DB).

Many software programs will ignore them on download if the user chooses.

However, many of the T/G's in my area use only partial encryption where dispatch is in the clear and only the cars / portables are encrypted.

Many users would probably like to hear even parts of the traffic rather than nothing at all.

A notation of partial encryption would show that some monitoring is possible as opposed to full encryption where nothing can be heard.

We do have that capability as Database Administrators, see this list:

Conventional frequencies:
FMN - FM Narrow
FMNe - FM Narrow with periodic encryption
FMNE - FM Narrow with full time encryption
P25 - P25 Digital
P25e - P25 Digital with periodic encryption
P25E - P25 Digital with full time encryption
etc etc. . .

Trunked Talkgroups
A - Analog
Ae - Analog with periodic encryption
AE - Analog with full time encryption
D - Digital
De - Digital with periodic encryption
DE - Digital with full time encryption
T - TDMA Digital
Te - TDMA Digital with periodic encryption
TE - TDMA Digital with full time encryption

Anything with a lower case "e" is what you are looking for. Advise your local DB Admin which talkgroups or conventional frequencies need updating.

Thanks for bringing this up!

[Nasby]

Thanks very much. I had never seen this notation before.

[rivardj]

This Mode scheme change has broken the Win500 program. The "Ignore Encrypted Talkgroups" function no longer works. I am guessing that Win500 only looks for one character in the "Mode" field and now only finds a letter "D" so it looks to Win500 like there are no encrypted groups. Can the data in the MPSCS database in the "Mode" field be put back to the way it was, either a just a "D" or and "E" please?

I think identifying the level of encryption is a great idea but I don't think it justifies breaking functionality in the scanner programming software. Can the periodic encryption status be added to the "Description" column instead of putting it in the "Mode" column?

I am referring to the MPSCS database, but I think every database would have this issue.

[mciupa]

Originally Posted by rivardj

This Mode scheme change has broken the Win500 program. The "Ignore Encrypted Talkgroups" function no longer works. I am guessing that Win500 only looks for one character in the "Mode" field and now only finds a letter "D" so it looks to Win500 like there are no encrypted groups. Can the data in the MPSCS database in the "Mode" field be put back to the way it was, either a just a "D" or and "E" please?

I think identifying the level of encryption is a great idea but I don't think it justifies breaking functionality in the scanner programming software. Can the periodic encryption status be added to the "Description" column instead of putting it in the "Mode" column?

I am referring to the MPSCS database, but I think every database would have this issue.

This would be a great opportunity for you to point out the shortcomings of the software to the software's author.

In the meantime, could you edit the problem talkgroups yourself?

[jemassey]

Originally Posted by rivardj

This Mode scheme change has broken the Win500 program. The "Ignore Encrypted Talkgroups" function no longer works. I am guessing that Win500 only looks for one character in the "Mode" field and now only finds a letter "D" so it looks to Win500 like there are no encrypted groups. Can the data in the MPSCS database in the "Mode" field be put back to the way it was, either a just a "D" or and "E" please?

I think identifying the level of encryption is a great idea but I don't think it justifies breaking functionality in the scanner programming software. Can the periodic encryption status be added to the "Description" column instead of putting it in the "Mode" column?

I am referring to the MPSCS database, but I think every database would have this issue.

You are correct. I checked by specifying an API version 14 and querying the SOAP web service for an encrypted talkgroup. The Mode field was "D" instead of "E" as expected for version 14 of the API.

To maintain backwards compatibility, the API should should return "E" for encrypted talkgroups if the API level specified by the client is 14 or less.

Originally Posted by mciupa

This would be a great opportunity for you to point out the shortcomings of the software to the software's author.

In the meantime, could you edit the problem talkgroups yourself?

This is not a problem with the software, but an issue of backwards compatibility with the web service.

[rivardj]

The Win500 software worked fine until this change was made.

Editing the problem talkgroups myself defeats the benefits of the automated features of the software.

The Win500 software has not had an update since 2015. I don't know that the authors will want to fix something they did not break. Also, I don't think the changes would be made for free and I don't want to pay for this change.

jemassey - Thank you for looking into this issue. Just to be sure I understand the issue, this is a website interface problem?

I hope this gets fixed soon, I just renewed my premium membership.

[jemassey]

Originally Posted by rivardj

Just to be sure I understand the issue, this is a website interface problem?

It's a problem with the SOAP web service (which is how programs retrieve system information) not maintaining backwards compatibility. The fix should be easy for full time encrypted talkgroups, return mode of "E". I would suggest that the web service return a mode of "D" instead of "E" for part time encrypted talkgroups.

See API - The RadioReference Wiki for a description of the web service.

[rivardj]

jemassey,

I agree with your recommendation.

Also, thanks for the link to the API Wiki.

I am not Java or XML literate, but I might learn a little something looking through the Wiki.

[blantonl]

Unfortunately, we did a fundamental architecture change on how we track encryption across the board, which made maintaining backwards compatibility in the Web service very difficult (i.e. we'd have to make some hard choices on what we actually return for backwards compatibility)

I made the decision to force us forward, including working with the major scanner vendors on the coordination.

There is now a separate attribute in version 15 which represents encryption usage

Added "enc" attribute to frequencies and trunked system talkgroups.  
The "enc" attribute represents the use of encryption on the frequency or talkgroup.  

Possible values are:
0 = no encryption
1 = mixed encryption
2 = fully encrypted

[rivardj]

Lindsay,

Thank you for responding to my inquiry.