Add 'sysId' support for multiple p25 systems for TG de-duping

[bctrainers]

Did some quick checks with the code, and could not find any support for TG de-duplication, just system ID matching from the sysId variable from config.json.

With that being said, I would like to see the SysId variable also be used in conjunction with same-talkgroup de-duping.

For example, let's say we have a P25 system... let's call it "TwoStateICS" or TSICS for short. TSICS has two unique simulcast sites, let's call them SimOne (sysid: a1a) and SimTwo (sysid: a1a). Now, we have configured TrunkRecorder to monitor both systems/sites, SimOne and SimTwo on the TSICS system. However, both systems are activating for the same talk group, lets say TG 1234. TG 1234 is a regional TG, so when it activates on SimOne system, it activates on SimTwo as well - along vice-versa. (Currently with TR, it will record both talkgroups upon activation - unless manually configured in the CSV and config files). When the transmission concludes, the additional recordings would be discarded and the original TG's recording would persist.

With that example in mind, we would then have to account for the following:

1) Which site has the stronger decode rate? (Weak decode means popping/garbling of audio) 2) Which site configured should be discarded or skipped on the recorder when a TG event concludes? 3) Should a secondary variable be added to the system configurations called "priority"? Such as 1 being highest and 100 being lowest, similar to the talkgroups file style. 4) If the TGs activate at the same time on both system sites, should time-delay due to radio time propagation be used to discard the additional same-TG activations?

[kcwebby]

I think ideally, some metadata about signal strength should be added into the json, so this can be handled on the remote end (whatever is receiving the audio). Take for example when you have multiple towers that are not on the same PC, that would make this code enhancement NF, since it cannot compare with another instance of TR even if on the same box.

I would downvote this enhancement, keep TR lightweight and just add some metrics to the json so downstream can make the decision, and CPU on the recorder can avoid that. Just my 0.02

[blantonl]

I'm in agreement with kcwebby here. There already are some metrics in the metadata json that could be used to adjust a call provider priority based on average signal quality at an infrastructure level. There are other components that have to be taken into account as well, including system upload time skew (bandwidth variance etc)

On Broadcastify Calls - we're handling all this on the back end infrastructure (call de-duplication). I think that is the logical place to handle these scenarios.

[kcwebby]

I think it would be great to add signal strength metrics and any transmission decode error rates to the json, that would certainly help any downstream processing down. Not sure if that's something that could be added to output though?

analogStrength: XXdb digitalStrength: XX decoderErrors:

etc.

On Sat, Jun 6, 2020 at 5:24 PM Lindsay C Blanton III < notifications@github.com> wrote:

I'm in agreement with kcwebby here. There already are some metrics in the metadata json that could be used to adjust a call provider priority based on average signal quality at an infrastructure level. There are other components that have to be taken into account as well, including system upload time skew (bandwidth variance etc)

On Broadcastify Calls - we're handling all this on the back end infrastructure (call de-duplication). I think that is the logical place to handle these scenarios.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/362#issuecomment-640125857, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSNSARCCWW6WP2BLJAACD3RVK62TANCNFSM4NMLAESA .