Network Working Group J. Rosenberg
Request for Comments: 4235 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
R. Mahy, Ed.
SIP Edge LLC
November 2005
Network Working Group J. Rosenberg
Request for Comments: 4235 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
R. Mahy, Ed.
SIP Edge LLC
November 2005
An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的INVITE启动的对话事件包
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 01) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 01）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved.
本文档定义了SIP事件体系结构的对话事件包，以及用于此包通知的数据格式。对话框包允许用户订阅另一个用户，并接收有关已订阅用户参与的INVITE发起的对话框使用状态更改的通知。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Dialog Event Package ............................................4
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................5
3.4. Subscription Duration ......................................6
3.5. NOTIFY Bodies ..............................................6
3.6. Notifier Processing of SUBSCRIBE Requests ..................7
3.7. Notifier Generation of NOTIFY Requests .....................8
3.7.1. The Dialog State Machine ............................8
3.7.2. Applying the State Machine .........................11
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Dialog Event Package ............................................4
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................5
3.4. Subscription Duration ......................................6
3.5. NOTIFY Bodies ..............................................6
3.6. Notifier Processing of SUBSCRIBE Requests ..................7
3.7. Notifier Generation of NOTIFY Requests .....................8
3.7.1. The Dialog State Machine ............................8
3.7.2. Applying the State Machine .........................11
3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9. Handling of Forked Requests ...............................12
3.10. Rate of Notifications ....................................13
3.11. State Agents .............................................13
4. Dialog Information Format ......................................13
4.1. Structure of Dialog Information ...........................13
4.1.1. Dialog Element .....................................14
4.1.2. State Element ......................................15
4.1.3. Duration Element ...................................15
4.1.4. Replaces Element ...................................15
4.1.5. Referred-By Element ................................16
4.1.6. Local and Remote Elements ..........................16
4.2. Sample Notification Body ..................................17
4.3. Constructing Coherent State ...............................18
4.4. Schema ....................................................19
5. Definition of New Media Feature Parameters .....................22
5.1. The "sip.byeless" Parameter ...............................22
5.2. The "sip.rendering" parameter .............................23
6. Examples .......................................................24
6.1. Basic Example .............................................24
6.2. Emulating a Shared-Line Phone System ......................26
6.3. Minimal Dialog Information with Privacy ...................31
7. Security Considerations ........................................32
8. IANA Considerations ............................................32
8.1. application/dialog-info+xml MIME Registration .............33
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info ........................34
8.3. Schema Registration .......................................34
8.4. Media Feature Parameter Registration ......................34
8.4.1. sip.byeless ........................................35
8.4.2. sip.rendering ......................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9. Handling of Forked Requests ...............................12
3.10. Rate of Notifications ....................................13
3.11. State Agents .............................................13
4. Dialog Information Format ......................................13
4.1. Structure of Dialog Information ...........................13
4.1.1. Dialog Element .....................................14
4.1.2. State Element ......................................15
4.1.3. Duration Element ...................................15
4.1.4. Replaces Element ...................................15
4.1.5. Referred-By Element ................................16
4.1.6. Local and Remote Elements ..........................16
4.2. Sample Notification Body ..................................17
4.3. Constructing Coherent State ...............................18
4.4. Schema ....................................................19
5. Definition of New Media Feature Parameters .....................22
5.1. The "sip.byeless" Parameter ...............................22
5.2. The "sip.rendering" parameter .............................23
6. Examples .......................................................24
6.1. Basic Example .............................................24
6.2. Emulating a Shared-Line Phone System ......................26
6.3. Minimal Dialog Information with Privacy ...................31
7. Security Considerations ........................................32
8. IANA Considerations ............................................32
8.1. application/dialog-info+xml MIME Registration .............33
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info ........................34
8.3. Schema Registration .......................................34
8.4. Media Feature Parameter Registration ......................34
8.4.1. sip.byeless ........................................35
8.4.2. sip.rendering ......................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
The SIP Events framework [1] defines general mechanisms for subscription to, and notification of, events within SIP networks. It introduces the notion of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events. Packages have been defined for user presence [16], watcher information [17], and message waiting indicators [18], amongst others. This document defines an event package for INVITE-initiated dialog usages. Dialogs refer to the SIP relationship established between two SIP peers [2]. Dialogs can be created by many methods, although RFC 3261 defines only one: the INVITE method. RFC 3265 [1] defines the SUBSCRIBE and NOTIFY methods, which also create new dialog usages. However, using this package to model state for non-session dialog usages is out of the scope of this specification.
SIP事件框架[1]定义了订阅和通知SIP网络内事件的一般机制。它引入了包的概念，包是一组定义良好的事件的事件机制的特定“实例化”。已为用户状态[16]、观察者信息[17]和消息等待指示器[18]等定义了包。本文档为INVITE启动的对话框用法定义了一个事件包。对话框指的是两个SIP对等方之间建立的SIP关系[2]。虽然RFC3261只定义了一个方法：INVITE方法，但可以通过许多方法创建对话框。RFC 3265[1]定义了SUBSCRIBE和NOTIFY方法，它们还创建了新的对话框用法。但是，使用此包为非会话对话框使用建模状态超出了本规范的范围。
A variety of applications are enabled through knowledge of INVITE dialog usage state. Some examples include:
通过了解INVITE对话框的使用状态，可以启用各种应用程序。一些例子包括：
Automatic Callback: In this basic Public Switched Telephone Network (PSTN) application, user A calls user B but User B is busy. User A would like to get a callback when user B hangs up. When B hangs up, user A's phone rings. When A picks up, they hear ringing, while they are being connected to B. To implement this with SIP, a mechanism is required for A to receive a notification when the dialogs at B are complete.
自动回拨：在这个基本的公共交换电话网（PSTN）应用程序中，用户A呼叫用户B，但用户B正忙。用户A希望在用户B挂断时获得回调。当B挂断电话时，用户A的电话响了。当A拾取时，当他们连接到B时，他们会听到铃声。要通过SIP实现这一点，A需要一种机制在B的对话完成时接收通知。
Presence-Enabled Conferencing: In this application, user A wishes to set up a conference call with users B and C. Rather than being scheduled, the call is created automatically when A, B and C are all available. To do this, the server providing the application would like to know whether A, B, and C are "online", not idle, and not in a phone call. Determining whether or not A, B, and C are in calls can be done in two ways. In the first, the server acts as a call-stateful proxy for users A, B, and C, and therefore knows their call state. This won't always be possible, however, and it introduces scalability, reliability, and operational complexities. In the second way, the server subscribes to the dialog state of those users and receives notifications as this state changes. This enables the application to be provided in a distributed way; the server need not reside in the same domain as the users.
支持状态的会议：在此应用程序中，用户A希望与用户B和C建立一个会议呼叫。当A、B和C都可用时，呼叫将自动创建，而不是安排。为此，提供应用程序的服务器希望知道A、B和C是否“在线”、是否空闲以及是否在电话中。可以通过两种方式确定A、B和C是否在调用中。在第一种情况下，服务器充当用户a、B和C的调用状态代理，因此知道他们的调用状态。然而，这并不总是可能的，它引入了可伸缩性、可靠性和操作复杂性。第二种方式是，服务器订阅这些用户的对话框状态，并在该状态更改时接收通知。这使得能够以分布式方式提供应用程序；服务器不必与用户驻留在同一个域中。
IM Conference Alerts: In this application, a user can receive an Instant Message (IM) on their phone whenever someone joins a conference that the phone is involved in. The IM alerts are generated by an application separate from the conference server.
IM会议警报：在此应用程序中，用户可以在其手机上接收即时消息（IM），无论何时有人加入手机所涉及的会议。IM警报由独立于会议服务器的应用程序生成。
In general, the dialog package allows for construction of distributed applications, where the application requires information on dialog state but is not co-resident with the end user on which that state resides.
通常，dialog包允许构造分布式应用程序，其中应用程序需要有关dialog状态的信息，但不与状态所在的最终用户共存。
This document also defines two new callee capability [10] feature parameters:
本文档还定义了两个新的被叫方功能[10]特征参数：
o "sip.byeless", which indicates that a SIP user agent (UA) is not capable of terminating a session itself (for example, in some announcement or recording services, or in some call centers) in which the UA is no longer interested in participating; and
o “sip.byless”，表示sip用户代理（UA）不能终止UA不再感兴趣参与的会话本身（例如，在某些公告或录音服务中，或在某些呼叫中心中）；和
o "sip.rendering", which positively describes whether the user agent is rendering any of the media it is receiving. These feature parameters are useful in many of the same applications that motivated the dialog package, such as conferencing, presence, and the shared-line example described in Section 6.2.
o “sip.rendering”，它肯定地描述了用户代理是否正在呈现它正在接收的任何媒体。这些功能参数在许多驱动对话框包的应用程序中非常有用，例如会议、状态和第6.2节中描述的共享线路示例。
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 RFC 2119 [9] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[9]中的描述进行解释，并表示符合性实施的要求级别。
This section provides the details for defining a SIP Events package, as specified in [1].
本节提供了定义SIP事件包的详细信息，如[1]中所述。
The name of this event package is "dialog". This package name is carried in the Event and Allow-Events header fields, as defined in [1].
此事件包的名称为“dialog”。如[1]中所定义，此程序包名称包含在事件和允许事件标题字段中。
This package defines four Event Package parameters: call-id, to-tag, from-tag, and include-session-description. If a subscription to a specific dialog is requested, the first three of these parameters MUST be present, to identify the dialog that is being subscribed to. The to-tag is matched against the local tag, the from-tag is matched against the remote tag, and the call-id is matched against the Call-ID. The include-session-description parameter indicates whether the subscriber would like to receive the session descriptions associated with the subscribed dialog usage or usages.
这个包定义了四个事件包参数：call id、to tag、from tag和include session description。如果请求订阅特定对话框，则必须存在这些参数中的前三个，以标识正在订阅的对话框。to标记与本地标记匹配，from标记与远程标记匹配，call id与call-id匹配。include session description参数指示订户是否希望接收与订阅的对话用法相关联的会话描述。
It is also possible to subscribe to the set of dialogs created as a result of a single INVITE sent by a UAC (user agent client). In that case, the call-id and to-tag MUST be present. The to-tag is matched against the local tag and the call-id is matched against the Call-ID.
还可以订阅由UAC（用户代理客户端）发送的单个邀请创建的对话框集。在这种情况下，呼叫id和to标记必须存在。to标记与本地标记匹配，call id与call-id匹配。
The ABNF for these parameters is shown below. It refers to many constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and token.
这些参数的ABNF如下所示。它引用了RFC3261的ABNF中的许多构造，例如EQUAL、DQUOTE和token。
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"
If any call-ids contain embedded double-quotes, those double-quotes MUST be escaped using the backslash-quoting mechanism. Note that the call-id parameter may need to be expressed as a quoted string. This is because the ABNF for the callid production and the word production, which is used by callid (both from RFC 3261 [1]), allow some characters (such as "@", "[", and ":") that are not allowed within a token.
如果任何调用ID包含嵌入的双引号，则必须使用反斜杠引用机制对这些双引号进行转义。请注意，调用id参数可能需要表示为带引号的字符串。这是因为callid生产的ABNF和callid（均来自RFC 3261[1]）使用的单词production允许标记中不允许的某些字符（如“@”、“[”和“：”）。
A SUBSCRIBE request for a dialog package MAY contain a body. This body defines a filter to be applied to the subscription. Filter documents are not specified in this document, and at the time of writing, they are expected to be the subject of future standardization activity.
对话框包的订阅请求可能包含正文。此正文定义要应用于订阅的筛选器。本文件未规定过滤文件，在编写本文件时，这些文件预计将成为未来标准化活动的主题。
A SUBSCRIBE request for a dialog package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is:
对话框包的订阅请求可以在没有正文的情况下发送。这意味着默认的订阅筛选策略。默认策略为：
o If the Event header field contained dialog identifiers, a notification is generated every time there is a change in the state of any matching dialogs for the user identified in the request URI of the SUBSCRIBE.
o 如果事件头字段包含对话框标识符，则每当订阅的请求URI中标识的用户的任何匹配对话框的状态发生更改时，都会生成通知。
o If there were no dialog identifiers in the Event header field, a notification is generated every time there is any change in the state of any dialogs for the user identified in the request URI of the SUBSCRIBE with the following exceptions. If the target (Contact) URI of a subscriber is equivalent to the remote target URI of a specific dialog, then the dialog element for that dialog is suppressed for that subscriber. (The subscriber is already a party in the dialog directly, so these notifications are
o 如果事件标头字段中没有对话框标识符，则每当订阅的请求URI中标识的用户的任何对话框的状态发生任何更改时，都会生成通知，但以下例外情况除外。如果订阅服务器的目标（联系人）URI等同于特定对话框的远程目标URI，则该订阅服务器将抑制该对话框的对话框元素。（订阅者已经直接成为对话框中的一方，因此这些通知是
superfluous.) If no dialogs remain after suppressing dialogs, the entire notification to that subscriber is suppressed and the version number in the dialog-info element is not incremented for that subscriber. Implicit filtering for one subscriber does not affect notifications to other subscribers.
如果在取消对话框后没有对话框保留，则对该订阅服务器的整个通知将被取消，并且该订阅服务器的dialog info元素中的版本号不会增加。对一个订阅服务器的隐式筛选不会影响对其他订阅服务器的通知。
o Notifications do not normally contain full state; rather, they only indicate the state of the dialog(s) whose state has changed. The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a NOTIFY that contains no dialog elements. These NOTIFYs contain the complete view of dialog state.
o 通知通常不包含完整状态；相反，它们只指示状态已更改的对话框的状态。例外情况是响应订阅发送的通知，以及不包含对话框元素的通知。这些NOTIFY包含对话框状态的完整视图。
o The notifications contain the identities of the participants in the dialog, the target URIs, and the dialog identifiers. Session descriptions are not included unless explicitly requested and explicitly authorized.
o 通知包含对话框中参与者的身份、目标URI和对话框标识符。除非明确请求和明确授权，否则不包括会话描述。
Dialog state changes fairly quickly. Once established, a typical phone call lasts a few minutes (this is different for other session types, of course). However, the interval between new calls is typically long. Clients SHOULD specify an explicit duration.
对话框状态变化相当快。一旦建立，典型的电话通话会持续几分钟（当然，对于其他会话类型，这是不同的）。但是，新呼叫之间的间隔通常很长。客户端应该指定一个显式的持续时间。
There are two distinct use cases for dialog state. The first is when a subscriber is interested in the state of a specific dialog or dialogs (and they are authorized to find out just the state of those dialogs). In that case, when the dialogs terminate, so too does the subscription. In these cases, the value of the subscription duration is largely irrelevant; it SHOULD be longer than the typical duration of a dialog. We recommend a default duration of two hours, which is likely to cover most dialogs.
对话框状态有两种不同的用例。第一种情况是订阅者对一个或多个特定对话框的状态感兴趣（他们被授权只了解这些对话框的状态）。在这种情况下，当对话框终止时，订阅也会终止。在这些情况下，订阅持续时间的价值在很大程度上是不相关的；它应该比对话框的典型持续时间长。我们建议默认持续时间为两小时，这可能涵盖大多数对话框。
In another case, a subscriber is interested in the state of all dialogs for a specific user. In these cases, a shorter interval makes more sense. The default is one hour for these subscriptions.
在另一种情况下，订户对特定用户的所有对话框的状态感兴趣。在这些情况下，较短的间隔更有意义。这些订阅的默认值为一小时。
As described in RFC 3265 [1], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or in a package-specific default format if the Accept header field was omitted from the SUBSCRIBE.
如RFC 3265[1]所述，NOTIFY消息将包含描述订阅资源状态的主体。此正文采用订阅的Accept header字段中列出的格式，或者如果订阅中省略了Accept header字段，则采用包特定的默认格式。
In this event package, the body of the notification contains a dialog information document. This document describes the state of one or more dialogs associated with the subscribed resource. All
在此事件包中，通知正文包含一个对话框信息文档。本文档描述了与订阅资源关联的一个或多个对话框的状态。全部的
subscribers and notifiers MUST support the "application/ dialog-info+xml" data format described in Section 4. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/dialog-info+xml". If the header field is present, it MUST include "application/ dialog-info+xml", and it MAY include any other types capable of representing dialog state.
订阅者和通知者必须支持第4节中描述的“应用程序/对话框信息+xml”数据格式。订阅请求可能包含接受标头字段。如果不存在此类标题字段，则其默认值为“应用程序/对话框信息+xml”。如果存在标题字段，则它必须包括“应用程序/对话框信息+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 dialog information for a user contains sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. All implementors of this package MUST support the digest authentication mechanism as a baseline. The authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
用户的对话框信息包含敏感信息。因此，在批准之前，所有订阅都应该经过身份验证和授权。此包的所有实现者都必须支持摘要身份验证机制作为基线。与往常一样，授权策略由管理员自行决定。然而，可以提出一些建议。
It is RECOMMENDED that, if the policy of user B is that user A is allowed to call them, dialog subscriptions from user A be allowed. However, the information provided in the notifications does not contain any dialog identification information, merely an indication of whether the user is in at least one call. Specifically, they should not be able to find out any more information than if they sent an INVITE. (This concept of a "virtual" dialog is discussed more in Section 3.7.2, and an example of such a notification body is shown below).
如果用户B的策略是允许用户A调用它们，则建议允许用户A进行对话框订阅。然而，在通知中提供的信息不包含任何对话框标识信息，仅指示用户是否在至少一个呼叫中。具体来说，他们应该无法找到比发送邀请更多的信息。（第3.7.2节详细讨论了“虚拟”对话框的概念，下面给出了此类通知主体的示例）。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>
A user agent that registers with the address-of-record X SHOULD authorize subscriptions that come from any entity that can authenticate itself as X. Complete information on the dialog state SHOULD be sent in this case. This authorization behavior allows a group of devices representing a single user to become aware of each other's state. This is useful for applications such as single-line-extension, also known as shared lines.
使用记录X的地址注册的用户代理应授权来自任何实体的订阅，该实体可以将其自身验证为X。在这种情况下，应发送有关对话框状态的完整信息。此授权行为允许代表单个用户的一组设备了解彼此的状态。这对于单线扩展（也称为共享线）等应用程序非常有用。
Note that many implementations of "shared-lines" have a feature that allows details of calls on a shared address-of-record to be made private. This is a completely reasonable authorization policy that could result in notifications that contain only the id attribute of the dialog element and the state element when shared-line privacy is requested, and notifications with more complete information when shared-line privacy is not requested.
请注意，“共享线路”的许多实现都有一个特性，允许对记录的共享地址调用的细节进行私有化。这是一个完全合理的授权策略，当请求共享线路隐私时，可能会生成只包含对话框元素和状态元素的id属性的通知，当不请求共享线路隐私时，会生成包含更完整信息的通知。
Notifications are generated for the dialog package when an INVITE request is sent, when a new dialog comes into existence at a UA, or when the state or characteristics of an existing dialog changes. Therefore, a model of dialog state is needed in order to determine precisely when to send notifications, and what their content should be. The SIP specification has a reasonably well defined lifecycle for dialogs. However, it is not explicitly modelled. This specification provides an explicit model of dialog state through a finite state machine.
当发送INVITE请求时，当UA上出现新对话框时，或当现有对话框的状态或特征更改时，将为对话框包生成通知。因此，需要一个对话框状态模型，以便准确地确定何时发送通知以及通知的内容。SIP规范为对话框定义了合理的生命周期。但是，它没有明确建模。本规范通过有限状态机提供对话框状态的显式模型。
It is RECOMMENDED that NOTIFY requests only contain information on the dialogs whose state or participation information has changed. However, if a notifier receives a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of all dialogs that the subscriber is authorized to see.
建议NOTIFY请求仅包含状态或参与信息已更改的对话框的信息。但是，如果通知程序收到订阅请求，则触发的通知应包含订阅者有权查看的所有对话框的状态。
Modelling of dialog state is complicated by two factors. The first is forking, which can cause a single INVITE to generate many dialogs at a UAC. The second is the differing views of state at the UAC (user agent client) and UAS (usage agent server). We have chosen to handle the first issue by extending the dialog finite state machine (FSM) to include the states between transmission of the INVITE and the creation of actual dialogs through receipt of 1xx and 2xx responses. As a result, this specification supports the notion of dialog state for dialogs before they are fully instantiated.
对话框状态的建模由于两个因素而变得复杂。第一种是分叉，这会导致单个邀请在UAC上生成许多对话框。第二个是UAC（用户代理客户端）和UAS（使用代理服务器）对状态的不同看法。我们选择通过扩展对话框有限状态机（FSM）来处理第一个问题，以包括INVITE传输和通过接收1xx和2xx响应创建实际对话框之间的状态。因此，该规范支持对话框在完全实例化之前的对话框状态概念。
We have also chosen to use a single FSM for both UAC and UAS.
我们还选择对UAC和UAS使用单一FSM。
+----------+ +----------+
| | 1xx-notag | |
| |----------->| |
| Trying | |Proceeding|-----+
| |---+ +-----| | |
| | | | | | |
+----------+ | | +----------+ |
| | | | | |
| | | | | |
+<--C-----C--+ |1xx-tag |
| | | | |
cancelled| | | V |
rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx
| | | | |
+<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w/new tag
| | | |<----C---+ (new FSM
| | +----------+ | instance
| | 2xx | | created)
| +----------------+ | |
| | |2xx |
| | | |
V V V |
+----------+ +----------+ |
| | | | |
| | | | |
|Terminated|<-----------| Confirmed|<----+
| | error | |
| | timeout | |
+----------+ replaced +----------+
local-bye | ^
remote-bye | |
| |
+------+
2xx w. new tag
(new FSM instance
created)
+----------+ +----------+
| | 1xx-notag | |
| |----------->| |
| Trying | |Proceeding|-----+
| |---+ +-----| | |
| | | | | | |
+----------+ | | +----------+ |
| | | | | |
| | | | | |
+<--C-----C--+ |1xx-tag |
| | | | |
cancelled| | | V |
rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx
| | | | |
+<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w/new tag
| | | |<----C---+ (new FSM
| | +----------+ | instance
| | 2xx | | created)
| +----------------+ | |
| | |2xx |
| | | |
V V V |
+----------+ +----------+ |
| | | | |
| | | | |
|Terminated|<-----------| Confirmed|<----+
| | error | |
| | timeout | |
+----------+ replaced +----------+
local-bye | ^
remote-bye | |
| |
+------+
2xx w. new tag
(new FSM instance
created)
Figure 3
图3
The FSM for dialog state is shown in Figure 3. The FSM is best understood by considering the UAC and UAS cases separately.
对话框状态的FSM如图3所示。最好通过分别考虑UAC和UAS案例来理解FSM。
The FSM is created in the Trying state when the UAC sends an INVITE request. Upon receipt of a 1xx without a tag, the FSM transitions to the Proceeding state. Note that there is no actual dialog yet, as defined by the SIP specification. However, there is a "half-dialog", in the sense that two of the three components of the dialog ID (the call identifier and local tag) are known. If a 1xx with a tag is received, the FSM transitions to the Early state. The full dialog identifier is now defined. Had a 2xx been received, the FSM would have transitioned to the Confirmed state.
当UAC发送INVITE请求时，FSM在尝试状态下创建。收到无标签的1xx后，FSM将转换为继续状态。注意，按照SIP规范的定义，还没有实际的对话框。然而，存在一个“半对话”，即对话ID的三个组件（调用标识符和本地标记）中的两个是已知的。如果收到带有标签的1xx，FSM将转换为早期状态。现在定义了完整的对话框标识符。如果收到2xx，FSM将转换为确认状态。
If, after transitioning to the Early or Confirmed states, the UAC receives another 1xx or 2xx respectively with a different tag, another instance of the FSM is created, initialized into the Early or Confirmed state, respectively. The benefit of this approach is that there will be a single FSM representing the entire state of the invitation and resulting dialog when dealing in the common case of no forking.
如果在转换到早期或确认状态后，UAC收到另一个分别带有不同标签的1x或2xx，则会创建另一个FSM实例，并分别初始化为早期或确认状态。这种方法的好处是，在处理无分叉的常见情况时，将有一个单独的FSM表示整个邀请状态和结果对话框。
If the UAC sends a CANCEL and then subsequently receives a 487 to its INVITE transaction, all FSMs spawned from that INVITE transition to the Terminated state with the event "cancelled". If the UAC receives a new invitation (with a Replaces [13] header) that replaces the current Early or Confirmed dialog, all INVITE transactions spawned from the replaced invitation transition to the Terminated state with the event "replaced". If the INVITE transaction terminates with a non-2xx response for any other reason, all FSMs spawned from that INVITE transition to the Terminated state with the event "rejected".
如果UAC发送一个取消，然后随后收到一个487到它的INVITE事务，则从INVITE转换生成的所有FSM都将进入终止状态，并显示事件“已取消”。如果UAC收到一个新的邀请（带有替换[13]标题），该邀请替换了当前的“提前”或“已确认”对话框，则所有从被替换的邀请转换到终止状态的邀请事务都会被事件“替换”。如果INVITE事务因任何其他原因以非2xx响应终止，则从INVITE转换到终止状态的所有FSM都会生成事件“rejected”。
Once in the Confirmed state, the call is active. It can transition to the Terminated state if the UAC sends a BYE or receives a BYE (corresponding to the "local-bye" and "remote-bye" events as appropriate), if a mid-dialog request generates a 481 or 408 response (corresponding to the "error" event), or a mid-dialog request generates no response (corresponding to the "timeout" event).
一旦处于确认状态，呼叫即处于活动状态。如果UAC发送BYE或接收BYE（视情况而定，对应于“本地BYE”和“远程BYE”事件），如果mid对话请求生成481或408响应（对应于“错误”事件），或者mid对话请求未生成响应（对应于“超时”事件），则可以转换为终止状态。
From the perspective of the UAS, when an INVITE is received, the FSM is created in the Trying state. If it sends a 1xx without a tag, the FSM transitions to the Proceeding state. If a 1xx is sent with a tag, the FSM transitions to the Early state, and if a 2xx is sent, it transitions to the Confirmed state. If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can occur in the Proceeding and Early states), the FSM transitions to the Terminated state with the event "cancelled". If the UAS generates any other non-2xx final response to the INVITE request, the FSM transitions to the Terminated state with the event "rejected". If the UAS receives a new invitation (with a Replaces [13] header field) that replaces the current Confirmed dialog, the replaced invitation transitions to the Terminated state with the event "replaced". Once
从UAS的角度来看，当收到邀请时，FSM将在尝试状态下创建。如果发送不带标签的1xx，FSM将转换为继续状态。如果发送带有标签的1x，FSM将转换为早期状态，如果发送2xx，则转换为确认状态。如果UAS接收到取消请求，然后生成对INVITE的487响应（可在继续和早期状态下发生），则FSM将转换到终止状态，事件为“取消”。如果UAS对INVITE请求生成任何其他非2xx最终响应，则FSM将转换为终止状态，并显示事件“已拒绝”。如果UAS收到一个新的邀请（带有替换[13]标题字段），该字段替换了当前确认的对话框，则替换的邀请将转换为终止状态，并显示事件“已替换”。一旦
in the Confirmed state, the other transitions to the Terminated state occur for the same reasons they do in the case of UAC.
在确认状态下，其他转换到终止状态的原因与UAC相同。
There should never be a transition from the Trying state to the Terminated state with the event "cancelled", since the SIP specification prohibits transmission of CANCEL until a provisional response is received. However, this transition is defined in the FSM just to unify the transitions from Trying, Proceeding, and Early states to the Terminated state.
在事件“已取消”的情况下，决不能从尝试状态转换到终止状态，因为SIP规范禁止在收到临时响应之前传输取消。但是，在FSM中定义此转换只是为了统一从尝试、继续和早期状态到终止状态的转换。
The notifier MAY generate a NOTIFY request on any event transition of the FSM. Whether it does or not is policy dependent. However, some general guidelines are provided.
通知程序可在FSM的任何事件转换时生成通知请求。它是否存在取决于策略。但是，提供了一些一般准则。
When the subscriber is unauthenticated, or it is authenticated but represents a third party with no specific authorization policies, it is RECOMMENDED that subscriptions to an individual dialog or to a specific set of dialogs be forbidden. Only subscriptions to all dialogs (i.e., there are no dialog identifiers in the Event header field) are permitted. In that case, actual dialog states across all dialogs will not be reported. Rather, a single "virtual" dialog FSM will be used, and event transitions on that FSM will be reported.
如果订阅服务器未经身份验证，或已通过身份验证但代表没有特定授权策略的第三方，建议禁止订阅单个对话框或特定对话框集。只允许订阅所有对话框（即，事件标题字段中没有对话框标识符）。在这种情况下，不会报告所有对话框的实际对话框状态。相反，将使用单个“虚拟”对话框FSM，并报告该FSM上的事件转换。
If there is any dialog at the UA whose state is Confirmed, the virtual FSM is in the Confirmed state. If there are no dialogs at the UA in the Confirmed state but there is at least one in the Early state, the virtual FSM is in the Early or Confirmed state. If there are no dialogs in the Confirmed or Early states but there is at least one in the Proceeding state, the virtual FSM is in the Proceeding, Early, or Confirmed state. If there are no dialogs in the Confirmed, Early, or Proceeding states but there is at least one in the Trying state, the virtual FSM is in the Trying, Proceeding, Early or Confirmed state. The choice of state to use depends on whether the UA wishes to let unknown users know that their phone is ringing, as opposed to being in an active call.
如果UA上存在任何状态已确认的对话框，则虚拟FSM处于已确认状态。如果UA上没有处于已确认状态的对话框，但至少有一个处于早期状态，则虚拟FSM处于早期或已确认状态。如果确认或早期状态中没有对话框，但至少有一个对话框处于继续状态，则虚拟FSM处于继续、早期或确认状态。如果确认、早期或继续状态中没有对话框，但至少有一个对话框处于尝试状态，则虚拟FSM处于尝试、继续、早期或确认状态。使用状态的选择取决于UA是否希望让未知用户知道他们的电话正在响，而不是处于活动通话中。
It is RECOMMENDED that, in the absence of any preference, Confirmed is used in all cases as shown in the example in Section 3.6. Furthermore, it is RECOMMENDED that the notifications of changes in the virtual FSM machine not convey any information except the state of the FSM and its event transitions - no dialog identifiers (which are ill-defined in this model in any case). The use of this virtual FSM allows minimal information to be conveyed. A subscriber cannot know how many calls are in progress, or with whom, just that there exists a call. This is the same information they would receive if
在没有任何偏好的情况下，建议在所有情况下使用“确认”，如第3.6节中的示例所示。此外，建议虚拟FSM机器中的更改通知不传递除FSM状态及其事件转换之外的任何信息-无对话标识符（在任何情况下，该模型中定义不正确）。这种虚拟FSM的使用允许传递最少的信息。订户不能只知道存在一个呼叫，就知道有多少个呼叫正在进行，或者与谁通话。这与他们在以下情况下收到的信息相同：
they simply sent an INVITE to the user instead; a 486 (Busy Here) response would indicate that they are on a call.
他们只是向用户发送了一个邀请；486（此处忙）响应表示他们正在通话。
When the subscriber is authenticated and has authenticated itself with the same address-of-record that the UA itself uses, if no explicit authorization policy is defined, it is RECOMMENDED that all state transitions on dialogs that have been subscribed to be reported, along with complete dialog IDs. This means either all of the dialogs, if no dialog identifiers were present in the Event header field, or the specific set of dialogs identified by the Event header field parameters.
当用户通过身份验证并使用UA本身使用的相同记录地址进行身份验证时，如果未定义明确的授权策略，建议报告已订阅的对话框上的所有状态转换以及完整的对话框ID。这意味着，如果事件标题字段中不存在对话框标识符，则表示所有对话框，或者表示由事件标题字段参数标识的特定对话框集。
The notifier SHOULD generate a NOTIFY request on any change in the characteristics associated with the dialog. Since these include Contact URIs, Contact parameters, and session descriptions, receipt of re-INVITEs and UPDATE requests [3] that modify this information MAY trigger notifications.
通知程序应在与对话框关联的特征发生任何更改时生成通知请求。由于这些包括联系人URI、联系人参数和会话描述，因此收到修改此信息的重新邀请和更新请求[3]可能会触发通知。
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in package-specific ways. In particular, a package should specify how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource.
SIP事件框架要求包指定订户如何以包特定的方式处理通知请求。特别是，包应该指定如何使用NOTIFY请求来构建订阅资源状态的一致视图。
Typically, the NOTIFY for the dialog package will contain information about only those dialogs whose state has changed. To construct a coherent view of the total state of all dialogs, a subscriber to the dialog package will need to combine NOTIFYs received over time.
通常，对话框包的NOTIFY将只包含状态已更改的对话框的信息。要构建所有对话框总状态的一致视图，对话框包的订阅者需要合并随时间接收的NOTIFY。
Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The details of this mechanism are specific to the particular document type. See Section 4.3 for information on constructing coherent information from an application/dialog-info+xml document.
此包中的通知可以传递部分信息；也就是说，它们可以指示与订阅关联的状态子集的信息。这意味着需要定义一个显式算法来构造相干和一致的状态。此机制的详细信息特定于特定的文档类型。有关从应用程序/对话框信息+xml文档构造一致信息的信息，请参见第4.3节。
Since dialog state is distributed across the UA for a particular user, it is reasonable and useful for a SUBSCRIBE request for dialog state to fork and to reach multiple UAs.
由于对话状态针对特定用户分布在整个UA中，因此对对话状态的订阅请求分叉并到达多个UA是合理和有用的。
As a result, a forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared
因此，对话框状态的分叉订阅请求可以安装多个订阅。必须准备好此包的订阅服务器
to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE.
为单个订阅生成的每个通知安装订阅状态。
For reasons of congestion control, it is important that the rate of notifications not be excessive. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second.
出于拥塞控制的原因，重要的是通知率不能过高。建议服务器为单个订阅者生成通知的速度不要超过每秒一次。
Dialog state is ideally maintained in the user agents in which the dialog resides. Therefore, the elements that maintain the dialog are the ones best suited to handle subscriptions to it. However, in some cases, a network agent may also know the state of the dialogs held by a user. Such state agents MAY be used with this package.
对话框状态在对话框所在的用户代理中得到理想的维护。因此，维护对话框的元素最适合处理对它的订阅。然而，在某些情况下，网络代理也可能知道用户持有的对话框的状态。此类状态代理可与此包一起使用。
Dialog information is an XML document [4] that MUST be well-formed and SHOULD be valid. Dialog 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 dialog 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:dialog-info
urn:ietf:params:xml:ns:dialog-info
A dialog information document begins with the root element tag "dialog-info".
对话框信息文档以根元素标记“dialog info”开头。
A dialog information document starts with a dialog-info element. This element has three mandatory attributes:
对话框信息文档以对话框信息元素开始。此元素有三个必需属性：
o version: This attribute allows the recipient of dialog 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 subscription. Versions MUST be representable using a non-negative 32 bit integer.
o 版本：此属性允许对话框信息文档的收件人正确排序。版本从0开始，发送到订阅服务器的每个新文档的版本增量为1。版本在订阅范围内。版本必须使用非负32位整数表示。
o state: This attribute indicates whether the document contains the full dialog information, or whether it contains only information on those dialogs that have changed since the previous document (partial).
o 状态：此属性指示文档是否包含完整的对话框信息，或仅包含自上一个文档（部分）以来已更改的对话框的信息。
o entity: This attribute contains a URI that identifies the user whose dialog information is reported in the remainder of the document. This user is referred to as the "observed user".
o 实体：此属性包含一个URI，用于标识其对话框信息在文档其余部分中报告的用户。该用户被称为“被观察用户”。
The dialog-info element has a series of zero or more dialog sub-elements. Each of those represents a specific dialog. An example:
对话框信息元素有一系列零个或多个对话框子元素。每一个都代表一个特定的对话框。例如：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>
The dialog element reports information about a specific dialog or "half-dialog". It has a single mandatory attribute: id. The id attribute provides a single string that can be used as an identifier for this dialog or "half-dialog". This is a different identifier than the dialog ID defined in RFC 3261 [2], but related to it.
dialog元素报告有关特定对话框或“半对话框”的信息。它有一个强制属性：id。id属性提供一个字符串，可以用作此对话框或“半对话框”的标识符。该标识符与RFC 3261[2]中定义的对话框ID不同，但与之相关。
For a caller, the id is created when an INVITE request is sent. When a 1xx response with a tag, or a 2xx response is received, the dialog is formally created. The id remains unchanged. However, if an additional 1xx or 2xx is received, resulting in the creation of another dialog (and resulting FSM), that dialog is allocated a new id.
对于调用方，在发送INVITE请求时创建id。当收到带有标记的1xx响应或2xx响应时，将正式创建对话框。id保持不变。但是，如果收到额外的1x或2xx，导致创建另一个对话框（以及由此产生的FSM），则会为该对话框分配一个新id。
For a callee, the id is created when an INVITE outside of an existing dialog is received. When a 2xx or a 1xx with a tag is sent, creating the dialog, the id remains unchanged.
对于被调用方，在接收到现有对话框外部的邀请时创建id。当发送带有标记的2xx或1xx创建对话框时，id保持不变。
The id MUST be unique amongst all current dialogs at a UA.
在UA的所有当前对话框中，id必须是唯一的。
There are a number of optional attributes that provide identification information about the dialog:
有许多可选属性可提供有关对话框的标识信息：
o call-id: This attribute is a string that represents the call-id component of the dialog identifier. (Note that single and double quotes inside a call-id must be escaped using "e; for " and ' for ' .)
o 调用id：该属性是一个字符串，表示对话框标识符的调用id组件。（请注意，调用id中的单引号和双引号必须使用"e；for“和&apos；for.”进行转义。）
o local-tag: This attribute is a string that represents the local-tag component of the dialog identifier.
o 本地标记：此属性是一个字符串，表示对话框标识符的本地标记组件。
o remote-tag: This attribute is a string that represents the remote-tag component of the dialog identifier. The remote tag attribute won't be present if there is only a "half-dialog",
o 远程标记：此属性是一个字符串，表示对话框标识符的远程标记组件。如果只有“半个对话框”，则远程标记属性将不存在，
resulting from the generation of an INVITE for which no final responses or provisional responses with tags has been received.
由于生成邀请，未收到带有标记的最终响应或临时响应。
o direction: This attribute is either initiator or recipient, and indicates whether the observed user was the initiator of the dialog, or the recipient of the INVITE that created it.
o 方向：此属性是启动器或收件人，并指示观察到的用户是对话框的启动器，还是创建对话框的邀请的收件人。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>
The sub-elements of the dialog element provide additional information about the dialog. Some of these sub-elements provide more detail about the dialog itself, while the local and remote sub-elements describe characteristics of the participants involved in the dialog. The only mandatory sub-element is the state element.
dialog元素的子元素提供有关对话框的附加信息。其中一些子元素提供了有关对话框本身的更多细节，而本地和远程子元素描述了对话框中涉及的参与者的特征。唯一必需的子元素是state元素。
The "state" element indicates the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above. It has an optional event attribute that can be used to indicate the event that caused any transition into the terminated state, and an optional code attribute that indicates the response code associated with any transition caused by a response to the original INVITE.
“state”元素表示对话框的状态。它的值是一个枚举类型，描述上述FSM中的一个状态。它有一个可选的事件属性，可用于指示导致任何转换到终止状态的事件，还有一个可选的代码属性，可用于指示与原始INVITE响应导致的任何转换相关联的响应代码。
<state event="rejected" code="486">terminated</state>
<state event="rejected" code="486">terminated</state>
The "duration" element contains the amount of time, in seconds, since the FSM was created.
“duration”元素包含自创建FSM以来的时间量（以秒为单位）。
<duration>145</duration>
<duration>145</duration>
The "replaces" element is used to correlate a new dialog with one it replaced as a result of an invitation with a Replaces header field. This element is present in the replacement dialog only (the newer dialog) and contains attributes with the call-id, local-tag, and remote-tag of the replaced dialog.
“replaces”元素用于将一个新对话框与一个由于带有replaces标题字段的邀请而被替换的对话框相关联。此元素仅存在于替换对话框（较新的对话框）中，并包含具有被替换对话框的调用id、本地标记和远程标记的属性。
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>
The "referred-by" element is used to correlate a new dialog with a REFER [12] request that triggered it. The element is present in a dialog that was triggered by a REFER request that contained a Referred-By [11] header field and contains the (optional) display name attribute and the Referred-By URI as its value.
“Referenced by”元素用于将新对话框与触发它的REFER[12]请求关联起来。元素出现在一个对话框中，该对话框由一个REFERER请求触发，该请求包含REFERED by[11]头字段，并包含（可选）display name属性和REFERED by URI作为其值。
<referred-by display="Bob">sip:bob@example.com</referred-by>
<referred-by display="Bob">sip:bob@example.com</referred-by>
The "local" and "remote" elements are sub-elements of the dialog element that contain information about the local and remote participants, respectively. They both have a number of optional sub-elements that indicate the identity conveyed by the participant, the target URI, the feature-tags of the target, and the session-description of the participant.
“本地”和“远程”元素是dialog元素的子元素，分别包含关于本地和远程参与者的信息。它们都有许多可选的子元素，这些子元素指示参与者传递的身份、目标URI、目标的特征标记以及参与者的会话描述。
The "identity" element indicates a local or remote URI, as defined in [2] as appropriate. It has an optional attribute, display, that contains the display name from the appropriate URI.
“identity”元素表示本地或远程URI，如[2]中所定义。它有一个可选属性display，该属性包含相应URI中的显示名称。
Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant. To avoid repeating identity information in each request, the subscriber can assume that the identity URIs are the same as in previous notifications if no identity elements are present in the corresponding local or remote element. If any identity elements are present in the local or remote part of a notification, the new list of identity tags completely supersedes the old list in the corresponding part.
请注意，如果多个标识（例如sip:URI和tel:URI）都对应于参与者，则可以包含它们。为了避免在每个请求中重复标识信息，如果相应的本地或远程元素中不存在标识元素，则订阅者可以假定标识URI与以前的通知中相同。如果通知的本地或远程部分中存在任何标识元素，则新的标识标记列表将完全取代相应部分中的旧列表。
<identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>
<identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>
The "target" contains the local or remote target URI constructed by the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" attribute.
“目标”包含用户代理为此对话框构造的本地或远程目标URI，如RFC 3261[2]中“URI”属性中所定义。
It can contain a list of Contact header parameters in param sub-elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped.
它可以包含参数子元素（如[10]中定义的参数）中的联系人标头参数列表。param元素包含两个必需的属性，pname和pval。布尔参数由显式pval值“true”和“false”表示（例如，当要素参数显式求反时）。完全没有值的参数由显式pval值“true”表示。param元素本身没有内容。为了避免在每个请求中重复联系人信息，如果相应的本地或远程元素中不存在目标元素，则订阅者可以假定目标URI和参数与以前的通知中的相同。如果通知的本地或远程部分中存在目标元素，则新的目标标记和参数标记列表将完全取代相应部分中的旧目标和参数列表。请注意，任何引号（包括[10]中用于引用字符串值的额外尖括号引号）或反斜杠转义必须在放入pval属性之前删除。任何剩余的单引号、双引号和符号都必须正确地进行XML转义。
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk & office"/>
<param pname="sip.rendering" pval="no"/>
</target>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk & office"/>
<param pname="sip.rendering" pval="no"/>
</target>
The session-description element contains the session description used by the observed user for its end of the dialog. This element should generally NOT be included in the notifications, unless it was explicitly requested by the subscriber. It has a single attribute, "type", which indicates the MIME media type of the session description. To avoid repeating session description information in each request, the subscriber can assume that the session description is the same as in previous notifications if no session description element is present in the corresponding local or remote element.
session description元素包含观察到的用户在对话框结束时使用的会话描述。此元素通常不应包含在通知中，除非订阅者明确请求它。它只有一个属性“type”，表示会话描述的MIME媒体类型。为了避免在每个请求中重复会话描述信息，如果相应的本地或远程元素中不存在会话描述元素，则订阅者可以假定会话描述与先前通知中的会话描述相同。
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
The dialog information subscriber maintains a table listing the dialogs, with a row for each dialog. Each row is indexed by an ID that is present in the "id" attribute of the "dialog" element. Each row contains the state of that dialog, as conveyed in the document.
对话框信息订阅服务器维护一个列出对话框的表，每个对话框有一行。每一行都由“dialog”元素的“ID”属性中存在的ID索引。每行包含该对话框的状态，如文档中所示。
The table is also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "dialog-info" element in the first document received. Each time a new document is received, the value of the local version number is compared to the "version" attribute in the new document. 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 and the document is processed. If the document did not contain full state, the subscriber SHOULD generate a refresh request (SUBSCRIBE) to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
该表还与版本号关联。版本号必须使用收到的第一个文档中“dialog info”元素的“version”属性值初始化。每次收到新文档时，都会将本地版本号的值与新文档中的“版本”属性进行比较。如果新文档中的值比本地版本号高一个，则本地版本号将增加一个，并处理文档。如果文档中的值比本地版本号高出一个以上，则本地版本号将设置为新文档中的值，并处理文档。如果文档不包含完整状态，订阅服务器应生成刷新请求（订阅）以触发完整状态通知。如果文档中的值小于本地版本，则文档将在不进行处理的情况下丢弃。
The processing of the dialog information 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 "dialog-info" element, the contents of the table are flushed and then repopulated from the document. A new row in the table is created for each "dialog" element. If the document contains partial state, as indicated by the value of the "state" attribute in the "dialog-info" element, the document is used to update the table. For each "dialog" element in the document, the subscriber checks to see whether a row exists for that dialog. This check compares the ID in the "id" attribute of the "dialog" element with the ID associated with the row. If the dialog does not exist in the table, a row is added and
对话框信息文档的处理取决于它是包含完全状态还是部分状态。如果它包含完整状态（由“dialog info”元素中的“state”属性的值表示），则刷新表的内容，然后从文档中重新填充。将为每个“对话框”元素创建表中的新行。如果文档包含部分状态，如“dialog info”元素中“state”属性的值所示，则文档将用于更新表。对于文档中的每个“dialog”元素，订阅者检查该对话框是否存在一行。此检查将“dialog”元素的“ID”属性中的ID与与行关联的ID进行比较。如果该对话框在表中不存在，则会添加一行并
its state is set to the information from that "dialog" element. If the dialog does exist, its state is updated to be the information from that "dialog" 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.
其状态设置为来自该“对话框”元素的信息。如果对话框确实存在，则其状态将更新为来自该“对话框”元素的信息。如果行被更新或创建，以致其状态现在已终止，则可以随时从表中删除该条目。
The following is the schema for the application/dialog-info+xml type:
以下是应用程序/对话框信息+xml类型的架构：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
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"/>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
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="dialog-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:dialog" 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:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dialog-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:dialog" 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:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dialog">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:element name="dialog">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:complexType>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
This section defines two new media feature parameters that are useful as input to user presence, in conferencing applications, and in applications like the shared-line example described in Section 6.2. These feature parameters are especially useful in combination with the dialog package, as they allow an authorized third party to become aware of these characteristics.
本节定义了两个新的媒体功能参数，它们在会议应用程序和第6.2节所述的共享线路示例等应用程序中用作用户状态的输入。这些特性参数与dialog软件包结合使用时特别有用，因为它们允许授权的第三方了解这些特性。
The "sip.byeless" media feature parameter is a new boolean parameter, defined in this document, that provides a positive indication that the user agent setting the parameter is unable to terminate sessions on its own (for example, by sending a BYE request). For example,
“sip.byless”媒体功能参数是本文档中定义的一个新布尔参数，它提供了一个肯定的指示，表明设置该参数的用户代理无法自行终止会话（例如，通过发送BYE请求）。例如
continuous announcement services and certain recording services are unable to determine when it would be desirable to terminate a session, and therefore they do not have the ability to terminate sessions at all. Also, many human call centers are configured so that they never terminate sessions. (This is to prevent call center agents from accidentally disconnecting the caller). (Note that per [10], this parameter name must be preceded by a "+" character when used in a SIP Contact header field.)
连续公告服务和某些录音服务无法确定何时需要终止会话，因此它们根本无法终止会话。此外，许多人工呼叫中心的配置使其永远不会终止会话。（这是为了防止呼叫中心代理意外断开呼叫方的连接）。（请注意，根据[10]，当在SIP联系人标头字段中使用时，此参数名称必须以“+”字符开头。）
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless
The "sip.rendering" media feature parameter is a new string parameter, defined in this document, that can provide a positive indication whether the user agent setting the parameter is currently rendering any of the media it is receiving in the context of a specific session. It MUST only be used in a Contact header field in a dialog created using the INVITE request.
“sip.rendering”媒体功能参数是本文档中定义的一个新字符串参数，它可以提供一个肯定的指示，即设置该参数的用户代理当前是否正在呈现它在特定会话上下文中接收的任何媒体。它只能在使用INVITE请求创建的对话框中的联系人标题字段中使用。
This parameter has three legal values: "yes", "no", and "unknown". The value "yes" indicates positive knowledge that the user agent is rendering at least one of the streams of media that it is receiving. The value "no" indicates positive knowledge that the user agent is rendering none of the media that it is receiving. The value "unknown" indicates that the user agent does not know whether the media associated with the session is being rendered (which may be the case if the user agent is acting as a 3pcc (Third Party Call Control) [19] controller).
此参数有三个合法值：“是”、“否”和“未知”。值“是”表示用户代理正在呈现其正在接收的媒体流中的至少一个的肯定知识。值“否”表示用户代理正在呈现其正在接收的任何媒体。值“未知”表示用户代理不知道是否正在呈现与会话相关联的媒体（如果用户代理充当3pcc（第三方呼叫控制）[19]控制器，则可能是这种情况）。
The "sip.rendering" parameter is useful in applications such as shared appearances, conference status monitoring, or as an input to user presence.
“sip.rendering”参数在诸如共享外观、会议状态监视或作为用户状态的输入等应用程序中非常有用。
Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no"
Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no"
For example, if a UAC sends an INVITE that looks, in part, like:
例如，如果UAC发送的邀请在某种程度上类似于：
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
[SDP not shown]
[未显示SDP]
The XML document in a notification from Alice might look like:
Alice通知中的XML文档可能如下所示：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
</dialog>
</dialog-info>
If the following 180 response is received:
如果收到以下180响应：
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com>
The XML document in a notification might look like:
通知中的XML文档可能如下所示：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If it receives a second 180 with a different tag:
如果它接收到另一个带有不同标签的180：
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com>
This results in the creation of a second dialog:
这将导致创建第二个对话框：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If a 200 OK response is received on the second dialog, the dialog moves to confirmed:
如果在第二个对话框上收到200 OK响应，则该对话框移动到确认：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>confirmed</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>confirmed</state>
</dialog>
</dialog-info>
32 seconds later, the other early dialog terminates because no 2xx response has been received for it. This implies that it was successfully cancelled, and therefore the following notification is sent:
32秒后，另一个早期对话框终止，因为没有收到该对话框的2xx响应。这意味着它已成功取消，因此将发送以下通知：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
The following example shows how a SIP telephone user agent can provide detailed state information and also emulate a shared-line telephone system (the phone "lies" about having a dialog while it is merely offhook).
下面的示例显示了SIP电话用户代理如何提供详细的状态信息，以及如何模拟共享线路电话系统（电话“撒谎”说有一个对话框，而它只是脱离连接）。
Idle:
闲置：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Seized:
抓住：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>
Dialing:
拨号：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local>
<identity display="Alice Smith">
sip:alice@example.com
</identity>
<target uri="sip:alice@pc33.example.com"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local>
<identity display="Alice Smith">
sip:alice@example.com
</identity>
<target uri="sip:alice@pc33.example.com"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>
Ringing:
铃声：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>
Answered (by voicemail):
答复（通过语音邮件）：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice would rather talk to Bob's assistant (Cathy Jones) than to Bob's voicemail. She indicates this preference by pressing a key (perhaps "0" in North America or "9" in Europe). Bob's voicemail system then acts on this keypress by transferring [20] Alice's call to Cathy's AOR.
爱丽丝宁愿和鲍勃的助手（凯西·琼斯）交谈，也不愿和鲍勃的语音信箱交谈。她通过按一个键来表示这种偏好（在北美可能是“0”，在欧洲可能是“9”）。Bob的语音信箱系统通过将[20]Alice的电话转接到Cathy的AOR，从而对这个按键进行操作。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
<remote>
<identity display="Cathy Jones">
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
<remote>
<identity display="Cathy Jones">
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice and Cathy talk, Cathy adds Alice to a local conference:
Alice和Cathy交谈，Cathy将Alice加入本地会议：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice puts Cathy on hold:
艾丽斯让凯西等着：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
</dialog>
</dialog-info>
Cathy hangs up:
Cathy挂断电话：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>
Alice hangs up:
爱丽丝挂断了电话：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>
The following example shows the same user agent providing minimal information to maintain privacy for services like automatic callback.
下面的示例显示了同一个用户代理，该代理提供最少的信息来维护自动回调等服务的隐私。
Onhook:
挂机：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Offhook: (implementation/policy choice for Alice to transition to this "state" when "seized", when Trying, when Proceeding, or when Confirmed.)
摘机：（Alice在“被捕获”、“尝试”、“继续”或“确认”时转换到此“状态”的实现/策略选择。）
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">
<state>confirmed</state>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">
<state>confirmed</state>
</dialog>
</dialog-info>
Onhook: (implementation/policy choice for Alice to transition to this "state" when terminated, or when no longer "seized")
Onhook：（Alice在终止或不再“捕获”时转换到此“状态”的实现/策略选择）
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full"
entity="sip:alice@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full"
entity="sip:alice@example.com">
</dialog-info>
Subscriptions to dialog state can reveal sensitive information. For this reason, Section 3.6 discusses authentication and authorization of subscriptions, and provides guidelines on sensible authorization policies. All implementations of this package MUST support the digest authentication mechanism.
对对话框状态的订阅可能会泄露敏感信息。因此，第3.6节讨论了订阅的身份验证和授权，并提供了有关合理授权策略的指导原则。此包的所有实现都必须支持摘要身份验证机制。
Since the data in notifications is sensitive as well, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. User agents that implement the dialog package SHOULD also implement SIP over TLS [15] and the sips: scheme.
由于通知中的数据也是敏感的，因此可以使用使用S/MIME的端到端SIP加密机制对其进行保护。实现dialog包的用户代理还应通过TLS实现SIP[15]和sips:scheme。
This document registers a new MIME type, application/dialog-info+xml; a new XML namespace; and two new media feature parameters in the SIP tree.
此文档注册了一个新的MIME类型，即应用程序/对话框信息+xml；一个新的XML名称空间；以及SIP树中的两个新媒体特征参数。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: dialog-info+xml
MIME子类型名称：对话框信息+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 that use this media type: This document type has been used to support SIP applications such as call return and auto-conference.
使用此媒体类型的应用程序：此文档类型已用于支持SIP应用程序，如呼叫返回和自动会议。
Additional Information:
其他信息：
Magic Number: None File Extension: .xml Macintosh file type code: "TEXT"
幻数：无文件扩展名：.xml Macintosh文件类型代码：“TEXT”
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。
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info
This section registers a new XML namespace, per the guidelines in [7].
本节根据[7]中的指南注册一个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:dialog-info.
URI：此命名空间的URI为urn:ietf:params:xml:ns:dialog info。
Registrant Contact: The IESG, <iesg@ietf.org> XML:
注册人联系人：IESG<iesg@ietf.org>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>Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</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>Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</a>.</p>
</body>
</html>
END
This specification registers a schema, per the guidelines in [7].
本规范根据[7]中的指南注册了一个模式。
URI: urn:ietf:params:xml:schema:dialog-info
URI: urn:ietf:params:xml:schema:dialog-info
Registrant Contact: The IESG, <iesg@ietf.org>
Registrant Contact: The IESG, <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 4.4.
XML：XML是第4.4节的唯一内容。
This section registers two new media feature tags, per the procedures defined in RFC 2506 [14]. The tags are placed into the sip tree, which is defined in [10].
本节按照RFC 2506[14]中定义的程序注册两个新的媒体功能标签。标签被放置在sip树中，sip树在[10]中定义。
8.4.1. Media Feature Tag sip.byeless Media feature tag name sip.byeless
8.4.1. 媒体功能标签sip.byless媒体功能标签名称sip.byless
ASN.1 Identifier 19
ASN.1标识符19
Summary of the media feature indicated by this tag: This feature tag is a boolean flag. When set it indicates that the device is incapable of terminating a session autonomously.
此标记指示的媒体功能摘要：此功能标记是一个布尔标志。设置时，表示设备无法自动终止会话。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of an application, such as an announcement service, recording service, conference, or call center.
功能标签主要用于以下应用程序、协议、服务或协商机制：此功能标签在通信应用程序中最有用，用于描述应用程序的功能，例如公告服务、录音服务、会议或呼叫中心。
Examples of typical use: Call centers and media services.
典型使用示例：呼叫中心和媒体服务。
Related standards or documents: RFC 4235 Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set. Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity.
相关标准或文档：RFC 4235安全注意事项：此媒体功能标签可用于影响应用程序行为或可能泄露私人信息的方式。例如，如果设置了此媒体功能标签，会议或其他应用程序可能会决定提前终止呼叫。因此，如果攻击者可以修改此标记的值，则可能会影响应用程序的行为。因此，使用此媒体功能标签的应用程序应提供确保其完整性的方法。类似地，只有当此功能标签来自标签所描述的用户或用户代理时，才应将其视为有效。因此，传输此功能标签的协议应该提供一种保证真实性的机制。
Media feature tag name: sip.rendering
媒体功能标签名称：sip.rendering
ASN.1 Identifier: 20
ASN.1标识符：20
Summary of the media feature indicated by this tag: This feature tag contains one of three string values indicating if the device is rendering any media from the current session ("yes"), none of the media from the current session ("no"), or if this status is not known to the device ("unknown").
此标记指示的媒体功能摘要：此功能标记包含三个字符串值之一，指示设备是否正在呈现当前会话中的任何媒体（“是”）、当前会话中的任何媒体（“否”）或设备是否不知道此状态（“未知”）。
Values appropriate for use with this feature tag: String.
适用于此功能标记的值：字符串。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the state of a device (such as a phone or PDA) during a multimedia session.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述多媒体会话期间设备（例如电话或PDA）的状态。
Examples of typical use: Conferencing, telephone shared-line emulation, and presence applications.
典型使用示例：会议、电话共享线路模拟和状态显示应用程序。
Related standards or documents: RFC 4235
相关标准或文件：RFC 4235
Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set to "no". Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity.
安全注意事项：此媒体功能标签可用于影响应用程序行为或可能泄露私人信息的方式。例如，如果此媒体功能标签设置为“否”，则会议或其他应用程序可能会决定提前终止呼叫。因此，如果攻击者可以修改此标记的值，则可能会影响应用程序的行为。因此，使用此媒体功能标签的应用程序应提供确保其完整性的方法。类似地，只有当此功能标签来自标签所描述的用户或用户代理时，才应将其视为有效。因此，传输此功能标签的协议应该提供一种保证真实性的机制。
The authors would like to thank Sean Olson for his comments.
作者要感谢肖恩·奥尔森的评论。
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[2] 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.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.
[4] Paoli，J.，Sperberg McQueen，C.，Bray，T.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C第一版REC-XML-20001006，2000年10月。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[10] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[11] Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 38922004年9月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[13] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[13] Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[14] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[14] Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[16] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[16] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[17] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[17] Rosenberg，J.，“会话启动协议（SIP）的观察者信息事件模板包”，RFC3857，2004年8月。
[18] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[18] Mahy，R.，“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[19] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, July 2005.
[20] Sparks，R.，“会话启动协议呼叫控制-传输”，正在进行的工作，2005年7月。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027号
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor) SIP Edge LLC
Rohan Mahy（编辑）SIP Edge有限责任公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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编辑功能的资金目前由互联网协会提供。