DVMProject
RF voice rejection from 0 to TG 0
The behavior of TG 0 has changed between 4.11F_maint and 4.30H_maint. TG 0 on 4.30H_maint instantly truncates calls even on apparently strong signals. TG 0 on 4.11F_maint a brief gap (less than a second) is heard in the audio, and the call continues. This behavior can be reproduced on all our RF DVM hosts and locally with a Quantar and a weak signal from a service monitor.
All our hosts are Quantars except one DIU3000, which has not seen this behavior.
R04J32 development branch introduces some code to mitigate this issue. eccb8ba00085b4af963e2e63dc51cd7869c7272f (ModemV24.cpp)
When generating very weak signals with the R-2670, R04J32 produces TG 0, truncates the call and will not recover until the Rx signal drops completely. Unknown if the hair trigger (TG 0 on apparently strong signals) is still a problem.
I hate this entirely, because it is out of spec completely, TGID0 is a blackhole TGID and all of this implementation is technically wrong.
Quantars are now IMHO straight and complete garbage, thanks to Motorola for improperly adhering to the P25 specification, and just doing whatever the fuck they want.
Try 28bd5a8 and enable the new forceAllowTG0 option, this should forcibly allow TG0 to pass rewritten as TG1 (the DVM network stack WILL NOT EVER PASS TG0, so this rewrite is required).
Oh and be aware if BOTH the source and TGID ID's are 0 DVM will STILL DROP THE CALL. There is NO way to process a call with entirely invalid data like this.
if BOTH the source and TGID ID's are 0 DVM will STILL DROP THE CALL
I did not intend to represent that the problem is only TG 0. We always see RF voice rejection from 0 to TG 0.
There is NO way to process a call with entirely invalid data like this.
Yet 4.11F didn't drop the call. Only a syllable or so would drop.
if BOTH the source and TGID ID's are 0 DVM will STILL DROP THE CALL
I did not intend to represent that the problem is only TG 0. We always see
RF voice rejection from 0 to TG 0.
Understood.
There is NO way to process a call with entirely invalid data like this.
Yet 4.11F didn't drop the call. Only a syllable or so would drop.
Then that's a bug in, 4.11F. The appropriate behavior of the check is to drop calls with entirely invalid metadata, source ID and TGID of 0 is entirely garbage. The entire system utilizes source ID/RID 0 and destination ID/TGID 0 specially to mean "none" (because this is what the spec uses for none). If 4.11F is allowing the call to pass that is incorrect and bad behavior in 4.11F.
Additionally, the FNE passing traffic with both source and TGID of 0 is entirely undefined, and frankly, unsupported.
As a note, after a quick review, the code in 4.11F to 4.30H or 4.32J for handling this ACL check to ensure source ID and destination ID's are non-zero hasn't been changed.
So I'm not sure why you see differing behavior.
Please also see R04J32 (4.32J); I added a literal configuration option "forceAllowTG0" to force the system to pass TG0.
@tsawyer I'm still extremely suspect about the entire issue.
Since the only way you get logged call rejects like this is if the call has stopped, the DVM has returned to a idle listening state (i.e. its waiting, looking for a new call, or late entry) and then receives a new call either with or without a HDU, containing questionable bad metadata.