RFC 6446

Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control

📅 published January 2012, from ietf

Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control 🦋

Authors: A. Niemi (Nokia), K. Kiss (Nokia), S. Loreto (Ericsson) Category: Standards Track ✨ ISSN: 2070-1721 Date: January 2012 🎀 Updates: RFC 3265 (this one doesn't obsolete anything, it just extends RFC 3265) 💅

Abstract ✨

okay so this doc is all about giving you knobs to control how fast SIP event notifications get sent 🔥 These knobs work on subscriptions to every SIP event package, not just one. It updates RFC 3265 🫶

Status of This Memo

This is an Internet Standards Track document 👑

It's a product of the Internet Engineering Task Force (IETF) 🌸 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6446 💜

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.

Some material in this document may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you've got an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions: formatting it for publication as an RFC, or translating it into languages other than English. 🙈

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Definitions and Document Conventions . . . . . . . . . . . . .  5
3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.1.  Use Case for Limiting the Maximum Rate of Notifications  .  5
  3.2.  Use Case for Setting a Minimum Rate for Notifications  . .  6
  3.3.  Use Case for Specifying an Adaptive Minimum Rate of
        Notifications  . . . . . . . . . . . . . . . . . . . . . .  6
  3.4.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  7
4.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  8
  4.1.  Subscriber Behavior  . . . . . . . . . . . . . . . . . . .  8
  4.2.  Notifier Behavior  . . . . . . . . . . . . . . . . . . . .  9
5.  Operation of the Maximum Rate Mechanism  . . . . . . . . . . .  9
  5.1.  Subscriber Behavior  . . . . . . . . . . . . . . . . . . .  9
  5.2.  Notifier Behavior  . . . . . . . . . . . . . . . . . . . . 10
  5.3.  Selecting the Maximum Rate . . . . . . . . . . . . . . . . 11
  5.4.  The Maximum Rate Mechanism for the Resource List Server  . 11
  5.5.  Buffer Policy Description  . . . . . . . . . . . . . . . . 13
    5.5.1.  Partial-State Notifications  . . . . . . . . . . . . . 13
    5.5.2.  Full-State Notifications . . . . . . . . . . . . . . . 13
  5.6.  Estimated Bandwidth Savings  . . . . . . . . . . . . . . . 14
6.  Operation of the Minimum Rate Mechanism  . . . . . . . . . . . 14
  6.1.  Subscriber Behavior  . . . . . . . . . . . . . . . . . . . 14
  6.2.  Notifier Behavior  . . . . . . . . . . . . . . . . . . . . 15
  6.3.  Selecting the Minimum Rate . . . . . . . . . . . . . . . . 16
7.  Operation of the Adaptive Minimum Rate Mechanism . . . . . . . 16
  7.1.  Subscriber Behavior  . . . . . . . . . . . . . . . . . . . 16
  7.2.  Notifier Behavior  . . . . . . . . . . . . . . . . . . . . 17
  7.3.  Selecting the Adaptive Minimum Rate  . . . . . . . . . . . 18
  7.4.  Calculating the Timeout  . . . . . . . . . . . . . . . . . 18
8.  Usage of the Maximum Rate, Minimum Rate, and Adaptive
    Minimum Rate Mechanisms in a Combination . . . . . . . . . . . 19
9.  Protocol Element Definitions . . . . . . . . . . . . . . . . . 20
  9.1.  "max-rate", "min-rate", and "adaptive-min-rate" Header
        Field Parameters . . . . . . . . . . . . . . . . . . . . . 21
  9.2.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . 21
  9.3.  Event Header Field Usage in Responses to the NOTIFY
        Request  . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
  13.2. Informative References . . . . . . . . . . . . . . . . . . 24

1. Introduction ✨

okay bestie, so the SIP events framework [RFC3265] is the generic setup for subscribing to events and getting notified about them 💖 It brings in the SUBSCRIBE and NOTIFY methods, plus the idea of an event package, which is basically a concrete app of that framework to one particular class of events.

One thing the framework requires is that every event package spec sets an absolute ceiling on how often a single notifier is allowed to generate notifications. The point is to keep network load down 🧚

Every existing event package spec has a recommended max notification rate. They range from once every five seconds [RFC3856], [RFC3680], [RFC3857] all the way to once per second [RFC3842] 🍓

The framework also lets each event package define extra throttle mechanisms so subscribers can slow notifications down even more. So far, though, no event package has actually defined one 🙈

The resource list extension [RFC4662] also handles rate limiting. It lets a subscriber watch a whole mixed list of resources with one SUBSCRIBE request, instead of making a separate subscription for each one 🫶 The list subscription can throttle too: the Resource List Server (RLS) buffers resource state changes and sends them in batches. The catch is that the list mechanism gives the subscriber no way to set how long that throttling interval is 😭

Some event packages also want an absolute or adaptive minimum rate at which a notifier has to generate notifications. This lets a subscriber mix different trigger criteria inside one subscription to skip pointless notifications, while still making sure the current event state arrives on a regular basis 💅

This document extends the SIP events framework with three Event header field parameters, so a subscriber can set a maximum, a minimum, and an adaptive minimum rate for the notifications the notifier generates 🌈

max-rate: specifies a maximum number of notifications per second.

min-rate: specifies a minimum number of notifications per second.

adaptive-min-rate: specifies an adaptive minimum number of notifications per second.

These mechanisms apply to any event subscription, whether it's a single event subscription or an event list subscription. A notifier that complies with this specification will adjust the rate at which it generates notifications ✨

2. Definitions and Document Conventions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. These are the official BCP 14 vibes, so take them seriously 👑

Indented passages like this one are just extra info and clarifying text in this doc. They don't contain normative protocol behavior, so you can relax on these ones 💜

3. Overview 🦋

3.1. Use Case for Limiting the Maximum Rate of Notifications

Picture this: a presence client on a mobile device has a list of 100 buddies, or presentities. To cut down the processing and network load of watching 100 presentities separately, the client uses an RLS with that buddy list. That means it only needs one subscription to the RLS to get notifications about the presence state of the whole resource list 🔥

To control the RLS buffer policy, the presence client sets a maximum rate of notifications. If state changes come in faster than the maximum rate allows them to be sent, the RLS buffers them and batches all the buffered changes into one notification. The maximum rate applies to the whole resource list, so it's a hard cap on how many notifications per second the presence client can expect to get. Literally iconic for keeping things calm 💖

The presence client can also change the maximum rate during the subscription's lifetime. Say the mobile device notices the user has been inactive for a while. The client can pause notifications by picking a "max-rate" value that allows only a single notification for the rest of the subscription's lifetime 😴 When the user gets active again, the client can bring the stream back by re-subscribing with a "max-rate" parameter set to the value it used before. Also, applying the mechanism from RFC 5839 [RFC5839] can cut out the need to send a (full-state) notification with the latest resource state to the presence client after a subscription refresh 🧚

(part 1 of 5 — the next part picks up with the minimum rate use case and the requirements in Section 3.2 onward, so stay tuned 💕)

3.2. Use Case for Setting a Minimum Rate for Notifications ✨

okay so picture this 🎯 a location app is watching a target move around. To keep the processing and network load down, the app subscribes to a Location Server with a set of location filters [RFC6447] that set trigger criteria. For example, it only wants an update when the target has moved at least n meters. 🗺️

BUT the app also wants the current state on a regular schedule, even when the target hasn't moved enough to trip any trigger, like not moving at least n meters within the period. Main character energy, but make it consistent 💅

So the location application sets a minimum rate of notifications and puts it in the subscription it sends to the Location Server. The min-rate parameter says the minimum number of notifications per second the notifier needs to generate. 🦋

The app can change the minimum rate at any point during the subscription's lifetime 🔄 This matters because when the subscription is first made, the notifier might not have location info yet, so the first notification could be empty or missing some values 🫠 The big use case is controlling when the complete state should show up after the subscription is created. Once the state is acquired and the second notification goes out, the subscriber updates or changes the min-rate parameter to a more sensible value. That update can happen in the response to the notification that carries the complete state info. It's giving planned ✨

3.3. Use Case for Specifying an Adaptive Minimum Rate of Notifications 🌸

Okay, so the minimum rate mechanism is static and instantaneous rate control. It can't speed up or slow down adaptively 🙃 Some apps would totally vibe better with adaptive minimum rate control, though.

Same setup: a location app monitoring a target 📍 This time, the app wants to cut down its own processing. It wants a subscription that lowers the minimum rate of notifications when the target has sent out several notifications recently. But if the target has only sent a few recent notifications, the app wants the minimum rate to go up 📈 Iconic balance, honestly.

So the location application sets an adaptive minimum rate of notifications and includes it in the subscription sent to the Location Server. The notifier uses the adaptive-min-rate parameter value to dynamically calculate the actual maximum time between two notifications. To work that out, the notifier looks at how fast notifications have been going out recently. With the adaptive minimum rate mechanism, the notifier can speed up or slow down the notification rate compared to the minimum rate mechanism, depending on how many notifications went out in the last period 🧠

The location application can also change the adaptive-min-rate parameter while the subscription is still running. 💜

3.4. Requirements 📋

Here's the checklist, bestie 🎀

REQ1: The subscriber must be able to set a maximum rate of notifications in a specific subscription.
REQ2: The subscriber must be able to set a minimum rate of notifications in a specific subscription.
REQ3: The subscriber must be able to set an adaptive minimum rate of notifications in a specific subscription, which adjusts the minimum rate of notifications based on a moving average.
REQ4: It must be possible to apply the maximum rate, the minimum rate, and the adaptive minimum rate mechanisms all together, or in any combination, in a specific subscription.
REQ5: It must be possible to use any of the different rate control mechanisms in subscriptions to any events.
REQ6: It must be possible to use any of the different rate control mechanisms together with any other event filtering mechanisms.
REQ7: The notifier must be allowed to use a policy in which the maximum rate, minimum rate, and adaptive minimum rate parameters are adjusted from the value given by the subscriber.

For example, due to congestion, local policy at the notifier could temporarily dictate a policy that in effect further decreases the maximum rate of notifications. In another example, the notifier could increase the subscriber-proposed maximum rate so that at least one notification is generated during the remainder of the subscription lifetime. 🌧️

REQ8: The different rate control mechanisms must address corner cases for setting the notification rates appropriately. At a minimum, the mechanisms must address the situation in which the time between two notifications exceeds the subscription duration and should provide procedures for avoiding this situation. 🚨
REQ9: It must be possible to invoke, modify, or remove the different rate control mechanisms in the course of an active subscription.
REQ10: The different rate control mechanisms must allow for the application of authentication and integrity protection mechanisms to subscriptions invoking that mechanism. 🔐

4. Basic Operations 🛠️

4.1. Subscriber Behavior 🫶

Generally speaking, a subscriber generates SUBSCRIBE requests and processes NOTIFY requests as described in RFC 3265 [RFC3265]. Standard stuff, no surprises ✨

A subscriber that wants a maximum, minimum, or adaptive minimum rate of event notifications in a specific event subscription does that by including a max-rate, min-rate, or adaptive-min-rate Event header field parameter (or parameters) in the SUBSCRIBE request 🎯

A subscriber that wants to update a previously agreed event rate control parameter does it by including the updated max-rate, min-rate, or adaptive-min-rate Event header field parameter (or parameters) in a later SUBSCRIBE request or in a 2xx response to the NOTIFY request. Now here's the sharp bit 🔪 If the subscriber doesn't include at least one of the max-rate, min-rate, or adaptive-min-rate header field parameters in the most recent SUBSCRIBE request in a given dialog, then 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. No sneaking them back in, periodt 🙅‍♀️

4.2. Notifier Behavior 🔔

Generally speaking, a notifier processes SUBSCRIBE requests and generates NOTIFY requests as described in RFC 3265 [RFC3265]. Same vibe, other side of the chat 💬

A notifier that supports the different rate control mechanisms MUST adjust its rate of notification according to the rate control values agreed with the subscriber. If the notifier needs to lower the subscription expiration value, or if a local policy or other implementation-determined constraint at the notifier can't satisfy the rate control request, then the notifier can adjust (that is, increase or decrease) the subscriber-requested rate control values as needed. 🎚️ The notifier MUST reflect back the possibly adjusted rate control values in a max-rate, min-rate, or adaptive-min-rate Subscription-State header field parameter in the subsequent NOTIFY requests. Receipts, bestie 🧾

5. Operation of the Maximum Rate Mechanism 🚦

5.1. Subscriber Behavior 💖

A subscriber that wants to apply a maximum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the max-rate Event header field parameter. This parameter gives the requested maximum number of notifications per second. The value of this parameter is a positive real number written as a finite decimal representation 🔢

Heads up: the grammar in section 9.2 limits this value to between 0.0000000001 and 99.9999999999. Zero is not an allowed value. 🙅‍♀️

Also, the rate actually witnessed may not match the max-rate value for a bunch of reasons. For example, network jitter and retransmissions might make the subscriber receive notifications more often than the max-rate value recommends. Networks are chaotic, bestie 🌪️

A subscriber that wants to update the previously agreed maximum rate of notifications MUST include the updated max-rate Event header field parameter in a subsequent SUBSCRIBE request or in a 2xx response to the NOTIFY request. 🔁

A subscriber that wants to remove the maximum rate control from notifications MUST indicate that by not including a max-rate Event header field parameter in a subsequent SUBSCRIBE request or in a 2xx response to the NOTIFY request. Leaving it out is the whole move 🙈

There are two main consequences for the subscriber when it applies the maximum rate mechanism: state transitions may be lost, and event notifications may be delayed. 😬 If either of those side effects is a problem for the application that uses the event notifications, developers are told not to use the mechanism. Know your app, bestie 💅

5.2. Notifier Behavior 🌈

A notifier that supports the maximum rate mechanism MUST extract the value of the max-rate Event header parameter from a SUBSCRIBE request or from a 2xx response to the NOTIFY request, and use it as the suggested maximum number of notifications per second. The notifier can adjust this value, as defined in Section 5.3. ⚖️

A compliant notifier MUST reflect back the possibly adjusted maximum rate of notifications in a max-rate Subscription-State header field parameter in the subsequent NOTIFY requests. The indicated max-rate value is adopted by the notifier, and the notification rate is adjusted to match ✨

A notifier that doesn't understand this extension won't reflect the max-rate Subscription-State header field parameter in its NOTIFY requests. The absence of this parameter tells the subscriber that the notifier doesn't support rate control 🙃

A compliant notifier MUST NOT generate a notification if the interval since the most recent notification is less than the reciprocal value of the max-rate parameter. The only exceptions are when the notification is generated upon receipt of a SUBSCRIBE request, when the subscription state changes from pending to active, or upon termination of the subscription (the last notification). Those are the VIP passes 🎫

When a local policy sets a maximum rate for notifications, a notifier won't generate notifications more frequently than that local policy maximum rate, even if the subscriber isn't asking for maximum rate control. The notifier MAY inform the subscriber about such a local policy maximum rate by using the max-rate Subscription-State header field parameter in subsequent NOTIFY requests. 📣

Retransmissions of NOTIFY requests aren't affected by the maximum rate mechanism. In other words, the maximum rate mechanism only applies to the generation of new transactions. It doesn't in any way break or modify the normal retransmission mechanism specified in RFC 3261 [RFC3261]. Retransmissions are totally safe, bestie 🦋

5.3. Selecting the Maximum Rate 🎀

okay so picking the maximum rate needs SO much care bestie 💅 because it could accidentally set a minimum time between notifications that's longer than the subscription expiration. the notifier would get quenched and only send exactly two notifications total 😭 not it. so if the subscriber asks for a maximum rate that means no notification before the subscription expires, the notifier MUST increase the maximum rate and set it to the reciprocal of the remaining subscription expiration time. and per [RFC3265], the notifier may also shorten the subscription expiry anytime during an active subscription 👀 if it does, the notifier MUST also increase the max-rate value and set it to the reciprocal of the reduced subscription expiration time. main character energy for the math, fr fr 🧚

sometimes you just wanna pause the notification stream on an existing subscription dialog without ending the whole subscription 🌸 like when the app UI goes idle. whenever a subscriber realizes it needs to do that pause, it SHOULD set the maximum rate to the reciprocal of the remaining subscription expiration value. the result is no more notifications until the subscription expires or the subscriber sends a SUBSCRIBE request to resume them ✨ easy peasy.

the notifier MAY decide to increase or decrease the proposed max-rate value that the subscriber asked for, based on its local policy, static configuration, or other implementation-determined constraints 🍓 also, different event packages MAY define other constraints for the allowed maximum rate ranges. those constraints are out of the scope of this specification, so don't look for them here 🙈

5.4. The Maximum Rate Mechanism for the Resource List Server 🦋

okay now the list subscription [RFC4662] version 🌈 the maximum rate mechanism has some extra considerations here. the big difference is that the maximum rate applies to the aggregate notification stream from the list subscription, rather than controlling the notification of each implied constituent event one by one. and the RLS can use the maximum rate mechanism on its own to control the rate of its back-end subscriptions so its buffer doesn't overflow 💖

the notifier is responsible for sending event notifications when the subscribed resource changes state. we can picture the notifier as four pieces: the event state resource(s), the RLS (or any other notifier), a notification buffer, and finally the subscriber (the watcher of the event state), like this:

                    +--------+
                    | Event  |
     +--------+     |Resource|     +--------+
     | Event  |     +--------+     | Event  |
     |Resource|         |          |Resource|
     +---.=---+         |          +---=----+
           `-..         |         _.--'
               ``-._    |    _.--'
                    +'--'--'-+
                    |Resource|
                    |  List  |
                    | Server |
                    +---.----+
                        |
                        |
                     )--+---(
                     |      |       .--------.
                     |Buffer|<======'max-rate|
                     |      |       `--------'
                     )--.---(
                        |
                        |
                    .---+---.
                    | Event |
                    |Watcher|
                    `-------'

Figure 1: Model for the RLS Supporting Event Rate Control

in short, the RLS reads event state changes from the event state resource, either by creating a back-end subscription or by other means 🧃 then it packages them into event notifications and submits them into the output buffer. the rate at which that output buffer drains is controlled by the subscriber through the maximum rate mechanism. when a set of notifications gets batched together, how the overlapping resource state gets handled depends on the type of resource state 👑

in theory, there are many buffer policies the notifier could implement 🤔 but this specification only concentrates on two practical ones, and leaves the rest for further study (they're out of scope here). both of these depend on the mode the notifier is operating in:

Full-state: the last (most recent) full-state notification of each resource gets sent out, and all the others in the buffer get discarded 🗑️ this policy applies to event packages that carry full-state notifications.
Partial-state: the state deltas of each buffered partial notification per resource get merged, and the resulting notification is sent out 🫶 this policy applies to event packages that carry partial-state notifications.

5.5. Buffer Policy Description 💅

5.5.1. Partial-State Notifications

with partial notifications, the notifier needs its own buffer for each subscriber, because each subscriber might have a different value for the maximum rate of notifications 🌸 the notifier always has to keep both a copy of the current full state of the resource, F, and the last successfully communicated full state view of the resource in a specific subscription, F'. building a partial notification means creating a difference between those two states and generating a notification that contains that difference.

when the maximum rate mechanism is applied to the subscription, it's super important that F' only gets replaced with F when the difference between F and F' is already included in a partial-state notification sent to the subscriber under the maximum rate mechanism 🔥 also, the notifier implementation SHOULD check that the size of an accumulated partial state notification is smaller than the full state, and if it isn't, the notifier SHOULD send the full-state notification instead 💀 smart, right?

5.5.2. Full-State Notifications

with full-state notifications, the notifier only needs to keep the full state of the resource. when that changes, it sends the resulting notification to the subscriber ✨ simple.

when the maximum rate mechanism is applied to the subscription, the notifier receives the state changes of the resource and generates a notification. if there's already a pending notification, the notifier just replaces it with the new one and throws out the older state 🧹

5.6. Estimated Bandwidth Savings 🦋

it's hard to estimate the total bandwidth savings from using the maximum rate mechanism over a subscription, since the numbers change depending on the usage scenario 🤷‍♀️ but it's easy to see that if several full-state notifications would normally be sent in an interval set by the max-rate parameter, only a single notification gets sent during that same interval with the maximum rate mechanism. that's bandwidth savings of several times the notification size, literally iconic 💜

with partial-state notifications, estimates get even trickier, because the states of consecutive updates may or may not overlap 🌀 but even in the worst-case scenario, where each partial update touches a different part of the full state, a rate-controlled notification merging all of those n partial states together should, at most, be the size of a full-state update. in that case, the bandwidth savings are approximately n times the size of the header fields of the NOTIFY request 🎀

it's also true that there are several compression schemes designed to save bandwidth in SIP, like SigComp [RFC3320] and TLS compression [RFC3943] 🗜️ but those are complementary, not competing, mechanisms to the maximum rate mechanism. after all, they can both be applied at the same time, which is so cute of them 🫶

6. Operation of the Minimum Rate Mechanism 👑

6.1. Subscriber Behavior 🌈

a subscriber that wants to apply a minimum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the min-rate Event header field parameter 💖 this parameter specifies the requested minimum number of notifications per second. its value is a positive real number given by a finite decimal representation.

Note that the grammar in section 9.2 constrains this value to be between 0.0000000001 and 99.9999999999. Zero is not an allowed value. 🙅‍♀️

a subscriber that wants to update the previously agreed minimum rate of notifications MUST include the updated min-rate Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request 🍓

a subscriber that wants to remove minimum rate control from notifications MUST indicate that by not including a min-rate Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request 🧚

the main consequence for the subscriber when applying the minimum rate mechanism is that it can receive a notification even if nothing has changed in the notifier's current state 🙈 however, RFC 5839 [RFC5839] defines a mechanism that allows suppression of a NOTIFY request, or a NOTIFY request body, if the state hasn't changed. lowkey a lifesaver 🫶

6.2. Notifier Behavior 🦋

a notifier that supports the minimum rate mechanism MUST extract the value of the min-rate Event header field parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request, and use it as the suggested minimum number of notifications per second 💅 this value can be adjusted by the notifier, as defined in Section 6.3.

a compliant notifier MUST reflect back the possibly adjusted minimum rate of notifications in a min-rate Subscription-State header field parameter of the subsequent NOTIFY requests 🌸 the indicated min-rate value is adopted by the notifier, and the notification rate gets adjusted accordingly ✨

a notifier that doesn't understand this extension won't reflect the min-rate Subscription-State header field parameter in its NOTIFY requests. the absence of that parameter tells the subscriber that the notifier doesn't support rate control 🙃

a compliant notifier MUST generate notifications when state changes occur, or when the time since the most recent notification exceeds the reciprocal value of the min-rate parameter 🔥 depending on the event package and the subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of the minimum rate mechanism MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state 💜 if the subscriber and the notifier support the procedures in RFC 5839 [RFC5839], the complete NOTIFY request or the NOTIFY request body can be suppressed when the state hasn't changed since the previous notification 🫧

retransmissions of NOTIFY requests aren't affected by the minimum rate mechanism. in other words, the minimum rate mechanism only applies to generating new transactions, and it doesn't in any way break or modify the normal retransmission mechanism 🎀

6.3. Selecting the Minimum Rate 💅

okay bestie, so the minimum rate mechanism can totally spam out a LOT of notifications 😭 which means extra processing work for the notifier, and some of them might just repeat stuff the subscriber already knows 🙈 there's no one-size-fits-all range for what's acceptable, BUT the subscriber SHOULD ask for the lowest minimum rate it can get 🍓 different event packages MAY set their own extra limits on the allowed minimum rate values too. those limits are out of scope for this spec ✨

the notifier MAY bump the proposed "min-rate" value up or down based on its own local policy, static config, or other constraints the implementation decides on. it's giving "I hear you, but I make the final call" 💅🫶

7. Operation of the Adaptive Minimum Rate Mechanism ✨

7.1. Subscriber Behavior 🦋

a subscriber that wants an adaptive minimum rate on its notifications MUST build a SUBSCRIBE request that includes the adaptive-min-rate Event header field parameter. this parameter sets an adaptive minimum number of notifications per second. the value is a positive real number written as a finite decimal representation 💖

Note that the grammar in section 9.2 constrains this value to be between 0.0000000001 and 99.9999999999. Zero is not an allowed value. 🙈

a subscriber that wants to change the adaptive minimum rate it already agreed on MUST include the updated adaptive-min-rate Event header field parameter in a later SUBSCRIBE request or in a 2xx response to the NOTIFY request. 🎀

a subscriber that wants to turn off the adaptive minimum rate control MUST say so by leaving out the adaptive-min-rate Event header field parameter in a later SUBSCRIBE request or in a 2xx response to the NOTIFY request. bye bye rate control 👋

the main thing to know as a subscriber is that you can get a notification even when nothing has changed on the notifier's end 😭 BUT ngl, RFC 5839 [RFC5839] has a mechanism that lets you suppress a NOTIFY request, or the body of one, if the state hasn't changed. lifesaver fr 🌸

7.2. Notifier Behavior 🌈

a notifier that supports the adaptive minimum rate mechanism MUST pull the adaptive-min-rate Event header parameter out of a SUBSCRIBE request or a 2xx response to the NOTIFY request, then use it to work out the actual maximum time between two notifications, as defined in Section 7.4. 🧚

the notifier is allowed to adjust the adaptive-min-rate value, as described in Section 7.3 ✨

a compliant notifier MUST reflect back the possibly adjusted adaptive minimum rate in an adaptive-min-rate Subscription-State header field parameter on the NOTIFY requests that follow. once that value is adopted by the notifier, the notification rate gets adjusted to match 💅 the vibe is "we're on the same page now" 🫶

a notifier that doesn't understand this extension won't reflect the adaptive-min-rate Subscription-State header parameter in its NOTIFY requests. so if that parameter is missing, the subscriber can tell that the notifier doesn't support rate control at all 💀

a compliant notifier MUST send out notifications when state changes happen, OR when the time since the last notification goes past the value the formula in Section 7.4 gives. depending on the event package and the subscriber's preferences in the SUBSCRIBE request, the NOTIFY request sent because of the minimum rate mechanism MUST carry either the full current state or only the partial state, which shows the difference from the last state that was successfully communicated. 🍓 and if both sides support the procedures in RFC 5839 [RFC5839], the whole NOTIFY request or just its body can be suppressed when the state hasn't changed since the previous notification. no need to send the same thing twice, periodt 💅

the adaptive minimum rate mechanism works like this:

when a subscription is first created, the notifier makes a record (the count parameter) to keep track of how many notifications got sent during the period. the count parameter starts out holding a history of having sent period * adaptive-min-rate notifications for that period. ✨
the timeout value gets calculated using the equation in Section 7.4. 🦋
if the timeout period passes without a NOTIFY request going out on the subscription, then the current resource state is sent (subject to any filtering tied to the subscription). ⏰
whenever a NOTIFY request goes out (whether it's because of a timeout event or a state change), the notifier updates the notification history stored in the count parameter, recalculates timeout, and goes back to step 3. 🔁

retransmissions of NOTIFY requests aren't affected by the timeout. the timeout only applies to generating new transactions 💖 in other words, the timeout doesn't break or change the normal retransmission mechanism from RFC 3261 [RFC3261] in any way. that mechanism stays exactly as it is 🫶

7.3. Selecting the Adaptive Minimum Rate 🌸

the adaptive minimum rate mechanism can also generate a lot of notifications, which means more processing work for the notifier 😭 some of those notifications might be unnecessary too, repeating state the subscriber already has 🙈 again, there aren't generic guidelines for what's acceptable, so the subscriber SHOULD ask for the lowest possible adaptive minimum rate value 🍓 different event packages MAY set other constraints on the allowed adaptive minimum rate values, and those constraints are out of scope for this specification ✨

the notifier MAY bump the proposed adaptive-min-rate value up or down based on its local policy, static configuration, or other constraints the implementation decides on. same energy as before, bestie 💅

7.4. Calculating the Timeout 🧚

this is the formula that changes the absolute pacing so it hits the adaptive minimum rate you asked for over the period. here it is in equation (1) 👑

timeout = count / ((adaptive-min-rate ^ 2) * period)              (1)

the output, timeout, is the time until the next notification, in seconds. the formula has three inputs:

adaptive-min-rate: the value of the adaptive-min-rate parameter carried in the Subscription-State header field.
period: the rolling average period, in seconds. the notifier's local policy sets the granularity of the period values, BUT the notifier MUST choose a value greater than the reciprocal of the adaptive-min-rate parameter. it's also RECOMMENDED that the notifier choose a period several times larger than that reciprocal, so equation (1) works its best ✨ and it's up to the implementation whether the notifier uses one period value for every subscription or a separate value for each one 🦋
count: the number of notifications sent during the last period seconds, not counting any retransmissions of requests. 🔢

if the maximum rate and the adaptive minimum rate mechanisms are both used in the same subscription, the formula that calculates the timeout is equation (2) 🔥

 timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2)

max-rate: the value of the max-rate parameter carried in the Subscription-State header field.

the formula in (2) makes sure that, for all the possible values of max-rate and adaptive-min-rate, with adaptive-min-rate < max-rate, the timeout never ends up lower than the reciprocal of max-rate. so the max rate always keeps its promise 💖

sometimes it might be a good idea for the notifier to hit an adaptive minimum rate in a different way than this algorithm allows. that's allowed, BUT the notifier MUST comply with any "max-rate" or "min-rate" parameters that were negotiated. no skipping those, okay? 🙅‍♀️💜

8. Usage of the Maximum Rate, Minimum Rate, and Adaptive Minimum Rate Mechanisms in a Combination 🌈

apps can subscribe to an event package using all the rate control mechanisms one at a time, or mixed together. there's no technical reason they can't work together 🦋 BUT some combos make little sense to use together 🙈 this section goes through every combination you can put into a subscription, and whether each one actually works 💅

maximum rate and minimum rate: this combo gives you a reduced notification rate, while still making sure you get periodic notifications. iconic 👑

a subscriber SHOULD choose a min-rate value lower than the max-rate value. otherwise, the notifier MUST adjust the subscriber-provided min-rate value to something equal to or lower than the max-rate value. 🎀

maximum rate and adaptive minimum rate: this one works a lot like the combo above, except the interval where notifications are guaranteed changes dynamically 🦋

a subscriber SHOULD choose an adaptive-min-rate value lower than the max-rate value. otherwise, the notifier MUST adjust the subscriber-provided adaptive-min-rate value to something equal to or lower than the max-rate value. 🧚

minimum rate and adaptive minimum rate: when you use the adaptive minimum rate mechanism, frequent state changes in a short window can lead to no notifications for a long stretch afterwards 😭 adding the minimum rate mechanism fixes that by making sure the subscriber always gets notifications after a set interval. saved 🫶

a subscriber SHOULD choose a min-rate value lower than the adaptive-min-rate value. otherwise, the notifier MUST NOT consider the min-rate value. 🙅‍♀️

maximum rate, minimum rate, and adaptive minimum rate: this combo makes little sense to use, although it's not forbidden 💀

a subscriber SHOULD choose min-rate and adaptive-min-rate values lower than the max-rate value. otherwise, the notifier MUST adjust the subscriber-provided min-rate and adaptive-min-rate values to something equal to or lower than the max-rate value. 🍓

a subscriber SHOULD choose a min-rate value lower than the adaptive-min-rate value. otherwise, the notifier MUST NOT consider the min-rate value. 💅

9. Protocol Element Definitions 🎀

this section describes the protocol extensions needed for the different rate control mechanisms ✨

9.1. "max-rate", "min-rate", and "adaptive-min-rate" Header Field Parameters 💖

the max-rate, min-rate, and adaptive-min-rate parameters get added to the rule definitions of the Event header field and the Subscription-State header field in the RFC 3265 [RFC3265] grammar. how these parameters get used is described in Sections 5, 6, and 7 🦋

9.2. Grammar ✨

Okay, bestie, this is the spot where the ABNF lives 🧚. The grammar is written in Augmented BNF [RFC5234], and it's built on the ruleset from RFC 3265 [RFC3265]. The new bit is that we add more options to the event-param and subexp-params sets that RFC 3265 already defined 💅.

event-param     =  max-rate-param
                   / min-rate-param
                   / amin-rate-param
subexp-params   =  max-rate-param
                   / min-rate-param
                   / amin-rate-param
max-rate-param  =  "max-rate" EQUAL
                   (1*2DIGIT ["." 1*10DIGIT])
min-rate-param  =  "min-rate" EQUAL
                   (1*2DIGIT ["." 1*10DIGIT])
amin-rate-param =  "adaptive-min-rate" EQUAL
                   (1*2DIGIT ["." 1*10DIGIT])

9.3. Event Header Field Usage in Responses to the NOTIFY Request 🦋

This table is a glow-up of the one in Section 7.2 of RFC 3265 [RFC3265] 🌸. The big change is that the Event header field is now allowed in a 2xx response to a NOTIFY request. Responses that aren't 2xx to NOTIFY requests are undefined and out of scope here, so don't go looking for rules about those in this spec 🙈.

Header field      where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Event             2xx          -   -   -   -   -   -   -   -   o

Okay, the main point: if a subscriber wants to change the agreed maximum, minimum, or adaptive minimum rate of notifications, they MUST include all the values they want for the "max-rate", "min-rate", and "adaptive-min-rate" parameters in an Event header field in the 2xx response to the NOTIFY request 🎀. Any other header field parameters that other specs have already defined for the Event header field don't mean anything when the Event header is in that 2xx response. If they show up anyway, the notifier MUST ignore them 🙅‍♀️.

Also, the event type in the Event header field of that 2xx response MUST match the event type in the Event header field of the NOTIFY request it's answering 💜.

10. IANA Considerations 🌈

This spec registers three new SIP header field parameters in the "Header Field Parameters and Parameter Values" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry ✨.

                                           Predefined
  Header Field         Parameter Name        Values      Reference
  -------------------- ---------------     ----------    ---------
  Event                max-rate            No            [RFC6446]
  Subscription-State   max-rate            No            [RFC6446]
  Event                min-rate            No            [RFC6446]
  Subscription-State   min-rate            No            [RFC6446]
  Event                adaptive-min-rate   No            [RFC6446]
  Subscription-State   adaptive-min-rate   No            [RFC6446]

This spec also updates the reference for the Event header field in the "Header Fields" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry 🍓.

Header Name  compact   Reference
-----------  -------   ------------------
Event          o       [RFC3265][RFC6446]

11. Security Considerations 🔥

Okay, this part is serious, so pay attention 🥺. The security considerations from RFC 3265 [RFC3265] all still apply in full, since this mechanism extends that spec. Authentication and message integrity SHOULD be applied to subscriptions that use this extension 🔐.

RFC 3265 [RFC3265] already recommends integrity protection for the Event header field of SUBSCRIBE requests. Implementations of this extension SHOULD also protect the integrity of the Event header field in the 2xx response to the NOTIFY request. Without that protection, an eavesdropper could see and change the Event header field. They could also mess with a 200 (OK) response to the NOTIFY request to either silence notifications or flood them, and the subscriber would never see what caused the problem 😱💀.

When the maximum rate mechanism involves partial-state notifications, the security considerations listed in RFC 5263 [RFC5263] apply in their entirety. Don't skip this one, bestie 🚨.

12. Acknowledgments 🫶

Big thank-yous to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, Michael Procter, Janet Gunn, and Ari Keranen for supporting and/or reviewing this work 👑.

Thanks also to Brian Rosen for coming up with the idea of the minimum and adaptive minimum rate mechanisms, and to Adam Roach for the work on the algorithm for the adaptive minimum rate mechanism and for all the other feedback 💖.

13. References 📚

13.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008.

13.2. Informative References

[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, November 2004.
[RFC5839] Niemi, A. and D. Willis, Ed., "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.
[RFC6447] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", RFC 6447, January 2012.

Authors' Addresses 🦋

Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN  00045
Finland

Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com


Krisztian Kiss
Nokia
200 South Mathilda Ave
Sunnyvale, CA  94086
US

Phone: +1 650 391 5969
EMail: krisztian.kiss@nokia.com


Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: salvatore.loreto@ericsson.com

📦 where this page comes from

ietf: rfc6446 2012-01
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms