PROTOCOL NOTES / 10
15 · Duplicates, stale media, hop exhaustion and rejected membership
Participants: Sender, Relay, Receiver
Implemented software · Physical qualification pending
Starting state
Actual valid keys/roles exist; duplicate or old packets, altered authentication, exhausted hops or unauthorized identities arrive as ordinary rejection cases.
Ordered events
- Sender → Relay
Datagram or control arrives at scoped peer endpoint
- Relay → Relay
Check role, structure, ride, hop authentication and replay
- Relay → Relay
Check admitted source and SRTP replay/source age
- Relay → Receiver
Only fresh authorized media can enqueue eligible branches
Fields and messages
Hop sequence, age, hops, source SSRC/index, signature source/seq; public versions and bounded lengths.
Authorization and invariants
Reject before source replay when role/hop proof fails; source authentication must succeed before forward. Admitted members share source symmetric keys and can impersonate media; no Byzantine guarantee.
Timers
Age 180 ms; egress 40 ms; source/hop replay windows; bounded control dedup.
Resource lifetime
Rejecting one packet cannot reset keys, replay, source clock or unrelated streams.
What the rider sees
Only bounded sanitized counters/events; no private packet/key logging.
Failure branches
Ordinary targeted authentication/replay tests are allowed; malformed-packet fuzzing, extended malformed campaigns, sanitizers and invasive memory stress remain excluded.
Resulting state
Rejected input does not deliver/flood speech or gain membership; valid subsequent traffic remains usable.
Evidence boundary
Existing valid-packet alteration, replay, age and membership functional tests; no excluded fuzz execution.
Authority: RWCP v2 reviewed scenario catalogue, scenario 15. Public examples are synthetic. This guide is maintained against the private implementation; it does not imply access to its source.