A SIP flood works by exhausting a voice server's call-setup state with a torrent of signalling messages, not by filling the network link with raw volume. It is one of the application-layer classes a thorough DDoS test is built to exercise, aimed squarely at the plane that sets up and tears down calls rather than the audio that flows once a call is live.
How a SIP flood works
SIP, the Session Initiation Protocol, is the signalling that stands up VoIP calls. It rides UDP or TCP on port 5060, or TLS on 5061, and carries the verbs that matter here: INVITE to start a call, REGISTER to bind a phone to an address, OPTIONS to probe a peer.
An INVITE flood is the common shape. Each INVITE forces the target, an IP-PBX, session border controller, or registrar, to open an INVITE server transaction, allocate call state, and usually issue a digest-authentication challenge and wait for the credentialed retry. The dialog then sits open awaiting an acknowledgement, and SIP's own timers hold that state for tens of seconds even when the caller never answers back.
A REGISTER flood aims one layer over, at the registrar and its location store. Every REGISTER triggers an authentication round-trip and a write, so a high rate of them burns CPU on challenge-response and pressure on the store rather than on call legs.
Both are variants of the same underlying problem as any protocol attack: a finite table of per-transaction state fills before the pipe does. Because SIP so often rides UDP, the source addresses are trivial to spoof, so a modest packet rate exhausts the transaction table and worker pool long before bandwidth becomes the constraint.
Why it matters under attack
A voice platform fails in ways a web load test never surfaces, because it runs two planes at once. The signalling plane carries SIP; the media plane carries the actual audio over RTP. A SIP flood hits the first, and the symptoms show up as registration storms, rising post-dial delay, fast-busy on dial, and one-way or dropped audio as session border controllers and media gateways starve. The bandwidth graph stays calm through all of it.
That signalling tier is a single point of failure for an entire carrier, and it has been proven so in public. The autumn 2021 wave of ransom-driven floods took down VoIP providers for days: VoIP.ms was knocked offline in September 2021 and Bandwidth.com days later, both hit at their SIP infrastructure rather than their pipes. When the registrar cannot answer, every downstream phone goes dark at once.
There is a familiar irony in which box fails first. The session border controller is bought to normalise and secure SIP, yet it is the device holding the transaction table an attacker most wants to fill, which makes the control itself the target.
What a DDoS test measures
A test drives the INVITE, REGISTER, and OPTIONS rate upward and watches the things a link monitor cannot see: transaction-table occupancy, call-setup latency, the registration success rate, and the point where media quality gives way to jitter and one-way audio. The number that comes back is a signalling-rate ceiling, not a bandwidth figure.
It then confirms the controls hold at that rate. Does SIP-aware rate limiting on the border controller cap the transaction table below its ceiling? Do per-source registration limits and digest-authentication challenges shed spoofed senders before they claim state? Are malformed and out-of-dialog messages dropped at the edge rather than parsed into the worker pool? What that means for defending an endpoint that cannot simply be rate-limited without dropping real calls is worked through in Layer 7 DDoS Testing.