You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
FreeDMR/docs/unit-data-hold.md

66 lines
3.6 KiB

# 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:
```ini
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.

Powered by TurnKey Linux.