I've recently setup a receiver that can receive a local P25 network from two separate sites. The talk groups available from each site are identical from what I have observed. So the main benefit of configuring both is redundancy.
In this case it's not clear to me what the best way to go about configuring this is. I'm uploading to the openMHz platform, but there seems to be inflexibility in how to configure aggregation of two local sites.
I can give them the same name, and enable multi-site and the same api token, which -seems- to remove duplicates and behaves as desired externally, but, when looking at the logging, locally, it becomes difficult to determine which of the two sites is actually being referred to:
[2023-06-21 10:46:19.221240] (info) [rmrvic] Decoding System ID 164 WACN: BEE00 NAC: 167
[2023-06-21 10:46:20.078012] (info) [rmrvic] Decoding System ID 164 WACN: BEE00 NAC: 165
[2023-06-21 10:52:59.022983] (info) [rmrvic] 29 msg/sec
[2023-06-21 10:52:59.022992] (info) [rmrvic] 26 msg/sec
Alternatively, if the systems are given them different short names, the options appear to be to upload ether duplicate conversations (if multisite is off), or, with multisite, two systems containing the calls split between them depending on which system the call is first seen on.
Are there any thoughts on how best to configure this? As a simple workaround, would it make sense to have an identifier used internally, and another that is advertised to streaming services?
More broadly, If I were designing/coding this, I'd be considering a hierarchical configuration model of a trunked system, with each system containing one or more child sites, define priority/aggregation/de-duplication/whitelist/blacklist rules for sites in that system, then configure uploads at a system level, after those rules have been applied to incoming calls.
In your talk groups file, have you specified a preferred NAC for talk groups? That's supposed to tell trunk-recorder which site a talk group should be recorded from.
I've recently setup a receiver that can receive a local P25 network from two separate sites. The talk groups available from each site are identical from what I have observed. So the main benefit of configuring both is redundancy.
In this case it's not clear to me what the best way to go about configuring this is. I'm uploading to the openMHz platform, but there seems to be inflexibility in how to configure aggregation of two local sites.
I can give them the same name, and enable multi-site and the same api token, which -seems- to remove duplicates and behaves as desired externally, but, when looking at the logging, locally, it becomes difficult to determine which of the two sites is actually being referred to:
Alternatively, if the systems are given them different short names, the options appear to be to upload ether duplicate conversations (if multisite is off), or, with multisite, two systems containing the calls split between them depending on which system the call is first seen on.
Are there any thoughts on how best to configure this? As a simple workaround, would it make sense to have an identifier used internally, and another that is advertised to streaming services?
More broadly, If I were designing/coding this, I'd be considering a hierarchical configuration model of a trunked system, with each system containing one or more child sites, define priority/aggregation/de-duplication/whitelist/blacklist rules for sites in that system, then configure uploads at a system level, after those rules have been applied to incoming calls.