Network Working Group J. Rosenberg
Request for Comments: 4538 Cisco Systems
Category: Standards Track June 2006
Network Working Group J. Rosenberg
Request for Comments: 4538 Cisco Systems
Category: Standards Track June 2006
Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
通过会话启动协议（SIP）中的对话标识请求授权
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.
本规范定义了会话启动协议（SIP）的目标对话框标题字段，以及相应的选项标记tdialog。此标头字段用于创建SIP对话框的请求中。它向收件人表明，发件人知道与收件人之间存在对话，这可能是因为发件人位于该对话的另一侧，也可能是因为发件人可以访问对话标识符。然后，接收者可以基于此感知对请求进行授权。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview of Operation ...........................................4
3. User Agent Client (UAC) Behavior ................................5
4. User Agent Server Behavior ......................................7
5. Proxy Behavior ..................................................8
6. Extensibility Considerations ....................................8
7. Header Field Definition .........................................9
8. Security Considerations .........................................9
9. Relationship with In-Reply-To ..................................10
10. Example Call Flow .............................................10
11. IANA Considerations ...........................................13
11.1. Header Field .............................................13
11.2. Header Field Parameters ..................................13
11.2.1. local-tag .........................................13
11.2.2. remote-tag ........................................13
11.3. SIP Option Tag ...........................................14
12. Acknowledgements ..............................................14
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................15
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview of Operation ...........................................4
3. User Agent Client (UAC) Behavior ................................5
4. User Agent Server Behavior ......................................7
5. Proxy Behavior ..................................................8
6. Extensibility Considerations ....................................8
7. Header Field Definition .........................................9
8. Security Considerations .........................................9
9. Relationship with In-Reply-To ..................................10
10. Example Call Flow .............................................10
11. IANA Considerations ...........................................13
11.1. Header Field .............................................13
11.2. Header Field Parameters ..................................13
11.2.1. local-tag .........................................13
11.2.2. remote-tag ........................................13
11.3. SIP Option Tag ...........................................14
12. Acknowledgements ..............................................14
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................15
The Session Initiation Protocol (SIP) [2] defines the concept of a dialog as a persistent relationship between a pair of user agents. Dialogs provide context, including sequence numbers, proxy routes, and dialog identifiers. Dialogs are established through the transmission of SIP requests with particular methods. Specifically, the INVITE, REFER [8], and SUBSCRIBE [3] requests all create dialogs.
会话启动协议（SIP）[2]将对话的概念定义为一对用户代理之间的持久关系。对话框提供上下文，包括序列号、代理路由和对话框标识符。通过使用特定方法传输SIP请求来建立对话。具体来说，INVITE、reference[8]和SUBSCRIBE[3]请求所有创建对话框。
When a user agent receives a request that creates a dialog, it needs to decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified in which a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whether the sender of the request is aware of a dialog the user agent has with another entity.
当用户代理收到创建对话框的请求时，它需要决定是否授权该请求。对于某些请求，授权是发送者身份、请求方法等的函数。然而，已经确定了许多情况，其中用户代理的授权决定取决于请求的发送者当前是否处于与该用户代理的对话中，或者请求的发送者是否知道用户代理与另一实体的对话。
One such example is call transfer, accomplished through REFER. If user agents A and B are in an INVITE dialog, and user agent A wishes to transfer user agent B to user agent C, user agent A needs to send a REFER request to user agent B, asking user agent B to send an INVITE request to user agent C. User agent B needs to authorize this REFER. The proper authorization decision is that user agent B should accept the request if it came from a user with whom B currently has an INVITE dialog relationship. Current implementations deal with this by sending the REFER on the same dialog as the one in place between user agents A and B. However, this approach has numerous problems [12]. These problems include difficulties in determining the lifecycle of the dialog and its usages and in determining which messages are associated with each application usage. Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER.
一个这样的例子是呼叫转移，通过REFER完成。如果用户代理A和B处于INVITE对话框中，并且用户代理A希望将用户代理B转移到用户代理C，则用户代理A需要向用户代理B发送REFER请求，要求用户代理B向用户代理C发送INVITE请求。用户代理B需要授权此REFER。正确的授权决策是，如果请求来自B当前与之具有邀请对话框关系的用户，则用户代理B应接受该请求。当前的实现通过在用户代理A和B之间的同一个对话框上发送reference来解决这个问题。然而，这种方法存在许多问题[12]。这些问题包括难以确定对话框的生命周期及其用法，以及难以确定哪些消息与每个应用程序用法相关联。相反，更好的方法是用户代理a将REFER请求发送到对话框外部的用户代理B。在这种情况下，用户代理B需要一种方法来授权引用。
Another example is the application interaction framework [14]. In that framework, proxy servers on the path of a SIP INVITE request can place user interface components on the user agent that generated or received the request. To do this, the proxy server needs to send a REFER request to the user agent, targeted to its Globally Routable User Agent URI (GRUU) [13], asking the user agent to fetch an HTTP resource containing the user interface component. In such a case, a means is needed for the user agent to authorize the REFER. The application interaction framework recommends that the request be authorized if it was sent from an entity on the path of the original dialog. This can be done by including the dialog identifiers in the
另一个例子是应用程序交互框架[14]。在该框架中，SIP INVITE请求路径上的代理服务器可以在生成或接收请求的用户代理上放置用户界面组件。为此，代理服务器需要向用户代理发送一个REFER请求，以其全局可路由用户代理URI（GRUU）[13]为目标，要求用户代理获取包含用户界面组件的HTTP资源。在这种情况下，用户代理需要一种方法来授权引用。应用程序交互框架建议，如果请求是从原始对话框路径上的实体发送的，则应授权该请求。这可以通过将对话框标识符包含在
REFER, which prove that the user agent that sent the REFER is aware of those dialog identifiers (this needs to be secured against eavesdroppers through the sips mechanism, of course).
REFER，这证明发送REFER的用户代理知道这些对话框标识符（当然，这需要通过sips机制防止窃听）。
Another example is if two user agents share an INVITE dialog, and an element on the path of the INVITE request wishes to track the state of the INVITE. In such a case, it sends a SUBSCRIBE request to the GRUU of the user agent, asking for a subscription to the dialog event package. If the SUBSCRIBE request came from an element on the INVITE request path, it should be authorized.
另一个示例是，如果两个用户代理共享一个INVITE对话框，INVITE请求路径上的元素希望跟踪INVITE的状态。在这种情况下，它向用户代理的GRUU发送订阅请求，请求订阅对话事件包。如果订阅请求来自INVITE请求路径上的元素，则应该对其进行授权。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
+--------+ +--------+
| | INVITE | |
| Server |----------->| Server |
| A | | B |
| |...........>| |
+--------+ +--------+
^ REFER . \
/ . \
/ . \
/ . \
/ . \
/ V V
+--------+ +--------+
| | | |
| User | | User |
| Agent | | Agent |
| A | | B |
+--------+ +--------+
+--------+ +--------+
| | INVITE | |
| Server |----------->| Server |
| A | | B |
| |...........>| |
+--------+ +--------+
^ REFER . \
/ . \
/ . \
/ . \
/ . \
/ V V
+--------+ +--------+
| | | |
| User | | User |
| Agent | | Agent |
| A | | B |
+--------+ +--------+
Figure 1
图1
Figure 1 shows the basic model of operation. User agent A sends an INVITE to user agent B, traversing two servers, server A and server B. Both servers act as proxies for this transaction. User B sends a 200 OK response to the INVITE. This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). The 200 OK response establishes a dialog between the two user agents.
图1显示了操作的基本模型。用户代理A向用户代理B发送一个INVITE，遍历服务器A和服务器B这两个服务器。这两个服务器都充当此事务的代理。用户B向邀请发送200 OK响应。此200 OK包括一个受支持的标题字段，指示对本规范的支持（通过tdialog选项标签的存在）。200 OK响应在两个用户代理之间建立对话。
Next, an entity that was present along the request path (server A, for example) wishes to send a dialog-forming request (such as REFER) to user agent A or B (user B for example). So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it can be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE), then the mechanism will work across NAT boundaries.
接下来，沿着请求路径存在的实体（例如，服务器A）希望向用户代理A或B（例如，用户B）发送对话形成请求（例如，REFER）。因此，该实体充当用户代理并将请求发送给用户代理B。该请求被发送到用户代理B的URI，服务器a通过检查INVITE请求的200 OK中的Contact header字段了解到该URI。如果此URI具有GRUU[11]属性（它可以被Internet上的任何元素（如服务器A）使用，以到达生成200 OK to INVITE的特定用户代理实例），那么该机制将跨NAT边界工作。
The request generated by server A will contain a Target-Dialog header field. This header field contains the dialog identifiers for the INVITE dialog between user agents A and B, composed of the Call-ID, local tag, and remote tag. Server A knew to include the Target-Dialog header field in the REFER request because it knows that user agent B supports it.
服务器A生成的请求将包含一个目标对话框头字段。此标头字段包含用户代理A和B之间的INVITE对话框的对话框标识符，由调用ID、本地标记和远程标记组成。服务器A知道在引用请求中包含目标对话框头字段，因为它知道用户代理B支持该字段。
When the request arrives at user agent B, it needs to make an authorization decision. Because the INVITE dialog was established using a sips URI, and because the dialog identifiers are cryptographically random [2], no entity except for user agent A or the proxies on the path of the initial INVITE request can know the dialog identifiers. Thus, because the request contains those dialog identifiers, user agent B can be certain that the request came from user agent A, the two proxies, or an entity to whom the user agent or proxies gave the dialog identifiers. As such, it authorizes the request and performs the requested actions.
当请求到达用户代理B时，它需要做出授权决策。由于INVITE对话框是使用sips URI建立的，并且由于对话框标识符是加密随机的[2]，因此除了用户代理a或初始INVITE请求路径上的代理之外，没有任何实体可以知道对话框标识符。因此，由于请求包含那些对话标识符，用户代理B可以确定请求来自用户代理A、两个代理或用户代理向其提供对话标识符的实体。因此，它授权请求并执行请求的操作。
A UAC SHOULD include a Target-Dialog header field in a request if the following conditions are all true:
如果以下条件均为真，UAC应在请求中包含目标对话框标题字段：
1. The request is to be sent outside of any existing dialog.
1. 请求将在任何现有对话框之外发送。
2. The user agent client believes that the request may not be authorized by the user agent server unless the user agent client can prove that it is aware of the dialog identifiers for some other dialog. Call this dialog the target dialog.
2. 用户代理客户端认为，除非用户代理客户端能够证明它知道某个其他对话框的对话框标识符，否则该请求可能不会被用户代理服务器授权。将此对话框称为目标对话框。
3. The request does not otherwise contain information that indicates that the UAC is aware of those dialog identifiers.
3. 该请求不包含指示UAC知道这些对话框标识符的信息。
4. The user agent client knows that the user agent server supports the Target-Dialog header field. It can know this if it has seen a request or response from the user agent server within the target dialog that contained a Supported header field that included the tdialog option tag.
4. 用户代理客户端知道用户代理服务器支持目标对话框标题字段。如果它在目标对话框中看到来自用户代理服务器的请求或响应，并且该对话框包含包含tdialog选项标记的受支持标头字段，则它可以知道这一点。
If the fourth condition is not met, the UAC SHOULD NOT use this specification. Instead, if it is currently within a dialog with the User Agent Server (UAS), it SHOULD attempt to send the request within the existing target dialog.
如果不满足第四个条件，UAC不应使用本规范。相反，如果它当前位于与用户代理服务器（UAS）的对话框中，则它应尝试在现有目标对话框中发送请求。
The following are examples of use cases in which these conditions are met:
以下是满足这些条件的用例示例：
o A REFER request is sent according to the principles of [14]. These REFER are sent outside of a dialog and do not contain any other information that indicates awareness of the target dialog. [14] also mandates that the REFER be sent only if the UA indicates support for the target dialog specification.
o 参考请求根据[14]的原则发送。这些引用是在对话框外部发送的，不包含任何其他表示已识别目标对话框的信息。[14] 还要求仅当UA表示支持目标对话框规范时才发送REFER。
o User A is in separate calls with users B and C. User A decides to start a three way call, and so morphs into a focus [17]. User B would like to learn the other participants in the conference. So, it sends a SUBSCRIBE request to user A (who is now acting as the focus) for the conference event package [16]. It is sent outside of the existing dialog between user B and the focus, and it would be authorized by A if user B could prove that it knows the dialog identifiers for its existing dialog with the focus. Thus, the Target-Dialog header field would be included in the SUBSCRIBE.
o 用户A与用户B和C分别进行通话。用户A决定开始一个三方通话，因此演变成焦点[17]。用户B希望了解会议的其他参与者。因此，它向用户a（现在作为焦点）发送会议事件包的订阅请求[16]。它被发送到用户B和焦点之间的现有对话之外，如果用户B能够证明它知道其与焦点之间的现有对话的对话标识符，它将被A授权。因此，目标对话框标题字段将包含在订阅中。
The following are examples of use cases in which these conditions are not met:
以下是不满足这些条件的用例示例：
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the Keypad Markup Language (KPML) event package [18] to find out about keypresses from the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription. As such, the request can be authorized without additional information.
o 充当代理的服务器是建立会话的INVITE对话框的参与者。服务器希望使用键盘标记语言（KPML）事件包[18]从原始用户代理查找有关按键的信息。为此，它发送一个订阅请求。但是，此订阅的事件标头字段包含指示订阅的目标对话框的事件参数。因此，可以在不提供额外信息的情况下对请求进行授权。
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the dialog event package [15] to find out about dialogs at the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription.
o 充当代理的服务器是建立会话的INVITE对话框的参与者。服务器希望使用dialog事件包[15]查找有关原始用户代理上的对话框的信息。为此，它发送一个订阅请求。但是，此订阅的事件标头字段包含指示订阅的目标对话框的事件参数。
As such, the request can be authorized without additional information.
因此，可以在不提供额外信息的情况下对请求进行授权。
Specifications that intend to make use of the Target-Dialog header field SHOULD discuss specific conditions in which it is to be included.
打算使用目标对话框标题字段的规范应讨论包含该字段的具体条件。
Assuming it is to be included, the value of the callid production in the Target-Dialog header field MUST be equal to the Call-ID of the target dialog. The "remote-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the remote tag from the perspective of the recipient of the new request. The "local-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the local tag from the perspective of the recipient of the new request.
假设要包括callid，则目标对话框标题字段中callid production的值必须等于目标对话框的调用ID。“remote tag”标头字段参数必须存在，并且必须包含从新请求的接收者的角度将被视为远程标记的标记。“local tag”标头字段参数必须存在，并且必须包含从新请求的接收者的角度将被视为本地标记的标记。
The request sent by the UAC SHOULD include a Require header field that includes the tdialog option tag. This request should, in principle, never fail with a 420 (Bad Extension) response, because the UAC would not have sent the request unless it believed the UAS supported the extension. If a Require header field was not included, and the UAS didn't support the extension, it would normally reject the request because it was unauthorized, probably with a 403. However, without the Require header field, the UAC would not be able to differentiate between the following:
UAC发送的请求应包括一个包含tdialog选项标签的Require标头字段。原则上，此请求不会因420（错误扩展）响应而失败，因为UAC不会发送请求，除非它相信UAS支持扩展。如果不包括Require header字段，并且UAS不支持该扩展，它通常会拒绝该请求，因为该请求未经授权，可能是403。但是，如果没有Require header字段，UAC将无法区分以下各项：
o a 403 that arrived because the UAS didn't actually understand the Target-Dialog header field (in which case the client should send the request within the target dialog if it can)
o 403，因为UAS实际上不理解目标对话框标题字段（在这种情况下，客户机应该在目标对话框中发送请求，如果可以的话）
o a 403 that arrived because the UAS understood the Target-Dialog header field, but elected not to authorize the request despite the fact that the UAC proved its awareness of the target dialog (in which case the client should not resend the request within the target dialog, even if it could).
o 403，因为UAS理解目标对话框标题字段，但选择不授权请求，尽管UAC证明其知道目标对话框（在这种情况下，客户端不应在目标对话框内重新发送请求，即使它可以）。
If a user agent server receives a dialog-creating request and wishes to authorize the request, and if that authorization depends on whether or not the sender has knowledge of an existing dialog with the UAS, and information outside of the Target-Dialog header field does not provide proof of this knowledge, the UAS SHOULD check the request for the existence of the Target-Dialog header field. If this header field is not present, the UAS MAY still authorize the request by other means.
如果用户代理服务器收到对话创建请求并希望授权该请求，并且该授权取决于发送方是否知道与UAS的现有对话，并且目标对话标题字段之外的信息不提供此知识的证明，UAS应检查请求是否存在目标对话框标题字段。如果此标头字段不存在，UAS仍可通过其他方式授权请求。
If the header field is present, and the value of the callid production, the "remote-tag", and "local-tag" values match the Call-ID, remote tag, and local tag of an existing dialog, and the dialog that they match was established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog.
如果存在标题字段，且callid production的值、“remote tag”和“local tag”值与现有对话框的调用ID、remote tag和local tag匹配，并且它们匹配的对话框是使用sips URI建立的，如果UAS将授权创建该对话框的请求路径上的任何实体，或创建该对话框的请求路径上的实体信任的任何实体，则UAS应授权该请求。
If the dialog identifiers match, but they match a dialog not created with a sips URI, the UAS MAY authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. However, in this case, any eavesdropper on the original dialog path would have access to the dialog identifiers, and thus the authorization is optional.
如果对话框标识符匹配，但它们与未使用sips URI创建的对话框匹配，则UAS可以授权请求，前提是它将授权创建该对话框的请求路径上的任何实体，或者授权创建该对话框的请求路径上的实体信任的任何实体。但是，在这种情况下，原始对话路径上的任何窃听者都可以访问对话标识符，因此授权是可选的。
If the dialog identifiers don't match, or if they don't contain both a "remote-tag" and "local-tag" parameter, the header field MUST be ignored, and authorization MAY be determined by other means.
如果对话框标识符不匹配，或者它们不同时包含“远程标记”和“本地标记”参数，则必须忽略标题字段，并且可以通过其他方式确定授权。
Proxy behavior is unaffected by this specification.
代理行为不受此规范的影响。
This specification depends on a user agent client knowing, ahead of sending a request to a user agent server, whether or not that user agent server supports the Target-Dialog header field. As discussed in Section 3, the UAC can know this because it saw a request or response sent by that UAS within the target dialog that contained the Supported header field whose value included the tdialog option tag.
此规范取决于用户代理客户端在向用户代理服务器发送请求之前知道该用户代理服务器是否支持目标对话框头字段。如第3节所述，UAC可以知道这一点，因为它在目标对话框中看到该UAS发送的请求或响应，该对话框包含支持的标题字段，其值包括tdialog选项标记。
Because of this requirement, it is especially important that user agents compliant to this specification include a Supported header field in all dialog forming requests and responses. Inclusion of the Supported header fields in requests is at SHOULD strength per RFC 3261. This specification does not alter that requirement. However, implementers should realize that, unless the tdialog option tag is placed in the Supported header field of requests and responses, this extension is not likely to be used, and instead, the request is likely to be re-sent within the existing target dialog (assuming the sender is the UA on the other side of the target dialog). As such, the conditions in which the SHOULD would not be followed would be those rare cases in which the UA does not want to enable usage of this extension.
由于这一要求，符合本规范的用户代理在所有对话框形成请求和响应中包括一个受支持的头字段尤为重要。根据RFC3261，请求中包含受支持的头字段的强度应为。本规范不改变该要求。然而，实施者应该意识到，除非tdialog选项标记被放置在请求和响应的受支持的头字段中，否则不可能使用此扩展，相反，请求可能在现有目标对话框中重新发送（假设发送者是目标对话框另一侧的UA）。因此，不应遵循的条件是UA不希望使用此扩展的罕见情况。
The grammar for the Target-Dialog header field is defined as follows:
目标对话框标题字段的语法定义如下：
Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI
td-param) ;callid from RFC 3261
td-param = remote-param / local-param /
generic-param
remote-param = "remote-tag" EQUAL token
local-param = "local-tag" EQUAL token
;token and generic-param from RFC 3261
Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI
td-param) ;callid from RFC 3261
td-param = remote-param / local-param /
generic-param
remote-param = "remote-tag" EQUAL token
local-param = "local-tag" EQUAL token
;token and generic-param from RFC 3261
Figures 3 and 4 are an extension of Tables 2 and 3 in RFC 3261 [2] for the Target-Dialog header field. The column "INF" is for the INFO method [4], "PRA" is for the PRACK method [5], "UPD" is for the UPDATE method [6], "SUB" is for the SUBSCRIBE method [3], "NOT" is for the NOTIFY method [3], "MSG" is for the MESSAGE method [7], "REF" is for the REFER method [8], and "PUB" is for the PUBLISH method [9].
图3和图4是RFC 3261[2]中表2和表3对目标对话框标题字段的扩展。列“INF”表示INFO方法[4]，“PRA”表示PRACK方法[5]，“UPD”表示更新方法[6]，“SUB”表示订阅方法[3]，“NOT”表示通知方法[3]，“MSG”表示消息方法[7]，“REF”表示引用方法[8]，“PUB”表示发布方法[9]。
Header field where proxy ACK BYE CAN INV OPT REG PUB
代理确认BYE可以INV OPT REG PUB的标头字段
Target-Dialog R - - - - o - - -
Target-Dialog R - - - - o - - -
Figure 3: Allowed Methods for Target-Dialog
图3：目标对话框允许的方法
Header field where proxy PRA UPD SUB NOT INF MSG REF
头字段，其中代理PRA UPD SUB不是INF MSG REF
Target-Dialog R - - - o - - - o
Target-Dialog R - - - o - - - o
Figure 4: Allowed Methods for Target-Dialog
图4：目标对话框允许的方法
The Target-Dialog header field is used to authorize requests based on the fact that the sender of the request has access to information that only certain entities have access to. In order for such an authorization decision to be secure, two conditions have to be met. Firstly, no eavesdroppers can have access to this information. That requires the original SIP dialog to be established using a sips URI, which provides TLS on each hop. With a sips URI, only the user agents and proxies on the request path will be able to know the dialog identifiers. The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration of a typical dialog (perhaps as long as a day), this amount of randomness appears adequate for
目标对话框标题字段用于根据请求的发送方可以访问只有某些实体可以访问的信息这一事实来授权请求。为了确保这种授权决定的安全，必须满足两个条件。首先，任何窃听者都无法获得这些信息。这要求使用sips URI建立原始SIP对话框，该URI在每个跃点上提供TLS。使用sips URI，只有请求路径上的用户代理和代理才能知道对话框标识符。第二个条件是，对话框标识符在加密方面具有足够的随机性，因此无法猜测。RFC 3261要求调用ID具有全局唯一性，每个标记具有32位加密随机性（一个对话框有两个标记）。考虑到一个典型对话框的持续时间很短（可能长达一天），这种随机性似乎足以满足用户的需求
preventing guessing attacks. However, it's important to note that this specification requires true cryptographic randomness as set forth in RFC 4086 [11]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, they are not sufficient to prevent an attacker from observing a sequence of identifiers, guessing the next one, and then using this specification to launch an attack.
防止猜测攻击。然而，需要注意的是，该规范要求RFC 4086[11]中规定的真正的密码随机性。较弱的伪随机标识符会降低冲突概率，但由于它们是可猜测的，因此不足以防止攻击者观察标识符序列，猜测下一个标识符，然后使用此规范发起攻击。
RFC 3261 defines the In-Reply-To header field. It provides a list of Call-IDs for calls that the current request references or returns. It was meant to serve a similar purpose as the Reply-To in email: to facilitate the construction of "threads" of conversations in a user interface. Target-Dialog is similar, in that it also references a previous session. Due to their similarities, it is important to understand the differences, as these two header fields are not substitutes for each other.
RFC 3261定义回复标头字段。它为当前请求引用或返回的调用提供调用ID列表。它的作用与电子邮件中的回复类似：促进用户界面中对话“线程”的构建。目标对话框与此类似，因为它还引用了上一个会话。由于它们的相似性，理解它们之间的差异很重要，因为这两个标题字段不是相互替代的。
Firstly, In-Reply-To is meant for consumption by a human or a user interface widget, for providing the user with a context that allows them to decide what a call is about and whether they should take it. Target-Dialog, on the other hand, is meant for consumption by the user agent itself, to facilitate authorization of session requests in specific cases where authorization is not a function of the user, but rather the underlying protocols. A UA will authorize a call containing Target-Dialog based on a correct value of the Target-Dialog header field.
首先，“回复”是指供人或用户界面小部件使用的，用于向用户提供一个上下文，该上下文允许用户决定呼叫的内容以及是否应该接听。另一方面，目标对话框旨在供用户代理本身使用，以便于在授权不是用户的功能而是底层协议的特定情况下对会话请求进行授权。UA将根据目标对话框标题字段的正确值授权包含目标对话框的调用。
Secondly, Target-Dialog references a specific dialog that must be currently in progress. In-Reply-To references a previous call attempt, most likely one that did not result in a dialog. This is why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of dialog identifiers.
其次，目标对话框引用当前必须进行的特定对话框。在回复引用之前的调用尝试时，很可能是没有导致对话的调用尝试。这就是为什么在应答中使用调用ID，而目标对话框使用一组对话框标识符的原因。
Finally, In-Reply-To implies cause and effect. When In-Reply-To is present, it means that the request is being sent because of the previous request that was delivered. Target-Dialog does not imply cause and effect, merely awareness for the purposes of authorization.
最后，在回答中暗示因果关系。当存在“答复”时，这意味着发送请求是因为之前的请求已传递。目标对话框并不意味着因果关系，只是出于授权目的的意识。
In this example, user agent A and user agent B establish an INVITE-initiated dialog through Server-A and Server-B, each of which acts as a proxy for the INVITE. Server B would then like to use the application interaction framework [14] to request that user agent A fetch an HTML user interface component. To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. The
在此示例中，用户代理A和用户代理B通过服务器A和服务器B建立一个INVITE启动的对话框，每个服务器A和服务器B都充当INVITE的代理。然后，服务器B希望使用应用程序交互框架[14]请求用户代理A获取HTML用户界面组件。为此，它向a的URI发送一个REFER请求。其流程如图5所示。这个
conventions of [19] are used to describe representation of long message lines.
[19]的约定用于描述长消息行的表示。
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
Figure 5
图5
First, the caller sends an INVITE, as shown in message 1.
首先，调用方发送一个INVITE，如消息1所示。
INVITE sips:B@example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
INVITE sips:B@example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
--未显示SDP--
The INVITE indicates that the caller supports GRUU (note its presence in the Contact header field of the INVITE) and the Target-Dialog header field. This INVITE is forwarded to the callee (messages 2-3), which generates a 200 OK response that is forwarded back to the caller (message 4-5). Message 5 might look like:
INVITE表示调用方支持GRUU（注意它在INVITE的Contact标头字段中的存在）和Target Dialog标头字段。此邀请被转发给被叫方（消息2-3），被叫方生成200 OK响应并转发回被叫方（消息4-5）。消息5可能看起来像：
SIP/2.0 200 OK
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>;tag=6544
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sips:B@pc.example.org>
Content-Length: ...
Content-Type: application/sdp
SIP/2.0 200 OK
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>;tag=6544
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sips:B@pc.example.org>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
--未显示SDP--
In this case, the called party does not support GRUU or the Target-Dialog header field. The caller generates an ACK (message 7). Server B then decides to send a REFER to user A:
在这种情况下，被叫方不支持GRUU或目标对话框头字段。调用者生成一个ACK（消息7）。然后，服务器B决定向用户a发送一个参考：
<allOneLine>
REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10
From: Server B <sip:serverB.example.org>;tag=mreysh
<allOneLine>
To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>
</allOneLine>
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;local-tag=kkaz-
;remote-tag=6544
Refer-To: http://serverB.example.org/ui-component.html
Call-ID: 86d65asfklzll8f7asdr@host.example.com
CSeq: 1 REFER
Max-Forwards: 70
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY
Contact: <sips:serverB.example.org>
Content-Length: 0
<allOneLine>
REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10
From: Server B <sip:serverB.example.org>;tag=mreysh
<allOneLine>
To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>
</allOneLine>
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;local-tag=kkaz-
;remote-tag=6544
Refer-To: http://serverB.example.org/ui-component.html
Call-ID: 86d65asfklzll8f7asdr@host.example.com
CSeq: 1 REFER
Max-Forwards: 70
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY
Contact: <sips:serverB.example.org>
Content-Length: 0
This REFER will be delivered to server A because it was sent to the GRUU. From there, it is forwarded to user agent A (message 9) and authorized because of the presence of the Target-Dialog header field.
此引用将被传递到服务器A，因为它已发送到GRUU。从那里，它被转发到用户代理A（消息9）并被授权，因为存在目标对话框头字段。
This specification registers a new SIP header field, a new option tag according to the processes of RFC 3261 [2], and two new header field parameters according to the processes of RFC 3968 [10].
本规范根据RFC 3261[2]的过程注册了一个新的SIP头字段、一个新的选项标签，并根据RFC 3968[10]的过程注册了两个新的头字段参数。
RFC Number: RFC 4538
RFC编号：RFC 4538
Header Field Name: Target-Dialog
标题字段名称：目标对话框
Compact Form: none
紧凑型：无
This section registers two header field parameters according to the processes of RFC 3968 [10].
本节根据RFC 3968[10]的过程注册两个报头字段参数。
Header Field: Target-Dialog
标题字段：目标对话框
Header Field Parameter: local-tag
标题字段参数：本地标记
Predefined Values: None
预定义值：无
RFC: RFC 4538
RFC:4538
Header Field: Target-Dialog
标题字段：目标对话框
Header Field Parameter: remote-tag
标题字段参数：远程标记
Predefined Values: None
预定义值：无
RFC: RFC 4538
RFC:4538
This specification registers a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
本规范根据RFC 3261第27.1节中的指南注册新的SIP选项标签。
Name: tdialog
姓名：tdialog
Description: This option tag is used to identify the target dialog header field extension. When used in a Require header field, it implies that the recipient needs to support the Target-Dialog header field. When used in a Supported header field, it implies that the sender of the message supports it.
描述：此选项标记用于标识目标对话框标题字段扩展。在Require头字段中使用时，表示收件人需要支持目标对话框头字段。在受支持的标头字段中使用时，表示消息的发件人支持该字段。
This specification is based on a header field first proposed by Robert Sparks in the dialog usage draft [12]. John Elwell provided helpful comments.
本规范基于Robert Sparks在对话框使用草案[12]中首次提出的标题字段。约翰·埃尔维尔提供了有益的评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[4] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[6] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[7] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[8] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[9] Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[10] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[10] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[11] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[12] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", Work in Progress, March 2006.
[12] Sparks，R.，“会话启动协议中的多重对话用法”，正在进行的工作，2006年3月。
[13] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006.
[13] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2006年5月。
[14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005.
[14] Rosenberg，J.，“会话启动协议（SIP）中的应用程序交互框架”，正在进行的工作，2005年7月。
[15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[15] Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", Work in Progress, July 2005.
[16] Rosenberg，J.，“会议状态的会话启动协议（SIP）事件包”，正在进行的工作，2005年7月。
[17] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[17] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[18] Burger, E., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Work in Progress, December 2004.
[18] Burger，E.，“按键刺激（KPML）的会话启动协议（SIP）事件包”，正在进行的工作，2004年12月。
[19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[19] Sparks，R.，Ed.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
Author's Address
作者地址
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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。