Network Working Group J. Rosenberg
Request for Comments: 3680 dynamicsoft
Category: Standards Track March 2004
Network Working Group J. Rosenberg
Request for Comments: 3680 dynamicsoft
Category: Standards Track March 2004
A Session Initiation Protocol (SIP) Event Package for Registrations
用于注册的会话启动协议（SIP）事件包
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
本文档定义了用于注册的会话启动协议（SIP）事件包。通过注册方法，SIP允许用户代理创建、修改和删除注册。管理员还可以更改注册以强制实施策略。因此，这些注册代表了网络中可以动态变化的状态。在许多情况下，用户代理希望收到此状态更改的通知。此事件包定义了一种机制，通过该机制，这些用户代理可以请求和获取此类通知。
Table of Contents
目录
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Usage Scenarios .............................................. 3
3.1. Forcing Re-Authentication .............................. 3
3.2. Composing Presence ..................................... 3
3.3. Welcome Notices ........................................ 4
4. Package Definition ........................................... 4
4.1. Event Package Name ..................................... 4
4.2. Event Package Parameters ............................... 5
4.3. SUBSCRIBE Bodies ....................................... 5
4.4. Subscription Duration .................................. 5
4.5. NOTIFY Bodies .......................................... 6
4.6. Notifier Processing of SUBSCRIBE Requests .............. 6
4.7. Notifier Generation of NOTIFY Requests ................. 7
4.7.1. The Registration State Machine ................. 7
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Usage Scenarios .............................................. 3
3.1. Forcing Re-Authentication .............................. 3
3.2. Composing Presence ..................................... 3
3.3. Welcome Notices ........................................ 4
4. Package Definition ........................................... 4
4.1. Event Package Name ..................................... 4
4.2. Event Package Parameters ............................... 5
4.3. SUBSCRIBE Bodies ....................................... 5
4.4. Subscription Duration .................................. 5
4.5. NOTIFY Bodies .......................................... 6
4.6. Notifier Processing of SUBSCRIBE Requests .............. 6
4.7. Notifier Generation of NOTIFY Requests ................. 7
4.7.1. The Registration State Machine ................. 7
4.7.2. Applying the state machine ..................... 9
4.8. Subscriber Processing of NOTIFY Requests ............... 9
4.9. Handling of Forked Requests ............................ 9
4.10. Rate of Notifications .................................. 10
4.11. State Agents ........................................... 10
5. Registration Information ..................................... 10
5.1. Structure of Registration Information .................. 10
5.2. Computing Registrations from the Document .............. 14
5.3. Example ................................................ 15
5.4. XML Schema ............................................. 16
6. Example Call Flow ............................................ 18
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SIP Event Package Registration ......................... 21
8.2. application/reginfo+xml MIME Registration .............. 22
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ......................... 23
9. References ................................................... 23
9.1. Normative References ................................... 23
9.2. Informative References ................................. 24
10. Contributors ................................................. 25
11. Acknowledgements ............................................. 25
12. Author's Address ............................................. 25
13. Full Copyright Statement ..................................... 26
4.7.2. Applying the state machine ..................... 9
4.8. Subscriber Processing of NOTIFY Requests ............... 9
4.9. Handling of Forked Requests ............................ 9
4.10. Rate of Notifications .................................. 10
4.11. State Agents ........................................... 10
5. Registration Information ..................................... 10
5.1. Structure of Registration Information .................. 10
5.2. Computing Registrations from the Document .............. 14
5.3. Example ................................................ 15
5.4. XML Schema ............................................. 16
6. Example Call Flow ............................................ 18
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SIP Event Package Registration ......................... 21
8.2. application/reginfo+xml MIME Registration .............. 22
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ......................... 23
9. References ................................................... 23
9.1. Normative References ................................... 23
9.2. Informative References ................................. 24
10. Contributors ................................................. 25
11. Acknowledgements ............................................. 25
12. Author's Address ............................................. 25
13. Full Copyright Statement ..................................... 26
The Session Initiation Protocol (SIP) [1] provides all of the functions needed for the establishment and maintenance of communications sessions between users. One of the functions it provides is a registration operation. A registration is a binding between a SIP URI, called an address-of-record, and one or more contact URIs. These contact URIs represent additional resources that can be contacted in order to reach the user identified by the address-of-record. When a proxy receives a request within its domain of administration, it uses the Request-URI as an address-of-record, and uses the contacts bound to the address-of-record to forward (or redirect) the request.
会话发起协议（SIP）[1]提供了用户之间建立和维护通信会话所需的所有功能。它提供的功能之一是注册操作。注册是SIPURI（称为记录地址）和一个或多个联系人URI之间的绑定。这些联系人URI表示可以联系的其他资源，以便联系记录地址标识的用户。当代理在其管理域内收到请求时，它使用请求URI作为记录地址，并使用绑定到记录地址的联系人转发（或重定向）请求。
The SIP REGISTER method provides a way for a user agent to manipulate registrations. Contacts can be added or removed, and the current set of contacts can be queried. Registrations can also change as a result of administrator policy. For example, if a user is suspected of fraud, their registration can be deleted so that they cannot receive any requests. Registrations also expire after some time if not refreshed.
SIP REGISTER方法为用户代理操作注册提供了一种方法。可以添加或删除联系人，也可以查询当前联系人集。注册也可能因管理员策略而更改。例如，如果用户涉嫌欺诈，可以删除其注册，使其无法接收任何请求。如果不刷新，注册也会在一段时间后过期。
Registrations represent a dynamic piece of state maintained by the network. There are many cases in which user agents would like to know about changes to the state of registrations. The SIP Events Framework [2] defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence [9], for example. This specification defines a package for registration state.
注册代表由网络维护的动态状态。在许多情况下，用户代理希望了解注册状态的更改。SIP事件框架[2]定义了一个通用框架，用于订阅和通知与SIP系统相关的事件。该框架定义了SUBSCRIBE和NOTIFY方法，并引入了包的概念。包是事件框架对特定事件类的具体应用。例如，已经为用户状态定义了包[9]。本规范定义了注册状态的包。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的描述进行解释，并指出合规实施的要求级别。
There are many applications of this event package. A few are documented here for illustrative purposes.
此事件包有许多应用程序。为了便于说明，这里记录了一些。
It is anticipated that many SIP devices will be wireless devices that will be always-on, and therefore, continually registered to the network. Unfortunately, history has shown that these devices can be compromised. To deal with this, an administrator will want to terminate or shorten a registration, and ask the device to re-register so it can be re-authenticated. To do this, the device subscribes to the registration event package for the address-of-record that it is registering contacts against. When the administrator shortens registration (for example, when fraud is suspected) the registration server sends a notification to the device. It can then re-register and re-authenticate itself. If it cannot re-authenticate, the expiration will terminate shortly thereafter.
可以预期，许多SIP设备将是无线设备，它们将始终处于开启状态，并因此持续地注册到网络。不幸的是，历史表明，这些设备可能受到危害。为了解决这个问题，管理员需要终止或缩短注册，并要求设备重新注册，以便重新验证。为此，设备向注册事件包订阅其注册联系人的记录地址。当管理员缩短注册时（例如，怀疑欺诈时），注册服务器将向设备发送通知。然后，它可以重新注册并重新验证自己。如果无法重新验证，则过期将在此后不久终止。
An important concept to understand is the relationship between this event package and the event package for user presence [9]. User presence represents the willingness and ability of a user to communicate with other users on the network. It is composed of a set of contact addresses that represent the various means for contacting the user. Those contact addresses might represent the contact address for voice, for example. Typically, the contact address
需要理解的一个重要概念是此事件包与用户状态事件包之间的关系[9]。用户在场表示用户与网络上其他用户通信的意愿和能力。它由一组联系人地址组成，代表联系用户的各种方式。例如，这些联系人地址可能代表语音的联系人地址。通常，联系人地址
listed for voice will be an address-of-record. The status of that contact (whether its open or closed) may depend on any number of factors, including the state of any registrations against that address-of-record. As a result, registration state can be viewed as an input to the process which determines the presence state of a user. Effectively, registration state is "raw" data, which is combined with other information about a user to generate a document that describes the user's presence.
为语音列出的将是记录地址。该联系人的状态（无论其打开还是关闭）可能取决于许多因素，包括该记录地址的任何注册状态。结果，注册状态可被视为确定用户的存在状态的过程的输入。实际上，注册状态是“原始”数据，它与关于用户的其他信息相结合，以生成描述用户存在的文档。
In fact, this event package allows for a presence server to be separated from a SIP registration server, yet still use registration information to construct a presence document. When a presence server receives a presence subscription for some user, the presence server itself would generate a subscription to the registration server for the registration event package. As a result, the presence server would learn about the registration state for that user, and it could use that information to generate presence documents.
事实上，此事件包允许状态服务器与SIP注册服务器分离，但仍然使用注册信息来构造状态文档。当状态服务器接收到某个用户的状态订阅时，状态服务器本身将为注册事件包生成对注册服务器的订阅。因此，状态服务器将了解该用户的注册状态，并可以使用该信息生成状态文档。
A common service in current mobile networks are "welcome notices". When the user turns on their phone in a foreign country, they receive a message that welcomes them to the country, and provides information on transportation services, for example.
当前移动网络中的一种常见服务是“欢迎通知”。例如，当用户在国外打开手机时，他们会收到一条欢迎他们到该国的信息，并提供有关交通服务的信息。
In order to implement this service in a SIP system, an application server can subscribe to the registration state of the user. When the user turns on their phone, the phone will generate a registration. This will result in a notification being sent to the application that the user has registered. The application can then send a SIP MESSAGE request [10] to the device, welcoming the user and providing any necessary information.
为了在SIP系统中实现该服务，应用服务器可以订阅用户的注册状态。当用户打开手机时，手机将生成注册。这将导致向用户已注册的应用程序发送通知。然后，应用程序可以向设备发送SIP消息请求[10]，欢迎用户并提供任何必要的信息。
This section fills in the details needed to specify an event package as defined in Section 4.4 of [2].
本节填写了指定[2]第4.4节中定义的事件包所需的详细信息。
The SIP Events specification requires package definitions to specify the name of their package or template-package.
SIP事件规范要求包定义指定其包或模板包的名称。
The name of this package is "reg". As specified in [2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.
此软件包的名称为“reg”。如[2]所述，此值出现在SUBSCRIBE和NOTIFY请求中的事件头中。
Example:
例子：
Event: reg
活动：注册
The SIP Events specification requires package and template-package definitions to specify any package specific parameters of the Event header that are used by it.
SIP事件规范要求包和模板包定义指定它所使用的事件头的任何包特定参数。
No package specific Event header parameters are defined for this event package.
没有为此事件包定义包特定的事件头参数。
The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
SIP事件规范要求包或模板包定义来定义订阅请求中主体的用法（如果有）。
A SUBSCRIBE for registration events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification.
订阅注册事件可能包含正文。该机构将用于筛选订阅。此类主体的定义不在本规范的范围内。
A SUBSCRIBE for the registration package MAY be sent without a body. This implies that the default registration filtering policy has been requested. The default policy is:
注册包的订阅可以在没有正文的情况下发送。这意味着已请求默认注册筛选策略。默认策略为：
o Notifications are generated every time there is any change in the state of any of the registered contacts for the resource being subscribed to. Those notifications only contain information on the contacts whose state has changed.
o 每当所订阅资源的任何已注册联系人的状态发生任何更改时，都会生成通知。这些通知仅包含状态已更改的联系人的信息。
o Notifications triggered from a SUBSCRIBE contain full state (the list of all contacts bound to the address-of-record).
o 从订阅触发的通知包含完整状态（绑定到记录地址的所有联系人的列表）。
Of course, the server can apply any policy it likes to the subscription.
当然，服务器可以对订阅应用它喜欢的任何策略。
The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
SIP事件规范要求包定义定义订阅持续时间的默认值，并讨论明确指定持续时间时的合理选择。
Registration state changes as contacts are created through REGISTER requests, and then time out due to lack of refresh. Their rate of change is therefore related to the typical registration expiration. Since the default expiration for registrations is 3600 seconds, the
通过注册请求创建联系人时，注册状态会发生更改，然后由于缺少刷新而超时。因此，它们的变化率与典型的注册到期时间有关。由于注册的默认过期时间为3600秒，因此
default duration of subscriptions to registration state is slightly longer, 3761 seconds. This helps avoid any potential problems with coupling of subscription and registration refreshes. Of course, clients MAY include an Expires header in the SUBSCRIBE request asking for a different duration.
注册状态订阅的默认持续时间稍长，为3761秒。这有助于避免订阅和注册刷新耦合的任何潜在问题。当然，客户端可能会在订阅请求中包含一个Expires头，请求不同的持续时间。
The SIP Events specification requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header in the SUBSCRIBE request.
SIP事件规范要求包定义描述NOTIFY请求中允许的一组主体类型，并指定订阅请求中没有Accept标头时使用的默认值。
The body of a notification of a change in registration state contains a registration information document. This document describes some or all of the contacts associated with a particular address-of-record. All subscribers and notifiers MUST support the "application/reginfo+xml" format described in Section 5. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/reginfo+xml". If the header field is present, it MUST include "application/reginfo+xml", and MAY include any other types capable of representing registration information.
注册状态变更通知的正文包含注册信息文档。本文档描述了与特定记录地址相关的部分或全部联系人。所有订阅者和通知者必须支持第5节中描述的“应用程序/reginfo+xml”格式。订阅请求可能包含接受标头字段。如果不存在这样的头字段，则其默认值为“application/reginfo+xml”。如果存在标题字段，则它必须包括“application/reginfo+xml”，并且可以包括能够表示注册信息的任何其他类型。
Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request.
当然，服务器生成的通知必须采用订阅请求中Accept header字段中指定的格式之一。
The SIP Events framework specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization.
SIP事件框架指定包应该在通知程序中定义订阅请求的任何包特定处理，特别是关于身份验证和授权。
Registration state can be sensitive information. Therefore, all subscriptions to it SHOULD be authenticated and authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [1]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
注册状态可能是敏感信息。因此，对它的所有订阅都应该在批准之前经过身份验证和授权。可以使用通过SIP可用的任何技术来执行认证，包括摘要、S/MIME、TLS或其他特定于传输的机制[1]。与往常一样，授权策略由管理员自行决定。然而，可以提出一些建议。
It is RECOMMENDED that a user be allowed to subscribe to their own registration state. Such subscriptions are useful when there are many devices that represent a user, each of which needs to learn the registration state of the other devices. We also anticipate that applications and automata will frequently be subscribers to the
建议允许用户订阅自己的注册状态。当有许多设备代表一个用户时，这样的订阅很有用，每个设备都需要了解其他设备的注册状态。我们还预计应用程序和自动机将经常成为
registration state. In those cases, authorization policy will typically be provided ahead of time.
注册国。在这些情况下，通常会提前提供授权策略。
The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed.
SIP事件框架请求包指定为该包发送通知的条件，以及如何构造此类通知。
To determine when a notifier should send notifications of changes in registration state, we define a finite state machine (FSM) that represents the state of a contact for a particular address-of-record. Transitions in this state machine MAY result in the generation of notifications. These notifications will carry information on the new state and the event which triggered the state change. It is important to note that this FSM is just a model of the registration state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
为了确定通知程序何时应该发送注册状态更改的通知，我们定义了一个有限状态机（FSM），它表示特定记录地址的联系人状态。此状态机中的转换可能导致生成通知。这些通知将包含有关新状态和触发状态更改的事件的信息。需要注意的是，此FSM只是由服务器维护的注册状态机制的一个模型。实现将以特定于实现的方式将自己的状态机映射到此状态机。
The underlying state machine for a registration is shown in Figure 1. The machine is very simple. An instance of this machine is associated with each address-of-record. When there are no contacts registered to the address-of-record, the state machine is in the init state. It is important to note that this state machine exists, and is well-defined, for each address-of-record in the domain, even if there are no contacts registered to it. This allows a user agent to subscribe to an address-of-record, and learn that there are no contacts registered to it. When the first contact is registered to that address-of-record, the state machine moves from init to active.
注册的底层状态机如图1所示。这台机器很简单。此计算机的一个实例与记录的每个地址相关联。当没有联系人注册到记录地址时，状态机处于初始状态。请务必注意，对于域中的每个记录地址，即使没有向其注册联系人，该状态机仍然存在，并且定义良好。这允许用户代理订阅记录地址，并了解到没有联系人注册到该地址。当第一个联系人注册到该记录地址时，状态机从init移动到active。
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
Figure 1: Registration State Machine
图1：注册状态机
As long as there is at least one contact bound to the address-of-record, the state machine remains in the active state. When the last contact expires or is removed, the registration transitions to terminated. From there, it immediately transitions back to the init state. This transition is invisible, in that it MUST NOT ever be reported to a subscriber in a NOTIFY request.
只要至少有一个联系人绑定到记录地址，状态机就会保持活动状态。当最后一个联系人过期或被删除时，注册转换为终止。从那里，它立即转换回init状态。此转换是不可见的，因为它决不能在NOTIFY请求中报告给订阅者。
This allows for an implementation optimization whereby the registrar can destroy the objects associated with the registration state machine once it enters the terminated state and a NOTIFY has been sent. Instead, the registrar can assume that, if the objects for that state machine no longer exist, the state machine is in the init state.
这允许实现优化，其中一旦进入终止状态并发送通知，注册器就可以销毁与注册状态机关联的对象。相反，注册器可以假设，如果该状态机的对象不再存在，则该状态机处于init状态。
In addition to this state machine, each registration is associated with a set of contacts, each of which is modeled with its own state machine. Unlike the FSM for the address-of-record, which exists even when no contacts are registered, the per-contact FSM is instantiated when the contact is registered, and deleted when it is removed. The diagram for the per-contact state machine is shown in Figure 2. This FSM is identical to the registration state machine in terms of its states, but has many more transition events.
除了这个状态机之外，每个注册都与一组联系人相关联，每个联系人都用自己的状态机建模。与记录地址的FSM（即使未注册联系人也存在）不同，每个联系人的FSM在注册联系人时实例化，在删除联系人时删除。每个触点状态机的图如图2所示。此FSM在状态方面与注册状态机相同，但有更多的转换事件。
When a new contact is added, the FSM for it is instantiated, and it moves into the active state. Because of that, the init state here is transient. There are two ways in which it can become active. One is
添加新联系人时，该联系人的FSM将被实例化，并进入活动状态。因此，这里的初始状态是瞬态的。有两种方式可以激活它。一是
through an actual SIP REGISTER request (corresponding to the registered event), and the other is when the contact is created administratively, or through some non-SIP means (the created event).
通过一个实际的SIP注册请求（对应于注册的事件），另一个是在管理上创建联系人时，或者通过一些非SIP方式（创建的事件）。
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
Figure 2: Contact State Machine
图2：接触状态机
The FSM remains in the active state so long as the contact is bound to the address-of-record. When a contact is refreshed through a REGISTER request, the FSM stays in the same state, but a refreshed event is generated. Likewise, when an administrator modifies the expiration time of a binding (without deleting the binding) to trigger the contact to re-register and possibly re-authenticate, the FSM stays in the active state, but a shortened event is generated.
只要联系人绑定到记录地址，FSM将保持活动状态。当通过注册请求刷新联系人时，FSM保持相同状态，但会生成刷新事件。同样，当管理员修改绑定的过期时间（不删除绑定）以触发联系人重新注册并可能重新验证时，FSM将保持活动状态，但会生成缩短的事件。
When the contact is no longer bound to the address-of-record, the FSM moves to the terminated state, and once a NOTIFY is sent, the state machine is destroyed. As a result, the terminated state is effectively transient. There are several reasons this can happen. The first is an expiration, which occurs when the contact was not refreshed by a REGISTER request. The second reason is deactivated. This occurs when the administrator has removed the contact as a valid binding, but still wishes the client to attempt to re-register the contact. In contrast, the rejected event occurs when an active contact is removed by the administrator, but re-registrations will not help to re-establish it. This might occur if a user does not pay their bills, for example. The probation event occurs when an active contact is removed by the administrator, and the administrator wants the client to re-register, but to do so at a later time. The unregistered event occurs when a REGISTER request sets the expiration time of that contact to zero.
当联系人不再绑定到记录地址时，FSM将移动到终止状态，一旦发送通知，状态机将被销毁。因此，终止状态实际上是瞬态的。发生这种情况有几个原因。第一个是过期，当联系人未通过注册请求刷新时发生。第二个原因已停用。当管理员已将该联系人作为有效绑定删除，但仍希望客户端尝试重新注册该联系人时，就会发生这种情况。相反，当管理员删除活动联系人时，会发生拒绝事件，但重新注册无助于重新建立该联系人。例如，如果用户不支付账单，可能会发生这种情况。如果管理员删除了活动联系人，并且管理员希望客户端重新注册，但以后再注册，则会发生试用事件。当注册请求将该联系人的过期时间设置为零时，将发生未注册事件。
The server MAY generate a notification to subscribers when any event occurs in either the address-of-record or per-contact state machines, except for the transition from terminated to init in the address-of-record state machine. As noted above, a notification MUST NOT be sent in this case. For other transitions, whether the server sends a notification or not is policy dependent. However, several guidelines are defined.
当记录状态机地址或每个联系人状态机中发生任何事件时，服务器可能会向订阅者生成通知，记录状态机地址中从terminated到init的转换除外。如上所述，在这种情况下不得发送通知。对于其他转换，服务器是否发送通知取决于策略。但是，定义了若干准则。
As a general rule, when a subscriber is authorized to receive notifications about a set of registrations, it is RECOMMENDED that notifications contain information about those contacts which have changed state (and thus triggered a notification), instead of delivering the current state of every contact in all registrations. However, notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all contacts for all registrations to be present in the NOTIFY.
作为一般规则，当订户被授权接收关于一组注册的通知时，建议通知中包含关于已更改状态（从而触发通知）的联系人的信息，而不是提供所有注册中每个联系人的当前状态。但是，由于提取操作（过期时间为0的订阅）而触发的通知应导致所有联系人的完整状态，以便所有注册都出现在通知中。
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the NOTIFY will only contain information for contacts whose state has changed. To construct a coherent view of the total state of all registrations, the subscriber will need to combine NOTIFYs received over time. The details of this process depend on the document format used to convey registration state. Section 5 outlines the process for the application/reginfo+xml format.
SIP事件框架期望包指定订阅者如何以包特定的方式处理NOTIFY请求，特别是如何使用NOTIFY请求来构建订阅资源状态的一致视图。通常，“通知”仅包含状态已更改的联系人的信息。为了构建所有注册的总状态的一致视图，订阅者需要合并随时间接收的NOTIFY。此过程的细节取决于用于传达注册状态的文档格式。第5节概述了应用程序/reginfo+xml格式的过程。
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
SIP事件框架要求包指示分叉订阅请求是否可以安装多个订阅。
Registration state is normally stored in some repository (whether it be co-located with a proxy/registrar or in a separate database). As such, there is usually a single place where the contact information for a particular address-of-record is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to registration information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of the SIP Events framework [2].
注册状态通常存储在某个存储库中（无论是与代理/注册器位于同一位置，还是存储在单独的数据库中）。因此，通常只有一个地方记录了特定地址的联系信息。这意味着该信息的订阅可以由访问该存储库的单个元素轻松处理。因此，无需向fork订阅注册信息。因此，订阅者不能因为一个订阅请求而创建多个对话框。SIP事件框架[2]第4.4.9节描述了确保只建立单个对话框所需的处理。
The SIP Events framework mandates that packages define a maximum rate of notifications for their package.
SIP事件框架要求包定义其包的最大通知速率。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
出于拥塞控制的原因，重要的是通知速率不要过高。因此，建议服务器不要以超过每5秒一次的速度为单个订户生成通知。
The SIP Events framework asks packages to consider the role of state agents in their design.
SIP事件框架要求包考虑状态代理在其设计中的作用。
State agents have no role in the handling of this package.
州代理在处理此包中没有任何角色。
Registration information is an XML document [4] that MUST be well-formed and SHOULD be valid. Registration information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying registration information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
注册信息是一个XML文档[4]，必须格式正确且有效。注册信息文档必须基于XML 1.0，并且必须使用UTF-8编码。本规范使用XML名称空间来标识注册信息文档和文档片段。本规范定义的元素的名称空间URI是URN[5]，使用[6]定义的名称空间标识符“ietf”，并由[7]扩展。这个骨灰盒是：
urn:ietf:params:xml:ns:reginfo
urn:ietf:params:xml:ns:reginfo
A registration information document begins with the root element tag "reginfo". It consists of any number of "registration" sub-elements, each of which contains the registration state for a particular address-of-record. The registration information for a particular address-of-record MUST be contained within a single "registration" element; it cannot be spread across multiple "registration" elements within a document. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the "reginfo" element, both of which MUST be present:
注册信息文档以根元素标记“reginfo”开头。它由任意数量的“注册”子元素组成，每个子元素都包含特定记录地址的注册状态。特定记录地址的注册信息必须包含在单个“注册”元素中；它不能分布在文档中的多个“注册”元素中。出于可扩展性的目的，可能存在来自不同名称空间的其他元素；必须忽略未知名称空间中的元素或属性。有两个属性与“reginfo”元素关联，这两个属性都必须存在：
version: This attribute allows the recipient of registration information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a
版本：此属性允许注册信息文档的收件人正确排序。版本从0开始，发送到订阅服务器的每个新文档的版本增量为1。版本的作用域为
subscription. Versions MUST be representable using a 32 bit integer.
订阅版本必须使用32位整数表示。
state: This attribute indicates whether the document contains the full registration state, or whether it contains only information on those registrations which have changed since the previous document (partial).
状态：此属性指示文档是否包含完全注册状态，或者是否仅包含自上一个文档（部分）以来已更改的注册的信息。
Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. For example, a domain might define sip:allusers@example.com as a subscribable resource that generates notifications when the state of any address-of-record in the domain changes.
请注意，文档格式明确允许传递有关多个记录地址的信息。这允许订阅注册组，其中此类组由某种URI标识。例如，域可以定义sip：allusers@example.com作为可订阅资源，当域中任何记录地址的状态更改时生成通知。
The "registration" element has a list of any number of "contact" sub-elements, each of which contains information on a single contact. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are three attributes associated with the "registration" element, all of which MUST be present:
“registration”元素具有任意数量的“contact”子元素列表，每个子元素都包含关于单个联系人的信息。出于可扩展性的目的，可能存在来自不同名称空间的其他元素；必须忽略未知名称空间中的元素或属性。“注册”元素有三个相关属性，所有属性都必须存在：
aor: The aor attribute contains a URI which is the address-of-record this registration refers to.
aor：aor属性包含一个URI，该URI是此注册引用的记录的地址。
id: The id attribute identifies this registration. It MUST be unique amongst all other id attributes present in other registration elements conveyed to the subscriber within the scope of their subscription. In particular, if two URI identifying an address-of-record differ after their canonicalization according to the procedures in step 5 of Section 10.3 of RFC 3261 [1], the id attributes in the "registration" elements for those addresses-of-record MUST differ. Furthermore, the id attribute for a "registration" element for a particular address-of-record MUST be the same across all notifications sent within the subscription.
id:id属性标识此注册。它必须是在订阅范围内传递给订阅方的其他注册元素中存在的所有其他id属性中唯一的。特别是，如果根据RFC 3261[1]第10.3节第5步中的程序进行规范化后，标识记录地址的两个URI不同，则这些记录地址的“注册”元素中的id属性必须不同。此外，在订阅中发送的所有通知中，特定记录地址的“registration”元素的id属性必须相同。
state: The state attribute indicates the state of the registration. The valid values are "init", "active" and "terminated".
state：state属性表示注册的状态。有效值为“init”、“active”和“terminated”。
The "contact" element contains a "uri" element, an optional "display-name" element, and an optional "unknown-param" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "contact" element which MUST be present:
“contact”元素包含一个“uri”元素、一个可选的“display name”元素和一个可选的“unknown param”元素。出于可扩展性的目的，可能存在来自不同名称空间的其他元素；必须忽略未知名称空间中的元素或属性。必须存在与“contact”元素相关联的几个属性：
id: The id attribute identifies this contact. It MUST be unique amongst all other id attributes present in other contact elements conveyed to the subscriber within the scope of their subscription. In particular, if the URI for two contacts differ (based on the URI comparison rules in RFC 3261 [1]), the id attributes for those contacts MUST differ. However, unlike the id attribute for an address-of-record, if the URI for two contacts are the same, their id attributes SHOULD be the same across notifications. This requirement is at SHOULD strength, and not MUST strength, since it is difficult to compute such an id as a function of the URI without retaining additional state. No hash function applied to the URI can, in fact, meet a MUST requirement. This is because equality of the SIP URI is not transitive. However, a hash function which includes unknown URI parameters (that is, any not defined in RFC 3261), will always result in a value that is the different if two URI are different, and usually the same if the URI are equal.
id:id属性标识此联系人。它必须在订阅范围内传送给订阅者的其他联系人元素中存在的所有其他id属性中唯一。特别是，如果两个联系人的URI不同（基于RFC 3261[1]中的URI比较规则），则这些联系人的id属性必须不同。但是，与记录地址的id属性不同，如果两个联系人的URI相同，则它们的id属性在通知中应该相同。这个需求应该是强大的，而不是必须是强大的，因为在不保留额外状态的情况下，很难将这样一个id作为URI的函数来计算。实际上，应用于URI的哈希函数都不能满足必需的要求。这是因为SIPURI的相等性是不可传递的。但是，包含未知URI参数（即RFC 3261中未定义的任何参数）的哈希函数在两个URI不同时总是会产生不同的值，而在URI相等时通常会产生相同的值。
state: The state attribute indicates the state of the contact. The valid values are "active" and "terminated".
状态：状态属性表示联系人的状态。有效值为“活动”和“终止”。
event: The event attribute indicates the event which caused the contact state machine to go into its current state. Valid values are registered, created, refreshed, shortened, expired, deactivated, probation, unregistered and rejected.
事件：事件属性表示导致联系人状态机进入其当前状态的事件。有效值包括注册、创建、刷新、缩短、过期、停用、试用、取消注册和拒绝。
If the event attribute has a value of shortened, the "expires" attribute MUST be present. It contains an unsigned long integer which indicates the number of seconds remaining until the binding is due to expire. This attribute MAY be included with any event attribute value for which the state of the contact is active.
如果event属性的值为shorted，则必须存在“expires”属性。它包含一个无符号长整数，表示绑定到期前剩余的秒数。此属性可以包含在联系人状态为活动状态的任何事件属性值中。
If the event attribute has a value of probation, the "retry-after" attribute MUST be present. It contains an unsigned long integer which indicates the amount of seconds after which the owner of the contact is expected to retry its registration.
如果event属性的值为permission，则必须存在“重试后”属性。它包含一个无符号长整数，该整数指示联系人的所有者在重试其注册后的秒数。
The optional "duration-registered" attribute conveys the amount of time that the contact has been bound to the address-of-record, in seconds. The optional "q" attribute conveys the relative priority of this contact compared to other registered contacts. The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the optional "cseq" attribute contains the last CSeq value present in a REGISTER request that updated this contact value.
可选的“duration registered”属性表示联系人绑定到记录地址的时间量，以秒为单位。可选的“q”属性表示此联系人相对于其他已注册联系人的相对优先级。可选的“callid”属性包含上次用于更新此联系人的寄存器中的当前呼叫ID，可选的“cseq”属性包含更新此联系人值的寄存器请求中的最后一个cseq值。
The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name.
“uri”元素包含与该联系人关联的uri。“display name”元素包含联系人的显示名称。“display name”元素可能包含xml:lang属性，以指示显示名称的语言。
The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in [11]. Each "unknown-param" element describes a single contact header field parameter. The name of the parameter is contained in the mandatory name attribute of the "unknown-param" element, and the value of the parameter is the content of the "unknown-param" element. For contact header field parameters that have no value, the content of the "unknown-param" element is empty.
“unknown param”元素用于传递RFC 3261中未指定的联系人标头字段参数。一个例子是[11]中指定的用户代理能力参数。每个“unknown param”元素描述一个联系人标题字段参数。参数的名称包含在“unknown param”元素的强制名称属性中，参数的值是“unknown param”元素的内容。对于没有值的联系人标头字段参数，“unknown param”元素的内容为空。
Typically, the NOTIFY for registration information will only contain information about those contacts whose state has changed. To construct a coherent view of the total state of all registrations, a subscriber will need to combine NOTIFYs received over time. The subscriber maintains a table for each registration it receives information for. Each registration is uniquely identified by the "id" attribute in the "registration" element. Each table contains a row for each contact in that registration. Each row is indexed by the unique ID for that contact. It is conveyed in the "id" attribute of the "contact" element. The contents of each row contain the state of that contact as conveyed in the "contact" element. The tables are also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "reginfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
通常，“注册通知”信息只包含状态已更改的联系人的信息。为了构建所有注册的总状态的一致视图，订阅者将需要合并一段时间内收到的NOTIFY。订阅者为其接收信息的每个注册维护一个表。每个注册都由“registration”元素中的“id”属性唯一标识。每个表包含该注册中每个联系人的一行。每一行都由该联系人的唯一ID索引。它在“contact”元素的“id”属性中传递。每行的内容都包含在“contact”元素中传递的联系人的状态。这些表还与版本号关联。必须使用收到的第一个文档中“reginfo”元素的“version”属性值初始化版本号。每次收到新文档时，都会比较本地版本号的值和新文档中的“版本”属性。如果新文档中的值比本地版本号高一个，则本地版本号将增加一个，并处理文档。如果文档中的值比本地版本号高出一个以上，则本地版本号将设置为新文档中的值，文档将被处理，订阅者应生成刷新请求以触发完整状态通知。如果文档中的值小于本地版本，则文档将在不进行处理的情况下丢弃。
The processing of the document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "reginfo" element, the contents of all tables associated with this subscription are flushed. They are re-populated from the document. A new table is created for each "registration" element, and a new row in each table is created for
文档的处理取决于它是包含完全状态还是部分状态。如果它包含完整状态（由“reginfo”元素中的“state”属性的值指示），则刷新与此订阅关联的所有表的内容。它们将从文档中重新填充。将为每个“注册”元素创建一个新表，并为每个元素在每个表中创建一个新行
each "contact" element. If the reginfo contains partial state, as indicated by the value of the "state" attribute in the "reginfo" element, the document is used to update the existing tables. For each "registration" element, the subscriber checks to see if a table exists for that registration. This check is done by comparing the value in the "id" attribute of the "registration" element with the ID associated with the table. If a table doesn't exist for that registration, one is created. For each "contact" element in the registration, the subscriber checks to see whether a row exists for that contact. This check is done by comparing the ID in the "id" attribute of the "contact" element with the ID associated with the row. If the contact doesn't exist in the table, a row is added, and its state is set to the information from that "contact" element. If the contact does exist, its state is updated to be the information from that "contact" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
每个“接触”元素。如果reginfo包含部分状态，如“reginfo”元素中“state”属性的值所示，则该文档用于更新现有表。对于每个“注册”元素，订阅者检查是否存在用于该注册的表。通过比较“registration”元素的“id”属性中的值与与表关联的id来完成此检查。如果该注册不存在表，则创建一个表。对于注册中的每个“联系人”元素，订阅者检查该联系人是否存在一行。通过比较“contact”元素的“ID”属性中的ID与与行关联的ID来完成此检查。如果表中不存在联系人，则添加一行，并将其状态设置为来自该“联系人”元素的信息。如果联系人确实存在，则其状态将更新为来自该“联系人”元素的信息。如果行被更新或创建，以致其状态现在已终止，则可以随时从表中删除该条目。
The following is an example registration information document:
以下是注册信息文档的示例：
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="7322"
q="0.8">
<uri>sip:user@pc887.example.com</uri>
</contact>
<contact id="77" state="terminated" event="expired"
duration-registered="3600"
q="0.5">
<uri>sip:user@university.edu</uri>
</contact>
</registration>
</reginfo>
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="7322"
q="0.8">
<uri>sip:user@pc887.example.com</uri>
</contact>
<contact id="77" state="terminated" event="expired"
duration-registered="3600"
q="0.5">
<uri>sip:user@university.edu</uri>
</contact>
</registration>
</reginfo>
The following is the schema definition of the reginfo format:
以下是reginfo格式的架构定义：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:reginfo"
xmlns:tns="urn:ietf:params:xml:ns:reginfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="reginfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:registration" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="registration">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:contact" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="init"/>
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:reginfo"
xmlns:tns="urn:ietf:params:xml:ns:reginfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="reginfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:registration" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="registration">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:contact" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="init"/>
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="unknown-param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="event" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="registered"/>
<xs:enumeration value="created"/>
<xs:enumeration value="refreshed"/>
<xs:enumeration value="shortened"/>
<xs:enumeration value="expired"/>
<xs:enumeration value="deactivated"/>
<xs:enumeration value="probation"/>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="unknown-param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="event" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="registered"/>
<xs:enumeration value="created"/>
<xs:enumeration value="refreshed"/>
<xs:enumeration value="shortened"/>
<xs:enumeration value="expired"/>
<xs:enumeration value="deactivated"/>
<xs:enumeration value="probation"/>
<xs:enumeration value="unregistered"/>
<xs:enumeration value="rejected"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration-registered" type="xs:unsignedLong"/>
<xs:attribute name="expires" type="xs:unsignedLong"/>
<xs:attribute name="retry-after" type="xs:unsignedLong"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="q" type="xs:string"/>
<xs:attribute name="callid" type="xs:string"/>
<xs:attribute name="cseq" type="xs:unsignedLong"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:enumeration value="unregistered"/>
<xs:enumeration value="rejected"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration-registered" type="xs:unsignedLong"/>
<xs:attribute name="expires" type="xs:unsignedLong"/>
<xs:attribute name="retry-after" type="xs:unsignedLong"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="q" type="xs:string"/>
<xs:attribute name="callid" type="xs:string"/>
<xs:attribute name="cseq" type="xs:unsignedLong"/>
</xs:complexType>
</xs:element>
</xs:schema>
User Registrar Application
| |(1) SUBSCRIBE |
| |Event:reg |
| |<------------------|
| |(2) 200 OK |
| |------------------>|
| |(3) NOTIFY |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) REGISTER | |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
| |(7) NOTIFY |
| |------------------>|
| |(8) 200 OK |
| |<------------------|
|(9) MESSAGE | |
|<--------------------------------------|
User Registrar Application
| |(1) SUBSCRIBE |
| |Event:reg |
| |<------------------|
| |(2) 200 OK |
| |------------------>|
| |(3) NOTIFY |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) REGISTER | |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
| |(7) NOTIFY |
| |------------------>|
| |(8) 200 OK |
| |<------------------|
|(9) MESSAGE | |
|<--------------------------------------|
Figure 3: Example Call Flow
图3：示例调用流
This section provides an example call flow, shown in Figure 3. It shows an implementation of the welcome notice application described in Section 3.3. First, the application SUBSCRIBEs to the registration event package for the desired user (1):
本节提供了一个示例调用流，如图3所示。它显示了第3.3节中描述的欢迎通知应用程序的实现。首先，应用程序为所需用户（1）订阅注册事件包：
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@app.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:app.example.com
Event: reg
Max-Forwards: 70
Accept: application/reginfo+xml
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@app.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:app.example.com
Event: reg
Max-Forwards: 70
Accept: application/reginfo+xml
The registrar (which is acting as the notifier for the registration event package) generates a 200 OK to the SUBSCRIBE:
注册器（充当注册事件包的通知程序）生成200 OK以订阅：
SIP/2.0 200 OK
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@app.example.com
CSeq: 9987 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
SIP/2.0 200 OK
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@app.example.com
CSeq: 9987 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
The registrar then generates a notification (3) with the current state. Since there is no active registration, the state of the registration is "init":
然后，注册器生成具有当前状态的通知（3）。由于没有活动注册，注册状态为“init”：
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: 9987@app.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
通过sip/2.0/UDP server19.example.com通知sip:app.example.com sip/2.0；分支=z9hG4bKnasaii来源：sip:joe@example.com;tag=xyzygg To:sip:app.example.com；tag=123aa9呼叫ID:9987@app.example.comCSeq:1288通知联系人：sip:server19.example.com事件：reg Max Forwards:70内容类型：application/reginfo+xml内容长度：。。。
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:joe@example.com" id="a7" state="init" />
</reginfo>
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:joe@example.com" id="a7" state="init" />
</reginfo>
Later on, the user registers (5):
随后，用户注册（5）：
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff
From: sip:joe@example.com;tag=99a8s
To: sip:joe@example.com
Call-ID: 88askjda9@pc34.example.com
CSeq: 9976 REGISTER
Contact: sip:joe@pc34.example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff
From: sip:joe@example.com;tag=99a8s
To: sip:joe@example.com
Call-ID: 88askjda9@pc34.example.com
CSeq: 9976 REGISTER
Contact: sip:joe@pc34.example.com
This results in a NOTIFY being generated to the application (7):
这将导致向应用程序生成通知（7）：
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: 9987@app.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
通过sip/2.0/UDP server19.example.com通知sip:app.example.com sip/2.0；branch=z9hG4bKnasaij发件人：sip:joe@example.com;tag=xyzygg To:sip:app.example.com；tag=123aa9呼叫ID:9987@app.example.comCSeq:1289通知联系人：sip:server19.example.com事件：reg Max Forwards:70内容类型：application/reginfo+xml内容长度：。。。
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="1" state="partial">
<registration aor="sip:joe@example.com" id="a7" state="active">
<contact id="76" state="active" event="registered"
duration-registered="0">
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="1" state="partial">
<registration aor="sip:joe@example.com" id="a7" state="active">
<contact id="76" state="active" event="registered"
duration-registered="0">
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
The application can then send its instant message to the device (9):
然后，应用程序可以将其即时消息发送到设备（9）：
MESSAGE sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds8
From: sip:app.example.com;tag=123aa10
To: sip:joe@example.com
Call-ID: 9988@app.example.com
CSeq: 82779 MESSAGE
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
MESSAGE sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds8
From: sip:app.example.com;tag=123aa10
To: sip:joe@example.com
Call-ID: 9988@app.example.com
CSeq: 82779 MESSAGE
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
Welcome to the example.com service!
欢迎使用example.com服务！
Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here.
RFC 3265[2]中讨论了SIP事件包的安全注意事项，这些注意事项适用于此处。
Registration information is sensitive, potentially private, information. Subscriptions to this event package SHOULD be authenticated and authorized according to local policy. Some policy guidelines are suggested in Section 4.6. In addition, notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of subscriber identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME.
注册信息是敏感的、可能是私有的信息。对此事件包的订阅应根据本地策略进行身份验证和授权。第4.6节提出了一些政策指南。此外，发送通知的方式应确保保密性、消息完整性和订户身份验证，例如使用SIPS URL发送订阅和通知，或使用S/MIME保护通知机构。
This document registers a new SIP Event Package, a new MIME type (application/reginfo+xml), and a new XML namespace.
本文档注册了一个新的SIP事件包、一个新的MIME类型（application/reginfo+xml）和一个新的xml名称空间。
Package name: reg
软件包名称：reg
Type: package
类型：包装
Contact: Jonathan Rosenberg, <jdrosen@jdrosen.net>
Contact: Jonathan Rosenberg, <jdrosen@jdrosen.net>
Published Specification: RFC 3680.
出版规范：RFC3680。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: reginfo+xml
MIME子类型名称：reginfo+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [8].
可选参数：与RFC 3023[8]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [8].
编码注意事项：与RFC 3023[8]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [8] and Section 7 of this specification.
安全注意事项：参见RFC 3023[8]第10节和本规范第7节。
Interoperability considerations: none.
互操作性考虑：无。
Published specification: This document.
已发布规范：本文件。
Applications which use this media type: This document type is being used in notifications to alert SIP user agents that their registrations have expired and must be redone.
使用此媒体类型的应用程序：此文档类型在通知中用于提醒SIP用户代理其注册已过期，必须重新进行。
Additional Information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .rif or .xml
文件扩展名：.rif或.xml
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net>
Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
This section registers a new XML namespace, as per the guidelines in [7].
本节根据[7]中的指导原则注册一个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:reginfo.
URI：此命名空间的URI为urn:ietf:params:xml:ns:reginfo。
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org>, Jonathan Rosenberg <jdrosen@jdrosen.net>.
注册人联系人：IETF，简单工作组<simple@ietf.org>，乔纳森·罗森伯格<jdrosen@jdrosen.net>.
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Registration Information Namespace</title>
</head>
<body>
<h1>Namespace for Registration Information</h1>
<h2>urn:ietf:params:xml:ns:reginfo</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt">
RFC3680</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Registration Information Namespace</title>
</head>
<body>
<h1>Namespace for Registration Information</h1>
<h2>urn:ietf:params:xml:ns:reginfo</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt">
RFC3680</a>.</p>
</body>
</html>
END
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-19980210.
[4] W.W.W.C.（W3C），“可扩展标记语言（xml）1.0”。xml 1.0规范可在http://www.w3.org/TR/1998/REC-xml-19980210.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6] Moats，R.，“IETF文档的URN名称空间”，RFC 2648，1999年8月。
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[7] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[8] Murata, M., St. Laurent, S. and D. Kohn, "XML media types", RFC 3023, January 2001.
[8] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[9] Rosenberg, J., "Session initiation protocol (SIP) extensions for presence", Work In Progress.
[9] Rosenberg，J.，“状态会话启动协议（SIP）扩展”，正在进行中。
[10] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[10] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[11] Schulzrinne, H. and J. Rosenberg, "Session initiation protocol (SIP) caller preferences and callee capabilities", Work In Progress.
[11] Schulzrinne，H.和J.Rosenberg，“会话启动协议（SIP）调用者偏好和调用者功能”，正在进行中。
[12] Mayer, G. and M. Beckmann, "Registration event package", Work In Progress.
[12] Mayer，G.和M.Beckmann，“注册活动包”，正在进行中。
This document is based heavily on the registration event package originally proposed by Beckmann and Mayer in [12]. They can be contacted at:
本文件主要基于Beckmann和Mayer在[12]中最初提出的注册事件包。可通过以下方式联系他们：
Georg Mayer Siemens AG Hoffmannstr. 51 Munich 81359 Germany
乔治梅耶西门子公司霍夫曼斯特。51慕尼黑81359德国
EMail: Georg.Mayer@icn.siemens.de
EMail: Georg.Mayer@icn.siemens.de
Mark Beckmann Siemens AG P.O. Box 100702 Salzgitter 38207 Germany
德国萨尔茨基特38207马克·贝克曼西门子公司邮政信箱100702
EMail: Mark.Beckmann@siemens.com
EMail: Mark.Beckmann@siemens.com
Rohan Mahy provided editorial work in order to progress this specification. His contact address is:
Rohan Mahy提供了编辑工作，以推进本规范。他的联络地址是：
Rohan Mahy Cisco Systems 170 West Tasman Dr, MS: SJC-21/3/3
Rohan Mahy Cisco Systems 170 West Tasman博士，MS:SJC-21/3/3
Phone: +1 408 526 8570
EMail: rohan@cisco.com
Phone: +1 408 526 8570
EMail: rohan@cisco.com
We would like to thank Dean Willis for his support.
我们要感谢迪安·威利斯的支持。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Jonathan Rosenberg dynamicsoft 600新泽西州帕西帕尼拉尼德斯广场07054
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。