Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6228 Ericsson
Category: Standards Track May 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6228 Ericsson
Category: Standards Track May 2011
ISSN: 2070-1721
Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
会话启动协议（SIP）响应代码，用于指示终止的对话
Abstract
摘要
This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities.
本规范定义了一个新的会话发起协议（SIP）响应代码，199早期对话终止，SIP分叉代理和用户代理服务器（UAS）可使用该代码向上游SIP实体（包括用户代理客户端（UAC））指示早期对话已终止，在向SIP实体发送最终响应之前。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6228.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6228.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Applicability and Limitation ....................................4
4. User Agent Client Behavior ......................................4
5. User Agent Server Behavior ......................................6
6. Proxy Behavior ..................................................7
7. Backward Compatibility ..........................................9
8. Usage with SDP Offer/Answer .....................................9
9. Message Flow Examples ...........................................9
9.1. Example with a Forking Proxy that Generates 199 ............9
9.2. Example with a Forking Proxy that Receives 200 OK .........10
9.3. Example with Two Forking Proxies, of which One
Generates 199 .............................................11
10. Security Considerations .......................................12
11. IANA Considerations ...........................................13
11.1. IANA Registration of the 199 Response Code ...............13
11.2. IANA Registration of the 199 Option-Tag ..................13
12. Acknowledgements ..............................................13
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................14
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Applicability and Limitation ....................................4
4. User Agent Client Behavior ......................................4
5. User Agent Server Behavior ......................................6
6. Proxy Behavior ..................................................7
7. Backward Compatibility ..........................................9
8. Usage with SDP Offer/Answer .....................................9
9. Message Flow Examples ...........................................9
9.1. Example with a Forking Proxy that Generates 199 ............9
9.2. Example with a Forking Proxy that Receives 200 OK .........10
9.3. Example with Two Forking Proxies, of which One
Generates 199 .............................................11
10. Security Considerations .......................................12
11. IANA Considerations ...........................................13
11.1. IANA Registration of the 199 Response Code ...............13
11.2. IANA Registration of the 199 Option-Tag ..................13
12. Acknowledgements ..............................................13
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................14
As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) early dialog is created when a non-100 provisional response is sent to the initial dialog initiation request (e.g., INVITE, outside an existing dialog). The dialog is considered to be in early state until a final response is sent.
如RFC 3261[RFC3261]中所定义，当向初始对话启动请求发送非100临时响应（例如，邀请，在现有对话之外）时，将创建会话启动协议（SIP）早期对话。在发送最终响应之前，对话框被视为处于早期状态。
When a proxy receives an initial dialog initiation request, it can forward the request towards multiple remote destinations. When the proxy does that, it performs forking [RFC3261].
当代理收到初始对话框启动请求时，它可以将请求转发到多个远程目标。当代理执行此操作时，它将执行分叉[RFC3261]。
When a forking proxy receives a non-100 provisional response, or a 2xx final response, it forwards the response upstream towards the sender of the associated request. After a forking proxy has forwarded a 2xx final response, it normally generates and sends CANCEL requests downstream towards all remote destinations where it previously forked the request associated with the 2xx final response and from which it has still not received a final response. The CANCEL requests are sent in order to terminate any outstanding early dialogs associated with the request.
当分叉代理收到非100临时响应或2xx最终响应时，它会将响应向上游转发到相关请求的发送方。分叉代理转发2xx最终响应后，通常会生成取消请求，并向下游所有远程目的地发送取消请求，在此之前分叉与2xx最终响应关联的请求，但尚未从中收到最终响应。发送取消请求是为了终止与请求相关的任何未完成的早期对话框。
Upstream SIP entities might receive multiple 2xx final responses. When a SIP entity receives the first 2xx final response, and it does not intend to accept any subsequent 2xx final responses, it will automatically terminate any other outstanding early dialog associated with the request. If the SIP entity receives a subsequent 2xx final response, it will normally generate and send an ACK request, followed with a BYE request, using the dialog identifier retrieved from the 2xx final response.
上游SIP实体可能会收到多个2xx最终响应。当SIP实体收到第一个2xx最终响应，并且不打算接受任何后续2xx最终响应时，它将自动终止与请求相关的任何其他未完成的早期对话。如果SIP实体接收到后续2xx最终响应，它通常会使用从2xx最终响应中检索到的对话框标识符生成并发送ACK请求，然后是BYE请求。
NOTE: A User Agent Client (UAC) can use the Request-Disposition header field [RFC3841] to request that proxies do not generate and send CANCEL requests downstream once they have received the first 2xx final response.
注意：用户代理客户端（UAC）可以使用请求处理头字段[RFC3841]请求代理在收到第一个2xx最终响应后不生成并向下游发送取消请求。
When a forking proxy receives a non-2xx final response, it does not always immediately forward the response upstream towards the sender of the associated request. Instead, the proxy "stores" the response and waits for subsequent final responses from other remote destinations where the associated request was forked. At some point, the proxy uses a specified mechanism to determine the "best" final response code, and forwards a final response using that response code upstream towards the sender of the associated request. When an upstream SIP entity receives the non-2xx final response, it will release resources associated with the session. The UAC will terminate, or retry, the session setup.
当分叉代理收到非2xx最终响应时，它并不总是立即将响应向上游转发到相关请求的发送方。相反，代理“存储”响应，并等待来自关联请求分叉的其他远程目标的后续最终响应。在某个时刻，代理使用指定的机制来确定“最佳”最终响应代码，并使用该响应代码向上游将最终响应转发给相关请求的发送方。当上游SIP实体收到非2xx最终响应时，它将释放与会话相关的资源。UAC将终止或重试会话设置。
Since the forking proxy does not always immediately forward non-2xx final responses, upstream SIP entities (including the UAC that initiated the request) are not immediately informed that an early dialog has been terminated, and will therefore maintain resources associated with the early dialog reserved until a final response is sent by the proxy, even if the early dialog has already been terminated. A SIP entity could use the resources for other things, e.g., to accept subsequent early dialogs that it otherwise would reject.
由于分叉代理并不总是立即转发非2xx最终响应，上游SIP实体（包括发起请求的UAC）不会立即被告知早期对话已终止，因此将保留与早期对话相关的资源，直到代理发送最终响应，即使早期对话框已经终止。SIP实体可以将这些资源用于其他用途，例如，接受它将拒绝的后续早期对话。
This specification defines a new SIP response code, 199 Early Dialog Terminated. A forking proxy can send a 199 provisional response to inform upstream SIP entities that an early dialog has been terminated. A UAS can send a 199 response code, prior to sending a non-2xx final response, for the same purpose. SIP entities that receive the 199 response can use it to trigger the release of resources associated with the terminated early dialog. In addition, SIP entities might also use the 199 response to make policy decisions related to early dialogs. For example, a media gate controlling a SIP entity might use the 199 response when deciding for which early dialogs media will be passed.
本规范定义了一个新的SIP响应代码，199提前终止对话。分叉代理可以发送199临时响应，通知上游SIP实体早期对话已终止。出于同样的目的，UAS可以在发送非2xx最终响应之前发送199响应代码。接收199响应的SIP实体可以使用它来触发释放与终止的早期对话相关联的资源。此外，SIP实体还可以使用199响应来做出与早期对话相关的策略决策。例如，控制SIP实体的媒体门在决定向哪个早期对话传递媒体时，可能会使用199响应。
Section 9 contains signalling examples that show when and how a forking proxy generates 199 responses in different situations.
第9节包含的信令示例显示了分叉代理在不同情况下何时以及如何生成199个响应。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The 199 response code is an optimization, and it only optimizes how quickly recipients might be informed about terminated early dialogs. The achieved optimization is limited. Since the response is normally not sent reliably by a UAS, and cannot be sent reliably when generated and sent by a proxy, it is possible that some or all of the 199 responses will get lost before they reach the recipients. In such cases, recipients will behave the same as if the 199 response code were not used at all.
199响应代码是一种优化，它只优化了收件人收到提前终止的对话框通知的速度。实现的优化是有限的。由于响应通常不是由UAS可靠发送的，并且在由代理生成和发送时也不能可靠发送，因此199个响应中的部分或全部可能在到达收件人之前丢失。在这种情况下，收件人的行为将与根本未使用199响应代码时的行为相同。
One example for which a UAC could use the 199 response is that when it receives a 199 response, it releases resources associated with the terminated early dialog. The UAC could also use the 199 response to make policy decisions related to early dialogs. For example, if a UAC is playing media associated with an early dialog, and it then receives a 199 response indicating the early dialog has been terminated, it could start playing media associated with a different early dialog.
UAC可以使用199响应的一个例子是，当它收到199响应时，它会释放与终止的早期对话框相关的资源。UAC还可以利用199年的回应来做出与早期对话相关的政策决定。例如，如果UAC正在播放与早期对话关联的媒体，然后它收到199响应，指示早期对话已终止，则它可以开始播放与其他早期对话关联的媒体。
Application designers utilizing the 199 response code MUST ensure that the application's user experience is acceptable if all 199 responses are lost and not delivered to the recipients.
使用199响应代码的应用程序设计人员必须确保，如果所有199个响应都丢失且未交付给收件人，则应用程序的用户体验是可接受的。
When a UAC sends an initial dialog initiation request, and if it is willing to receive 199 responses, it MUST insert a "199" option-tag in the Supported header field [RFC3261] of the request. The option-tag indicates that the UAC supports, and is willing to receive, 199 responses. A UAC SHOULD NOT insert a "199" option-tag in the Require or the Proxy-Require header field [RFC3261] of the request, since in many cases it would result in unnecessary session establishment failures.
当UAC发送初始对话启动请求时，如果它愿意接收199个响应，则必须在请求的受支持标头字段[RFC3261]中插入“199”选项标记。选项标签表示UAC支持并愿意接收199个响应。UAC不应在请求的Require或Proxy Require头字段[RFC3261]中插入“199”选项标记，因为在许多情况下，这会导致不必要的会话建立失败。
NOTE: The UAC always needs to insert a "199" option-tag in the Supported header field, in order to indicate that it supports, and is willing to receive, 199 responses, even if it also inserts the option-tag in the Require or Proxy-Require header field.
注意：UAC始终需要在支持的标题字段中插入“199”选项标记，以表明它支持并愿意接收199个响应，即使它也在Require或Proxy Require标题字段中插入选项标记。
It is RECOMMENDED that a UAC not insert a "100rel" option-tag [RFC3262] in the Require header field when it also indicates support for 199 responses, unless the UAC also uses some other SIP extension or procedure that mandates it to do so. The reason is that proxies are not allowed to generate and send 199 responses when the UAC has required provisional responses to be sent reliably.
当UAC也表示支持199个响应时，建议UAC不要在Require header字段中插入“100rel”选项标记[RFC3262]，除非UAC还使用其他一些SIP扩展或程序强制它这样做。原因是当UAC要求可靠地发送临时响应时，不允许代理生成和发送199个响应。
When a UAC receives a 199 response, it might release resources associated with the terminated early dialog. A UAC might also use the 199 response to make policy decisions related to early dialogs.
当UAC收到199响应时，它可能会释放与终止的早期对话框相关的资源。UAC也可以使用199响应来做出与早期对话相关的政策决策。
NOTE: The 199 response indicates that the early dialog has been terminated, so there is no need for the UAC to send a BYE request in order to terminate the early dialog when it receives the 199 response.
注意：199响应表示早期对话已终止，因此UAC无需发送BYE请求，以便在收到199响应时终止早期对话。
NOTE: The 199 response does not affect other early dialogs associated with the session establishment. For those dialogs, the normal SIP rules regarding transaction timeout, etc., still apply.
注意：199响应不影响与会话建立相关的其他早期对话框。对于这些对话框，关于事务超时等的正常SIP规则仍然适用。
Once a UAC has received and accepted a 199 response, it MUST NOT send any media associated with the early dialog. In addition, if the UAC is able to associate received media with early dialogs, it MUST NOT process any received media associated with the early dialog that was terminated.
UAC收到并接受199响应后，不得发送与早期对话相关的任何媒体。此外，如果UAC能够将接收到的媒体与早期对话框关联，则它不得处理与终止的早期对话框关联的任何接收到的媒体。
If multiple usages [RFC5057] are used within an early dialog, and it is not clear which dialog usage the 199 response terminates, SIP entities that keep dialog state SHALL NOT release resources associated with the early dialog when they receive the 199 response.
如果在早期对话中使用了多个用法[RFC5057]，并且不清楚199响应终止了哪个对话用法，则保持对话状态的SIP实体在收到199响应时不得释放与早期对话相关的资源。
If a UAC receives an unreliably sent 199 response on a dialog that has not previously been established (this can happen if a 199 response reaches the client before the 18x response that would establish the early dialog) it SHALL discard the 199 response. If a UAC receives a reliably sent 199 response on a dialog that has not previously been created, it MUST acknowledge the 199 response, as described in RFC 3262 [RFC3262].
如果UAC在之前未建立的对话上收到不可靠发送的199响应（如果199响应在建立早期对话的18x响应之前到达客户端，则可能发生这种情况），UAC应放弃199响应。如果UAC在之前未创建的对话框上接收到可靠发送的199响应，它必须确认199响应，如RFC 3262[RFC3262]中所述。
If a UAC has received a 199 response for all early dialogs, and no early dialogs associated with the session establishment remain, it maintains the "Proceeding" state [RFC3261] and waits for possible subsequent early dialogs to be established, and eventually for a final response to be received.
如果UAC已收到所有早期对话的199响应，且没有与会话建立相关的早期对话保留，则UAC将保持“继续”状态[RFC3261]，并等待可能的后续早期对话建立，最终等待收到最终响应。
If a UAS receives an initial dialog initiation request with a Supported header field that contains a "199" option-tag, it SHOULD NOT send a 199 response on an early dialog associated with the request before it sends a non-2xx final response. Cases where a UAS might send a 199 response are if it has been configured to do so due to lack of support for the 199 response code by forking proxies or other intermediate SIP entities, or if it is used in an environment that specifies that it shall send a 199 response before sending a non-2xx response.
如果UAS接收到带有支持的标题字段（包含“199”选项标记）的初始对话启动请求，则在发送非2xx最终响应之前，不应在与该请求相关联的早期对话上发送199响应。UAS可能发送199响应的情况是，由于缺乏通过分叉代理或其他中间SIP实体对199响应代码的支持，UAS被配置为发送199响应，或者UAS用于指定在发送非2xx响应之前发送199响应的环境中。
NOTE: If a UAS has created multiple early dialogs associated with an initial dialog initiation request (the UAS is acting similarly to a forking proxy), it does not always intend to send a final response on all of those early dialogs.
注意：如果UAS创建了多个与初始对话启动请求相关联的早期对话（UAS的行为类似于分叉代理），它并不总是打算在所有这些早期对话上发送最终响应。
NOTE: If the Require header field of an initial dialog initiation request contains a "100rel" option-tag, proxies will not be able to generate and send 199 responses. In such cases, the UAS might choose to send a 199 response on an early dialog before it sends a non-2xx final response, even if it would not do so in other cases.
注意：如果初始对话框启动请求的Require header字段包含“100rel”选项标记，代理将无法生成和发送199个响应。在这种情况下，UAS可能会选择在发送非2xx最终响应之前在早期对话中发送199响应，即使在其他情况下不会这样做。
If the Supported header field of an initial dialog initiation request does not contain a "199" option-tag, the UAC MUST NOT send a 199 response on any early dialog associated with the request.
如果初始对话启动请求的受支持标题字段不包含“199”选项标记，UAC不得在与该请求相关联的任何早期对话上发送199响应。
When a UAS generates a 199 response, the response MUST contain a To header field tag parameter [RFC3261], in order for other entities to identify the early dialog that has been terminated. The UAS MUST also insert a Reason header field [RFC3326] that contains a response code describing the reason why the early dialog was terminated. The UAS MUST NOT insert a "199" option-tag in the Supported, Require, or Proxy-Require header field of the 199 response.
当UAS生成199响应时，响应必须包含To header字段标记参数[RFC3261]，以便其他实体识别已终止的早期对话框。UAS还必须插入一个原因标题字段[RFC3326]，该字段包含一个描述早期对话框终止原因的响应代码。UAS不得在199响应的Supported、Require或Proxy Require标头字段中插入“199”选项标记。
If a UAS intends to send 199 responses, and if it supports the procedures defined in RFC 3840 [RFC3840], it MAY during the registration procedure use the sip.extensions feature tag [RFC3840] to indicate support for the 199 response code.
如果UAS打算发送199个响应，并且如果它支持RFC 3840[RFC3840]中定义的过程，它可以在注册过程中使用sip.extensions功能标签[RFC3840]来指示对199响应代码的支持。
A 199 response SHOULD NOT contain a Session Description Protocol (SDP) offer/answer message body, unless required by the rules in RFC 3264 [RFC3264].
199响应不应包含会话描述协议（SDP）提供/应答消息正文，除非RFC 3264[RFC3264]中的规则要求。
According to RFC 3264, if an INVITE request does not contain an SDP offer, and the 199 response is the a first reliably sent response associated with the request, the 199 response is required to contain an SDP offer. In this case, the UAS SHOULD send the 199 response unreliably, or send the 199 response reliably and include an SDP offer with no "m=" lines in the response.
根据rfc3264，如果INVITE请求不包含SDP提供，并且199响应是与该请求相关联的第一个可靠发送的响应，则199响应需要包含SDP提供。在这种情况下，UAS应该不可靠地发送199响应，或者可靠地发送199响应，并在响应中包含没有“m=”行的SDP报价。
Since a 199 response is only used for information purposes, the UAS SHOULD send it unreliably, unless the "100rel" option-tag is present in the Require header field of the associated request.
由于199响应仅用于信息目的，UAS应不可靠地发送它，除非相关请求的Require header字段中存在“100rel”选项标记。
When a proxy receives a 199 response to an initial dialog initiation request, it MUST process the response as any other non-100 provisional response. The proxy will forward the response upstream towards the sender of the associated request. The proxy MAY release resources it has reserved associated with the early dialog that is terminated. If a proxy receives a 199 response out of dialog, it MUST process it as other non-100 provisional responses received out of dialog.
当代理收到对初始对话启动请求的199响应时，它必须将该响应作为任何其他非100临时响应进行处理。代理将向上游向相关请求的发送方转发响应。代理可以释放其保留的与终止的早期对话框关联的资源。如果代理收到对话框外的199响应，它必须将其作为对话框外收到的其他非100临时响应进行处理。
When a forking proxy receives a non-2xx final response to an initial dialog initiation request that it recognizes as terminating one or more early dialogs associated with the request, it MUST generate and send a 199 response upstream for each of the terminated early dialogs that satisfy each of the following conditions:
当分叉代理接收到对初始对话框启动请求的非2xx最终响应，并将其识别为终止与该请求相关的一个或多个早期对话框时，它必须为满足以下条件的每个终止的早期对话框生成并向上游发送199响应：
- The forking proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy).
- 分叉代理不打算立即转发最终回复（根据分叉代理规则）。
- The UAC has indicated support (by inserting the "199" option-tag in a Supported header field) for the 199 response code in the associated request.
- UAC已表示支持相关请求中的199响应代码（通过在支持的标题字段中插入“199”选项标记）。
- The UAC has not required provisional responses to be sent reliably (i.e., has not inserted the "100rel" option-tag in a Require or Proxy-Require header field) in the associated request.
- UAC没有要求在相关请求中可靠地发送临时响应（即，没有在Require或Proxy Require头字段中插入“100rel”选项标记）。
- The forking proxy has not already received and forwarded a 199 response for the early dialog.
- 分叉代理尚未接收并转发早期对话框的199响应。
- The forking proxy has not already sent a final response for any of the early dialogs.
- 分叉代理尚未发送任何早期对话框的最终响应。
As a consequence, once a final response to an initial dialog initiation request has been issued by the proxy, no further 199 responses associated with the request will be generated or forwarded by the proxy.
因此，一旦代理发出了对初始对话启动请求的最终响应，代理将不再生成或转发与该请求相关的199个响应。
When a forking proxy forks an initial dialog initiation request, it generates a unique Via header branch parameter value for each forked leg. A proxy can determine whether additional forking has occurred downstream of the proxy by storing the top Via branch value from each response that creates an early dialog. If the same top Via branch value is received for multiple early dialogs, the proxy knows that additional forking has occurred downstream of the proxy. A non-2xx final response received for a specific early dialog also terminates all other early dialogs for which the same top Via branch value was received in the responses that created those early dialogs.
当分叉代理分叉初始对话框启动请求时，它会为每个分叉分支生成唯一的Via头分支参数值。代理可以通过存储创建早期对话框的每个响应的top-Via分支值来确定是否在代理的下游发生了额外的分叉。如果为多个早期对话框接收到相同的top Via分支值，则代理知道在代理的下游发生了额外的分叉。对于特定的早期对话框，接收到的非2xx最终响应也会终止所有其他早期对话框，在创建这些早期对话框的响应中接收到相同的top Via分支值。
Based on implementation policy, a forking proxy MAY wait before sending the 199 response, e.g., if it expects to receive a 2xx final response on another dialog shortly after it received the non-2xx final response that triggered the 199 response.
根据实施策略，分叉代理可能会在发送199响应之前等待，例如，如果它预期在收到触发199响应的非2xx最终响应后不久在另一个对话框上接收2xx最终响应。
When a forking proxy generates a 199 response, the response MUST contain a To header field tag parameter that identifies the terminated early dialog. A proxy MUST also insert a Reason header field that contains the SIP response code of the response that triggered the 199 response. The SIP response code in the Reason header field informs the receiver of the 199 response about the SIP response code that was used by the UAS to terminate the early dialog, and the receiver might use that information for triggering different types of actions and procedures. The proxy MUST NOT insert a "199" option-tag in the Supported, Require, or Proxy-Require header field of the 199 response.
当分叉代理生成199响应时，响应必须包含一个To header field tag参数，该参数标识终止的早期对话框。代理还必须插入一个原因头字段，该字段包含触发199响应的响应的SIP响应代码。原因报头字段中的SIP响应代码通知接收者199响应关于UAS用于终止早期对话的SIP响应代码，并且接收者可以使用该信息触发不同类型的动作和过程。代理不得在199响应的Supported、Require或proxy Require标头字段中插入“199”选项标记。
A forking proxy that supports the generation of 199 responses MUST keep track of early dialogs, in order to determine whether to generate a 199 response when the proxy receives a non-2xx final response. In addition, a proxy MUST keep track on which early dialogs it has received and forwarded 199 responses, in order to not generate additional 199 responses for those early dialogs.
支持生成199个响应的分叉代理必须跟踪早期对话框，以便在代理收到非2xx最终响应时确定是否生成199个响应。此外，代理必须跟踪它已接收和转发199个响应的早期对话框，以便不为这些早期对话框生成额外的199个响应。
If a forking proxy receives a reliably sent 199 response for a dialog for which it has previously generated and sent a 199 response, it MUST forward the 199 response. If a proxy receives an unreliably sent 199 response for which it has previously generated and sent a 199 response, it MAY forward the response, or it MAY discard it.
如果forking代理接收到一个可靠发送的199响应，并且它之前已经为该对话框生成并发送了199响应，那么它必须转发199响应。如果代理接收到不可靠发送的199响应，并且它之前已经为该响应生成并发送了199响应，则它可以转发该响应，也可以丢弃该响应。
When a forking proxy generates and sends a 199 response, the response SHOULD NOT contain a Contact header field or a Record-Route header field [RFC3261].
分叉代理生成并发送199响应时，响应不应包含联系人标头字段或记录路由标头字段[RFC3261]。
If the Require header field of an initial dialog initiation request contains a "100rel" option-tag, a proxy MUST NOT generate and send 199 responses associated with that request. The reason is that a proxy is not allowed to generate and send 199 responses reliably.
如果初始对话框启动请求的Require header字段包含“100rel”选项标记，则代理不得生成和发送与该请求关联的199个响应。原因是不允许代理可靠地生成和发送199个响应。
Since all SIP entities involved in a session setup do not necessarily support the specific meaning of the 199 Early Dialog Terminated provisional response, the sender of the response MUST be prepared to receive SIP requests and responses associated with the dialog for which the 199 response was sent (a proxy can receive SIP messages from either direction). If such a request is received by a UA, it MUST act in the same way as if it had received the request after sending the final non-2xx response to the INVITE request, as specified in RFC 3261. A UAC that receives a 199 response for an early dialog MUST NOT send any further requests on that dialog, except for requests that acknowledge reliable responses. A proxy MUST forward requests according to RFC 3261, even if the proxy has knowledge that the early dialog has been terminated.
由于会话设置中涉及的所有SIP实体不一定支持199早期对话终止临时响应的特定含义，因此响应的发送者必须准备接收与发送199响应的对话相关联的SIP请求和响应（代理可以从任意方向接收SIP消息）。如果UA收到此类请求，则必须按照RFC 3261中的规定，在向INVITE请求发送最终非2xx响应后，以与收到请求相同的方式行事。对于早期对话，收到199响应的UAC不得在该对话上发送任何进一步的请求，但确认可靠响应的请求除外代理必须根据RFC 3261转发请求，即使代理知道早期对话已终止。
A 199 response does not "replace" a final response. RFC 3261 specifies when a final response is sent.
199响应不会“取代”最终响应。RFC 3261指定何时发送最终响应。
A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] message body, unless required by the rules in RFC 3264.
199响应不应包含SDP提供/应答[RFC3264]消息正文，除非RFC 3264中的规则要求。
If an INVITE request does not contain an SDP offer, and the 199 response is the first reliably sent response, the 199 response is required to contain an SDP offer. In this case, the UAS SHOULD send the 199 response unreliably, or include an SDP offer with no "m=" lines in a reliable 199 response.
如果INVITE请求不包含SDP要约，并且199响应是第一个可靠发送的响应，则199响应需要包含SDP要约。在这种情况下，UAS应该不可靠地发送199响应，或者在可靠的199响应中包含没有“m=”行的SDP报价。
Figure 1 shows an example where a proxy (P1) forks an INVITE received from a UAC. The forked INVITE reaches UAS_2, UAS_3, and UAS_4, which send 18x provisional responses in order to establish early dialogs between themselves and the UAC. UAS_2 and UAS_3 each reject the INVITE by sending a 4xx error response. When P1 receives the 4xx
图1显示了代理（P1）分叉从UAC接收的邀请的示例。分叉邀请到达UAS_2、UAS_3和UAS_4，它们发送18个临时响应，以便在它们自己和UAC之间建立早期对话。UAS_2和UAS_3各自通过发送4xx错误响应来拒绝邀请。当P1接收到4xx时
responses, it immediately sends 199 responses towards the UAC, to indicate that the early dialogs for which it received the 4xx responses have been terminated. The early dialog leg is shown in parentheses.
响应时，它立即向UAC发送199个响应，以表明其收到4xx响应的早期对话框已终止。早期对话框的分支显示在括号中。
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 4xx (2) -----| | |
| |--- ACK (2) ---->| | |
|<- 199 (2) --| | | |
| |<-- 4xx (3) -------------| |
| |--- ACK (3) ------------>| |
|<- 199 (3) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 4xx (2) -----| | |
| |--- ACK (2) ---->| | |
|<- 199 (2) --| | | |
| |<-- 4xx (3) -------------| |
| |--- ACK (3) ------------>| |
|<- 199 (3) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
Figure 1: Example Call Flow
图1：示例调用流
Figure 2 shows an example where a proxy (P1) forks an INVITE request received from a UAC. The forked request reaches UAS_2, UAS_3, and UAS_4, all of which send 18x provisional responses in order to establish early dialogs between themselves and the UAC. Later, UAS_4 accepts the session and sends a 200 OK final response. When P1 receives the 200 OK response, it immediately forwards it towards the UAC. P1 does not send 199 responses for the early dialogs from UAS_2 and UAS_3, since P1 has still not received any final responses on those early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3, P1 may still receive a 200 OK final response from UAS_2 or UAS_3, which P1 would have to forward towards the UAC. The early dialog leg is shown in parentheses.
图2显示了代理（P1）分叉从UAC接收的INVITE请求的示例。分叉请求到达UAS_2、UAS_3和UAS_4，所有这些请求都发送18个临时响应，以便在它们自己和UAC之间建立早期对话。稍后，UAS_4接受会话并发送200 OK最终响应。当P1收到200 OK响应时，它立即将其转发给UAC。P1未发送来自UAS_2和UAS_3的199个早期对话响应，因为P1尚未收到这些早期对话的任何最终响应（即使P1向UAS_2和UAS_3发送取消请求，P1仍可能收到来自UAS_2或UAS_3的200 OK最终响应，P1必须将该响应转发给UAC。早期对话段显示在括号中。
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
Figure 2: Example Call Flow
图2：示例调用流
Figure 3 shows an example where a proxy (P1) forks an INVITE request received from a UAC. One of the forked requests reaches UAS_2. The other requests reach another proxy (P2), which forks the request to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses in order to establish early dialogs between themselves and the UAC. Later, UAS_3 and UAS_4 each reject the INVITE request by sending a 4xx error response. P2 does not support the 199 response code and forwards a single 4xx response. P1 supports the 199 response code, and when it receives the 4xx response from P2, it also manages to associate the early dialogs from both UAS_3 and UAS_4 with the response. Therefore, P1 generates and sends two 199 responses to indicate that the early dialogs from UAS_3 and UAS_4 have been terminated. The early dialog leg is shown in parentheses.
图3显示了代理（P1）分叉从UAC接收的INVITE请求的示例。其中一个分叉请求到达UAS_2。其他请求到达另一个代理（P2），该代理将请求分叉到UAS_3和UAS_4。UAS_3和UAS_4发送18次临时响应，以便在其与UAC之间建立早期对话。稍后，UAS_3和UAS_4分别通过发送4xx错误响应来拒绝INVITE请求。P2不支持199响应代码，并转发单个4xx响应。P1支持199响应代码，当收到P2的4xx响应时，它还设法将UAS_3和UAS_4的早期对话框与响应关联起来。因此，P1生成并发送两个199响应，以指示来自UAS_3和UAS_4的早期对话已终止。早期对话框的分支显示在括号中。
UAC P1 P2 UAS_2 UAS_3 UAS_4
| | | | | |
|-- INVITE -->| | | | |
| |-- INVITE (2) ------------------>| | |
| |-- INVITE ---->| | | |
| | |--- INVITE (3) --------->| |
| | |--- INVITE (4) ----------------->|
| | |<-- 18x (3) -------------| |
| |<- 18x (3) ----| | | |
|<- 18x (3) --| | | | |
| | |<-- 18x (4) ---------------------|
| |<- 18x (4) ----| | | |
|<- 18x (4) --| | | | |
| | |<-- 4xx (3) -------------| |
| | |--- ACK (3) ------------>| |
| | |<-- 4xx (4) ---------------------|
| | |--- ACK (4) -------------------->|
| |<- 4xx (3) ----| | | |
| |-- ACK (3) --->| | | |
|<- 199 (3) --| | | | |
|<- 199 (4) --| | | | |
| |<- 200 (2) ----------------------| | |
|<- 200 (2) --| | | | |
|-- ACK (2) ->| | | | |
| |-- ACK (2) --------------------->| | |
| | | | | |
UAC P1 P2 UAS_2 UAS_3 UAS_4
| | | | | |
|-- INVITE -->| | | | |
| |-- INVITE (2) ------------------>| | |
| |-- INVITE ---->| | | |
| | |--- INVITE (3) --------->| |
| | |--- INVITE (4) ----------------->|
| | |<-- 18x (3) -------------| |
| |<- 18x (3) ----| | | |
|<- 18x (3) --| | | | |
| | |<-- 18x (4) ---------------------|
| |<- 18x (4) ----| | | |
|<- 18x (4) --| | | | |
| | |<-- 4xx (3) -------------| |
| | |--- ACK (3) ------------>| |
| | |<-- 4xx (4) ---------------------|
| | |--- ACK (4) -------------------->|
| |<- 4xx (3) ----| | | |
| |-- ACK (3) --->| | | |
|<- 199 (3) --| | | | |
|<- 199 (4) --| | | | |
| |<- 200 (2) ----------------------| | |
|<- 200 (2) --| | | | |
|-- ACK (2) ->| | | | |
| |-- ACK (2) --------------------->| | |
| | | | | |
Figure 3: Example Call Flow
图3：示例调用流
General security issues related to SIP responses are described in RFC 3261. Due to the nature of the 199 response, it may be attractive to use it for launching attacks in order to terminate specific early dialogs (other early dialogs will not be affected). In addition, if a man-in-the-middle generates and sends towards the UAC a 199 response that terminates a specific dialog, it can take a while until the UAS finds out that the UAC, and possible stateful intermediates, have terminated the dialog. SIP security mechanisms (e.g., hop-to-hop Transport Layer Security (TLS)) can be used to minimize, or eliminate, the risk of such attacks.
RFC 3261中描述了与SIP响应相关的一般安全问题。由于199响应的性质，将其用于发起攻击以终止特定的早期对话（其他早期对话将不受影响）可能是有吸引力的。此外，如果中间人生成并向UAC发送终止特定对话的199响应，UAS可能需要一段时间才能发现UAC和可能的有状态中间人已终止对话。SIP安全机制（例如，跳到跳传输层安全（TLS））可用于最小化或消除此类攻击的风险。
This section registers a new SIP response code and a new option-tag, according to the procedures of RFC 3261.
本节根据RFC 3261的程序注册新的SIP响应代码和新的选项标签。
This section registers a new SIP response code, 199. The required information for this registration, as specified in RFC 3261, is:
本节注册一个新的SIP响应代码199。RFC 3261中规定的本次注册所需信息如下：
RFC Number: RFC 6228
RFC编号：RFC 6228
Response Code Number: 199
回应编号：199
Default Reason Phrase: Early Dialog Terminated
默认原因短语：早期对话框终止
This section registers a new SIP option-tag, 199. The required information for this registration, as specified in RFC 3261, is:
本节注册一个新的SIP选项标签199。RFC 3261中规定的本次注册所需信息如下：
Name: 199
姓名：199
Description: This option-tag is for indicating support of the 199 Early Dialog Terminated provisional response code. When present in a Supported header of a request, it indicates that the UAC supports the 199 response code. When present in a Require or Proxy-Require header field of a request, it indicates that the UAS, or proxies, MUST support the 199 response code. It does not require the UAS, or proxies, to actually send 199 responses.
描述：此选项标记用于指示对199早期对话框终止的临时响应代码的支持。当出现在请求的受支持标头中时，表示UAC支持199响应代码。当出现在请求的Require或Proxy Require头字段中时，表示UAS或代理必须支持199响应代码。它不要求UAS或代理实际发送199个响应。
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith Drage, Hans Erik van Elburg, and Cullen Jennings for their feedback and suggestions.
感谢Paul Kyzivat、Dale Worley、Gilad Shaham、Francois Audet、Attila Sipos、Robert Sparks、Brett Tate、Ian Elz、Hadriel Kaplan、Timothy Dwight、Dean Willis、Serhad Doken、John Elwell、Gonzalo Camarillo、Adam Roach、Bob Penfield、Tom Taylor、Ya Ching Tan、Keith Drage、Hans Erik van Elburg、，以及Cullen Jennings的反馈和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057]Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，2007年11月。
Author's Address
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com