Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
updates
- rfc-3265 — Session Initiation Protocol (SIP)-Specific Event Notification
Extracted elements (25)
Retransmissions of NOTIFY requests are explicitly excluded from all three rate control mechanisms; the mechanisms only apply to the generation of new transactions. This preserves the normal RFC 3261 retransmission behavior without modification.
The adaptive minimum rate mechanism was introduced because a static minimum rate lacks the ability to increase or decrease dynamically. When a target sends frequent notifications in a short burst, the adaptive mechanism increases the timeout for subsequent notifications, reducing unnecessary load; when notifications are sparse, it decreases the timeout to ensure timely delivery.
The notifier is explicitly allowed to adjust the subscriber-requested rate control values based on local policy, static configuration, or other constraints. This allows the notifier to handle congestion or enforce operator policies without requiring subscriber awareness.
A notifier that does not understand this extension will not reflect the 'max-rate', 'min-rate', or 'adaptive-min-rate' Subscription-State header field parameters in NOTIFY requests; the absence of these parameters signals to the subscriber that no rate control is supported.
The rate control mechanisms are complementary to SIP compression schemes such as SigComp (RFC 3320) and TLS compression (RFC 3943); both can be applied simultaneously since they address different aspects of bandwidth reduction.
A compliant notifier MUST generate notifications when state changes occur or when the time since the most recent notification exceeds the value calculated using the adaptive timeout formula defined in Section 7.4.
A compliant notifier MUST NOT generate a notification if the interval since the most recent notification is less than the reciprocal of the 'max-rate' parameter, except upon receipt of a SUBSCRIBE request, when the subscription state changes from 'pending' to 'active', or upon subscription termination.
A notifier that supports the rate control mechanisms MUST adjust its rate of notification according to the rate control values agreed with the subscriber, and MUST reflect back the possibly adjusted rate control values in the corresponding Subscription-State header field parameter of subsequent NOTIFY requests.
If the subscriber did not include at least one rate control parameter in the most recent SUBSCRIBE request in a given dialog, the subscriber MUST NOT include an Event header field with any of those parameters in a 2xx response to a NOTIFY request in that dialog.
If the subscriber requests a maximum rate that would result in no notification before the subscription expiration, the notifier MUST increase the maximum rate and set it to the reciprocal value of the remaining subscription expiration time.
If the subscription expiry is shortened during an active subscription, the notifier MUST also increase the 'max-rate' value and set it to the reciprocal value of the reduced subscription expiration time.
The event type listed in the Event header field of the 2xx response to the NOTIFY request MUST match the event type of the Event header field in the corresponding NOTIFY request.
The 'period' parameter for the adaptive minimum rate formula MUST be chosen to be greater than the reciprocal value of the 'adaptive-min-rate' parameter, and it is RECOMMENDED to be several times larger than that reciprocal to maximize the effectiveness of the timeout formula.
When combining max-rate and min-rate, if the subscriber provides a 'min-rate' value higher than 'max-rate', the notifier MUST adjust the 'min-rate' value to a value equal to or lower than the 'max-rate' value.
When combining min-rate and adaptive-min-rate, if the subscriber provides a 'min-rate' value higher than 'adaptive-min-rate', the notifier MUST NOT consider the 'min-rate' value.
For the Resource List Server (RLS) maximum rate mechanism, the rate applies to the aggregate notification stream of the list subscription, not individual constituent events. The RLS buffers state changes and drains the buffer at the max-rate. For full-state notifications, pending notifications are replaced by newer state; for partial-state, state deltas are merged.
The adaptive minimum rate timeout formula is: timeout = count / ((adaptive-min-rate ^ 2) * period), where 'count' is notifications sent in the last 'period' seconds, and 'timeout' is the time in seconds to the next notification. When both max-rate and adaptive-min-rate are combined, timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2) * period)].
The Event header field is extended to appear in 2xx responses to NOTIFY requests, allowing subscribers to update rate control parameters mid-subscription. Other Event header field parameters in such responses have no meaning and MUST be ignored by the notifier.
Three new Event header field parameters are defined: 'max-rate' (maximum notifications per second), 'min-rate' (minimum notifications per second), and 'adaptive-min-rate' (adaptive minimum notifications per second). These parameters are added to both the Event header field and the Subscription-State header field.
With partial-state notifications and max-rate, the notifier maintains both the current full state F and the last communicated full state F'. F' is only replaced with F after the partial difference has been included in a notification. If the accumulated partial state exceeds full state size, the notifier SHOULD send full state instead.
Six new SIP header field parameters are registered in the 'Header Field Parameters and Parameter Values' sub-registry: 'max-rate' and 'min-rate' and 'adaptive-min-rate' each for both the Event header field and the Subscription-State header field, all with no predefined values. The Event header field reference is also updated to add RFC 6446.
Authentication and message integrity SHOULD be applied to subscriptions using this extension, per RFC 3265. Integrity protection SHOULD also be applied to the Event header field in 2xx responses to NOTIFY requests; without it, an eavesdropper could manipulate rate control parameters to suppress or flood notifications without the subscriber's knowledge.
When the maximum rate mechanism is used with partial-state notifications, all security considerations from RFC 5263 (SIP Partial Notification of Presence) apply in their entirety.
The adaptive minimum rate notifier maintains a 'count' record tracking notifications sent in the last 'period'. On subscription creation, 'count' is initialized to 'period * adaptive-min-rate'. Each NOTIFY sent (timeout or state change) triggers an update to 'count' and recalculation of 'timeout'. If timeout expires without a NOTIFY, current resource state is sent.
The grammar for the three rate parameters uses ABNF: each accepts a positive real number represented as 1-2 digits optionally followed by a decimal point and 1-10 digits, constraining values to the range 0.0000000001 to 99.9999999999. Zero is not an allowed value.