Kerchunking Protection / Voice Activity Detection about svxlink HOT 9 OPEN

Thank you, @sm0svx, for your perspective on the challenges of implementing countermeasures against misuse.

I understand your concerns about potential adaptability by those intent on misusing the system. However, I believe integrating VAD could offer benefits in improving system efficiency and the user experience for legitimate operators, aside from just attempting to deter misuse.

Given the complexity of system management and misuse prevention, I propose a trial implementation of VAD to assess its practical benefits and challenges. This could help us gather data on its impact and refine our approach based on real-world usage — additionally, leveraging RoLink network, which boasts over 100 active nodes, presents a fantastic opportunity for real-world testing of this approach.

I have started experimenting with libfvad - which I managed to implement in the project, but I am encountering issues where it does not recognize voice effectively within the audio processing pipeline. Specifically, I’ve been trying to integrate it in Reflector.cpp and ReflectorClient.cpp, but with limited success (it does detect voice every time).

Any advice or insights into my current implementation challenges would also be greatly appreciated.

Thank you for considering this approach. I’m looking forward to your suggestions and any further guidance you could provide.

73, Silviu

from svxlink.

from svxlink.

Hi Chris,

Thank you for your detailed response and for outlining the measures already in place with [RepeaterLogic] to mitigate unintended transmissions and interference. Your experience with the system in France highlights a critical balance we need to strike between reducing abuse and ensuring the repeater remains user-friendly and accessible.

Your explanation of the SQL_FLAP_SUP_MIN_TIME and SQL_FLAP_SUP_MAX_COUNT settings gives me a good starting point for understanding how SVXLink currently handles short bursts and squelch flapping. It’s clear that while these settings offer some control, the challenge of users activating the repeater without meaningful transmission persists, hence my interest in exploring the integration of voice activity detection (VAD).

The idea behind leveraging libfvad is to add another layer of filtering that specifically targets the issue of ‘kerchunking’ by identifying whether an activated transmission actually contains voice. This could complement the existing configurations by providing a more nuanced approach to handling transmissions, potentially reducing the frequency of announcements about unannounced transmissions and improving the overall user experience.

I appreciate your insights into the potential annoyances of frequent repeater announcements. As I work on integrating libfvad, I’ll be mindful of the balance between effectively managing misuse and maintaining a positive user experience. I’ll also take into consideration your advice on examining the man svxlink.conf sections closely as I develop this feature.

Thank you again for your guidance. I’m hopeful that by combining our efforts and insights, we can enhance SVXLink’s functionality and make it even more robust against unintentional activations while keeping it welcoming for all users.

73,
Silviu

from svxlink.

I wanted to share my thoughts on Silviu's suggestion regarding identifying voice transmission rather than an unmodulated carrier. To put it simply, it's like having a DTMF decoder but for real speech, which sounds pretty intriguing.

The existing methods to prevent misuse by ham operators seem rather rudimentary, relying mainly on timers. While they do the job to some extent, they aren't foolproof against someone with malicious intent who can bypass them easily.

I'm fully in favor of this feature request as it opens up numerous development opportunities and possibilities for new integrations.

Razvan / YO6NAM

from svxlink.

The current "flapping squelch suppression" is not targeted at suppressing misuse but rather at QRM suppression. Implementing features to stop misuse is almost always a waste of time because the people that is misusing the system on purpose will find a way around the countermeasures. They probably will see it as a challenge to overcome.

In the case of adding VAD, you will probably instead get people transmitting nonsense speech instead of just a carrier. So then the problem has actually gotten worse.

from svxlink.

In the case of adding VAD, you will probably instead get people transmitting nonsense speech instead of just a carrier. So then the problem has actually gotten worse.

In a large network environment, kerchunking often becomes nearly unavoidable without implementing certain variable customizations such as delays. However, as the network expands significantly, administrators face challenges in controlling each node or repeater individually.

Enhancing the capabilities of the reflector could greatly enhance the overall reception experience across the network. For instance, when someone verifies the status of a repeater for connectivity, it triggers the activation of all other nodes. With this occurring frequently, say 10 times per hour, it can become increasingly burdensome and may lead to the desire to deactivate the radio altogether.

Therefore, why not explore the potential of integrating the VAD library into our system? Merely assuming the actions of others won't propel the svxlink project forward.

from svxlink.