Network Working Group W. Marshall, Ed.
Request for Comments: 3603 AT&T
Category: Informational F. Andreasen, Ed.
Cisco
October 2003
Network Working Group W. Marshall, Ed.
Request for Comments: 3603 AT&T
Category: Informational F. Andreasen, Ed.
Cisco
October 2003
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
专用会话发起协议（SIP）代理到代理扩展，用于支持PacketCable分布式呼叫信令体系结构
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
为了在不同的域中大规模部署住宅电话服务，不同服务提供商拥有的可信元素必须交换可信信息，以传达客户特定的信息和有关通话各方的期望。本文档描述了会话发起协议（SIP）（RFC3261）的专用扩展，用于支持PacketCable分布式呼叫信令体系结构中受信任实体之间的客户信息和计费信息交换。这些扩展提供了接入网络协调机制，以防止服务被盗、骚扰电话的客户追踪、对运营商服务和紧急服务的支持，以及对各种其他监管问题的支持。扩展的使用仅适用于封闭的管理域内，或在需要协调收费和其他功能的情况下，具有先前商定政策的管理域联合会之间。
Table of Contents
目录
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conventions used in this document . . . . . . . . . . . . . . 6
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Trust Boundary. . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conventions used in this document . . . . . . . . . . . . . . 6
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6
5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7
5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7
5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7
5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7
5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8
5.6.1. Procedures at Originating Proxy . . . . . . . . 8
5.6.2. Procedures at Terminating Proxy . . . . . . . . 8
6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9
6.3. Procedures at a Trusted User Agent Client (UAC) . . . . 10
6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10
6.5. Procedures at a Trusted User Agent Server (UAS) . . . . 11
6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14
7.3. Procedures at a Trusted User Agent Client (UAC) . . . . 14
7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15
7.5. Procedures at a Trusted User Agent Server (UAS) . . . . 15
7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
7.6.1. Procedures at Originating Proxy . . . . . . . . 16
7.6.2. Procedures at Terminating Proxy . . . . . . . . 17
7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18
8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20
8.3. Procedures at a Trusted User Agent Client (UAC) . . . . 20
8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21
8.5. Procedures at a Trusted User Agent Server (UAS) . . . . 21
8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
8.6.1. Procedures at Originating Proxy . . . . . . . . 22
8.6.2. Procedures at Terminating Proxy . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References. . . . . . . . . . . . . . . . . . 25
12.2. Informative References. . . . . . . . . . . . . . . . . 26
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
5. P-DCS-TRACE-PARTY-ID. . . . . . . . . . . . . . . . . . . . . 6
5.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures at an Untrusted User Agent Client (UAC). . . 7
5.3. Procedures at a Trusted User Agent Client (UAC) . . . . 7
5.4. Procedures at an Untrusted User Agent Server (UAS). . . 7
5.5. Procedures at a Trusted User Agent Server (UAS) . . . . 7
5.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 8
5.6.1. Procedures at Originating Proxy . . . . . . . . 8
5.6.2. Procedures at Terminating Proxy . . . . . . . . 8
6. P-DCS-OSPS. . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Procedures at an Untrusted User Agent Client (UAC). . . 9
6.3. Procedures at a Trusted User Agent Client (UAC) . . . . 10
6.4. Procedures at an Untrusted User Agent Server (UAS). . . 10
6.5. Procedures at a Trusted User Agent Server (UAS) . . . . 11
6.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 11
7. P-DCS-BILLING-INFO. . . . . . . . . . . . . . . . . . . . . . 11
7.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Procedures at an Untrusted User Agent Client (UAC). . . 14
7.3. Procedures at a Trusted User Agent Client (UAC) . . . . 14
7.4. Procedures at an Untrusted User Agent Server (UAS). . . 15
7.5. Procedures at a Trusted User Agent Server (UAS) . . . . 15
7.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 16
7.6.1. Procedures at Originating Proxy . . . . . . . . 16
7.6.2. Procedures at Terminating Proxy . . . . . . . . 17
7.6.3. Procedures at Tandem Proxy. . . . . . . . . . . 18
8. P-DCS-LAES and P-DCS-REDIRECT . . . . . . . . . . . . . . . . 18
8.1. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Procedures at an Untrusted User Agent Client (UAC). . . 20
8.3. Procedures at a Trusted User Agent Client (UAC) . . . . 20
8.4. Procedures at an Untrusted User Agent Server (UAS). . . 21
8.5. Procedures at a Trusted User Agent Server (UAS) . . . . 21
8.6. Procedures at Proxy . . . . . . . . . . . . . . . . . . 21
8.6.1. Procedures at Originating Proxy . . . . . . . . 22
8.6.2. Procedures at Terminating Proxy . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Intellectual Property Rights Notice . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References. . . . . . . . . . . . . . . . . . 25
12.2. Informative References. . . . . . . . . . . . . . . . . 26
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 26
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
The SIP extensions described in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The use of these headers is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required, as in for example the architecture presented in [6]. Use outside such a domain could result in the leakage of potentially sensitive or private information. User consent to the privacy implications of the policies in [6] is strongly encouraged in those domains as well.
本文档中描述的SIP扩展对网络拓扑、SIP和较低层之间的链接以及可传递信任的可用性做出了某些假设。这些假设通常不适用于整个互联网。这些报头的使用仅适用于封闭的管理域内，或在需要协调收费和其他功能的具有先前商定政策的管理域联合会之间，如[6]中所示的架构。在此类域之外使用可能导致潜在敏感或私人信息泄漏。这些领域也强烈鼓励用户同意[6]中政策的隐私影响。
Although RFC 2119 language is used in this document, the scope of the normative language is only for the area of applicability of the document and, like the technology, it does not apply to the general Internet.
尽管本文件使用了RFC 2119语言，但规范性语言的范围仅限于本文件的适用范围，与技术一样，不适用于一般互联网。
In order to deploy a SIP-based [2] residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys billing information and expectations about the parties involved in the call.
为了在不同的域中大规模部署基于SIP的[2]住宅电话服务，不同服务提供商拥有的可信元素必须交换可信信息，这些信息传递计费信息和对通话各方的期望。
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
今天，有许多计费模型用于从电话服务中获得收入。电话服务的收费与网络资源的使用紧密相连。讨论这些众多不同方法的细节超出了本文件的范围。
A key motivating principle of the DCS architecture described in [6] is the need for network service providers to be able to control and monitor network resources; revenue may be derived from the usage of these resources as well as from the delivery of enhanced services such as telephony. Furthermore, the DCS architecture recognizes the need for coordination between call signaling and resource management. This coordination ensures that users are authenticated and authorized before receiving access to network resources and billable enhanced services.
[6]中描述的DCS体系结构的一个关键激励原则是网络服务提供商需要能够控制和监控网络资源；收入可能来自使用这些资源以及提供电话等增强服务。此外，DCS体系结构认识到需要在呼叫信令和资源管理之间进行协调。这种协调可确保用户在获得对网络资源和可计费增强服务的访问权之前经过身份验证和授权。
DCS Proxies, as defined in [6], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connectivity and resource policy enforcement mechanism and also capture and report network connectivity and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The DCS Proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among DCS Proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call. See [6] for a description of the trust boundary and trusted versus untrusted entities.
[6]中定义的DCS代理可以访问用户信息，并充当呼叫信令路径上的策略决策点和可信中介。边缘路由器提供网络连接和资源策略实施机制，还可以捕获和报告网络连接和资源使用信息。边缘路由器需要提供计费信息，这些信息可以通过记录或计费服务器记录。DCS代理作为呼叫信令和资源管理之间的协调中心点，可以基于主叫方和被叫方的认证身份提供此信息。由于DCS代理之间存在信任关系，因此可以依赖它们来交换与呼叫相关方有关的可信计费信息。有关信任边界和受信任与不受信任实体的描述，请参见[6]。
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. It is the intent that the extensions would only appear on trusted network segments, should be inserted upon entering a trusted network region, and removed before leaving trusted network segments.
由于这些原因，考虑定义SIP报头扩展是合适的，以允许DCS代理在呼叫建立期间交换信息。其目的是，扩展仅出现在受信任的网段上，应在进入受信任的网络区域时插入，并在离开受信任的网段之前删除。
Significant amounts of information is retrieved by an originating DCS Proxy in its handling of a connection setup request from a user agent. Such information includes location information about the subscriber (essential for emergency services calls), billing information, and station information (e.g., coin operated phone). In addition, while translating the destination number, information such as the local-number-portability office code is obtained and will be needed by all other proxies handling this call.
原始DCS代理在处理来自用户代理的连接设置请求时检索大量信息。此类信息包括关于订户的位置信息（紧急服务呼叫所必需）、计费信息和站点信息（例如，投币式电话）。此外，在翻译目的地号码时，将获得本地号码可移植性办公室代码等信息，并且处理此呼叫的所有其他代理都需要这些信息。
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
对于使用情况记帐记录，需要有一个标识符，该标识符可以与为调用生成的所有事件记录相关联。SIP Call ID header字段不能用作这样的标识符，因为它是由发起用户代理选择的，并且在所有过去的呼叫以及当前呼叫中可能不是唯一的。此外，由于该标识符将由服务提供商使用，因此其选择方式和格式应满足服务提供商的需求。
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.
对于每个用户，计费信息可能不一定是唯一的（考虑一下从办公室打电话到同一个帐户的情况）。单个用户拨打的所有电话的计费信息可能不一定相同（考虑预付费电话、信用卡电话、对方付费电话等）。因此，有必要将计费信息与主叫方和被叫方标识分开。此外，一些计费模型要求分次计费，其中多个实体为部分呼叫计费。
The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
SIP General Header字段的添加允许捕获通话期间的计费信息和计费标识。
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a DCS Proxy in INVITE and REFER requests and INVITE responses in a trusted network segment, and removed before leaving trusted network segments.
其目的是，计费扩展仅出现在受信任的网段上，可由DCS代理插入受信任网段中的INVITE和REFER请求以及INVITE响应中，并在离开受信任网段之前删除。
In addition to support for billing, current residential telephone service includes the need for customer originated trace (of harassing or obscene calls), for operator services such as busy line verification and emergency interrupt (initiated by an operator from an Operator Services Position System (OSPS)), for emergency services such as 9-1-1 calls to a Public Service Access Point (PSAP) and the subsequent call handling, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders. In all of these cases, additional information about the call and about the subscribers involved in the call needs to be exchanged between the proxies.
除计费支持外，当前的住宅电话服务还包括对来自客户的跟踪（骚扰或淫秽电话）的需求，用于运营商服务，如繁忙线路验证和紧急中断（由运营商从运营商服务定位系统（OSPS）发起），用于紧急服务，如9-1-1呼叫公共服务接入点（PSAP）和后续呼叫处理，以及支持适用立法和法院命令要求的电子监控和执法访问。在所有这些情况下，需要在代理之间交换有关呼叫和呼叫中涉及的订户的附加信息。
The DCS architecture [6] defines a trust boundary around the various systems and servers that are owned, operated by, and/or controlled by the service provider. These trusted systems include the proxies and various servers such as bridge servers, voicemail servers, announcement servers, etc. Outside of the trust boundary lie the customer premises equipment, and various application and media servers operated by third-party service providers.
DCS体系结构[6]围绕服务提供商拥有、操作和/或控制的各种系统和服务器定义了信任边界。这些受信任的系统包括代理和各种服务器，如桥接服务器、语音邮件服务器、公告服务器等。信任边界之外是客户场所设备，以及由第三方服务提供商操作的各种应用程序和媒体服务器。
Certain subscriber-specific information, such as billing and accounting information, stays within the trust boundary. Other subscriber-specific information, such as endpoint identity, may be presented to untrusted endpoints or may be withheld based on subscriber profiles.
某些特定于订户的信息（如账单和会计信息）保留在信任边界内。其他特定于订阅者的信息，例如端点标识，可以呈现给不受信任的端点，或者可以基于订阅者配置文件而保留。
The User Agent (UA) may be either within the trust boundary or outside the trust boundary, depending on exactly what function is being performed and exactly how it is being performed. Accordingly, the procedures followed by a User Agent are different depending on whether the UA is within the trust boundary or outside the trust boundary.
用户代理（UA）可以在信任边界内或信任边界外，具体取决于正在执行的功能以及执行的方式。因此，用户代理遵循的过程根据UA是在信任边界之内还是在信任边界之外而不同。
The following sections giving procedures for User Agents therefore are subdivided into trusted user agents and untrusted user agents.
因此，以下给出用户代理程序的部分被细分为受信任的用户代理和不受信任的用户代理。
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The term "private-URL" used in this document refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy. The "userinfo" typically contains (or points to) information that is not to be disclosed outside the trusted domain of the proxies, such as billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information. Consequently, the information is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the "userinfo" portion of the URL. A checksum is included in the "userinfo" data to detect tampering. The mechanism by which a proxy recognizes a "userinfo" as a private-URL and decodes and recovers the original information is local to the proxy and is not subject to standardization. Some possible implementations include an initial magic cookie (e.g., z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (e.g., "private") with the optional "password" containing the pointer/information.
本文档中使用的术语“私有URL”是指由代理生成的SIP URI，包含标识代理的“主机端口”，并包含由代理生成的“用户信息”字符串。“userinfo”通常包含（或指向）不在代理的受信任域之外公开的信息，例如计费账号、电子监控指示、电子监控参数和呼叫重定向信息。因此，该信息要么由代理本地存储，要么使用只有代理知道的私钥进行加密，并在URL的“userinfo”部分以字符串形式编码。“userinfo”数据中包含校验和，用于检测篡改。代理将“userinfo”识别为私有URL并解码和恢复原始信息的机制是代理的本地机制，不受标准化的约束。一些可能的实现包括初始的magic cookie（例如，z9hG4Bk后跟指针/信息），或者使用保留的“用户名”（例如，“私有”）和包含指针/信息的可选“密码”。
In the telephone network, calling identity information is used to support regulatory requirements such as the Customer Originated Trace service, which provide the called party with the ability to report obscene or harassing phone calls to law enforcement. This service is provided independently of caller-id, and works even if the caller requested anonymity. The calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. One way to achieve this is described in [10].
在电话网络中，主叫身份信息用于支持监管要求，如客户发起的跟踪服务，该服务使被叫方能够向执法部门报告猥亵或骚扰电话。此服务独立于呼叫者id提供，即使呼叫者请求匿名也可以工作。呼叫方在此被标识为发起呼叫的站。为了使该服务可靠，被叫方必须能够相信所提供的主叫身份信息是有效的。实现这一点的一种方法如[10]所述。
To initiate a customer-originated-trace from an untrusted UAC, an additional header is defined for the INVITE request. This header is called P-DCS-Trace-Party-ID, and does not appear in any other request or response. The entity addressed by the Request-URI performs the service-provider-specific functions of recording and reporting the caller identity in the P-DCS-Trace-Party-ID for law enforcement action. It then forwards the call to either an announcement server or to the service-provider's business office to collect further information about the complaint. A trusted UAC does not use this header, as it initiates this action locally.
要从不受信任的UAC启动源自客户的跟踪，将为INVITE请求定义一个附加的头。此标头称为P-DCS-Trace-Party-ID，不会出现在任何其他请求或响应中。由请求URI寻址的实体执行特定于服务提供商的功能，即在P-DCS-Trace-PARY-ID中记录和报告呼叫者身份，以便采取执法行动。然后，它将呼叫转发给公告服务器或服务提供商的业务办公室，以收集有关投诉的进一步信息。受信任的UAC不使用此标头，因为它在本地启动此操作。
The ABNF description of this header is (some terms used in this ABNF are defined in [2]):
此标题的ABNF描述为（此ABNF中使用的一些术语在[2]中定义）：
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
P-DCS-Trace-Party-ID=“P-DCS-Trace-Party-ID”HCOLON name addr
This document adds the following entry to Table 2 of [2]:
本文件在[2]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
The addr-spec contained in name-addr contains a URL that identifies the remote endpoint. Addr-spec typically contains a tel: URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that established the session to be traced.
名称addr中包含的addr规范包含标识远程端点的URL。Addr规范通常包含一个tel:URL或SIP URI，提供远程端点的标识，如建立要跟踪的会话的信令消息中所提供的。
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA.
UAC必须在客户发起的跟踪请求的初始INVITE消息中插入P-DCS-Trace-Party-ID头。UAC必须在userinfo设置为“call trace”的请求URI中使用SIP URI，并在hostport中标识不受信任UA的呼叫跟踪实体。
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted UAS, described below. A trusted UAC MUST NOT include this header in any request.
可信UAC以类似于可信UAS的方式执行客户发起的跟踪，如下所述。受信任的UAC不得在任何请求中包含此标头。
This header MUST NOT appear in any response sent by a UAS.
此标头不得出现在UAS发送的任何响应中。
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" and hostport set to the UAS, the UAS MUST perform the service-provider-specific functions of recording and reporting
如果来自UAC的初始INVITE请求中存在P-DCS-Trace-Party-ID头，并且INVITE的请求URI将userinfo设置为“call Trace”，并将hostport设置为UAS，则UAS必须执行服务提供商特定的记录和报告功能
the caller identity for law enforcement action. The UAS then MUST redirect the call, via a 3xx response, to either an announcement server or to the service-provider's business office to collect further information about the complaint.
用于执法行动的呼叫者身份。然后，UAS必须通过3xx响应将呼叫重定向到公告服务器或服务提供商的业务办公室，以收集有关投诉的进一步信息。
This header MUST NOT appear in any response sent by a UAS.
此标头不得出现在UAS发送的任何响应中。
Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
定义了两组代理过程：（1）原始代理的过程，以及（2）终止代理的过程。发起代理是从不受信任的端点接收INVITE请求的代理。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
终止代理是将INVITE请求发送到不受信任端点的代理。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to an untrusted endpoint, performs both sets of procedures.
同时从不受信任的端点接收INVITE请求并将INVITE请求发送到不受信任端点的代理将执行这两组过程。
If the P-DCS-Trace-Party-ID header is present in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace" and hostport set to other than a potentially provisioned call tracing entity, then the Proxy MAY reject the request, or MAY remove the P-DCS-Trace-Party-ID header from the request. If the header is present in a valid request, and contains a private-URL that identifies the Proxy in the hostport, then the Originating Proxy SHOULD replace the private-URL with its original contents (i.e., the verified identity of the caller of the session that is being traced).
如果UAC的初始INVITE请求中存在P-DCS-Trace-PARY-ID头，并且INVITE的请求URI的userinfo不是“call Trace”，hostport设置为非潜在配置的呼叫跟踪实体，则代理可以拒绝该请求，或者可以从请求中删除P-DCS-Trace-PARY-ID头。如果标头存在于有效的请求中，并且包含在hostport中标识代理的私有URL，则发起代理应使用其原始内容（即正在跟踪的会话调用方的已验证标识）替换该私有URL。
This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint.
此标头不得出现在终止代理发送到不受信任端点的任何请求或响应中。
Some calls have special call processing requirements that may not be satisfied by normal user agent call processing. For example, when a user is engaged in a call and another call arrives, such a call might be rejected with a busy indication. However, some PSTN operator services require special call processing. In particular, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services initiated by an operator from an Operator Services Position System
某些呼叫有特殊的呼叫处理要求，正常的用户代理呼叫处理可能无法满足这些要求。例如，当用户正在进行呼叫且另一个呼叫到达时，这样的呼叫可能会被拒绝，并伴有忙指示。然而，一些PSTN运营商服务需要特殊的呼叫处理。特别是，由操作员从操作员服务位置系统启动的忙线验证（BLV）和紧急中断（EI）服务
(OSPS) on the PSTN network have such a need. Similarly, emergency calls to a 9-1-1 Public Service Access Point (PSAP) may result in trunk signaling causing operator ringback using a howling tone or sustained ring on the originating line (country-specific variations may exist).
PSTN网络上的OSP有这样的需求。类似地，对9-1-1公共服务接入点（PSAP）的紧急呼叫可能导致中继信令，从而导致运营商在始发线路上使用啸叫音或持续响铃进行回铃（可能存在特定国家的变化）。
In order to inform the SIP user agent that special treatment should be given to a call, we use a new P-DCS-OSPS header field, which may be set to a value indicating when a special type of call processing is requested. We define three values in this header, namely "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (e.g., howling/sustained tone ring in the US).
为了通知SIP用户代理应该对呼叫进行特殊处理，我们使用了一个新的P-DCS-OSPS报头字段，该字段可以设置为一个值，指示何时请求特殊类型的呼叫处理。我们在该报头中定义了三个值，即“BLV”用于繁忙线路验证，“EI”用于紧急中断，以及“RING”用于操作员回铃（例如，在美国，嚎叫/持续铃声）。
If the user agent decides to honor such a request, the response of the user agent to an INVITE with either "BLV" or "EI" will not be a busy indication. Since "EI" and "RING" only occur on established dialogs, they may also appear in UPDATE requests.
如果用户代理决定接受此类请求，则用户代理对带有“BLV”或“EI”的邀请的响应将不是忙指示。由于“EI”和“RING”仅出现在已建立的对话框上，因此它们也可能出现在更新请求中。
The ABNF description of the P-DCS-OSPS header is as follows (some terms used in this ABNF are defined in [2]):
P-DCS-OSPS标头的ABNF描述如下（本ABNF中使用的一些术语在[2]中有定义）：
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / token
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / token
This document adds the following entry to Table 2 of [2]:
本文件在[2]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - o -
The OSPS-Tag value of "token" is defined for extensibility, and is reserved for future use.
OSPS标记值“token”是为可扩展性而定义的，并保留供将来使用。
The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC.
P-DCS-OSPS标头不得在来自不受信任UAC的请求中发送。
This header is typically only inserted by a Media Gateway Controller [6] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. This trunk group is usually referred to as a BLV-trunk group and employs special signaling procedures that prevent inadvertent use. Calls originating at the PSTN OSPS system are sent over this trunk group, and result in an INVITE request with the P-DCS-OSPS header.
此报头通常仅由媒体网关控制器[6]插入，该控制器通过PSTN OSPS系统或PSAP的特殊中继控制媒体网关。该干线组通常被称为BLV干线组，并采用特殊的信令程序，以防止意外使用。在PSTN OSPS系统发起的呼叫通过该中继组发送，并产生带有P-DCS-OSPS头的INVITE请求。
This header MAY be sent in an INVITE request, and MUST NOT appear in any message other than those listed below.
此标题可以在邀请请求中发送，并且不得出现在除下列消息之外的任何消息中。
OSPS-Tag value "BLV" MUST NOT appear in any request or response other than an initial INVITE request establishing a new dialog.
OSPS标记值“BLV”不得出现在任何请求或响应中，除了建立新对话框的初始INVITE请求。
OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a pre-existing dialog established with the OSPS-Tag value of "BLV".
OSPS标签值“EI”不得出现在任何请求或响应中，除了（1）使用OSPS标签值“BLV”建立的现有对话框中的后续邀请，或（2）使用OSPS标签值“BLV”建立的现有对话框中的更新请求。
OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a pre-existing dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a pre-existing dialog established by a UAC to an operator or PSAP.
OSPS标签值“环”不得出现在任何请求或响应中，除了（1）UAC向运营商或PSAP建立的预先存在的对话框中的后续邀请，或（2）UAC向运营商或PSAP建立的预先存在的对话框中的更新请求。
If the UAS receives an INVITE request with an OSPS-Tag of "BLV", dialog identification that matches an existing dialog, and the existing call was not established with the OSPS-Tag, it MUST reject the request with a 403-Forbidden error code.
如果UAS接收到OSPS标记为“BLV”的INVITE请求、与现有对话匹配的对话标识，并且现有呼叫未使用OSPS标记建立，则UAS必须使用403禁止的错误代码拒绝该请求。
If the UAS receives an INVITE/UPDATE request with an OSPS-Tag value of "EI" or "RING", with dialog identification that does not match an existing dialog, it MUST reject the request with a 403-Forbidden response code.
如果UAS接收到OSPS标签值为“EI”或“RING”且对话框标识与现有对话框不匹配的INVITE/UPDATE请求，则必须使用403禁止响应代码拒绝该请求。
If the UAS receives an INVITE that contains an OSPS-Tag value of "BLV" and is not willing to cooperate in offering this service, it MUST reject the request with a 403-Forbidden response code.
如果UAS收到包含OSPS标签值“BLV”的INVITE，并且不愿意合作提供此服务，则必须使用403禁止响应代码拒绝该请求。
The UAS SHOULD NOT reject an INVITE with a BLV OSPS-Tag due to a busy condition. The UAS MUST NOT respond with a 3xx-Redirect response code to an INVITE with a BLV OSPS-Tag. The UAS SHOULD NOT alert the user of the incoming call attempt if the BLV OSPS-Tag is present in the INVITE.
UAS不应因繁忙情况而拒绝带有BLV OSPS标签的邀请。UAS不得使用3xx重定向响应代码响应带有BLV OSPS标记的INVITE。如果INVITE中存在BLV OSPS标签，UAS不应提醒用户来电尝试。
If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all QoS pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the SDP of the INVITE. The UAS MAY perform a mixing operation between the two ends of an existing active call and send the resulting media stream to the address and port indicated. Alternatively, the UAS MAY send a copy of the local voice stream, and (if no activity on the local voice stream) send a copy of the received voice stream of an existing call. If the state of the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS. If the state of the UAS is ringing or ringback, the UAS SHOULD send a ringback stream to OSPS.
如果接受OSPS标记为“BLV”的INVITE（例如，满足所有QoS先决条件等），UAS必须在此连接上将音频流发送到INVITE SDP中给出的地址和端口。UAS可以在现有活动呼叫的两端之间执行混合操作，并将结果媒体流发送到所指示的地址和端口。或者，UAS可以发送本地语音流的副本，并且（如果本地语音流上没有活动）发送现有呼叫的接收语音流的副本。如果UAS的状态为空闲，则UAS应向OSP发送静默数据包流。如果UAS的状态为振铃或回铃，则UAS应向OSP发送回铃流。
If an INVITE/UPDATE with OSPS-Tag of "EI" is accepted, the UAS MUST enable communication between the UAC and the local user. The UAS MAY put any existing call on hold, or initiate an ad-hoc conference.
如果接受OSPS标签为“EI”的邀请/更新，UAS必须启用UAC和本地用户之间的通信。UAS可暂停任何现有通话，或发起临时会议。
If an INVITE/UPDATE with OSPS-Tag of "RING" is accepted, the UAS MUST perform operator ringback in accordance with local procedures, e.g., generate a 3-second howling tone or a sustained ring, depending on the state of the user equipment.
如果接受OSPS标记为“响铃”的INVITE/UPDATE，UAS必须根据本地程序执行操作员回铃，例如，根据用户设备的状态生成3秒啸叫音或持续响铃。
The procedures at a trusted UAS MUST be identical to those described in 6.4.
受信任UAS的程序必须与6.4中描述的程序相同。
In the DCS architecture, the OSPS is considered a trusted UAC. If a proxy receives a P-DCS-OSPS header in a request from an untrusted source, it MUST either remove the header or reject the request with a 403-Forbidden response.
在DCS体系结构中，OSPS被视为受信任的UAC。如果代理在来自不受信任源的请求中接收到P-DCS-OSPS头，则必须删除该头或以403禁止响应拒绝该请求。
A proxy that implements a call-forwarding service MUST NOT respond to an INVITE request with a 3xx response, if the request contained the P-DCS-OSPS header.
如果INVITE请求包含P-DCS-OSPS头，则实现呼叫转移服务的代理不得以3xx响应响应INVITE请求。
There are many billing models used in deriving revenue from telephony services today. Charging for telephony services is tightly coupled to the use of network resources. It is outside the scope of this document to discuss the details of these numerous and varying methods.
今天，有许多计费模型用于从电话服务中获得收入。电话服务的收费与网络资源的使用紧密相连。讨论这些众多不同方法的细节超出了本文件的范围。
Proxies have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path. Edge routers provide the network connection and resource
代理可以访问用户信息，并在呼叫信令路径上充当策略决策点和可信中介。边缘路由器提供网络连接和资源
policy enforcement mechanism and also capture and report network connection and resource usage information. Edge routers need to be given billing information that can be logged with Record Keeping or Billing servers. The proxy, as a central point of coordination between call signaling and resource management, can provide this information based on the authenticated identity of the calling and called parties. Since there is a trust relationship among proxies, they can be relied upon to exchange trusted billing information pertaining to the parties involved in a call.
策略实施机制，并捕获和报告网络连接和资源使用信息。边缘路由器需要提供计费信息，这些信息可以通过记录或计费服务器记录。代理作为呼叫信令和资源管理之间的协调中心点，可以基于呼叫方和被叫方的认证身份提供此信息。由于代理之间存在信任关系，因此可以依赖它们来交换与呼叫中涉及的各方有关的可信计费信息。
For Usage Accounting records, it is necessary to have an identifier that can be associated with all the event records produced for the call. The SIP Call-ID header field cannot be used as such an identifier since it is selected by the originating user agent, and may not be unique among all past calls as well as current calls. Further, since this identifier is to be used by the service provider, it should be chosen in a manner and in a format that meets the service provider's needs.
对于使用情况记帐记录，需要有一个标识符，该标识符可以与为调用生成的所有事件记录相关联。SIP Call ID header字段不能用作这样的标识符，因为它是由发起用户代理选择的，并且在所有过去的呼叫以及当前呼叫中可能不是唯一的。此外，由于该标识符将由服务提供商使用，因此其选择方式和格式应满足服务提供商的需求。
Billing information may not necessarily be unique for each user (consider the case of calls from an office all billed to the same account). Billing information may not necessarily be identical for all calls made by a single user (consider prepaid calls, credit card calls, collect calls, etc). It is therefore necessary to carry billing information separate from the calling and called party identification. Furthermore, some billing models call for split-charging where multiple entities are billed for portions of the call.
对于每个用户，计费信息可能不一定是唯一的（考虑一下从办公室打电话到同一个帐户的情况）。单个用户拨打的所有电话的计费信息可能不一定相同（考虑预付费电话、信用卡电话、对方付费电话等）。因此，有必要将计费信息与主叫方和被叫方标识分开。此外，一些计费模型要求分次计费，其中多个实体为部分呼叫计费。
The addition of a SIP General Header Field allows for the capture of billing information and billing identification for the duration of the call.
SIP General Header字段的添加允许捕获通话期间的计费信息和计费标识。
It is the intent that the billing extensions would only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE requests in a trusted network segment, and removed before leaving trusted network segments. The P-DCS-Billing-Info header extension is used only on requests and responses between proxies and trusted User Agents. It is never sent to, nor sent by, an untrusted UA.
其目的是计费扩展只出现在受信任的网段上，并且可以由代理或受信任的UA在受信任网段的INVITE请求中插入，并在离开受信任的网段之前删除。P-DCS-Billing-Info标头扩展仅用于代理和受信任用户代理之间的请求和响应。它不会发送给不受信任的UA，也不会由不受信任的UA发送。
The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [2]):
DCS计费信息头由以下ABNF定义（本ABNF中使用的一些术语在[2]中定义）：
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT
This document adds the following entry to Table 2 of [2]:
本文件在[2]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
The P-DCS-Billing-Info extension contains an identifier that can be used by an event recorder to associate multiple usage records, possibly from different sources, with a billable account. It further contains the subscriber account information, and other information necessary for accurate billing of the service. This header is only used between proxies and trusted User Agents.
P-DCS-Billing-Info扩展包含一个标识符，事件记录器可使用该标识符将多个使用记录（可能来自不同来源）与可计费帐户关联。它还包含用户帐户信息，以及准确计费服务所需的其他信息。此标头仅在代理和受信任的用户代理之间使用。
The Billing-Correlation-ID is specified in [9] as a 24-byte binary structure, containing 4 bytes of NTP timestamp, 8 bytes of the unique identifier of the network element that generated the ID, 8 bytes
在[9]中，计费关联ID被指定为24字节的二进制结构，包含4字节的NTP时间戳，8字节的生成ID的网元唯一标识符，8字节
giving the time zone, and 4 bytes of monotonically increasing sequence number at that network element. This identifier is chosen to be globally unique within the system for a window of several months. This MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. Leading zeroes MAY be suppressed.
给出时区，以及该网元上4字节单调递增的序列号。该标识符在系统内选择为全局唯一，为期几个月。这必须在P-DCS-Billing-Info报头中编码为最多48个字符的十六进制字符串。前导零可能被抑制。
The Financial-Entity-ID (FEID) is specified in [9] as an 8-byte structure, containing the financial identifier for that domain, followed by a domain name. FEID can be associated with a type of service and could be assigned to multiple domains by the same provider. A domain could contain multiple assigned FEIDs. This 8- byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. Trailing zeroes MAY be suppressed. "Host" contains the domain name.
[9]将金融实体ID（FEID）指定为8字节结构，包含该域的金融标识符，后跟域名。FEID可以与一种服务类型相关联，并且可以由同一提供商分配给多个域。一个域可以包含多个分配的FEID。此8字节结构必须在P-DCS-Billing-Info报头中编码为最多16个字符的十六进制字符串。可以抑制尾随零。“主机”包含域名。
The RKS-Group-ID specifies a record keeping server (or group of cooperating servers) for event messages relating to this call. It is used to control certain optimizations of procedures when multiple event message streams are being sent to the same Record Keeping Server.
RKS组ID为与此调用相关的事件消息指定一个记录保存服务器（或一组协作服务器）。当多个事件消息流被发送到同一个记录保存服务器时，它用于控制过程的某些优化。
Additional parameters contain the information needed for generation of event message records. Acct-Charge-URI, Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI are each defined as URLs; they should all contain tel: URLs with E.164 formatted addresses. These fields are further defined in [9] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22).
其他参数包含生成事件消息记录所需的信息。账户费用URI、账户调用URI、账户调用URI、账户路由URI和账户位置路由URI均定义为URL；它们都应该包含带有E.164格式地址的tel:URL。[9]在要素标识符“费用方编号”（要素ID 16）、“主叫方编号”（要素ID 4）、“被叫方编号”（要素ID 5）、“路由编号”（要素ID 25）和“位置方编号”（要素ID 22）下进一步定义了这些字段。
This header is never sent to an untrusted UAC, and is never sent by an untrusted UAC.
此标头从未发送到不受信任的UAC，也从未由不受信任的UAC发送。
The UAC MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the UAC. If the UAC performed a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number returned by the query.
UAC必须生成呼叫的计费关联ID，并将其与呼叫的计费信息一起插入发送到终止代理的初始INVITE消息中的P-DCS-Billing-Info头中。UAC必须包含其FEID和UAC使用的记录保存服务器的RKS组ID。如果UAC执行本地号码可移植性（LNP）查询，则必须包括查询返回的路由号码和位置路由号码。
If the response to the initial INVITE is a 3xx-Redirect, the UAC generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If a UAC receives a 3xx-Redirect response to an initial INVITE, the new INVITE generated by the UAC MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response. If the UAC is acting as a B2BUA, instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
如果对初始INVITE的响应是3xx重定向，UAC将根据标准SIP生成一个新的初始INVITE请求，发送到Contact:头中指定的目的地。如果UAC收到对初始邀请的3xx重定向响应，UAC生成的新邀请必须包含3xx重定向响应中的P-DCS-Billing-Info头。如果UAC充当B2BUA，它可能会生成一个私有URL，并将其放置在发送到发起端点的3xx重定向响应的联系人标头中，而不是生成一个新的INVITE。此专用URL必须包含（或包含指向）P-DCS-Billing-Info值，该值指示新呼叫的收费安排，以及未来很短的到期时间，以限制发起人对多个呼叫重复使用此专用URL的能力。
A UAC that includes a Refer-to header in a REFER request MUST include a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator of the REFER.
在Refer请求中包含Refer-Refer标头的UAC必须在Refer-Refer的URL中包含P-DCS-Billing-Info标头。此P-DCS-Billing-Info标头必须包含提交人的会计信息。
This header is never sent to an untrusted UAS, and is never sent by an untrusted UAS.
此标头从未发送到不受信任的UAS，也从未由不受信任的UAS发送。
The UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping-Server being used by the UAS. The UAS MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the new Acct-Charge-URI MUST be determined by service provider policy provisioned in the UAS. If the UAS performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
UAS必须在对初始INVITE消息的第一个可靠1x（100除外）或2xx响应中包含P-DCS-Billing-Info标头。此P-DCS-Billing-Info标头必须包括UAS生成的计费关联ID、UAS的FEID以及UAS使用的记录保存服务器的RKS组ID。如果UAS希望覆盖INVITE中存在的计费信息（例如，对于免费电话），则UAS可以更改Acct Charge URI的值。执行此操作的决定以及新帐户费用URI的内容必须由UAS中提供的服务提供商策略确定。如果UAS执行LNP查询，则必须包括查询返回的路由号码和位置路由号码。
The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.
UAS必须在对初始邀请的3xx重定向响应中添加一个P-DCS-Billing-Info报头，为从目的地到转发目的地的呼叫段提供呼叫转发器的记帐信息。
Three sets of proxy procedures are defined: (1) the procedures at an originating proxy, (2) the procedures at a terminating proxy, and (3) the procedures at a tandem proxy.
定义了三组代理程序：（1）发起代理程序，（2）终止代理程序，以及（3）串联代理程序。
The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
发起代理是从不受信任的端点接收INVITE请求的代理。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
终止代理是将INVITE请求发送到不受信任端点的代理。
A proxy that is neither an originating proxy, nor a terminating proxy, is a tandem proxy.
既不是原始代理也不是终止代理的代理是串联代理。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.
对于中间呼叫更改，例如呼叫转移，从非受信任端点接收请求的代理被视为发起代理；将请求发送到不受信任端点的代理被视为收件人代理。发起代理的程序包含在发起代理的程序中，接收方代理的程序包含在终止代理的程序中。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, performs both sets of procedures.
同时从不受信任的端点接收INVITE请求并将INVITE请求发送到不受信任的端点的代理将执行这两组过程。
The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE message sent to the terminating proxy, along with the charging information for the call. The originating proxy MUST include its FEID, and the RKS-Group-ID for the Record-Keeping-Server being used by the originating proxy. If the originating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed.
发起代理必须生成呼叫的计费关联ID，并将其与呼叫的计费信息一起插入发送到终止代理的初始INVITE消息中的P-DCS-Billing-Info头中。原始代理必须包括其FEID和原始代理使用的记录保留服务器的RKS组ID。如果原始代理执行LNP查询，则必须包括查询返回的路由号码和位置路由号码。必须删除来自不受信任UA的任何P-DCS-Billing-Info标头。
If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting information for the call originator, and insert a P-DCS-Billing-Info header including that information.
如果请求URI包含私有URL，且解码的用户名包含计费信息，则发起代理必须使用该解密信息生成P-DCS-billing-Info标头。否则，发起代理必须确定呼叫发起人的会计信息，并插入包含该信息的P-DCS-Billing-Info报头。
If the response to the initial INVITE is a 3xx-Redirect, received prior to a 18x, the originating proxy generates a new initial INVITE request to the destination specified in the Contact: header, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a 18x response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.
如果对初始INVITE的响应是在18x之前接收到的3xx重定向，则发起代理将根据标准SIP向Contact:标头中指定的目的地生成新的初始INVITE请求。如果发起代理在18x响应之前收到对初始INVITE的3xx重定向响应，则代理生成的INVITE必须包含3xx重定向响应的P-DCS-Billing-Info标头。
If the response to the initial INVITE is a 3xx-Redirect, received after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls.
如果对初始INVITE的响应是在18x之后接收的3xx重定向，则发起代理将生成一个私有URL，并将其放置在发送到发起端点的3xx重定向响应的联系人标头中。此专用URL必须包含（或包含指向）P-DCS-Billing-Info值，该值指示新呼叫的收费安排，以及未来很短的到期时间，以限制发起者对多个呼叫重复使用此专用URL的能力。
An originating proxy that processes a REFER request from an untrusted UA MUST include a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator.
处理来自不受信任UA的REFER请求的原始代理必须在REFER的URL中包含P-DCS-Billing-Info标头。此P-DCS-Billing-Info标头必须包含发起人的会计信息。
The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination.
终止代理不得将P-DCS-Billing-Info标头发送到不受信任的目标。
The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record-Keeping-Server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed a LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
终止代理必须在对初始INVITE消息的第一个可靠1x（100除外）或2xx响应中包含P-DCS-Billing-Info标头。此P-DCS-Billing-Info标头必须包括终止代理生成的计费关联ID、终止代理的FEID以及终止代理使用的记录保留服务器的RKS组ID。如果终止代理希望覆盖INVITE中存在的计费信息（例如，对于免费呼叫），则终止代理可以更改Acct Charge URI的值。执行此操作的决定以及生成的P-DCS-Billing-Info报头的内容必须由终止代理中提供的服务提供商策略确定。如果终止代理执行LNP查询，则必须包括查询返回的路由号码和位置路由号码。
The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination.
终止代理必须将P-DCS-Billing-Info头添加到对初始邀请的3xx重定向响应中，为从目的地到转发目的地的呼叫段提供呼叫转发器的记帐信息。
A proxy receiving a mid-call REFER request that includes a Refer-to header generates a private-URL and places it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-Billing-Info value, which indicate the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls.
代理接收包含refere-to头的mid-call-refere请求时，会生成一个私有URL，并将其放置在发送给端点的refere-to头中。此专用URL必须包含P-DCS-Billing-Info值，该值指示新呼叫的收费安排，以及未来很短的到期时间，以限制端点对多个呼叫重复使用此专用URL的能力。
If the tandem proxy performed a LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response.
如果串联代理执行LNP查询，则必须将查询返回的路由号码和位置路由号码插入第一个可靠的1xx/2xx/3xx（100除外）响应中的P-DCS-Billing-Info标头。
NOTE: According to RFC 2804 [5], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The RFC 2119 language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology.
注：根据RFC 2804[5]，如果有必要开发合法拦截技术，IETF支持合法拦截技术的文档。以下部分提供了此类文档。如上所述，RFC 2119语言仅在实施时描述规范的要求，且严格在上述适用范围内。有关此技术的隐私、安全性和复杂性问题的说明，请参见RFC 2804。
The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header may also contain an additional address and port for delivery of call content. Security key information is included to enable pairs of Delivery Functions to securely exchange surveillance information. This header is only used between proxies and trusted User Agents.
P-DCS-LAES扩展包含支持合法授权电子监控所需的信息。此标头包含电子监视传递功能的地址和端口，用于传递与此呼叫相关的重复事件消息流。报头还可以包含用于传送呼叫内容的附加地址和端口。包括安全密钥信息，以使成对的传递功能能够安全地交换监视信息。此标头仅在代理和受信任的用户代理之间使用。
The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted User Agents.
P-DCS-Redirect分机包含支持合法授权的重定向呼叫电子监控要求所需的呼叫识别信息。此标头仅在代理和受信任的用户代理之间使用。
Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination of legislation, regulation, and court orders, which MUST be followed. In certain cases inclusion of these headers will be mandated, and therefore MUST be present in the requests and responses indicated. In other cases inclusion of these headers will be forbidden, and therefore MUST NOT be present in the request and responses indicated. In the sub-sections that follow, use of "SHOULD" is intended to
P-DCS-LAES和P-DCS-Redirect的使用由立法、法规和法院命令的组合控制，必须遵守。在某些情况下，将强制包含这些标题，因此必须出现在所示的请求和响应中。在其他情况下，将禁止包含这些标头，因此不得出现在所示的请求和响应中。在下面的小节中，使用“应该”旨在
capture these conflicting situations, e.g., a P-DCS-LAES header SHOULD be included in an initial INVITE means either that it MUST be included or that it MUST NOT be included, based on the applicable court orders.
捕获这些冲突情况，例如，初始邀请中应包含P-DCS-LAES标题意味着根据适用的法院命令，必须包含或不包含该标题。
The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [2] and [3]):
以下ABNF给出了P-DCS-LAES和P-DCS-Redirect标头的格式（本ABNF中使用的一些术语在[2]和[3]中有定义）：
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-key / generic-param
Laes-content = "content" EQUAL hostport
Laes-key = "key" EQUAL token
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-key / generic-param
Laes-content = "content" EQUAL hostport
Laes-key = "key" EQUAL token
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGIT
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGIT
This document adds the following entry to Table 2 of [2]:
本文件在[2]的表2中添加了以下条目：
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - -
P-DCS-Redirect adr - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - -
P-DCS-Redirect adr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
- - - - - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- - - - - -
- - - - - -
The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call-content, respectively. Laes-key is a string generated by the proxy that is used by the Delivery Function to securely transfer information between them [8].
Laes sig和Laes内容的值是电子监视传送功能的地址，分别用作呼叫识别信息和呼叫内容的目的地地址。Laes密钥是由代理生成的字符串，传递函数使用该字符串在它们之间安全地传输信息[8]。
The P-DCS-Redirect header contains redirection information. The redir-uri-param indicates the original destination requested by the user (e.g., dialed number), the Redirector indicates the new destination, and the Redir-count indicates the number of redirections that have occurred.
P-DCS-Redirect标头包含重定向信息。redir uri参数表示用户请求的原始目的地（例如，已拨号码），重定向器表示新目的地，redir计数表示已发生的重定向数。
This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC.
此标头不得发送到不受信任的UAC，也不得由不受信任的UAC发送。
The UAC checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
UAC检查发起用户的未完成合法授权监视命令，如果存在，则将此信息包括在服务质量授权[7]中，或将此信息发送给执行拦截的设备（例如，媒体网关）。
If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the UAC MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).
如果P-DCS-LAES报头出现在第一个可靠的1x（100除外）、2xx或3xx响应中（表示需要对终端用户进行监控，但终端设备无法执行该功能），UAC必须在服务质量授权中包含该信息，或者必须将此信息发送给执行截获的设备（例如，媒体网关）。
If a 3xx-Redirect response is received to the initial INVITE request, and if a P-DCS-LAES header is present in the 3xx response, the UAC SHOULD include that header unchanged in the reissued INVITE. The UAC SHOULD also include a P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred. Although it is technically possible for the originating equipment to perform this surveillance (or add to its existing surveillance of the call), the design of the surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.
如果收到对初始INVITE请求的3xx重定向响应，并且如果3xx响应中存在P-DCS-LAES头，UAC应在重新发布的INVITE中包含该头不变。UAC还应包括一个P-DCS-Redirect标头，其中包含原始拨号号码、新目的地号码和已发生的重定向次数。虽然从技术上讲，始发设备可以执行此监视（或添加到其现有的呼叫监视中），但监视系统的设计具有对所有中间转发器执行监视的终端设备。
A UAC that includes a Refer-to header in a REFER request, when the originating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header attached to the Refer-to. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
当发起订户有未完成的合法授权监视命令时，在Refer请求中包含Refer Refer标头的UAC应包括附加到Refer Refer的P-DCS-LAES标头。P-DCS-LAES报头应包括本地电子监控交付功能的地址和端口（用于呼叫事件消息的副本），如果要拦截呼叫内容，则应包括本地电子监控交付功能的地址和端口（用于呼叫内容的副本），并且应该包含一个随机字符串，用作传递函数之间的安全密钥。
The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
受信任的UAC不得将P-DCS-LAES和P-DCS-Redirect头发送到不受信任的实体。
This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS.
此标头不得发送给不受信任的UAS，也不得由不受信任的UAS发送。
The UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber, or presence of the P-DCS-LAES header in the INVITE request. If either is present, the UAS includes this information in the authorization for Quality of Service [7].
UAS检查终止用户的未完成合法授权监视命令，或INVITE请求中是否存在P-DCS-LAES标头。如果存在任何一种情况，UAS将该信息包括在服务质量授权中[7]。
If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the UAS SHOULD include a P-DCS-LAES header in the first reliable non-100 response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
如果终端设备无法执行所需的监视（例如，如果目的地是语音邮件服务器），UAS应在请求发起代理执行监视的第一个可靠非100响应中包括P-DCS-LAES报头。P-DCS-LAES报头应包括本地电子监控交付功能的地址和端口（用于呼叫事件消息的副本），如果要拦截呼叫内容，则应包括本地电子监控交付功能的地址和端口（用于呼叫内容的副本），并且应该包含一个随机字符串，用作传递函数之间的安全密钥。
If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
如果对初始INVITE请求的响应是3xx重定向响应，并且存在针对终止订户的未完成的合法授权监视命令，则UAS应在3xx重定向响应中包含一个P-DCS-LAES头，其内容如上所述。
The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
受信任的UAS不得将P-DCS-LAES和P-DCS-Redirect头发送到不受信任的实体。
Two sets of proxy procedures are defined: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy. The originating proxy is a proxy that received the INVITE request from a non-trusted endpoint.
定义了两组代理过程：（1）原始代理的过程，以及（2）终止代理的过程。发起代理是从不受信任的端点接收INVITE请求的代理。
The terminating proxy is a proxy that sends the INVITE request to a non-trusted endpoint.
终止代理是将INVITE请求发送到不受信任端点的代理。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from a non-trusted endpoint is considered the initiating proxy; the proxy that sends the request to a non-trusted endpoint is considered the recipient proxy. Procedures for the initiating proxy are included below with those for originating proxies, while procedures for the recipient proxy are included with those for terminating proxies.
对于中间呼叫更改，例如呼叫转移，从非受信任端点接收请求的代理被视为发起代理；将请求发送到不受信任端点的代理被视为收件人代理。发起代理的程序包含在发起代理的程序中，接收方代理的程序包含在终止代理的程序中。
A proxy that both receives the INVITE request from an untrusted endpoint, and sends the INVITE request to a non-trusted endpoint, MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers.
从不受信任的端点接收INVITE请求并将INVITE请求发送到不受信任的端点的代理不得生成P-DCS-LAES或P-DCS-Redirect头。
A proxy that is neither an originating proxy nor a terminating proxy SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers in requests and responses.
既不是原始代理也不是终止代理的代理应在请求和响应中传递P-DCS-Laes和P-DCS-Redirect头。
The Originating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or untrusted UA.
发起代理必须删除对不受信任的代理或不受信任的UA的请求或响应中的任何P-DCS-LAE和P-DCS-Redirect头。
The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and, if present, includes this information in the Authorization for Quality of Service [7] or signals this information to the device performing the intercept (e.g., a Media Gateway).
发起代理为发起订户检查未完成的合法授权监视命令，如果存在，则将此信息包括在服务质量授权中[7]，或将此信息发送给执行拦截的设备（例如，媒体网关）。
If the P-DCS-LAES header is present in the first reliable 1xx (except 100), 2xx or 3xx response (indicating surveillance is required on the terminating subscriber, but that the terminating equipment is unable to perform that function), the originating proxy MUST include this information in the Authorization for Quality of Service, or MUST signal this information to the device performing the intercept (e.g., a Media Gateway).
如果P-DCS-LAES报头出现在第一个可靠的1x（100除外）、2xx或3xx响应中（表示需要对终端用户进行监控，但终端设备无法执行该功能），则发起代理必须在服务质量授权中包含该信息，或者必须将此信息发送给执行截获的设备（例如，媒体网关）。
If the Request-URI in an initial INVITE request contains a private-URL, the originating proxy MUST decrypt the userinfo information to find the real destination for the call, and other special processing information. If electronic surveillance information is contained in the decrypted userinfo, the originating proxy SHOULD generate a P-DCS-LAES header with the surveillance information.
如果初始INVITE请求中的请求URI包含私有URL，则发起代理必须解密userinfo信息以找到调用的真实目的地以及其他特殊处理信息。如果解密的用户信息中包含电子监控信息，则发起代理应生成带有监控信息的P-DCS-LAES标头。
If a 3xx-Redirect response is received to the initial INVITE request prior to a 18x, and if a P-DCS-LAES header is present in the 3xx response, the originating proxy SHOULD include that header unchanged in the reissued INVITE. The originating proxy SHOULD also include a
如果在18x之前接收到针对初始INVITE请求的3xx重定向响应，并且如果3xx响应中存在P-DCS-LAES头，则发起代理应在重新发布的INVITE中包含该头，该头不变。发起代理还应包括
P-DCS-Redirect header containing the original dialed number, the new destination number, and the number of redirections that have occurred.
P-DCS-Redirect标头，包含原始拨号号码、新目的地号码和已发生的重定向次数。
If a 3xx-Redirect response is received to the initial INVITE request after a 18x, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. If a P-DCS-LAES header is present in the 3xx response, this private-URL MUST contain (1) the electronic surveillance information from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections of this call.
如果在18x之后收到对初始INVITE请求的3xx重定向响应，则发起代理将生成一个私有URL，并将其放置在发送到发起端点的3xx重定向响应的联系人标头中。如果3xx响应中存在P-DCS-LAES报头，则此专用URL必须包含（1）来自3xx重定向响应的电子监控信息，（2）原始目的地号码，（3）重定向方的身份，以及（4）此呼叫的重定向次数。
An originating proxy that processes a REFER request [4] from an untrusted UA, when the originating subscriber has an outstanding lawfully authorized surveillance order, becomes a B2BUA for that request. It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-to's URL. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, (2) the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and (3) a random string for use as a security key between the Delivery Functions.
当发起订户有未完成的合法授权监视命令时，处理来自不受信任UA的引用请求[4]的发起代理成为该请求的B2BUA。它应该重新发出请求，并将P-DCS-LAES头添加到refereto的URL中。P-DCS-LAES报头应包括（1）本地电子监控交付功能的地址和端口，用于呼叫事件消息的副本，（2）本地电子监控交付功能的地址和端口，用于呼叫内容的副本（如果要拦截呼叫内容），以及（3）用作传递函数之间的安全密钥的随机字符串。
An initiating proxy that sends a mid-call REFER request including a Refer-to header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-to's URL.
当发起订户有未完成的合法授权的监视命令时，发送包括REFER-to头的mid call REFER请求的发起代理应在REFER的URL中包含P-DCS-LAES头。
The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity.
发起代理不得将P-DCS-LAES和P-DCS-Redirect头发送到不受信任的实体。
The Terminating Proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or UA.
终止代理必须删除对不受信任的代理或UA的请求或响应中的任何P-DCS-LAE和P-DCS-Redirect头。
The terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber. If present, the terminating proxy includes this information in the authorization for Quality of Service [7].
终止代理为终止订户检查未完成的合法授权监视命令。如果存在，终止代理将此信息包括在服务质量授权中[7]。
The terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity, either as headers in the request or response, or as headers attached to URIs in the request or response.
终止代理不得将P-DCS-LAES和P-DCS-Redirect头作为请求或响应中的头或作为附加到请求或响应中URI的头发送到不受信任的实体。
If the terminating equipment is unable to perform the required surveillance (e.g., if the destination is a voicemail server), the terminating proxy SHOULD include a P-DCS-LAES header in the first reliable 1xx/2xx/3xx (except 100) response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is to be intercepted, and SHOULD include a random string for use as a security key between the Delivery Functions.
如果终端设备无法执行所需的监视（例如，如果目的地是语音邮件服务器），则终端代理应在请求发起代理执行监视的第一个可靠1xx/2xx/3xx（100除外）响应中包含P-DCS-LAES报头。P-DCS-LAES报头应包括本地电子监控交付功能的地址和端口（用于呼叫事件消息的副本），如果要拦截呼叫内容，则应包括本地电子监控交付功能的地址和端口（用于呼叫内容的副本），并且应该包含一个随机字符串，用作传递函数之间的安全密钥。
If the response to the initial INVITE request is a 3xx-Redirect response, and there is an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with contents as described above.
如果对初始INVITE请求的响应是3xx重定向响应，并且存在针对终止订户的未完成合法授权的监视命令，则终止代理应在3xx重定向响应中包含一个P-DCS-LAES头，其内容如上所述。
A proxy receiving a mid-call REFER request [4] that includes a Refer-to header with a P-DCS-LAES header attached becomes a B2BUA for this request. It MUST generate a private-URL and place it in the Refer-to header sent to the endpoint. This private-URL MUST contain the P-DCS-LAES information from the attached header.
接收到中间调用引用请求[4]的代理（该请求包括带有P-DCS-LAES头的引用头）将成为该请求的B2BUA。它必须生成一个私有URL，并将其放置在发送到端点的refere-to头中。此专用URL必须包含附加标头中的P-DCS-LAES信息。
QoS gate coordination, billing information, and electronic surveillance information are all considered to be sensitive information that MUST be protected from eavesdropping and furthermore require integrity checking. It is therefore necessary that the trusted UAs and proxies take precautions to protect this information from eavesdropping and tampering. Use of IPsec or TLS between Proxies is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [8]. Also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies, both of which MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party. If IPsec is to be used, the specification of the security policies and procedures of the administrative domain where these headers are applicable (and all connections between administrative domains in the federation) MUST define an interoperable set of options.
QoS门协调、计费信息和电子监控信息都被视为敏感信息，必须防止窃听，并且需要进行完整性检查。因此，受信任的UAs和代理必须采取预防措施，保护这些信息不被窃听和篡改。需要在代理之间使用IPsec或TLS。[8]给出了为DCS体系结构实施IPsec配置的最低要求。还需要代理之间的相互身份验证（1）和（2）受信任的UAs和代理之间的相互身份验证，这两者都可以通过管理预共享密钥或通过与另一个受信任的第三方协商来实现。如果要使用IPsec，这些头文件适用的管理域（以及联合体中管理域之间的所有连接）的安全策略和过程规范必须定义一组可互操作的选项。
This document defines a number of SIP extension headers, which have been included in the registry of SIP headers defined in [2]. Registration information for new headers is as follows:
本文档定义了许多SIP扩展头，这些扩展头已包含在[2]中定义的SIP头注册表中。新标题的注册信息如下所示：
Header Field Name: P-DCS-Trace-Party-ID RFC Number: 3603 Compact Form: none
标题字段名称：P-DCS-Trace-Party-ID RFC编号：3603压缩格式：无
Header Field Name: P-DCS-OSPS RFC Number: 3603 Compact Form: none
标题字段名称：P-DCS-OSPS RFC编号：3603压缩格式：无
Header Field Name: P-DCS-Billing-Info RFC Number: 3603 Compact Form: none
标题字段名称：P-DCS-Billing-Info RFC编号：3603压缩格式：无
Header Field Name: P-DCS-LAES RFC Number: 3603 Compact Form: none
标题字段名称：P-DCS-LAES RFC编号：3603压缩格式：无
Header Field Name: P-DCS-Redirect RFC Number: 3603 Compact Form: none
标题字段名称：P-DCS-Redirect RFC编号：3603压缩格式：无
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[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] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[5] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[5] IAB和IESG，“IETF关于窃听的政策”，RFC 2804，2000年5月。
[6] DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", Work in Progress.
[6] DCS小组，“利用基于SIP的分布式呼叫控制机制提供电信级电话服务的架构考虑”，正在进行中。
[7] PacketCable Dynamic Quality of Service Specification, pkt-sp-dqos-i07-030815, August 2003.
[7] PacketCable动态服务质量规范，pkt-sp-dqos-i07-0308152003年8月。
[8] PacketCable Security Specification, pkt-sp-sec-i09-030728, July 2003.
[8] 打包电缆安全规范，pkt-sp-sec-i09-0307282003年7月。
[9] PacketCable Event Message Specification, pkt-sp-em-i07-030815, August 2003.
[9] PacketCable事件消息规范，pkt-sp-em-i07-0308152003年8月。
[10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[10] Jennings，C.，Peterson，J.和M.Watson，“可信网络中断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications.
PacketCable项目中的分布式呼叫信令工作是代表许多不同公司的大量人员的工作。作者要感谢并感谢以下人员的帮助：摩托罗拉的John Wheeler；大卫·博德曼、丹尼尔·保罗、阿里斯互动；比尔·布鲁姆、乔恩·费罗斯、杰伊·斯特拉特、杰夫·奥利斯、克莱夫·霍尔博罗、摩托罗拉；Doug Newlin，Guido Schuster，Ikhlaq Sidhu，3Com；海湾网络公司Jiri Matousek；法尔齐·哈扎伊，北电；约翰·查普曼、比尔·古克尔、迈克尔·拉马霍、思科；查克·卡尔马内克、道格·诺茨、约翰·劳泽、詹姆斯·郑、萧东海、帕托·米什拉、AT&T；Telcordia技术公司；和朗讯有线通讯。
Previous versions further acknowledged, as co-authors, several people for providing the text of this document. They are:
以前的版本进一步确认，作为共同作者，有几个人提供了本文件的文本。他们是：
Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan
(kkrama@research.att.com), AT&T; Ed Miller
(edward.miller@terayon.com), Terayon; Glenn Russell
(G.Russell@Cablelabs.com), CableLabs; Burcak Beser
(burcak@juniper.net) Juniper Networks, Mike Mannette
(Michael_Mannette@3com.com) and Kurt Steinbrenner
(Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and
Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan
(kkrama@research.att.com), AT&T; Ed Miller
(edward.miller@terayon.com), Terayon; Glenn Russell
(G.Russell@Cablelabs.com), CableLabs; Burcak Beser
(burcak@juniper.net) Juniper Networks, Mike Mannette
(Michael_Mannette@3com.com) and Kurt Steinbrenner
(Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and
Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney (poornima.lalwaney@nokia.com), Nokia; Jon Fellows (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans (n7dr@arrisi.com) Arris, and Keith Kelly (keith@netspeak.com), NetSpeak.
弗莱明·安德里森(fandreas@cisco.com)，思科系统；约翰·皮肯斯(jpickens@com21.com)，Com21；普尔尼玛·拉尔瓦尼（普尔尼玛。lalwaney@nokia.com)诺基亚,；乔恩·费罗斯(jfellows@coppermountain.com)，铜山网络；埃文斯医生(n7dr@arrisi.com)Arris和Keith Kelly(keith@netspeak.com)，网语。
Bill Marshall AT&T Florham Park, NJ 07932
新泽西州弗罗勒姆公园比尔·马歇尔AT&T公司，邮编：07932
EMail: wtm@research.att.com
EMail: wtm@research.att.com
Flemming Andreasen Cisco Edison, NJ
弗莱明·安德里森·思科·爱迪生，新泽西州
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。