Feature Request: Call Alert Decoding

[hoosierscanner]

P25 trunked systems use the Call Alert TSBK (opcode 0x1F) as an individual radio paging mechanism. Unlike a conventional voice grant, a Call Alert is a short control channel message directed at a specific radio unit ID — it carries no audio and no voice channel is ever granted. The addressed radio responds by alerting the subscriber via vibrate, audible tone, or in specialized equipment, a relay closure.
This is actively used by fire departments for firehouse alerting. A dispatch console sends a Call Alert targeting a specific unit ID installed at the fire station. That radio's relay output triggers the station alerting system — bay doors, lights, tones — without any voice traffic. Because no channel grant occurs, there is no associated tsbk00 and no audio recording. These are intentionally control-channel-only events.

Current Behavour

trunk-recorder recognizes the 0x1F opcode and logs it, but decodes nothing from the payload:
[debug] tsbk1f: Call Alert
The destination unit ID (the station radio being paged), the source unit ID (the initiating console), and the MFID are all silently discarded. No data reaches the plugin layer — meaning plugins such as tr-plugin-mqtt or trunk-recorder-mqtt-status have no opportunity to act on these events regardless of their configuration.

P25 Standard Reference
Per TIA-102.AABC §7.3.31, the Call Alert TSBK is a fixed-length 96-bit packet:

Opcode 8bit 0x1F
MFID 8bit Manufature ID
Reserved 8bit
Destination UID 24bit
Source UID 24bit
CRC-CCITT 16 bit

The Destination Unit ID is the operationally significant field — it identifies which specific station radio (and therefore which firehouse) is being alerted.

Attached is a debug log excerpt. Unit 4810011 is the dispatch console originating the Call Alerts 4810184 is a known station alerting radio.
The tsbk20 Acknowledge Response traffic confirms these are real events and the radio infrastructure is responding to them — but because tsbk1f emits no decoded fields, there is no reliable way to identify the destination unit from the log or plugin stream:

[debug]   tsbk20   Acknowledge Response    ga 65533        sa 4810184      Reserved: 255
[debug]   tsbk1f: Call Alert
[debug]   tsbk20   Acknowledge Response    ga 65533        sa 4810184      Reserved: 255
[debug]   tsbk1f: Call Alert
[debug]   tsbk20   Acknowledge Response    ga 27160        sa 4810011      Reserved: 106

Requested Changes

Decode the tsbk1f payload in the core P25 decoder — extract and log dst (destination unit ID) and src (source unit ID):

tsbk1f: Call Alert src: 4810011 dst: 4810184

Expose the decoded fields via the plugin callback interface — Call Alert should either get its own callback or be included in the existing trunking message callback with its fields populated, so that downstream plugins can act on the event. The current behavior swallows the packet entirely before it reaches plugin space.
With the fields exposed at the plugin layer, consumers like tr-plugin-mqtt could emit Call Alert events with no further changes to TR core beyond the decoder and callback wiring.

[hoosierscanner]

This comment is AI generated - so take it with caution (the above request was just edited for clarity by AI, and AI researched the P25 Call Alert standard)

Having reviewed the source in p25_parser.cc, the fix is straightforward. The 0x1f handler in decode_tsbk() is currently a stub that logs and does nothing:

cpp} else if (opcode == 0x1f) {
    BOOST_LOG_TRIVIAL(debug) << "tsbk1f: Call Alert";
}

Compare this to the 0x20 (Acknowledge Response) handler immediately below it, which follows the established decode pattern:

cpp} else if (opcode == 0x20) { // Acknowledge response
    unsigned long ga = bitset_shift_mask(tsbk, 40, 0xffff);
    unsigned long op = bitset_shift_mask(tsbk, 48, 0xff);
    unsigned long sa = bitset_shift_mask(tsbk, 16, 0xffffff);

    message.message_type = ACKNOWLEDGE;
    message.talkgroup = ga;
    message.source = sa;

    BOOST_LOG_TRIVIAL(debug) << "tsbk20\tAcknowledge Response\tga " << std::dec << ga << "\tsa " << sa << "\tReserved: " << op;
}

The proposed replacement for the 0x1f block, using the same bit extraction pattern and accounting for the 16-bit CRC shift already applied before decode_tsbk() is called:

cpp} else if (opcode == 0x1f) { // Call Alert (CALL_ALRT)
    unsigned long dst = bitset_shift_mask(tsbk, 40, 0xffffff); // Destination Unit ID (24 bits)
    unsigned long src = bitset_shift_mask(tsbk, 16, 0xffffff); // Source Unit ID (24 bits)

    message.message_type = CALL_ALERT; // new type needed in enum
    message.talkgroup = dst;
    message.source = src;

    BOOST_LOG_TRIVIAL(debug) << "tsbk1f\tCall Alert\tsrc " << std::dec << src << "\tdst " << dst;
}

The bit offsets follow directly from the TIA-102.AABC packet structure — destination unit ID at bits 40–63, source unit ID at bits 16–39, matching the positional pattern already used for sa/ta in the unit-to-unit grant handlers (0x04, 0x06).
The only additional work beyond this block is adding CALL_ALERT to the message_type enum (likely in trunk_message.h or equivalent) and ensuring the plugin callback layer does not silently drop messages of that type. Currently the 0x1f handler never sets message_type, so the message exits decode_tsbk() typed as UNKNOWN and is effectively invisible to any plugin.