Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 6446 K. Kiss
Updates: 3265 Nokia
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
January 2012
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 6446 K. Kiss
Updates: 3265 Nokia
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
January 2012
Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
用于通知速率控制的会话启动协议（SIP）事件通知扩展
Abstract
摘要
This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265.
本文档指定了调整会话启动协议（SIP）事件通知速率的机制。这些机制可以应用于所有SIP事件包的订阅中。本文档更新了RFC 3265。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6446.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6446.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
The SIP events framework [RFC3265] defines a generic framework for subscriptions to and notifications of events related to SIP systems. This framework defines the methods SUBSCRIBE and NOTIFY, and introduces the concept of an event package, which is a concrete application of the SIP events framework to a particular class of events.
SIP事件框架[RFC3265]定义了一个通用框架，用于订阅和通知与SIP系统相关的事件。该框架定义了SUBSCRIBE和NOTIFY方法，并引入了事件包的概念，它是SIP事件框架对特定事件类的具体应用。
One of the things the SIP events framework mandates is that each event package specification defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier. Such a limit is provided in order to reduce network load.
SIP事件框架规定的一件事是，每个事件包规范定义了单个通知程序允许生成通知的绝对最大速率。提供这样的限制是为了减少网络负载。
All of the existing event package specifications include a recommendation for the maximum notification rate, ranging from once in every five seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842].
所有现有的事件包规范都包括最大通知速率的建议，范围从每五秒钟一次[RFC3856]、[RFC3680]、[RFC3857]到每秒一次[RFC3842]。
Per the SIP events framework, each event package specification is allowed to define additional throttle mechanisms that allow the subscriber to further limit the rate of event notification. So far, none of the event package specifications have defined such a mechanism.
根据SIP事件框架，允许每个事件包规范定义额外的节流机制，以允许订阅者进一步限制事件通知的速率。到目前为止，没有一个事件包规范定义了这种机制。
The resource list extension [RFC4662] to the SIP events framework also deals with rate limiting of event notifications. The extension allows a subscriber to subscribe to a heterogeneous list of resources with a single SUBSCRIBE request, rather than having to install a subscription for each resource separately. The event list subscription also allows rate limiting, or throttling of notifications, by means of the Resource List Server (RLS) buffering notifications of resource state changes, and sending them in batches. However, the event list mechanism provides no means for the subscriber to set the interval for the throttling.
SIP事件框架的资源列表扩展[RFC4662]还处理事件通知的速率限制。该扩展允许订阅者通过单个订阅请求订阅异构资源列表，而不必分别为每个资源安装订阅。事件列表订阅还允许通过资源列表服务器（RLS）缓冲资源状态更改的通知并成批发送来限制通知的速率或限制通知。但是，事件列表机制没有为订阅服务器提供设置限制间隔的方法。
Some event packages are also interested in specifying an absolute or an adaptive minimum rate at which notifications need to be generated by a notifier. This helps the subscriber to effectively use different trigger criteria within a subscription to eliminate unnecessary notifications but at the same time make sure that the current event state is periodically received.
一些事件包还对指定通知程序需要生成通知的绝对或自适应最小速率感兴趣。这有助于订阅服务器在订阅中有效地使用不同的触发条件，以消除不必要的通知，但同时确保定期接收当前事件状态。
This document defines an extension to the SIP events framework by defining the following three Event header field parameters that allow a subscriber to set a maximum, a minimum, and an adaptive minimum rate of notifications generated by the notifier:
本文档通过定义以下三个事件头字段参数来定义SIP事件框架的扩展，这些参数允许订阅者设置由通知程序生成的通知的最大、最小和自适应最小速率：
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 are applicable to any event subscription, both single event subscription and event list subscription. A notifier compliant to this specification will adjust the rate at which it generates notifications.
这些机制适用于任何事件订阅，包括单个事件订阅和事件列表订阅。符合此规范的通知程序将调整其生成通知的速率。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain normative protocol behavior.
本文档中使用缩进段落（如本段落）来提供附加信息和澄清文本。它们不包含规范的协议行为。
A presence client in a mobile device contains a list of 100 buddies or presentities. In order to decrease the processing and network load of watching 100 presentities, the presence client has employed an RLS with the list of buddies, and therefore only needs a single subscription to the RLS to receive notifications of the presence state of the resource list.
移动设备中的状态客户端包含100个好友或状态实体的列表。为了减少观看100个呈现实体的处理和网络负载，呈现客户端使用了具有好友列表的RLS，因此仅需要对RLS的单个订阅来接收资源列表的呈现状态的通知。
In order to control the buffer policy of the RLS, the presence client sets a maximum rate of notifications. The RLS will buffer notifications that are generated faster than they are allowed to be sent due to the maximum rate and batch all of the buffered state changes together in a single notification. The maximum rate applies to the overall resource list, which means that there is a hard cap imposed by the maximum rate to the number of notifications per second that the presence client can expect to receive.
为了控制RLS的缓冲区策略，状态客户端设置最大通知速率。RLS将缓冲由于最大速率而产生的比允许发送的更快的通知，并在单个通知中批处理所有缓冲状态更改。最大速率适用于整个资源列表，这意味着存在状态客户端预期每秒可接收的通知数有一个由最大速率施加的硬上限。
The presence client can also modify the maximum rate of notifications during the lifetime of the subscription. For example, if the mobile device detects inactivity from the user for a period of time, the presence client can simply pause notifications by choosing a "max-rate" parameter that allows only a single notification for the
状态客户端还可以修改订阅生存期内通知的最大速率。例如，如果移动设备在一段时间内检测到来自用户的不活动，则存在客户端可以通过选择“最大速率”参数来简单地暂停通知，该参数仅允许针对该用户的单个通知
remainder of the subscription lifetime. When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "max-rate" parameter set to the earlier-used value. Application of the mechanism defined by RFC 5839 [RFC5839] can also eliminate the transmission of a (full-state) notification carrying the latest resource state to the presence client after a subscription refresh.
订阅生存期的剩余部分。当用户再次变为活动状态时，状态客户端可以通过使用设置为先前使用的值的“最大速率”参数重新订阅来恢复通知流。应用RFC 5839[RFC5839]定义的机制还可以消除在订阅刷新后将携带最新资源状态的（完整状态）通知传输到状态客户端的情况。
A location application is monitoring the movement of a target. In order to decrease the processing and network load, the location application has made a subscription to a Location Server with a set of location filters [RFC6447] that specify trigger criteria, e.g., to send an update only when the target has moved at least n meters. However, the application is also interested in receiving the current state periodically, even if the state of the target has not changed enough to satisfy any of the trigger criteria, e.g., has not moved at least n meters within the period.
定位应用程序正在监视目标的移动。为了减少处理和网络负载，位置应用程序向位置服务器订阅了一组位置过滤器[RFC6447]，这些过滤器指定了触发条件，例如，仅当目标移动至少n米时才发送更新。然而，应用程序还希望周期性地接收当前状态，即使目标的状态没有改变到足以满足任何触发标准，例如，在该周期内没有移动至少n米。
The location application sets a minimum rate of notifications and includes it in the subscription sent to the Location Server. The "min-rate" parameter indicates the minimum number of notifications per second the notifier needs to generate.
位置应用程序设置通知的最小速率，并将其包含在发送到位置服务器的订阅中。“min rate”参数表示通知程序每秒需要生成的最小通知数。
The location application can modify the minimum rate of notifications during the lifetime of the subscription. For example, when the subscription to the movement of a target is made, the notifier may not have the location information available. Thus, the first notification might be empty or certain values might be absent. An important use case is placing constraints on when complete state should be provided after creating the subscription. Once state is acquired and the second notification is sent, the subscriber updates or changes the "min-rate" parameter to a more sensible value. This update can be performed in the response to the notification that contains the complete state information.
位置应用程序可以在订阅的生存期内修改通知的最小速率。例如，当预订目标的移动时，通知程序可能没有可用的位置信息。因此，第一个通知可能为空，或者可能缺少某些值。一个重要的用例是在创建订阅后设置何时应提供完整状态的约束。一旦获取状态并发送第二个通知，订户将更新或更改“最小速率”参数为更合理的值。可以在响应包含完整状态信息的通知时执行此更新。
The minimum rate mechanism introduces a static and instantaneous rate control without the functionality to increase or decrease the notification rate adaptively. However, there are some applications that would work better with an adaptive minimum rate control.
最小速率机制引入了静态和瞬时速率控制，没有自适应增加或减少通知速率的功能。但是，有些应用程序使用自适应最小速率控制效果更好。
A location application is monitoring the movement of a target. In order to decrease the processing in the application, the location application wants to make a subscription that dynamically decreases the minimum rate of notifications if the target has sent out several
定位应用程序正在监视目标的移动。为了减少应用程序中的处理，如果目标发送了多个通知，位置应用程序希望进行订阅，以动态降低最小通知速率
notifications recently. However, if there have been only few recent notifications by the target, the location application wants the minimum rate of notifications to increase.
最近的通知。但是，如果目标最近只有很少的通知，则位置应用程序希望增加最小通知率。
The location application sets an adaptive minimum rate of notifications and includes it in the subscription sent to the Location Server. The "adaptive-min-rate" parameter value is used by the notifier to dynamically calculate the actual maximum time between two notifications. In order to dynamically calculate the maximum time, the notifier takes into consideration the rate at which notifications have been sent recently. In the adaptive minimum rate mechanism, the notifier can increase or decrease the notification rate compared to the minimum rate mechanism based on the recent number of notifications sent out in the last period.
位置应用程序设置自适应的最小通知速率，并将其包含在发送到位置服务器的订阅中。通知程序使用“自适应最小速率”参数值动态计算两次通知之间的实际最长时间。为了动态计算最长时间，通知程序将考虑最近发送通知的速率。在自适应最小速率机制中，与最小速率机制相比，通知程序可以基于最近在上一时段发送的通知数来增加或减少通知速率。
The location application can also modify the "adaptive-min-rate" parameter during the lifetime of the subscription.
位置应用程序还可以在订阅的生存期内修改“自适应最小速率”参数。
REQ1: The subscriber must be able to set a maximum rate of notifications in a specific subscription.
请求1：订阅者必须能够在特定订阅中设置最大通知速率。
REQ2: The subscriber must be able to set a minimum rate of notifications in a specific subscription.
REQ2：订阅者必须能够在特定订阅中设置最低通知率。
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.
REQ3：订阅者必须能够在特定订阅中设置自适应最小通知速率，该速率根据移动平均值调整最小通知速率。
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.
要求4：必须能够在特定订阅中同时或以任何组合应用最大速率、最小速率和自适应最小速率机制。
REQ5: It must be possible to use any of the different rate control mechanisms in subscriptions to any events.
REQ5：必须能够在订阅任何事件时使用任何不同的速率控制机制。
REQ6: It must be possible to use any of the different rate control mechanisms together with any other event filtering mechanisms.
要求6：必须能够使用任何不同的速率控制机制以及任何其他事件过滤机制。
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.
REQ7：必须允许通知程序使用一个策略，其中最大速率、最小速率和自适应最小速率参数根据订户给定的值进行调整。
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.
要求8：不同的速率控制机制必须解决角落情况，以便适当设置通知速率。这些机制至少必须解决两次通知之间的时间超过订阅持续时间的情况，并应提供避免这种情况的程序。
REQ9: It must be possible to invoke, modify, or remove the different rate control mechanisms in the course of an active subscription.
REQ9：在活动订阅过程中，必须能够调用、修改或删除不同的速率控制机制。
REQ10: The different rate control mechanisms must allow for the application of authentication and integrity protection mechanisms to subscriptions invoking that mechanism.
REQ10：不同的速率控制机制必须允许对调用该机制的订阅应用身份验证和完整性保护机制。
In general, a subscriber generates SUBSCRIBE requests and processes NOTIFY requests as described in RFC 3265 [RFC3265].
通常，订户生成订阅请求并处理RFC 3265[RFC3265]中所述的通知请求。
A subscriber that wants to have a maximum, minimum, or adaptive minimum rate of event notifications in a specific event subscription does so by including a "max-rate", "min-rate", or "adaptive-min-rate" Event header field parameter(s) as part of the SUBSCRIBE request.
希望在特定事件订阅中具有最大、最小或自适应最小事件通知速率的订阅方通过将“最大速率”、“最小速率”或“自适应最小速率”事件头字段参数作为订阅请求的一部分来实现。
A subscriber that wants to update a previously agreed event rate control parameter does so by including the updated "max-rate", "min-rate", or "adaptive-min-rate" Event header field parameter(s) as part of a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request. If the subscriber does not 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, 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.
想要更新先前约定的事件速率控制参数的订阅者通过将更新后的“最大速率”、“最小速率”或“自适应最小速率”事件标头字段参数作为后续订阅请求或通知请求的2xx响应的一部分来实现。如果订阅者在给定对话框中的最新订阅请求中未包含至少一个“最大速率”、“最小速率”或“自适应最小速率”标头字段参数，则订阅者不得在该对话框中对通知请求的2xx响应中包含具有任何这些参数的事件标头字段。
In general, a notifier processes SUBSCRIBE requests and generates NOTIFY requests as described in RFC 3265 [RFC3265].
通常，通知程序处理订阅请求并生成通知请求，如RFC 3265[RFC3265]中所述。
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 cannot satisfy the rate control request, then the notifier can adjust (i.e., increase or decrease) appropriately the subscriber-requested rate control values. 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 of the subsequent NOTIFY requests.
支持不同速率控制机制的通知程序必须根据与订阅服务器商定的速率控制值调整其通知速率。如果通知程序需要降低订阅过期值，或者如果通知程序处的本地策略或其他实现确定的约束无法满足速率控制请求，则通知程序可以适当调整（即，增加或减少）订阅者请求的速率控制值。通知程序必须在后续通知请求的“最大速率”、“最小速率”或“自适应最小速率”订阅状态标头字段参数中反映可能调整的速率控制值。
A subscriber that wishes 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 specifies the requested maximum number of notifications per second. The value of this parameter 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.
请注意，第9.2节中的语法将该值限制在0.0000000001和99.99999999之间。零不是允许的值。
Note that the witnessed notification rate may not conform to the "max-rate" value for a number of reasons. For example, network jitter and retransmissions may result in the subscriber receiving the notifications more frequently than the "max-rate" value recommends.
请注意，由于多种原因，见证通知速率可能不符合“最大速率”值。例如，网络抖动和重传可能导致订户接收通知的频率高于“最大速率”值建议的频率。
A subscriber that wishes 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 a 2xx response to the NOTIFY request.
希望更新先前约定的最大通知速率的订阅服务器必须在后续订阅请求或对通知请求的2xx响应中包含更新的“最大速率”事件标头字段参数。
A subscriber that wishes to remove the maximum rate control from notifications MUST indicate so by not including a "max-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
希望从通知中删除最大速率控制的订阅者必须通过在后续订阅请求或对通知请求的2xx响应中不包含“最大速率”事件标头字段参数来表示。
There are two main consequences for the subscriber when applying the maximum rate mechanism: state transitions may be lost and event notifications may be delayed. If either of these side effects constitute a problem to the application that utilizes the event notifications, developers are instructed not to use the mechanism.
应用最大速率机制时，订阅者有两个主要后果：状态转换可能会丢失，事件通知可能会延迟。如果这些副作用中的任何一个对使用事件通知的应用程序构成问题，则会指示开发人员不要使用该机制。
A notifier that supports the maximum rate mechanism MUST extract the value of the "max-rate" Event header parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request and use it as the suggested maximum number of notifications per second. This value can be adjusted by the notifier, as defined in Section 5.3.
支持最大速率机制的通知程序必须从订阅请求或对通知请求的2xx响应中提取“最大速率”事件头参数的值，并将其用作建议的每秒最大通知数。如第5.3节所述，该值可由通知程序进行调整。
A compliant notifier MUST reflect back the possibly adjusted maximum rate of notifications in a "max-rate" Subscription-State header field parameter of the subsequent NOTIFY requests. The indicated "max-rate" value is adopted by the notifier, and the notification rate is adjusted accordingly.
符合要求的通知程序必须在后续通知请求的“最大速率”订阅状态标头字段参数中反映可能调整的最大通知速率。通知程序采用指示的“最大速率”值，并相应调整通知速率。
A notifier that does not understand this extension will not reflect the "max-rate" Subscription-State header field parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
不理解此扩展的通知程序不会在通知请求中反映“最大速率”订阅状态标头字段参数；缺少此参数表示订阅服务器不支持通知程序的速率控制。
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, except when generating the notification either upon receipt of a SUBSCRIBE request, when the subscription state is changing from "pending" to "active" state, or upon termination of the subscription (the last notification).
如果最近通知的间隔小于“最大速率”参数的倒数值，则符合要求的通知程序不得生成通知，除非在收到订阅请求时生成通知，订阅状态从“挂起”更改为“活动”状态，或在认购终止时（最后一次通知）。
When a local policy dictates a maximum rate for notifications, a notifier will not generate notifications more frequently than the local policy maximum rate, even if the subscriber is not asking for maximum rate control. The notifier MAY inform the subscriber about such a local policy maximum rate using the "max-rate" Subscription-State header field parameter included in subsequent NOTIFY requests.
当本地策略指定通知的最大速率时，通知程序生成通知的频率不会高于本地策略的最大速率，即使订阅服务器未请求最大速率控制。通知者可以使用包括在后续通知请求中的“最大速率”订阅状态报头字段参数来通知订户这种本地策略最大速率。
Retransmissions of NOTIFY requests are not affected by the maximum rate mechanism, i.e., the maximum rate mechanism only applies to the generation of new transactions. In other words, the maximum rate mechanism does not in any way break or modify the normal retransmission mechanism specified in RFC 3261 [RFC3261].
NOTIFY请求的重新传输不受最大速率机制的影响，即最大速率机制仅适用于新事务的生成。换句话说，最大速率机制不会以任何方式破坏或修改RFC 3261[RFC3261]中规定的正常重传机制。
Special care needs to be taken when selecting the maximum rate. For example, the maximum rate could potentially set a minimum time value between notifications that exceeds the subscription expiration value. Such a configuration would effectively quench the notifier, resulting in exactly two notifications being generated. 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. According to RFC 3265 [RFC3265], the notifier may also shorten the subscription expiry anytime during an active subscription. 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.
选择最大速率时需要特别小心。例如，最大速率可能会设置超过订阅过期值的通知之间的最小时间值。这样的配置将有效地终止通知程序，从而恰好生成两个通知。如果订阅服务器请求的最大速率将导致在订阅到期之前没有通知，则通知程序必须增加最大速率并将其设置为剩余订阅到期时间的倒数值。根据RFC 3265[RFC3265]，通知程序还可以在活动订阅期间随时缩短订阅到期时间。如果在活动订阅期间缩短订阅到期时间，通知程序还必须增加“最大速率”值，并将其设置为缩短订阅到期时间的倒数值。
In some cases, it makes sense to temporarily pause the notification stream on an existing subscription dialog without terminating the subscription, e.g., due to inactivity on the application user interface. Whenever a subscriber discovers the need to perform the notification pause operation, it SHOULD set the maximum rate to the reciprocal value of the remaining subscription expiration value. This results in receiving no further notifications until the subscription expires or the subscriber sends a SUBSCRIBE request resuming notifications.
在某些情况下，暂时暂停现有订阅对话框上的通知流而不终止订阅是有意义的，例如，由于应用程序用户界面上的不活动。每当订户发现需要执行通知暂停操作时，应将最大速率设置为剩余订阅到期值的倒数值。这将导致在订阅过期或订阅服务器发送订阅请求恢复通知之前，不会再收到任何通知。
The notifier MAY decide to increase or decrease the proposed "max-rate" value by the subscriber based on its local policy, static configuration, or other implementation-determined constraints. In addition, different event packages MAY define other constraints for the allowed maximum rate ranges. Such constraints are out of the scope of this specification.
通知程序可根据其本地策略、静态配置或其他实现确定的约束，决定增加或减少订阅者提出的“最大速率”值。此外，不同的事件包可能会为允许的最大速率范围定义其他约束。此类约束超出本规范的范围。
When applied to a list subscription [RFC4662], the maximum rate mechanism has some additional considerations. Specifically, the maximum rate applies to the aggregate notification stream resulting from the list subscription, rather than explicitly controlling the notification of each of the implied constituent events. Moreover, the RLS can use the maximum rate mechanism on its own to control the rate of the back-end subscriptions to avoid overflowing its buffer.
当应用于列表订阅[RFC4662]时，最大速率机制还有一些额外的注意事项。具体而言，最大速率应用于由列表订阅产生的聚合通知流，而不是显式控制每个隐含组成事件的通知。此外，RLS可以单独使用最大速率机制来控制后端订阅的速率，以避免其缓冲区溢出。
The notifier is responsible for sending event notifications upon state changes of the subscribed resource. We can model the notifier as consisting of four components: the event state resource(s), the
通知程序负责在订阅资源的状态更改时发送事件通知。我们可以将通知程序建模为由四个组件组成：事件状态资源、
RLS (or any other notifier), a notification buffer, and finally the subscriber, or watcher of the event state, as shown in Figure 1.
RLS（或任何其他通知程序）、通知缓冲区，最后是事件状态的订阅者或观察者，如图1所示。
+--------+
| Event |
+--------+ |Resource| +--------+
| Event | +--------+ | Event |
|Resource| | |Resource|
+---.=---+ | +---=----+
`-.. | _.--'
``-._ | _.--'
+'--'--'-+
|Resource|
| List |
| Server |
+---.----+
|
|
)--+---(
| | .--------.
|Buffer|<======'max-rate|
| | `--------'
)--.---(
|
|
.---+---.
| Event |
|Watcher|
`-------'
+--------+
| Event |
+--------+ |Resource| +--------+
| Event | +--------+ | Event |
|Resource| | |Resource|
+---.=---+ | +---=----+
`-.. | _.--'
``-._ | _.--'
+'--'--'-+
|Resource|
| List |
| Server |
+---.----+
|
|
)--+---(
| | .--------.
|Buffer|<======'max-rate|
| | `--------'
)--.---(
|
|
.---+---.
| Event |
|Watcher|
`-------'
Figure 1: Model for the RLS Supporting Event Rate Control
图1：支持事件速率控制的RLS模型
In short, the RLS reads event state changes from the event state resource, either by creating a back-end subscription or by other means; it packages them into event notifications and submits them into the output buffer. The rate at which this output buffer drains is controlled by the subscriber via the maximum rate mechanism. When a set of notifications are batched together, the way in which overlapping resource state is handled depends on the type of the resource state:
简言之，RLS通过创建后端订阅或通过其他方式从事件状态资源读取事件状态更改；它将它们打包到事件通知中，并将它们提交到输出缓冲区中。订户通过最大速率机制控制此输出缓冲区耗尽的速率。将一组通知批处理在一起时，处理重叠资源状态的方式取决于资源状态的类型：
In theory, there are many buffer policies that the notifier could implement. However, we only concentrate on two practical buffer policies in this specification, leaving additional ones for further study and out of the scope of this specification. These two buffer policies depend on the mode in which the notifier is operating.
理论上，通知程序可以实现许多缓冲区策略。然而，在本规范中，我们只关注两个实际的缓冲区策略，留下更多的缓冲区策略供进一步研究，超出了本规范的范围。这两个缓冲区策略取决于通知程序的操作模式。
Full-state: Last (most recent) full-state notification of each resource is sent out, and all others in the buffer are discarded. This policy applies to those event packages that carry full-state notifications.
完全状态：发送每个资源的最后（最近）完全状态通知，并丢弃缓冲区中的所有其他资源。此策略适用于携带完整状态通知的事件包。
Partial-state: The state deltas of each buffered partial notification per resource are merged, and the resulting notification is sent out. This policy applies to those event packages that carry partial-state notifications.
部分状态：合并每个资源的每个缓冲部分通知的状态增量，并发送结果通知。此策略适用于那些带有部分状态通知的事件包。
With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. The notifier will always need to keep both a copy of the current full state of the resource F, as well as the last successfully communicated full state view F' of the resource in a specific subscription. The construction of a partial notification then involves creating a difference of the two states, and generating a notification that contains that difference.
对于部分通知，通知程序需要为每个订阅服务器维护一个单独的缓冲区，因为每个订阅服务器的最大通知速率可能有不同的值。通知程序将始终需要保留资源F当前完整状态的副本，以及特定订阅中最后一次成功通信的资源完整状态视图F'。然后，构建部分通知涉及创建两个状态的差异，并生成包含该差异的通知。
When the maximum rate mechanism is applied to the subscription, it is important that F' be replaced with F only when the difference of F and F' is already included in a partial-state notification to the subscriber allowed by the maximum rate mechanism. Additionally, the notifier implementation SHOULD check to see that the size of an accumulated partial state notification is smaller than the full state, and if not, the notifier SHOULD send the full-state notification instead.
当最大速率机制应用于订阅时，重要的是，只有在最大速率机制允许的向订阅方发送的部分状态通知中已包含F和F的差异时，才将F'替换为F'。此外，通知程序实现应检查累积部分状态通知的大小是否小于完整状态，如果不是，则通知程序应改为发送完整状态通知。
With full-state notifications, the notifier only needs to keep the full state of the resource, and when that changes, send the resulting notification to the subscriber.
对于完整状态通知，通知程序只需要保持资源的完整状态，当状态发生变化时，将结果通知发送给订阅服务器。
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 is a pending notification, the notifier simply replaces that notification with the new notification, discarding the older state.
当最大速率机制应用于订阅时，通知程序接收资源的状态更改并生成通知。如果存在挂起的通知，通知程序只需将该通知替换为新通知，即放弃旧状态。
It is difficult to estimate the total bandwidth savings accrued by using the maximum rate mechanism over a subscription, since such estimates will vary depending on the usage scenarios. However, it is easy to see that given a subscription where several full-state notifications would have normally been sent in any given interval set by the "max-rate" parameter, only a single notification is sent during the same interval when using the maximum rate mechanism, yielding bandwidth savings of several times the notification size.
很难估计通过在订阅上使用最大速率机制所累积的总带宽节省，因为这种估计将根据使用场景而有所不同。但是，很容易看出，如果订阅中的多个完整状态通知通常在“max-rate”参数设置的任何给定间隔内发送，则在使用最大速率机制时，在相同间隔内只发送一个通知，从而节省了通知大小几倍的带宽。
With partial-state notifications, drawing estimates is further complicated by the fact that the states of consecutive updates may or may not overlap. However, even in the worst-case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update. In this case, the bandwidth savings are approximately n times the size of the header fields of the NOTIFY request.
对于部分状态通知，连续更新的状态可能重叠，也可能不重叠，这使得图形估计更加复杂。但是，即使在最坏的情况下，每个部分更新都是完整状态的不同部分，合并所有这n个部分状态的速率控制通知的最大大小也应为完整状态更新的大小。在这种情况下，带宽节省大约是NOTIFY请求的报头字段大小的n倍。
It is also true that there are several compression schemes available that have been designed to save bandwidth in SIP, e.g., SigComp [RFC3320] and TLS compression [RFC3943]. However, such compression schemes are complementary rather than competing mechanisms to the maximum rate mechanism. After all, they can both be applied simultaneously.
还有一些压缩方案是为节省SIP中的带宽而设计的，例如SigComp[RFC3320]和TLS压缩[RFC3943]。然而，这种压缩方案是最大速率机制的补充机制而不是竞争机制。毕竟，它们可以同时应用。
A subscriber that wishes 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. The value of this parameter 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.
请注意，第9.2节中的语法将该值限制在0.0000000001和99.99999999之间。零不是允许的值。
A subscriber that wishes 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.
希望更新先前约定的最低通知速率的订户必须在后续订阅请求或对通知请求的2xx响应中包含更新的“最小速率”事件标头字段参数。
A subscriber that wishes to remove the minimum rate control from notifications MUST indicate so by not including a "min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
希望从通知中删除最低速率控制的订阅者必须通过在后续订阅请求或对通知请求的2xx响应中不包含“最小速率”事件标头字段参数来表示。
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 current state of the notifier. However, RFC 5839 [RFC5839] defines a mechanism that allows suppression of a NOTIFY request or a NOTIFY request body if the state has not changed.
应用最小速率机制时，订户的主要结果是，即使通知程序的当前状态没有任何变化，它也可以接收通知。但是，RFC 5839[RFC5839]定义了一种机制，允许在状态未更改时抑制NOTIFY请求或NOTIFY请求正文。
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.
支持最小速率机制的通知程序必须从订阅请求或对通知请求的2xx响应中提取“最小速率”事件标头字段参数的值，并将其用作每秒建议的最小通知数。如第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 is adjusted accordingly.
符合要求的通知程序必须在后续通知请求的“最小速率”订阅状态标头字段参数中反映可能调整的最小通知速率。通知程序采用指示的“最小速率”值，并相应调整通知速率。
A notifier that does not understand this extension will not reflect the "min-rate" Subscription-State header field parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
不理解此扩展的通知程序不会在通知请求中反映“最小速率”订阅状态标头字段参数；缺少此参数表示订阅服务器不支持通知程序的速率控制。
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 subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a 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 if the state has not changed from the previous notification.
当发生状态更改或自最近一次通知起的时间超过“最小速率”参数的倒数值时，符合要求的通知程序必须生成通知。根据订阅请求中指示的事件包和订阅者首选项，作为最低速率机制的结果发送的通知请求必须包含当前完全状态或显示当前状态与上次成功通信状态之间差异的部分状态。如果订户和通知程序支持RFC 5839[RFC5839]中的程序，则如果状态没有改变，则可以抑制完整的通知请求或通知请求正文。
Retransmissions of NOTIFY requests are not affected by the minimum rate mechanism, i.e., the minimum rate mechanism only applies to the generation of new transactions. In other words, the minimum rate mechanism does not in any way break or modify the normal retransmission mechanism.
NOTIFY请求的重新传输不受最小速率机制的影响，即，最小速率机制仅适用于新事务的生成。换句话说，最小速率机制不会以任何方式破坏或修改正常的重传机制。
The minimum rate mechanism can be used to generate a lot of notifications, creating additional processing load for the notifier. Some of the notifications may also be unnecessary possibly repeating already known state information to the subscriber. It is difficult to provide generic guidelines for the acceptable minimum rate value ranges; however, the subscriber SHOULD request the lowest possible minimum rate. Different event packages MAY define other constraints for the allowed minimum rate values. Such constraints are out of the scope of this specification.
最小速率机制可用于生成大量通知，从而为通知程序创建额外的处理负载。一些通知也可能是不必要的，可能会向订阅者重复已经知道的状态信息。很难为可接受的最小速率值范围提供通用指南；但是，用户应请求尽可能低的最低费率。不同的事件包可能会为允许的最小速率值定义其他约束。此类约束超出本规范的范围。
The notifier MAY decide to increase or decrease the proposed "min-rate" value by the subscriber based on its local policy, static configuration, or other implementation-determined constraints.
通知程序可根据其本地策略、静态配置或其他实现确定的约束，决定增加或减少订阅者提出的“最小速率”值。
A subscriber that wishes to apply an adaptive minimum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the "adaptive-min-rate" Event header field parameter. This parameter specifies an adaptive minimum number of notifications per second. The value of this parameter 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.
请注意，第9.2节中的语法将该值限制在0.0000000001和99.99999999之间。零不是允许的值。
A subscriber that wishes to update the previously agreed adaptive minimum rate of notifications MUST include the updated "adaptive-min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
希望更新先前约定的自适应最小通知速率的订阅服务器必须在后续订阅请求或对通知请求的2xx响应中包含更新的“自适应最小速率”事件标头字段参数。
A subscriber that wishes to remove the adaptive minimum rate control from notifications MUST indicate so by not including an "adaptive-min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
希望从通知中删除自适应最小速率控制的订户必须通过在后续订阅请求或对通知请求的2xx响应中不包含“自适应最小速率”事件标头字段参数来表示。
The main consequence for the subscriber when applying the adaptive minimum rate mechanism is that it can receive a notification, even if nothing has changed in the current state of the notifier. However, RFC 5839 [RFC5839] defines a mechanism that allows suppression of a NOTIFY request or a NOTIFY request body if the state has not changed.
应用自适应最小速率机制时，订户的主要结果是，即使通知程序的当前状态没有任何变化，它也可以接收通知。但是，RFC 5839[RFC5839]定义了一种机制，允许在状态未更改时抑制NOTIFY请求或NOTIFY请求正文。
A notifier that supports the adaptive minimum rate mechanism MUST extract the value of the "adaptive-min-rate" Event header parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request and use it to calculate the actual maximum time between two notifications, as defined in Section 7.4.
支持自适应最小速率机制的通知程序必须从订阅请求或对通知请求的2xx响应中提取“自适应最小速率”事件头参数的值，并使用它计算两次通知之间的实际最长时间，如第7.4节所定义。
The "adaptive-min-rate" value can be adjusted by the notifier, as defined in Section 7.3.
“自适应最小速率”值可由通知程序进行调整，如第7.3节所述。
A compliant notifier MUST reflect back the possibly adjusted adaptive minimum rate of notifications in an "adaptive-min-rate" Subscription-State header field parameter of the subsequent NOTIFY requests. The indicated "adaptive-min-rate" value is adopted by the notifier, and the notification rate is adjusted accordingly.
符合要求的通知程序必须在后续通知请求的“自适应最小速率”订阅状态标头字段参数中反映可能调整的自适应最小通知速率。通知程序采用指示的“自适应最小速率”值，并相应调整通知速率。
A notifier that does not understand this extension will not reflect the "adaptive-min-rate" Subscription-State header parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
不理解此扩展的通知程序不会在通知请求中反映“自适应最小速率”订阅状态标头参数；缺少此参数表示订阅服务器不支持通知程序的速率控制。
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 formula defined in Section 7.4. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a 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 if the state has not changed from the previous notification.
当状态发生变化或自最近一次通知以来的时间超过使用第7.4节中定义的公式计算的值时，符合要求的通知程序必须生成通知。根据订阅请求中指示的事件包和订阅者首选项，作为最低速率机制的结果发送的通知请求必须包含当前完全状态或显示当前状态与上次成功通信状态之间差异的部分状态。如果订户和通知程序支持RFC 5839[RFC5839]中的程序，则如果状态没有改变，则可以抑制完整的通知请求或通知请求正文。
The adaptive minimum rate mechanism is implemented as follows:
自适应最小速率机制的实现如下：
1) When a subscription is first created, the notifier creates a record ("count" parameter) that keeps track of the number of notifications that have been sent in the "period". The "count" parameter is initialized to contain a history of having sent a "period * adaptive-min-rate" number of notifications for the "period".
1) 首次创建订阅时，通知程序将创建一条记录（“计数”参数），用于跟踪在“期间”内发送的通知数。“count”参数初始化为包含已发送“period*adaptive min rate”数量的“period”通知的历史记录。
2) The "timeout" value is calculated according to the equation given in Section 7.4.
2) 根据第7.4节给出的公式计算“超时”值。
3) If the timeout period passes without a NOTIFY request being sent in the subscription, then the current resource state is sent (subject to any filtering associated with the subscription).
3) 如果在订阅中未发送NOTIFY请求的情况下超时，则会发送当前资源状态（受与订阅相关联的任何筛选的约束）。
4) Whenever a NOTIFY request is sent (regardless of whether due to a "timeout" event or a state change), the notifier updates the notification history record stored in the "count" parameter, recalculates the value of "timeout", and returns to step 3.
4) 无论何时发送通知请求（无论是由于“超时”事件还是状态更改），通知程序都会更新存储在“计数”参数中的通知历史记录，重新计算“超时”的值，并返回步骤3。
Retransmissions of NOTIFY requests are not affected by the timeout, i.e., the timeout only applies to the generation of new transactions. In other words, the timeout does not in any way break or modify the normal retransmission mechanism specified in RFC 3261 [RFC3261].
NOTIFY请求的重新传输不受超时的影响，即超时仅适用于新事务的生成。换句话说，超时不会以任何方式中断或修改RFC 3261[RFC3261]中指定的正常重传机制。
The adaptive minimum rate mechanism can be used to generate a lot of notifications, creating additional processing load for the notifier. Some of the notifications may also be unnecessary, possibly repeating already known state information to the subscriber. It is difficult to provide generic guidelines for the acceptable adaptive minimum rate value ranges; however, the subscriber SHOULD request the lowest possible adaptive minimum rate value. Different event packages MAY define other constraints for the allowed adaptive minimum rate values. Such constraints are out of the scope of this specification.
自适应最小速率机制可用于生成大量通知，从而为通知程序创建额外的处理负载。一些通知也可能是不必要的，可能会向订阅者重复已经知道的状态信息。很难为可接受的自适应最小速率值范围提供通用指南；但是，订户应请求最低可能的自适应最小速率值。不同的事件包可能会为允许的自适应最小速率值定义其他约束。此类约束超出本规范的范围。
The notifier MAY decide to increase or decrease the proposed "adaptive-min-rate" value based on its local policy, static configuration, or other implementation-determined constraints.
通知程序可根据其本地策略、静态配置或其他实现确定的约束，决定增加或减少建议的“自适应最小速率”值。
The formula used to vary the absolute pacing in a way that will meet the adaptive minimum rate requested over the period is given in equation (1):
方程式（1）中给出了用于改变绝对起搏的公式，该公式将满足整个周期内要求的自适应最小速率：
timeout = count / ((adaptive-min-rate ^ 2) * period) (1)
timeout = count / ((adaptive-min-rate ^ 2) * period) (1)
The output of the formula, "timeout", is the time to the next notification, expressed in seconds. The formula has three inputs:
公式“timeout”的输出是到下一个通知的时间，以秒表示。该公式有三个输入：
adaptive-min-rate: The value of the "adaptive-min-rate" parameter conveyed in the Subscription-State header field.
自适应最小速率：订阅状态标头字段中传递的“自适应最小速率”参数的值。
period: The rolling average period, in seconds. The granularity of the values for the "period" parameter is set by local policy at the notifier; however, the notifier MUST choose a value greater than the reciprocal value of the "adaptive-min-rate" parameter. It is also RECOMMENDED that the notifier choose a "period" parameter several times larger than reciprocal value of the "adaptive-min-rate" parameter in order to maximize the effectiveness of equation (1). It is an implementation decision whether the notifier uses the same value of the "period" parameter for all subscriptions or individual values for each subscription.
周期：滚动平均周期，以秒为单位。“period”参数值的粒度由通知程序的本地策略设置；但是，通知程序必须选择一个大于“自适应最小速率”参数倒数值的值。还建议通知者选择一个比“自适应最小速率”参数倒数值大几倍的“周期”参数，以最大化等式（1）的有效性。通知程序是为所有订阅使用相同的“period”参数值，还是为每个订阅使用单独的值，这是一个实现决策。
count: The number of notifications that have been sent during the last "period" of seconds, not including any retransmissions of requests.
计数：在最后几秒的“时间段”内发送的通知数，不包括请求的任何重新传输。
In case both the maximum rate and the adaptive minimum rate mechanisms are used in the same subscription, the formula used to dynamically calculate the timeout is given in equation (2):
如果在同一订阅中同时使用最大速率和自适应最小速率机制，则用于动态计算超时的公式在等式（2）中给出：
timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2)
timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2)
max-rate: The value of the "max-rate" parameter conveyed in the Subscription-State header field.
最大速率：订阅状态标头字段中传递的“最大速率”参数的值。
The formula in (2) makes sure that for all the possible values of the "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min-rate" < "max-rate", the timeout never results in a lower value than the reciprocal value of the "max-rate" parameter.
（2）中的公式确保对于“最大速率”和“自适应最小速率”参数的所有可能值，“自适应最小速率”<“最大速率”，超时不会导致低于“最大速率”参数倒数值的值。
In some situations, it may be beneficial for the notifier to achieve an adaptive minimum rate in a different way than the algorithm detailed in this document allows. However, the notifier MUST comply with any "max-rate" or "min-rate" parameters that have been negotiated.
在某些情况下，通知程序以不同于本文中详述的算法的方式实现自适应最小速率可能是有益的。但是，通知程序必须遵守已协商的任何“最大速率”或“最小速率”参数。
8. Usage of the Maximum Rate, Minimum Rate, and Adaptive Minimum Rate Mechanisms in a Combination
8. 组合使用最大速率、最小速率和自适应最小速率机制
Applications can subscribe to an event package using all the rate control mechanisms individually, or in combination; in fact there is no technical incompatibility among them. However, there are some combinations of the different rate control mechanisms that make little sense to be used together. This section lists all the combinations that are possible to insert in a subscription; the ability to use each combination in a subscription is also analyzed.
应用程序可以单独或组合使用所有速率控制机制订阅事件包；事实上，它们之间没有技术上的不兼容。然而，有一些不同的速率控制机制组合在一起使用没有什么意义。本节列出了可在订阅中插入的所有组合；还分析了在订阅中使用每个组合的能力。
maximum rate and minimum rate: This combination allows a reduced notification rate, but at the same time assures the reception of periodic notifications.
最大速率和最小速率：这种组合允许降低通知速率，但同时确保定期接收通知。
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 a value equal to or lower than the "max-rate" value.
订户应选择低于“最大速率”值的“最小速率”值，否则，通知程序必须将订户提供的“最小速率”值调整为等于或低于“最大速率”值的值。
maximum rate and adaptive minimum rate: It works in a similar way as the combination above, but with the difference that the interval at which notifications are assured 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 a value equal to or lower than the "max-rate" value.
订户应选择低于“最大速率”值的“自适应最小速率”值，否则，通知程序必须将订户提供的“自适应最小速率”值调整为等于或低于“最大速率”值的值。
minimum rate and adaptive minimum rate: When using the adaptive minimum rate mechanism, frequent state changes in a short period can result in no notifications for a longer period following the short period. The addition of the minimum rate mechanism ensures that the subscriber always receives notifications after a specified interval.
最小速率和自适应最小速率：当使用自适应最小速率机制时，短时间内频繁的状态更改可能导致短时间后较长时间内没有通知。最小速率机制的添加确保订阅者总是在指定的时间间隔后收到通知。
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 combination makes little sense to be used, although it is not forbidden.
最大速率、最小速率和自适应最小速率：这种组合使用起来没有什么意义，尽管它不是禁止的。
A subscriber SHOULD choose a "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 a value 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.
用户应选择比“自适应最小速率”值低的“最小速率”值，否则通知器不必考虑“最小速率”值。
This section describes the protocol extensions required for the different rate control mechanisms.
本节介绍不同速率控制机制所需的协议扩展。
9.1. "max-rate", "min-rate", and "adaptive-min-rate" Header Field Parameters
9.1. “最大速率”、“最小速率”和“自适应最小速率”标题字段参数
The "max-rate", "min-rate", and "adaptive-min-rate" parameters are added to the rule definitions of the Event header field and the Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage of this parameter is described in Sections 5, 6, and 7.
“最大速率”、“最小速率”和“自适应最小速率”参数添加到RFC 3265[RFC3265]语法中事件头字段和订阅状态头字段的规则定义中。第5、6和7节介绍了此参数的用法。
This section describes the Augmented BNF [RFC5234] definitions for the new header field parameters. Note that we derive here from the ruleset present in RFC 3265 [RFC3265], adding additional alternatives to the alternative sets of "event-param" and "subexp-params" defined therein.
本节介绍新标头字段参数的扩充BNF[RFC5234]定义。注意，我们在这里从RFC 3265[RFC3265]中的规则集衍生而来，为其中定义的“事件参数”和“子表达式参数”的备选集添加了其他备选集。
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])
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])
This table expands the table described in Section 7.2 of RFC 3265 [RFC3265], allowing the Event header field to appear in a 2xx response to a NOTIFY request. The use of the Event header field in responses other than 2xx to NOTIFY requests is undefined and out of scope of this specification.
此表扩展了RFC 3265[RFC3265]第7.2节中所述的表，允许事件标题字段出现在对通知请求的2xx响应中。在响应（2xx除外）中使用事件头字段通知请求未定义，超出了本规范的范围。
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Event 2xx - - - - - - - - o
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Event 2xx - - - - - - - - o
A subscriber that wishes to update the previously agreed value for maximum, minimum, or adaptive minimum rate of notifications MUST include all desired values for the "max-rate", "min-rate", and "adaptive-min-rate" parameters in an Event header field of the 2xx response to a NOTIFY request. Any of the other header field
希望更新先前约定的最大、最小或自适应最小通知速率值的订户必须在对通知请求的2xx响应的事件标头字段中包含“最大速率”、“最小速率”和“自适应最小速率”参数的所有所需值。任何其他标题字段
parameters currently defined for the Event header field by other specifications do not have a meaning if the Event header field is included in the 2xx response to the NOTIFY request. These header field parameters MUST be ignored by the notifier, if present.
如果事件标题字段包含在对NOTIFY请求的2xx响应中，则当前由其他规范为事件标题字段定义的参数没有意义。通知程序必须忽略这些标头字段参数（如果存在）。
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.
对NOTIFY请求的2xx响应的event header字段中列出的事件类型必须与相应NOTIFY请求中的event header字段的事件类型匹配。
This specification 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.
本规范在“会话初始化协议（SIP）参数”注册表的“头字段参数和参数值”子注册表中注册了三个新的SIP头字段参数。
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]
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 specification also updates the reference defining the Event header field in the "Header Fields" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry.
本规范还更新了在“会话初始化协议（SIP）参数”注册表的“头字段”子注册表中定义事件头字段的引用。
Header Name compact Reference
----------- ------- ------------------
Event o [RFC3265][RFC6446]
Header Name compact Reference
----------- ------- ------------------
Event o [RFC3265][RFC6446]
Naturally, the security considerations listed in RFC 3265 [RFC3265], which the rate control mechanisms described in this document extends, apply in their entirety. In particular, authentication and message integrity SHOULD be applied to subscriptions with this extension.
当然，RFC 3265[RFC3265]中列出的安全注意事项（本文档中所述的速率控制机制对其进行了扩展）完全适用。特别是，应将身份验证和消息完整性应用于具有此扩展的订阅。
RFC 3265 [RFC3265] recommends the integrity protection of the Event header field of SUBSCRIBE requests. Implementations of this extension SHOULD also provide integrity protection for the Event header field included in the 2xx response to the NOTIFY request. Without integrity protection, an eavesdropper could see and modify the Event header field, or it could manipulate the transmission of a 200 (OK) response to the NOTIFY request to suppress or flood notifications without the subscriber seeing what caused the problem.
RFC 3265[RFC3265]建议对订阅请求的事件头字段进行完整性保护。此扩展的实现还应为NOTIFY请求的2xx响应中包含的事件头字段提供完整性保护。在没有完整性保护的情况下，窃听者可能会看到并修改事件头字段，或者它可能会操纵对NOTIFY请求的200（OK）响应的传输，以抑制或淹没通知，而订阅者看不到问题的原因。
When the maximum rate mechanism involves partial-state notifications, the security considerations listed in RFC 5263 [RFC5263] apply in their entirety.
当最大速率机制涉及部分状态通知时，RFC 5263[RFC5263]中列出的安全注意事项将全部适用。
Thanks 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 support and/or review of this work.
感谢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和Ari Keranen对这项工作的支持和/或审查。
Thanks to Brian Rosen for 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 other feedback.
感谢Brian Rosen关于最小和自适应最小速率机制的想法，以及Adam Roach关于自适应最小速率机制和其他反馈算法的工作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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.
[RFC5263]Lonnfors，M.，Costa Requena，J.，Leppanen，E.，和H.Khartabil，“存在信息部分通知的会话启动协议（SIP）扩展”，RFC 5263，2008年9月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3320]Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC3680，2004年3月。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3842]Mahy，R.“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[RFC3857]Rosenberg，J.，“会话启动协议（SIP）的观察者信息事件模板包”，RFC3857，2004年8月。
[RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, November 2004.
[RFC3943]Friend，R.，“使用Lempel-Ziv-Stac（LZS）的传输层安全（TLS）协议压缩”，RFC 39432004年11月。
[RFC5839] Niemi, A. and D. Willis, Ed., "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.
[RFC5839]Niemi，A.和D.Willis，Ed.，“用于条件事件通知的会话启动协议（SIP）事件的扩展”，RFC 5839，2010年5月。
[RFC6447] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", RFC 6447, January 2012.
[RFC6447]Mahy，R.，Rosen，B.，和H.Tschofenig，“在会话启动协议（SIP）中过滤位置通知”，RFC 6447，2012年1月。
Authors' Addresses
作者地址
Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团Aki Niemi诺基亚邮政信箱407
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Krisztian Kiss Nokia 200 South Mathilda Ave Sunnyvale, CA 94086 US
美国加利福尼亚州桑尼维尔南玛蒂尔达大街200号克里斯蒂安之吻诺基亚94086
Phone: +1 650 391 5969
EMail: krisztian.kiss@nokia.com
Phone: +1 650 391 5969
EMail: krisztian.kiss@nokia.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
萨尔瓦托·洛雷托·爱立信·赫萨兰蒂11 Jorvas 02420芬兰
EMail: salvatore.loreto@ericsson.com
EMail: salvatore.loreto@ericsson.com