Network Working Group F. Andreasen
Request for Comments: 5503 Cisco
Obsoletes: 3603 B. McKibben
Category: Informational CableLabs
B. Marshall
AT&T
March 2009
Network Working Group F. Andreasen
Request for Comments: 5503 Cisco
Obsoletes: 3603 B. McKibben
Category: Informational CableLabs
B. Marshall
AT&T
March 2009
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
In order to deploy a residential telephone service at a 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, RFC 3261, 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.
为了在不同的域中大规模部署住宅电话服务，不同服务提供商拥有的可信元素必须交换可信信息，以传达客户特定的信息和有关通话各方的期望。本文档描述了会话启动协议RFC 3261的专用扩展，用于支持PacketCable分布式呼叫信令体系结构中受信任实体之间的客户信息和计费信息交换。这些扩展提供了接入网络协调机制，以防止服务被盗、骚扰电话的客户追踪、对运营商服务和紧急服务的支持，以及对各种其他监管问题的支持。扩展的使用仅适用于封闭的管理域内，或在需要协调收费和其他功能的情况下，具有先前商定政策的管理域联合会之间。
Table of Contents
目录
1. Applicability Statement .........................................4
2. Introduction ....................................................4
3. Trust Boundary ..................................................6
4. Conventions Used in This Document ...............................7
5. P-DCS-TRACE-PARTY-ID ............................................7
5.1. Syntax .....................................................8
5.2. Procedures at an Untrusted User Agent Client (UAC) .........9
5.3. Procedures at a Trusted User Agent Client (UAC) ............9
5.4. Procedures at an Untrusted User Agent Server (UAS) .........9
5.5. Procedures at a Trusted User Agent Server (UAS) ............9
5.6. Procedures at Proxy .......................................10
5.6.1. Procedures at Originating Proxy ....................10
5.6.2. Procedures at Terminating Proxy ....................11
6. P-DCS-OSPS .....................................................11
6.1. Syntax ....................................................11
6.2. Procedures at an Untrusted User Agent Client (UAC) ........12
6.3. Procedures at a Trusted User Agent Client (UAC) ...........12
6.4. Procedures at an Untrusted User Agent Server (UAS) ........13
6.5. Procedures at a Trusted User Agent Server (UAS) ...........13
6.6. Procedures at Proxy .......................................14
7. P-DCS-BILLING-INFO .............................................14
7.1. Syntax ....................................................16
7.2. Procedures at an Untrusted User Agent Client (UAC) ........18
7.3. Procedures at a Trusted User Agent Client (UAC) ...........18
7.4. Procedures at an Untrusted User Agent Server (UAS) ........18
7.5. Procedures at a Trusted User Agent Server (UAS) ...........18
7.6. Procedures at Proxy .......................................19
7.6.1. Procedures at Originating Proxy ....................19
7.6.2. Procedures at Terminating Proxy ....................20
7.6.3. Procedures at Tandem Proxy .........................21
8. P-DCS-LAES and P-DCS-Redirect ..................................21
8.1. Syntax ....................................................23
8.2. Procedures at an Untrusted User Agent Client (UAC) ........24
8.3. Procedures at a Trusted User Agent Client (UAC) ...........24
8.4. Procedures at an Untrusted User Agent Server (UAS) ........25
8.5. Procedures at a Trusted User Agent Server (UAS) ...........25
8.6. Procedures at Proxy .......................................26
8.6.1. Procedures at Originating Proxy ....................26
8.6.2. Procedures at Terminating Proxy ....................28
9. Security Considerations ........................................29
10. IANA Considerations ...........................................29
11. Changes since RFC 3603 ........................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
1. Applicability Statement .........................................4
2. Introduction ....................................................4
3. Trust Boundary ..................................................6
4. Conventions Used in This Document ...............................7
5. P-DCS-TRACE-PARTY-ID ............................................7
5.1. Syntax .....................................................8
5.2. Procedures at an Untrusted User Agent Client (UAC) .........9
5.3. Procedures at a Trusted User Agent Client (UAC) ............9
5.4. Procedures at an Untrusted User Agent Server (UAS) .........9
5.5. Procedures at a Trusted User Agent Server (UAS) ............9
5.6. Procedures at Proxy .......................................10
5.6.1. Procedures at Originating Proxy ....................10
5.6.2. Procedures at Terminating Proxy ....................11
6. P-DCS-OSPS .....................................................11
6.1. Syntax ....................................................11
6.2. Procedures at an Untrusted User Agent Client (UAC) ........12
6.3. Procedures at a Trusted User Agent Client (UAC) ...........12
6.4. Procedures at an Untrusted User Agent Server (UAS) ........13
6.5. Procedures at a Trusted User Agent Server (UAS) ...........13
6.6. Procedures at Proxy .......................................14
7. P-DCS-BILLING-INFO .............................................14
7.1. Syntax ....................................................16
7.2. Procedures at an Untrusted User Agent Client (UAC) ........18
7.3. Procedures at a Trusted User Agent Client (UAC) ...........18
7.4. Procedures at an Untrusted User Agent Server (UAS) ........18
7.5. Procedures at a Trusted User Agent Server (UAS) ...........18
7.6. Procedures at Proxy .......................................19
7.6.1. Procedures at Originating Proxy ....................19
7.6.2. Procedures at Terminating Proxy ....................20
7.6.3. Procedures at Tandem Proxy .........................21
8. P-DCS-LAES and P-DCS-Redirect ..................................21
8.1. Syntax ....................................................23
8.2. Procedures at an Untrusted User Agent Client (UAC) ........24
8.3. Procedures at a Trusted User Agent Client (UAC) ...........24
8.4. Procedures at an Untrusted User Agent Server (UAS) ........25
8.5. Procedures at a Trusted User Agent Server (UAS) ...........25
8.6. Procedures at Proxy .......................................26
8.6.1. Procedures at Originating Proxy ....................26
8.6.2. Procedures at Terminating Proxy ....................28
9. Security Considerations ........................................29
10. IANA Considerations ...........................................29
11. Changes since RFC 3603 ........................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
The Session Initiation Protocol (SIP) [RFC3261] 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 [DCSARCH]. 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 [DCSARCH] is strongly encouraged in those domains as well.
本文档中描述的会话发起协议（SIP）[RFC3261]扩展对网络拓扑、SIP和较低层之间的链接以及可传递信任的可用性做出了某些假设。这些假设通常不适用于整个互联网。这些报头的使用仅适用于封闭的管理域内，或在需要协调计费和其他功能的具有先前商定政策的管理域联盟之间，例如[DCSARCH]中介绍的架构。在此类域之外使用可能导致潜在敏感或私人信息泄漏。这些领域也强烈鼓励用户同意[DCSARCH]中政策的隐私影响。
Although [RFC2119] 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.
尽管本文件使用[RFC2119]语言，但规范性语言的范围仅限于本文件的适用范围，与技术一样，不适用于一般互联网。
In order to deploy a SIP based 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的住宅电话服务，不同服务提供商拥有的可信元素必须交换可信信息，以传递计费信息和对呼叫相关方的期望。
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 Distributed Call Signaling (DCS) architecture described in [DCSARCH] 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.
[DCSARCH]中描述的分布式呼叫信令（DCS）体系结构的一个关键激励原则是网络服务提供商需要能够控制和监控网络资源；收入可能来自使用这些资源以及提供电话等增强服务。此外，DCS体系结构认识到需要在呼叫信令和资源管理之间进行协调。这种协调可确保用户在获得对网络资源和可计费增强服务的访问权之前经过身份验证和授权。
DCS Proxies, as defined in [DCSARCH], 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 [DCSARCH] for a description of the trust boundary and trusted versus untrusted entities.
[DCSARCH]中定义的DCS代理可以访问订户信息，并在呼叫信令路径上充当策略决策点和可信中介。边缘路由器提供网络连接和资源策略实施机制，还可以捕获和报告网络连接和资源使用信息。边缘路由器需要提供计费信息，这些信息可以通过记录或计费服务器记录。DCS代理作为呼叫信令和资源管理之间的协调中心点，可以基于主叫方和被叫方的认证身份提供此信息。由于DCS代理之间存在信任关系，因此可以依赖它们来交换与呼叫相关方有关的可信计费信息。有关信任边界和受信任与不受信任实体的描述，请参见[DCSARCH]。
For these reasons, it is appropriate to consider defining SIP header extensions to allow DCS Proxies to exchange information during call setup. The extensions only appear on trusted network segments, are inserted upon entering a trusted network region, and are removed before leaving trusted network segments.
由于这些原因，考虑定义SIP报头扩展是合适的，以允许DCS代理在呼叫建立期间交换信息。扩展仅出现在受信任的网段上，在进入受信任的网络区域时插入，在离开受信任的网段之前删除。
Significant amounts of information are 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 it 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字段的添加允许捕获通话期间的计费信息和计费标识。
The billing extensions 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 for support of 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 [DCSARCH] 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体系结构[DCSARCH]围绕服务提供商拥有、操作和/或控制的各种系统和服务器定义了信任边界。这些受信任系统包括代理和各种服务器，如桥接服务器、语音邮件服务器、公告服务器等。在信任边界之外是由第三方服务提供商运营的客户场所设备和各种应用程序和媒体服务器。
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. Since UAs may support client and server functions, the UA sections include procedures for the User Agent Client (UAC) and User Agent Server (UAS).
因此，以下给出用户代理程序的部分被细分为受信任的用户代理和不受信任的用户代理。由于UAs可能支持客户端和服务器功能，UA部分包括用户代理客户端（UAC）和用户代理服务器（UAs）的过程。
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, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
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 [RFC3325].
在电话网络中，主叫身份信息用于支持监管要求，如客户发起的跟踪服务，该服务使被叫方能够向执法部门报告猥亵或骚扰电话。此服务独立于呼叫者id提供，即使呼叫者请求匿名也可以工作。呼叫方在此被标识为发起呼叫的站。为了使该服务可靠，被叫方必须能够相信所提供的主叫身份信息是有效的。[RFC3325]中描述了实现这一点的一种方法。
To initiate a customer-originated-trace from an untrusted User Agent Client (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 untrusted UAC also includes the
要从不受信任的用户代理客户端（UAC）启动源于客户的跟踪，将为INVITE请求定义一个额外的头。此标头称为P-DCS-Trace-Party-ID，不会出现在任何其他请求或响应中。不受信任的UAC还包括
Target-Dialog header field, defined in [RFC4538], in the INVITE request in order to explicitly identify the call to be traced. 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.
INVITE请求中的[RFC4538]中定义的目标对话框标题字段，用于明确标识要跟踪的调用。由请求URI寻址的实体执行特定于服务提供商的功能，即在P-DCS-Trace-PARY-ID中记录和报告呼叫者身份，以便采取执法行动。然后，它将呼叫转发给公告服务器或服务提供商的业务办公室，以收集有关投诉的进一步信息。受信任的UAC不使用此标头，因为它在本地启动此操作。
The ABNF description of this header is (some terms used in this ABNF are defined in [RFC3261]):
此标题的ABNF描述为（此ABNF中使用的一些术语在[RFC3261]中定义）：
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
*1(SEMI timestamp-param) *(SEMI trace-param)
timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT]
trace-param = generic-param ; defined in RFC 3261
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
*1(SEMI timestamp-param) *(SEMI trace-param)
timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT]
trace-param = generic-param ; defined in RFC 3261
This document adds the following entry to Table 2 of [RFC3261]:
本文件将以下条目添加到[RFC3261]的表2中：
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dmr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dmr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
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 timestamp-param contains the value of the time the UA determines it received the session initiation request of the call requested to be traced. The timestamp-param is populated using the Network Time Protocol timestamp format defined in RFC 1305 [RFC1305] and used by the Simple Network Time Protocol [RFC4330]. The timestamp SHOULD be encoded in UTF-8 Format per [RFC3629]. The trace-param is a generic parameter for future extensions.
timestamp参数包含UA确定其接收到请求跟踪的呼叫的会话启动请求的时间值。时间戳参数使用RFC 1305[RFC1305]中定义的网络时间协议时间戳格式填充，并由简单网络时间协议[RFC4330]使用。时间戳应按照[RFC3629]以UTF-8格式编码。跟踪参数是将来扩展的通用参数。
An example of the P-DCS-Trace-Party-ID header is shown as follows:
P-DCS-Trace-Party-ID头的示例如下所示：
P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>;
timestamp=3434688831.2327
P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>;
timestamp=3434688831.2327
The UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request. The trace request from the Untrusted User Agent Client is able to be initiated during the dialog or after the release of the dialog or call that is requested to be traced. 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. The [RFC3603] version of the P-DCS-Trace-Party-ID did not include the timestamp-param parameter; however, the syntax is backwards compatible with [RFC3603]. A UAC compliant to this updated specification MUST insert the timestamp and the Target-Dialog header field defined in [RFC4538] if known to the UAC.
UAC必须在客户发起的跟踪请求的初始INVITE消息中插入P-DCS-Trace-Party-ID头。来自不受信任的用户代理客户端的跟踪请求可以在对话框期间或释放请求跟踪的对话框或调用之后启动。UAC必须在userinfo设置为“call trace”的请求URI中使用SIP URI，并在hostport中标识不受信任UA的呼叫跟踪实体。P-DCS-Trace-PARY-ID的[RFC3603]版本不包括timestamp param参数；但是，该语法与[RFC3603]向后兼容。符合此更新规范的UAC必须插入时间戳和[RFC4538]中定义的目标对话框标题字段（如果UAC已知）。
In case of an anonymous malicious call, where the remote party is not known to the Untrusted UAC, the Untrusted UAC SHOULD indicate the user as anonymous in the P-DCS-Trace-Party-ID, for example, as follows: sip:anonymous@anonymous.invalid.
在匿名恶意呼叫的情况下，如果不受信任的UAC不知道远程方，则不受信任的UAC应在P-DCS-Trace-PARY-ID中指示用户为匿名用户，例如，如下所示：sip：anonymous@anonymous.invalid.
A trusted UAC performs the customer-originated-trace in a manner similar to the trusted User Agent Server (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 the caller identity and associated trace parameters (if any) from the Target-Dialog header field 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.
如果UAC的初始INVITE请求中存在P-DCS-Trace-Party-ID头，并且INVITE的请求URI将userinfo设置为“call Trace”，并将hostport设置为UAS，则UAS必须执行服务提供商特定的功能，记录和报告呼叫者身份和相关跟踪参数（如果有）从执法行动的目标对话框标题字段。然后，UAS必须通过3xx响应将呼叫重定向到公告服务器或服务提供商的业务办公室，以收集有关投诉的进一步信息。
This header MUST NOT appear in any response sent by a UAS.
此标头不得出现在UAS发送的任何响应中。
If the P-DCS-Trace-Party-ID header is not present in the initial INVITE request from a UAC, and the Request-URI of the INVITE has userinfo set to "call-trace" the UAS MUST reject the request.
如果来自UAC的初始INVITE请求中不存在P-DCS-Trace-Party-ID头，并且INVITE的请求URI的userinfo设置为“call Trace”，则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 an untrusted endpoint.
定义了两组代理过程：（1）原始代理的过程，以及（2）终止代理的过程。发起代理是从不受信任的端点接收INVITE请求的代理。
The terminating proxy is a proxy that sends the INVITE request to an untrusted 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 it 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 and trace parameters from the Target-Dialog header fields defined in [RFC4538]).
如果UAC的初始INVITE请求中存在P-DCS-Trace-PARY-ID头，并且INVITE的请求URI的userinfo不是“call Trace”，hostport设置为非潜在配置的呼叫跟踪实体，则代理可能拒绝该请求，或者可能从请求中删除P-DCS-Trace-PARY-ID头。如果标头存在于有效请求中，并且包含在主机端口中标识代理的专用URL，则发起代理应使用其原始内容（即，正在跟踪的会话调用方的已验证标识和中定义的目标对话框标头字段中的跟踪参数）替换专用URL[RFC4538]）。
The proxy records the caller URL and target dialog IDs on sessions directed toward the untrusted UAC if provisioned to do so by the network operator. If the is P-DCS-Trace-Party-ID header is present in a valid request, and contains an anonymous caller indication in the name-addr parameter, the originating proxy MUST replace the anonymous URL with the verified identity of the caller of the session that is being traced if available and recorded by the proxy. Otherwise, the proxy does not replace the anonymous URL.
如果网络运营商提供了指向不受信任UAC的会话，则代理会记录呼叫方URL和目标对话框ID。如果有效请求中存在is P-DCS-Trace-Party-ID头，并且name addr参数中包含匿名呼叫者指示，则发起代理必须将匿名URL替换为正在跟踪的会话的呼叫者的已验证身份（如果可用并由代理记录）。否则，代理不会替换匿名URL。
If the origination proxy is provisioned to store URLs and target dialog IDs for incoming calls, and if the proxy detects that the URL and target dialog ID in a trace request does not match a recorded incoming dialog request, then the proxy MUST reject the trace call request.
如果将发起代理设置为存储传入呼叫的URL和目标对话框ID，并且如果代理检测到跟踪请求中的URL和目标对话框ID与记录的传入对话框请求不匹配，则代理必须拒绝跟踪呼叫请求。
The origination proxy does not add the P-DCS-Trace-Party-ID header from a request that does not already contain the header.
发起代理不会从尚未包含标头的请求中添加P-DCS-Trace-Party-ID标头。
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 Public Switched Telephone Network (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 (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）运营商服务需要特殊的呼叫处理。特别地，由运营商从PSTN网络上的运营商服务定位系统（OSPS）发起的忙线验证（BLV）和紧急中断（EI）服务具有这样的需求。类似地，对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, with a field that may be set to a value indicating when a special type of call processing is requested. We define three values in this header field, 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 [RFC3261]):
P-DCS-OSPS标头的ABNF描述如下（本ABNF中使用的一些术语在[RFC3261]中定义）：
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 [RFC3261]:
本文件将以下条目添加到[RFC3261]的表2中：
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - o - -
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - 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 [DCSARCH] 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.
此报头通常仅由媒体网关控制器[DCSARCH]插入，该控制器通过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 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 preexisting dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a preexisting 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 preexisting dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a preexisting 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, it MUST reject the request with a 403 (Forbidden) response.
如果UAS接收到OSPS标记为“BLV”的INVITE请求，即与现有对话框匹配的对话框标识，则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 that was established with the OSPS-Tag value of "BLV", it MUST reject the request with a 403 (Forbidden) response.
如果UAS收到OSPS标签值为“EI”或“RING”的INVITE/UPDATE请求，且对话框标识与OSPS标签值为“BLV”的现有对话框不匹配，则UAS必须以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.
如果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中存在“BLV”OSPS标签，UAS不应提醒用户来电尝试。
If an INVITE with OSPS-Tag of "BLV" is accepted (e.g., meeting all quality-of-service (QoS) pre-conditions, etc.), the UAS MUST send an audio stream on this connection to the address and port given in the Session Description Protocol (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 there is 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字段的添加允许捕获通话期间的计费信息和计费标识。
The billing extensions only appear on trusted network segments, and MAY be inserted by a proxy or trusted UA in INVITE and SUBSCRIBE 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 UAs. It is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.
计费扩展仅出现在受信任的网段上，可由代理或受信任的UA在受信任网段的邀请和订阅请求中插入，并在离开受信任网段之前删除。P-DCS-Billing-Info标头扩展仅用于代理和受信任UAs之间的请求和响应。它从不发送给不受信任的UA。预计不受信任的UAs不会发送此标头。
The DCS-Billing-Info header is defined by the following ABNF (some terms used in this ABNF are defined in [RFC3261]):
DCS计费信息头由以下ABNF定义（此ABNF中使用的一些术语在[RFC3261]中定义）：
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 /
JIP-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
JIP-param = "jip" EQUAL jip
jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT
jip-context = ";jip-context=" jip-descriptor
jip-descriptor = global-hex-digits
global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
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 /
JIP-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
JIP-param = "jip" EQUAL jip
jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT
jip-context = ";jip-context=" jip-descriptor
jip-descriptor = global-hex-digits
global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
This document adds the following entry to Table 2 of [RFC3261]:
本文件将以下条目添加到[RFC3261]的表2中：
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
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 UAs.
P-DCS-Billing-Info扩展包含一个标识符，事件记录器可使用该标识符将多个使用记录（可能来自不同来源）与可计费帐户关联。它还包含用户帐户信息，以及准确计费服务所需的其他信息。此标头仅在代理和受信任的UAs之间使用。
The Billing-Correlation-ID, BCID, is specified in [PCEM] 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 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.
计费相关ID BCID在[PCEM]中指定为24字节的二进制结构，包含4字节的NTP时间戳、8字节的生成ID的网元唯一标识符、8字节的时区以及该网元上4字节的单调递增序列号。该标识符在系统内选择为全局唯一，为期几个月。这必须在P-DCS-Billing-Info报头中编码为最多48个字符的十六进制字符串。前导零可能被抑制。
The Financial-Entity-ID (FEID) is specified in [PCEM] 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.
金融实体ID（FEID）在[PCEM]中指定为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-Loc-Routing-URI are each defined as URLs; they should all contain tel URLs with E.164 formatted addresses. These fields are further defined in [PCEM] 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).
其他参数包含生成事件消息记录所需的信息。Acct费用URI、Acct调用URI、Acct调用URI、Acct路由URI和Acct Loc路由URI均定义为URL；它们都应该包含带有E.164格式地址的tel URL。这些字段在[PCEM]中的元素标识符“费用编号”（元素ID 16）、“呼叫方编号”（元素ID 4）、“被叫方编号”（元素ID 5）、“路由编号”（元素ID 25）和“位置路由编号”（元素ID 22）下进一步定义。
The JIP-param contains the calling jurisdiction information, or numbering plan area, of the network in which the call originated. The field is further defined in [PCEM] under the element identifier "Jurisdiction_Information_Parameter" (element ID 82). An older [RFC3603] compliant implementation may not use the JIP-param.
JIP参数包含发起呼叫的网络的呼叫管辖权信息或编号计划区域。该字段在元素标识符“辖区信息参数”（元素ID 82）下的[PCEM]中进一步定义。较早的[RFC3603]兼容实现可能不使用JIP参数。
This header is never sent to an untrusted UA. It is expected that untrusted UAs do not send this header.
此标头永远不会发送到不受信任的UA。预计不受信任的UAs不会发送此标头。
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 or SUBSCRIBE message sent to the terminating entity, 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. If available to the UAC, the UAC MUST include the JIP-param.
UAC必须生成呼叫的计费关联ID，并将其与呼叫的计费信息一起插入发送给终止实体的初始邀请或订阅消息中的P-DCS-Billing-Info头中。UAC必须包含其FEID和UAC使用的记录保存服务器的RKS组ID。如果UAC执行本地号码可移植性（LNP）查询，则必须包括查询返回的路由号码和位置路由号码。如果UAC可用，UAC必须包括JIP参数。
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 field, 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 field values from the 3xx-Redirect response. If the UAC is acting as a back-to-back user agent (B2BUA), instead of generating a new INVITE it MAY generate a private-URL and place it in the Contact header field 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 header字段中指定的目的地。如果UAC收到对初始邀请的3xx重定向响应，UAC生成的新邀请必须包含3xx重定向响应中的P-DCS-Billing-Info头字段值。如果UAC充当背对背的用户代理（B2BUA），它可能不会生成新的INVITE，而是生成一个私有URL，并将其放置在发送到发起端点的3xx重定向响应的联系人标头字段中。此专用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 or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the UAS, the FEID of the UAS, and
UAS必须在对初始邀请或订阅消息的第一个可靠1x（100除外）或2xx响应中包含P-DCS-Billing-Info报头。此P-DCS-Billing-Info标头必须包括UAS生成的计费关联ID、UAS的FEID和
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 an LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
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 or SUBSCRIBE request from an untrusted endpoint.
发起代理是从不受信任的端点接收INVITE或SUBSCRIBE请求的代理。
The terminating proxy is a proxy that sends the INVITE or SUBSCRIBE request to an untrusted endpoint.
终止代理是将INVITE或SUBSCRIBE请求发送到不受信任端点的代理。
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 an untrusted 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 request from an untrusted endpoint, and sends the request to an untrusted endpoint, performs both sets of procedures.
同时从不受信任的端点接收请求并将请求发送到不受信任端点的代理将执行这两组过程。
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 or SUBSCRIBE message sent to the terminating entity, along with the charging information for the call. The originating proxy MUST include its FEID and the RKS-Group-ID for the
发起代理必须生成呼叫的计费关联ID，并将其与呼叫的计费信息一起插入发送给终止实体的初始INVITE或SUBSCRIBE消息中的P-DCS-Billing-Info头中。原始代理必须包括其FEID和用于代理的RKS组ID
Record-Keeping server being used by the originating proxy. If the originating proxy performed an LNP query, it MUST include the Routing Number, Location Routing Number, and JIP-param returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed.
原始代理正在使用的记录保留服务器。如果原始代理执行LNP查询，则必须包括查询返回的路由编号、位置路由编号和JIP参数。必须删除来自不受信任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 non-100 provisional response, the originating proxy generates a new initial INVITE request to the destination specified in the Contact header field, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a non-100 provisional response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response.
如果对初始INVITE的响应是在非100临时响应之前接收到的3xx重定向，则发起代理将根据标准SIP向Contact header字段中指定的目的地生成新的初始INVITE请求。如果发起代理在非100临时响应之前收到对初始INVITE的3xx重定向响应，则代理生成的INVITE必须包含来自3xx重定向响应的P-DCS-Billing-Info标头。
If the response to the initial INVITE is a 3xx-Redirect, received after a non-100 provisional response, 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 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的响应是在非100临时响应之后接收的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 or SUBSCRIBE 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
终止代理必须在对初始邀请或订阅消息的第一个可靠1x（100除外）或2xx响应中包含P-DCS-Billing-Info标头。此P-DCS-Billing-Info标头必须包括终止代理生成的计费关联ID、终止代理的FEID以及终止代理使用的记录保留服务器的RKS组ID。如果希望，终止代理可以更改帐户费用URI的值
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 an LNP query, it MUST include the Routing Number and Location Routing Number returned by the query.
覆盖邀请中显示的计费信息（例如，免费电话）。执行此操作的决定以及生成的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 indicates 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 an 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 [RFC2804], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The [RFC2119] 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[RFC2804]，如果有必要开发合法拦截技术，IETF支持其文档。以下部分提供了此类文档。如上所述，[RFC2119]语言仅在实施时描述规范的要求，且严格在上述适用范围内。有关此技术的隐私、安全性和复杂性问题的说明，请参见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 fields MAY also contain the associated BCID for the event stream as well as additional address and port for delivery of call content and associated cccid. The BCID is used to correlate a series of events associated with a single call or session. The cccid is used to identify an intercepted call content to an intercepted
P-DCS-LAES扩展包含支持合法授权电子监控所需的信息。此标头包含电子监视传递功能的地址和端口，用于传递与此呼叫相关的重复事件消息流。报头字段还可以包含事件流的关联BCID以及用于传递呼叫内容和关联cccid的附加地址和端口。BCID用于关联与单个呼叫或会话关联的一系列事件。cccid用于向被截获的用户标识被截获的呼叫内容
call. The P-DCS-LAES header is only used between proxies and trusted UAs. The P-DCS-LAES header defined here is not backwards compatible with that defined in [RFC3603], which is deprecated by the document. This version of the P-DCS-LAES header adds a cccid parameter to support the intercept of content, and deletes security key information. This version does not mandate the use of the BCID.
呼叫P-DCS-LAES标头仅在代理和受信任的UAs之间使用。此处定义的P-DCS-LAES标题与[RFC3603]中定义的标题不向后兼容，该文件不推荐使用该标题。此版本的P-DCS-LAES标头添加了一个cccid参数以支持内容截取，并删除安全密钥信息。此版本不强制使用BCID。
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 UAs.
P-DCS-Redirect分机包含支持合法授权的重定向呼叫电子监控要求所需的呼叫识别信息。此标头仅在代理和受信任的UAs之间使用。
Note that there is overlap in function between the P-DCS-Redirect header and the History-Info header specified in RFC 4244. The original P-DCS-Redirect came to existence in RFC 3603 before the History-Info. Therefore, the P-DCS-Redirect header is continued here for backwards compatibility with existing implementations.
请注意，P-DCS-Redirect标头和RFC 4244中指定的历史信息标头之间存在功能重叠。原始的P-DCS-Redirect在历史信息之前出现在RFC 3603中。因此，这里继续使用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 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和P-DCS-Redirect的使用由立法、法规和法院命令的组合控制，必须遵守。在某些情况下，将强制包含这些标题，因此必须出现在所示的请求和响应中。在其他情况下，将禁止包含这些标头，因此不得出现在所示的请求和响应中。在下面的小节中，使用“应该”旨在捕获这些冲突情况，例如，初始邀请中应包含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 [RFC3261] and [RFC5234]):
以下ABNF给出了P-DCS-LAES和P-DCS-Redirect标头的格式（本ABNF中使用的一些术语在[RFC3261]和[RFC5234]中定义）：
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig *(SEMI Laes-param) Laes-sig = hostport Laes-param = Laes-content / Laes-cccid Laes-bcid / generic-param Laes-content = "content" EQUAL hostport
P-DCS-LAES=“P-DCS-LAES”HCOLON LAES sig*（半LAES参数）LAES sig=主机端口LAES参数=LAES内容/LAES cccid LAES bcid/通用参数LAES内容=“内容”等于主机端口
Laes-bcid = "bcid" EQUAL 1*48(HEXDIG)
Laes-cccid = "cccid" EQUAL 1*8(HEXDIG)
Laes-bcid = "bcid" EQUAL 1*48(HEXDIG)
Laes-cccid = "cccid" EQUAL 1*8(HEXDIG)
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(SEMI 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
*(SEMI 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 [RFC3261]:
本文件将以下条目添加到[RFC3261]的表2中：
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - - -
P-DCS-Redirect adr - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - - -
P-DCS-Redirect adr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
- - - - - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
- - - - - - -
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-bcid contains a correlation ID that is used to link a sequence of intercepted call processing events related to a single call. Laes-cccid contains an identifier of the intercepted call content. The Laes-bcid field MAY be present. The BCID is included per network operator configuration to support events reported as defined in [PCEM]. The Laes-cccid field MAY be present when the Laes-content field is present. The Laes-cccid is included
Laes sig和Laes内容的值是电子监视传送功能的地址，分别用作呼叫识别信息和呼叫内容的目的地地址。Laes bcid包含一个关联ID，用于链接与单个呼叫相关的被截获呼叫处理事件序列。Laes cccid包含截获呼叫内容的标识符。Laes bcid字段可能存在。BCID包含在每个网络运营商配置中，以支持[PCEM]中定义的报告事件。当Laes内容字段存在时，Laes cccid字段可能存在。包括Laes cccid
per network operator configuration for networks where entities receiving the intercepted contents may act a media relay functions to other surveillance functions that are the source of the content surveillance request. The design of multiple surveillance entities that receive call content is beyond the scope of this document.
每个网络运营商的网络配置，其中接收截获内容的实体可以充当媒体中继功能，以连接到作为内容监视请求来源的其他监视功能。接收呼叫内容的多个监控实体的设计超出了本文档的范围。
The P-DCS-Redirect header contains redirection information. The Called-ID indicates the original destination requested by the user (e.g., number dialed originally), the redir-uri-param indicates the entity performing the redirection, and the Redir-count indicates the number of redirections that have occurred. For example, if A calls B, who forwards to C, who forwards to D, then, when C forwards to D, the Called-ID will be A, redir-uri-param will be C, and count will be 2.
P-DCS-Redirect标头包含重定向信息。被叫ID表示用户请求的原始目的地（例如，最初拨打的号码），redir uri参数表示执行重定向的实体，redir计数表示已发生的重定向数量。例如，如果A调用B，who转发给C，who转发给D，那么，当C转发给D时，被调用的ID将是A，redir uri param将是C，计数将是2。
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, MAY include this information in the Authorization for Quality of Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
UAC检查发起订户的未完成的合法授权监视命令，如果存在，可以将该信息包括在服务质量授权[PCDQOS]中，或者可以将该信息发送给执行截获的设备（例如，媒体网关）。否则，将指示拦截接入点通过本文档范围之外的机制执行呼叫内容和/或呼叫数据拦截。
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 MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
如果P-DCS-LAES报头出现在第一个可靠的1x（100除外）、2xx或3xx响应中（表示需要对终端用户进行监控，但终端设备无法执行该功能），UAC可将该信息包括在服务质量授权中，或者可以向执行截取的设备（例如，媒体网关）发送该信息的信号。否则，将指示拦截接入点通过本文档范围之外的机制执行呼叫内容和/或呼叫数据拦截。
If a 3xx-Redirect response to the initial INVITE request is received, 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 most recent redirecting party, 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
如果收到对初始INVITE请求的3xx重定向响应，并且如果3xx响应中存在P-DCS-LAES标头，UAC应在重新发布的INVITE中包含该标头，该标头应保持不变。UAC还应包括一个P-DCS-Redirect标头，其中包含原始拨号号码、最近的重定向方和已发生的重定向次数。虽然从技术上讲，始发设备可以执行此监视（或添加到其现有的呼叫监视中），但
surveillance system has the terminating equipment performing the surveillance for all the intermediate forwardings.
监控系统具有终端设备，对所有中间转送进行监控。
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 UAC MAY also include a P-DCS-Redirect header. The P-DCS-LAES header MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, 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 MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
当发起订户有未完成的合法授权监视命令时，在Refer请求中包含Refer Refer标头的UAC应包括附加到Refer Refer的P-DCS-LAES标头。UAC还可以包括P-DCS-Redirect标头。P-DCS-LAES报头可包括LAES bcid参数，该参数设置为唯一标识呼叫的值，应包括本地电子监控传递功能的地址和端口，用于呼叫事件消息的副本，如果要截获呼叫内容，则应包括本地电子监控交付功能的地址和端口，用于呼叫内容的副本；如果要截获呼叫内容，则可包括Laes cccid参数，该参数设置为唯一标识截获音频流的值。
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 MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
UAS检查终止用户的未完成合法授权监视命令，或INVITE请求中是否存在P-DCS-LAES标头。如果存在其中一个，UAS可将该信息包括在服务质量授权[PCDQOS]中。否则，将指示拦截接入点通过本文档范围之外的机制执行呼叫内容和/或呼叫数据拦截。
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 1xx (except 100), 2xx, or 3xx response requesting the originating proxy to perform the surveillance. The P-DCS-LAES header MAY include the Laes-bcid parameter with a value that uniquely identifies the call, 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
如果终端设备无法执行所需的监视（例如，如果目的地是语音邮件服务器），UAS应在第一个可靠的1x（100除外）、2xx或3xx响应中包含一个P-DCS-LAES报头，请求发起代理执行监视。P-DCS-LAES报头可能包括LAES bcid参数，该参数具有唯一标识呼叫的值，应包括本地电子监控传递功能的地址和端口，用于呼叫事件消息的副本，应包括本地电子监控交付功能的地址和端口，以便在呼叫时复制呼叫内容
content is to be intercepted, and MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
内容将被截获，并且可能包括Laes cccid参数，该参数设置为一个值，如果要截获呼叫内容，该值将唯一标识截获的音频流。
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 receives the INVITE request from an untrusted endpoint.
定义了两组代理过程：（1）原始代理的过程，以及（2）终止代理的过程。发起代理是从不受信任的端点接收INVITE请求的代理。
The terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.
终止代理是将INVITE请求发送到不受信任端点的代理。
For purposes of mid-call changes, such as call transfers, the proxy that receives the request from an untrusted endpoint is considered the initiating proxy; the proxy that sends the request to an untrusted 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 an untrusted 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, MAY include this information in the Authorization for Quality of
发起代理为发起订户检查未完成的合法授权监督令，如果存在，可将此信息包括在授权质量中
Service [PCDQOS] or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
服务[PCDQOS]或可向执行截获的设备（例如，媒体网关）发送该信息的信号。否则，将指示拦截接入点通过本文档范围之外的机制执行呼叫内容和/或呼叫数据拦截。
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 MAY include this information in the Authorization for Quality of Service, or MAY signal this information to the device performing the intercept (e.g., a Media Gateway). Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
如果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 and (if necessary) a P-DCS-REDIRECT header with the surveillance information.
如果初始INVITE请求中的请求URI包含私有URL，则发起代理必须解密userinfo信息以找到调用的真实目的地以及其他特殊处理信息。如果解密的userinfo中包含电子监控信息，则发起代理应生成一个P-DCS-LAES和（如有必要）一个带有监控信息的P-DCS-REDIRECT标头。
If a 3xx-Redirect response to the initial INVITE request is received prior to a non-100 provisional response, 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 P-DCS-Redirect header containing the original dialed number, the most recent redirecting party, and the number of redirections that have occurred.
如果在非100临时响应之前收到对初始INVITE请求的3xx重定向响应，并且如果3xx响应中存在P-DCS-LAES标头，则发起代理应在重新发布的INVITE中包含该标头，且该标头保持不变。发起代理还应包括一个P-DCS-Redirect标头，其中包含原始拨号号码、最近的重定向方和已发生的重定向次数。
If a 3xx-Redirect response to the initial INVITE request is received after a non-100 provisional response, 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.
如果在非100临时响应之后收到对初始INVITE请求的3xx重定向响应，则发起代理将生成一个私有URL，并将其放置在发送到发起端点的3xx重定向响应的联系人标头中。如果3xx响应中存在P-DCS-LAES报头，则此专用URL必须包含（1）来自3xx重定向响应的电子监控信息，（2）原始目的地号码，（3）重定向方的身份，以及（4）此呼叫的重定向次数。
An originating proxy that processes a REFER request [RFC3515] 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. It MAY also include a P-DCS-Redirect header. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a
当发起订户有未完成的合法授权监视命令时，处理来自不受信任UA的REFER请求[RFC3515]的发起代理成为该请求的B2BUA。它应该重新发出请求，并将P-DCS-LAES头添加到refereto的URL中。它还可能包括一个P-DCS-Redirect标头。P-DCS-LAES标题应包括（1）本地电子监控交付功能的地址和端口
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. The P-DCS-LAES header MAY include (1) the Laes-bcid parameter set to a value that uniquely identifies the call, and (2) the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is to be intercepted.
呼叫事件消息的副本，（2）如果要截获呼叫内容，本地电子监控交付功能用于呼叫内容副本的地址和端口。P-DCS-LAES报头可包括（1）LAES bcid参数设置为唯一标识呼叫的值，以及（2）LAES cccid参数设置为唯一标识要侦听呼叫内容的被侦听音频流的值。
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 MAY include this information in the authorization for Quality of Service [PCDQOS]. Otherwise, intercept access points are instructed to perform call content and/or call data intercept by mechanisms that are outside the scope of this document.
终止代理为终止订户检查未完成的合法授权监视命令。如果存在，终止代理可以在服务质量授权[PCDQOS]中包括该信息。否则，将指示拦截接入点通过本文档范围之外的机制执行呼叫内容和/或呼叫数据拦截。
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 MAY include the Laes-bcid parameter set to a value that uniquely identifies the call, 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 MAY include the Laes-cccid parameter set to a value that uniquely identifies the audio stream if call content is to be intercepted.
如果终端设备无法执行所需的监视（例如，如果目的地是语音邮件服务器），则终端代理应在请求发起代理执行监视的第一个可靠1xx/2xx/3xx（100除外）响应中包含P-DCS-LAES报头。P-DCS-LAES报头可包括LAES bcid参数，该参数设置为唯一标识呼叫的值，应包括本地电子监控传递功能的地址和端口，用于呼叫事件消息的副本，如果要截获呼叫内容，则应包括本地电子监控交付功能的地址和端口，用于呼叫内容的副本；如果要截获呼叫内容，则可包括Laes cccid参数，该参数设置为唯一标识音频流的值。
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 [RFC3515] 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 and P-DCS-Redirect information from the attached header fields.
接收到中间调用REFER请求[RFC3515]的代理（该请求包括带有P-DCS-LAES头的REFER头）将成为该请求的B2BUA。它必须生成一个私有URL，并将其放置在发送到端点的refere-To头中。此专用URL必须包含附加标题字段中的P-DCS-LAES和P-DCS-Redirect信息。
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 and trusted UAs is REQUIRED. A minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [PCSEC]. 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和代理必须采取预防措施，保护这些信息不被窃听和篡改。需要在代理和受信任的UAs之间使用IPsec或TLS。[PCSEC]给出了为DCS体系结构实施IPsec配置的最低要求。还需要代理之间的相互身份验证（1）和（2）受信任的UAs和代理之间的相互身份验证，这两者都可以通过管理预共享密钥或通过与另一个受信任的第三方协商来实现。如果要使用IPsec，这些头文件适用的管理域（以及联合体中管理域之间的所有连接）的安全策略和过程规范必须定义一组可互操作的选项。
The following changes to the Session Initiation Protocol (SIP) Parameters registry have been made by IANA.
IANA对会话启动协议（SIP）参数注册表进行了以下更改。
The Header Fields registry has been updated as follows:
标题字段注册表已更新如下：
Header Name compact Reference
----------------- ------- ---------
P-DCS-Trace-Party-ID [RFC5503]
P-DCS-OSPS [RFC5503]
P-DCS-Billing-Info [RFC5503]
P-DCS-LAES [RFC5503]
P-DCS-Redirect [RFC5503]
Header Name compact Reference
----------------- ------- ---------
P-DCS-Trace-Party-ID [RFC5503]
P-DCS-OSPS [RFC5503]
P-DCS-Billing-Info [RFC5503]
P-DCS-LAES [RFC5503]
P-DCS-Redirect [RFC5503]
The following entries in the Header Field Parameters and Parameter Values registry have been updated:
标题字段参数和参数值注册表中的以下条目已更新：
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info called No
[RFC5503]
P-DCS-Billing-Info calling No
[RFC5503]
P-DCS-Billing-Info charge No
[RFC5503]
P-DCS-Billing-Info locroute No
[RFC5503]
P-DCS-Billing-Info rksgroup No
[RFC5503]
P-DCS-Billing-Info routing No
[RFC3603]
P-DCS-LAES content No
[RFC5503]
P-DCS-Redirect count No
[RFC5503]
P-DCS-Redirect redirector-uri No
[RFC5503]
P-DCS-Billing-Info called No
[RFC5503]
P-DCS-Billing-Info calling No
[RFC5503]
P-DCS-Billing-Info charge No
[RFC5503]
P-DCS-Billing-Info locroute No
[RFC5503]
P-DCS-Billing-Info rksgroup No
[RFC5503]
P-DCS-Billing-Info routing No
[RFC3603]
P-DCS-LAES content No
[RFC5503]
P-DCS-Redirect count No
[RFC5503]
P-DCS-Redirect redirector-uri No
[RFC5503]
The following entry in the Header Field Parameters and Parameter Values registry has been marked "OBSOLETED":
标题字段参数和参数值注册表中的以下条目已标记为“已过时”：
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-LAES key (OBSOLETED) No
[RFC3603][RFC5503]
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-LAES key (OBSOLETED) No
[RFC3603][RFC5503]
The following entries in the Header Field Parameters and Parameter Values registry have been created:
已在标头字段参数和参数值注册表中创建以下条目：
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info jip No
[RFC5503]
P-DCS-LAES bcid No
[RFC5503]
P-DCS-LAES cccid No
[RFC5503]
P-DCS-Trace-Party-ID timestamp No
[RFC5503]
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info jip No
[RFC5503]
P-DCS-LAES bcid No
[RFC5503]
P-DCS-LAES cccid No
[RFC5503]
P-DCS-Trace-Party-ID timestamp No
[RFC5503]
o A timestamp parameter is added to the P-DCS-Trace-Party-ID header when available. Procedures on the use of the Target-Dialog header used together with the P-DCS-Trace-Party-ID are added.
o 时间戳参数在可用时添加到P-DCS-Trace-Party-ID头中。添加了与P-DCS-Trace-PARY-ID一起使用的目标对话框标题的使用程序。
o The JIP parameter is added to the P-DCS-Billing-Info header when available.
o JIP参数在可用时添加到P-DCS-Billing-Info标题中。
o The BCID billing correlation identifier and cccid (call content channel identifier) are added to the P-DCS-LAES header.
o BCID计费相关标识符和cccid（呼叫内容通道标识符）添加到P-DCS-LAES报头。
o P-DCS-Billing-Info header is applied to the SUBSCRIBE method.
o P-DCS-Billing-Info报头应用于订阅方法。
o P-DCS-REDIRECT header is applied to the REFER method.
o P-DCS-REDIRECT标头应用于REFER方法。
o The use of QoS authorization to establish content intercept is made optional in order not to preclude alternative content intercept provisioning mechanisms.
o 使用QoS授权来建立内容截获是可选的，以便不排除其他内容截获供应机制。
o PUBLISH and MESSAGE methods are added to the SIP method applicability matrices throughout.
o 发布和消息方法始终添加到SIP方法适用性矩阵中。
o Correction is made to Table 2 to add m=modify.
o 对表2进行了修正，以添加m=修改。
o IANA considerations are updated.
o IANA注意事项已更新。
o Corrections are made to timestamp format, and references are updated.
o 对时间戳格式进行了更正，并更新了引用。
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, Brian Lindsay. 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; Lucent Cable Communications; and Miguel Garcia, Ericsson.
PacketCable项目中的分布式呼叫信令工作是代表许多不同公司的大量人员的工作。作者要感谢并感谢以下人员的帮助：摩托罗拉的John Wheeler；大卫·博德曼、丹尼尔·保罗、阿里斯互动；比尔·布鲁姆、乔恩·费罗斯、杰伊·斯特拉特、杰夫·奥利斯、克莱夫·霍尔博罗、摩托罗拉；Doug Newlin，Guido Schuster，Ikhlaq Sidhu，3Com；海湾网络公司Jiri Matousek；法兹·哈扎伊，布莱恩·林赛。北电,；约翰·查普曼、比尔·古克尔、迈克尔·拉马霍、思科；Chuck Kalmanek，Doug Nortz，John Lawser，James Cheng，Tong Hai Xiao，Partho Mishra，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; David Hancock (D.Hancock@ Cablelabs.com) and 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.
比尔·马歇尔(wtm@research.att.com)和K·K·罗摩克里希南(kkrama@research.att.com)，美国电话电报公司；埃德·米勒（爱德华。miller@terayon.com)，太阳穴；大卫·汉考克（D.Hancock@Cablelabs.com）和格伦·拉塞尔（G。Russell@Cablelabs.com)，有线实验室；伯克贝瑟(burcak@juniper.net)Juniper网络；迈克·曼奈特（迈克尔_Mannette@3com.com)和Kurt Steinbrenner（Kurt_Steinbrenner@3com.com)、3Com；戴夫·奥兰(oran@cisco.com)还有弗莱明·安德里森(fandreas@cisco.com)，思科系统；约翰·皮肯斯(jpickens@com21.com)，Com21；普尔尼玛·拉尔瓦尼（普尔尼玛。lalwaney@nokia.com)诺基亚,；乔恩·费罗斯(jfellows@coppermountain.com)，铜山网络；埃文斯医生(n7dr@arrisi.com)Arris和Keith Kelly(keith@netspeak.com)，网语。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[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月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，2006年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", January 2003.
[DCSARCH]Marshall，W.，Osman，M.，Andreasen，F.，和D.Evans，“利用基于SIP的分布式呼叫控制机制提供电信级电话服务的架构考虑”，2003年1月。
[PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Dynamic Quality of Service", August 2005.
[PCDQOS]有线电视实验室有限公司，“PacketCable 1.5规范，动态服务质量”，2005年8月。
[PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Event Messages", December 2005.
[PCEM]有线电视实验室有限公司，“PacketCable 1.5规范，事件消息”，2005年12月。
[PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Security", January 2005.
[PCSEC]有线电视实验室有限公司，“PacketCable 1.5规范，安全”，2005年1月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804]IAB和IESG，“IETF关于窃听的政策”，RFC28042000年5月。
[RFC3325] 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.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 3603, October 2003.
[RFC3603]Marshall，W.和F.Andreasen，“支持分组电缆分布式呼叫信令体系结构的专用会话发起协议（SIP）代理到代理扩展”，RFC 3603，2003年10月。
Authors' Addresses
作者地址
Flemming Andreasen Cisco Edison, NJ USA
弗莱明·安德里森·思科·爱迪生，美国新泽西州
EMail: fandreas@cisco.com
EMail: fandreas@cisco.com
Bernie McKibben CableLabs Louisville, CO USA
美国路易斯维尔市伯尼·麦基本有线实验室
EMail: B.McKibben@cablelabs.com
EMail: B.McKibben@cablelabs.com
Bill Marshall AT&T Florham Park, NJ USA
比尔·马歇尔美国新泽西州弗洛勒姆公园AT&T酒店
EMail: wtm@research.att.com
EMail: wtm@research.att.com