parrotOnlyToOriginatingPeer broken with CC/VC split sites

[proxiboi69]

Hey,

Found an issue with the parrot feature when using parrotOnlyToOriginatingPeer: true on the FNE with a CC/VC split architecture.

The problem:
When a site has a dedicated CC and separate VC (VC configured as authoritative: false), parrot playback never works. The VC logs this:

W: [NON-AUTHORITATIVE] Ignoring network traffic, destination not permitted, dstId = 9990

What's happening:
In TagP25Data.cpp around line 807, when m_parrotOnlyOriginating is true, the grant demand gets sent directly to pkt.peerId - which is the VC. But since the VC is non-authoritative, it ignores it because there's no active grant from the CC.

The FNE already tracks which VC belongs to which CC via ccPeerId(), but the parrot code doesn't use it.

Suggested fix:
When the originating peer is a VC (has a valid ccPeerId), send the grant demand to the CC instead:

if (m_network->m_parrotOnlyOriginating) {
    uint32_t targetPeerId = pkt.peerId;
    
    // If peer is a VC, route grant demand to its CC
    auto it = m_network->m_peers.find(pkt.peerId);
    if (it != m_network->m_peers.end() && it->second->ccPeerId() != 0) {
        targetPeerId = it->second->ccPeerId();
    }
    
    m_network->writePeer(targetPeerId, targetPeerId, ...);
}

This way the CC gets the grant demand, assigns the channel properly, and radios actually switch to the VC frequency to hear the parrot.

Cheers!

[gatekeep]

Thank you for your submission. This is under review by the team.

While your suggested fix is very likely correct after a review of the code for parrot playback, and will effectively ensure a generated grant demand is sent to the CC, this still leaves a problem for multi-channel sites:

• Trunked sites with multiple voice channels, can potentially run into a condition where the originating voice channel is in use for another call, or a different channel is granted out from the grant demand. This would still have the effect of preventing the call from routing and still result in destination not permitted warnings.

[proxiboi69]

Good point! I hadn't considered multi-VC sites.

So even if the grant demand goes to the CC, if the original VC is busy and a different VC gets granted, that VC would still reject it since it has no active permission for the parrot TG.

Seems like the FNE would need to either:

1. Track the original VC and ensure parrot playback is routed specifically to it (and wait if it's busy?)
2. Or mark parrot traffic in a way that VCs accept it regardless of m_permittedDstId

Definitely more complex than my initial fix. Happy to help test any solution you come up with!