ASVS 5.0 V17.2.5 requires that the media server keeps processing incoming media during a flood of SRTP packets from legitimate users. It is a Level 3 requirement.
The word legitimate matters. These are authenticated participants, so cryptography will not filter them. A buggy client or a hostile participant can send far more than a normal stream.
Why it matters
Media servers do work for every packet: decrypt, forward, maybe transcode. One participant sending at ten times the expected rate can use the CPU that other calls need.
How to implement it
- Set a per stream packet and bitrate ceiling based on the negotiated codec and resolution, and drop what exceeds it.
- Apply a budget per participant and per room so one room cannot take the whole server.
- Pin work to bounded queues and drop the oldest packets rather than growing memory.
- Autoscale or reject new rooms when CPU passes a threshold.
- Alert on per participant rate anomalies and disconnect repeat offenders.
class TokenBucket:
def __init__(self, rate, burst):
self.rate, self.burst, self.tokens, self.t = rate, burst, burst, 0.0
def allow(self, now):
self.tokens = min(self.burst, self.tokens + (now - self.t) * self.rate)
self.t = now
if self.tokens >= 1:
self.tokens -= 1
return True
return False
How to test it
In a staging room, have one participant send at 10 to 20 times the normal packet rate while ten other participants hold a normal call. Measure the others' packet loss, jitter and server CPU. Pass when the other calls stay within your quality target and the flooder is limited or removed.
What a legitimate flood looks like
Legitimate flooding is not always malicious. A video encoder stuck in a bug can emit keyframes in a loop, or a client on a retransmission storm can duplicate packets. The server cannot tell intent, so the controls must be about behavior. Detect sustained rates above the negotiated bitrate, send a signal to the client to reduce, and drop or disconnect if it does not.
Test with realistic packet sizes and timing, since a flood of tiny packets stresses packet rate while a flood of large ones stresses bandwidth. Cover both.
Common mistakes
- Limits per server only, with none per participant.
- Unbounded receive queues.
- Testing flood from a single IP rather than from an authenticated participant.
Quick check
Why does a per participant limit matter here?
The sender is authenticated and legitimate, so only rate limits stop it from consuming shared capacity.
