Session Initiation Protocol (SIP) Overload Control
Extracted elements (31)
The "oc" parameter value applies to all SIP requests (dialog-forming and in-dialog) destined to the overloaded server, so both client and server share a common view of which messages overload control covers, enabling coherent message prioritization at the client.
The Via header parameter mechanism was chosen over a SIP event package because it is lightweight (no extra messages), automatically reaches all active upstream neighbors without explicit subscription management, and naturally provides hop-by-hop semantics without requiring end-to-end support.
Overload control is negotiated hop-by-hop using Via header parameters; it functions between any pair of adjacent SIP entities that both support it, regardless of whether the rest of the network does. This permits incremental deployment.
When multiple overload control algorithms are listed in "oc-algo", the client MAY order them by decreasing preference, but cannot assume the server will honor the preference order; the server's selection is final and remains until the server changes it.
A SIP client MUST add an "oc" parameter (without a value) and an "oc-algo" parameter (with at least the token "loss") to the topmost Via header it inserts in every SIP request, signaling support for overload control.
A SIP client MUST honor overload control values received from downstream neighbors and MUST NOT forward more requests to a SIP server than permitted by the current "oc" and "oc-algo" parameter values for that server.
A SIP client MUST support the loss-based overload control scheme and MUST insert at least the token "loss" in the "oc-algo" parameter; it MAY additionally list other supported schemes.
A SIP client SHOULD remove "oc", "oc-validity", and "oc-seq" parameters from all but the topmost Via header of a received response, preventing inadvertently or maliciously injected parameters from propagating upstream.
A SIP server that is overloaded and has started throttling MUST reject some requests from non-participating (non-overload-control-supporting) upstream clients with a 503 (Service Unavailable) response without a Retry-After header.
For the loss-based scheme, the "oc" parameter value MUST be in the range [0, 100] inclusive, representing the percentage by which the upstream client is to reduce forwarded requests.
If overload control information is inserted into a 100 Trying response, the server MUST re-insert the same (or updated) overload control parameters in the first non-100 Trying response, because 100 Trying may be consumed at the transaction layer and not reach the TU.
In the event of repeated timeouts or fatal transport errors from a downstream server, the SIP client MUST stop sending requests to that server and SHOULD use exponential back-off when probing liveness.
Once a server selects an overload control algorithm for a client, the algorithm SHOULD NOT be changed for at least 3600 seconds (1 hour) to allow the algorithm to stabilize and avoid flapping.
Overload control is hop-by-hop: a SIP proxy SHOULD strip the overload control parameters from the incoming request before proxying it further downstream; the proxy may add its own parameters in the Via header it inserts.
Overload control parameter values generated by a server algorithm at time t and t+1 MUST carry an increasing "oc-seq" value. If the sequence counter overflows, it MUST be reset to the current timestamp or an appropriate base value.
The downstream SIP server MUST add a numeric value to the "oc" parameter in the response destined upstream; the absence of a value indicates the server does not support overload control.
The "oc-validity" and "oc-seq" parameters MUST NOT be inserted by a SIP client in a request; they are server-only response parameters. A non-zero "oc-validity" MUST appear only alongside an "oc" parameter.
To terminate overload control explicitly, the SIP server MUST set "oc-validity" to 0 and MUST increment "oc-seq", and SHOULD set "oc" to 0; upon receiving this, the client SHOULD disregard the "oc" value and cease throttling.
When a SIP client receives a response with the "oc" parameter filled in, it MUST reduce the number of requests it sends downstream to that server as indicated by the "oc" and "oc-algo" parameter values.
The loss-based overload control default algorithm categorizes requests into two buckets — category 1 (subject to reduction) and category 2 (protected, reduced only after category 1 is exhausted) — and uses random discard proportional to the "oc" value to achieve the target reduction percentage.
The "oc-algo" Via header parameter is inserted by the SIP client listing supported overload control algorithm classes (e.g., "loss", optionally others); the server selects one and returns the single chosen algorithm in the response.
The "oc-seq" Via header parameter, set by the server only, carries a monotonically increasing sequence number (or timestamp) that allows upstream clients to discard stale out-of-order overload control feedback.
The "oc-validity" Via header parameter, set by the server only, specifies in milliseconds how long the overload control instruction in "oc" remains in effect. Default is 500 ms; a value of 0 signals that overload control should stop.
The "oc" Via header parameter is inserted by the SIP client (without a value) in every SIP request to advertise overload control support, and is filled in by the downstream SIP server in responses to indicate the requested traffic reduction level.
This document registers four new Via header field parameters — "oc", "oc-validity", "oc-seq", and "oc-algo" — each with predefined values, in the IANA "Header Field Parameter and Parameter Values" sub-registry per RFC 3968.
A DDoS attack can force a legitimate server into sustained overload by synchronizing attack traffic with the "oc-validity" interval; combating such attacks is outside the scope of this document.
A malicious SIP entity may claim to support overload control but never reduce traffic, gaining an unfair advantage while compliant neighbors throttle. Servers should monitor client compliance and treat non-conforming clients as non-supporting (applying 503 rejection per Section 5.10.2).
An attacker able to modify traffic on a link can forge overload indications (by altering Via header "oc" values) to cause a DoS on a target SIP server by tricking upstream clients into dropping all traffic to it, or suppress legitimate overload signals to force traffic into an already overloaded server.
TLS (in conjunction with BCP 38) provides the best mitigation against both falsified and suppressed overload signals; TCP or WebSockets with BCP 38 raises the bar but remains inadequate against an adversary controlling the link.
Overload control transitions between inactive and active states per downstream server: inactive when no valid "oc" context exists or "oc-validity" has expired; active when a non-expired "oc" value is held. The transition to inactive is triggered by expiry of the validity period or receipt of "oc-validity=0".
ABNF defines via-params extensions: "oc" is an optional numeric value (1*DIGIT); "oc-validity" is a delta-ms (1*DIGIT); "oc-seq" is a 1–12 digit integer followed by "." and 1–5 digits; "oc-algo" is a DQUOTE-enclosed comma-separated list of algorithm tokens.