FreeDMR/docs/unit-data-hold.md

Unit-Data Slot Hold

Unit-data slot protection is enabled by default for every MODE: MASTER section. It can also be set explicitly in the FreeDMR configuration:

UNIT_DATA_HOLD: True

Existing configurations that omit this setting enable the hold on upgrade. Set UNIT_DATA_HOLD: False to restore the previous admission behaviour. The setting applies independently to both slots of that master, not to the whole server or mesh. In a worker deployment, configure the receiving HBP worker's master section.

Existing voice activity and voice hangtime checks still determine whether unit data may start. An admitted outbound unit-data burst, including a preamble, holds its destination slot for its ordered source/destination DMR-ID pair for five seconds. Each further admitted burst for that pair refreshes the hold. Stream IDs do not identify ownership, and packet contents are not reassembled or changed by the hold. This applies to unit data generally, including SMS, not exclusively to IP service 5005.

During the hold, competing network voice, generated prompts/beacons and unit data for other pairs are suppressed on that slot. An already-active generated prompt prevents a new data hold. Suppressed prompts are cancelled, not queued for replay. After five seconds without admitted data, normal admission resumes without waiting for a background cleanup task. Continuous data can retain the slot indefinitely; there is no fairness or packet-count limit in this version.

This is server-side outbound protection, not an RF reservation or a bidirectional session lock. It does not stop an RF station transmitting, measure modem buffering, queue busy-dropped packets, add retries, or contain IP traffic to the local server. The hold expires from the last network submission, not measured RF completion. Disable it where these trade-offs are inappropriate for the particular access master.

Gateway Request To Send

The enabled, authenticated DATA-GATEWAY FBP5 relationship can request a provisional hold using BCRQ; BCTS replies with granted, busy, no local route or denied. Ordinary mesh relationships cannot request holds. The new controls use a 16-byte keyed BLAKE2b tag; existing FBCP controls are unchanged.

The worker resolves the local destination through its subscriber map or an unambiguous connected-hotspot match. A grant reserves that slot for 500ms for the requesting relationship and ordered source/destination pair. The first matching admitted burst promotes it to the five-second hold above. With no packet, it expires automatically. Existing voice/hangtime and prompt checks still apply, and UNIT_DATA_HOLD: False denies requests for that master.

Duplicate request IDs return the original result and remaining window, not a renewed hold. Changed addresses under the same ID are denied. New request IDs also cannot prolong an unused hold. The cache holds at most 256 requests for 30 seconds per Gateway relationship. It is a bounded duplicate cache, not cryptographic replay protection across that window or a process restart.

The sender must correlate the reply, allow for round-trip latency, and start within its remaining budget. A grant is not an RF lock or delivery receipt: new RF activity or a changed route can still prevent admission. There is no cancel, packet-count fairness, new DMR field or mesh-wide reservation. Ordinary unreserved SMS/data remains supported. The experimental Gateway IP sender uses the new exchange. Gateway SMS can opt in with FREEDMR_GATEWAY_SMS_ADMISSION=true; its default remains off for compatibility with older workers. Opt-in clients must understand the Gateway API's queued state before transport submission.