Network Working Group K. Carlberg
Request for Comments: 4190 G11
Category: Informational I. Brown
UCL
C. Beard
UMKC
November 2005
Network Working Group K. Carlberg
Request for Comments: 4190 G11
Category: Informational I. Brown
UCL
C. Beard
UMKC
November 2005
Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
IP电话中支持紧急电信服务（ETS）的框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.
本文件提供了一个框架，用于在IP电话环境中支持授权的紧急相关通信。我们提出了一系列目标，这些目标反映了授权应急服务与应急电信服务（ETS）应如何在当今的IP架构和服务模型中实现的一般观点。从这些目标出发，我们提出了一套相应的协议和功能，为现有IETF协议提供了一套更具体的建议。最后，我们将介绍两个场景，作为本文档中列出的目标和功能的指导模型。这些模型，再加上公共交换电话网（PSTN）中现有服务的一个例子，形成了一个受限的解决方案空间。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Emergency Related Data .....................................4
1.1.1. Government Emergency Telecommunications
Service (GETS) ......................................4
1.1.2. International Emergency Preparedness Scheme (IEPS) ..5
1.2. Scope of This Document .....................................5
2. Objective .......................................................7
3. Considerations ..................................................7
4. Protocols and Capabilities ......................................7
4.1. Signaling and State Information ............................8
4.1.1. SIP .................................................8
4.1.2. Diff-Serv ...........................................8
4.1.3. Variations Related to Diff-Serv and Queuing .........9
4.1.4. RTP ................................................10
4.1.5. GCP/H.248 ..........................................11
4.2. Policy ....................................................12
4.3. Traffic Engineering .......................................12
4.4. Security ..................................................13
4.4.1. Denial of Service ..................................13
4.4.2. User Authorization .................................14
4.4.3. Confidentiality and Integrity ......................15
4.5. Alternate Path Routing ....................................16
4.6. End-to-End Fault Tolerance ................................17
5. Key Scenarios ..................................................18
5.1. Single IP Administrative Domain ...........................18
5.2. Multiple IP Administrative Domains ........................19
6. Security Considerations ........................................20
7. Informative References .........................................20
Appendix A: Government Telephone Preference Scheme (GTPS) .........24
A.1. GTPS and the Framework Document ..........................24
Appendix B: Related Standards Work ................................24
B.1. Study Group 16 (ITU) .....................................25
Acknowledgements ..................................................26
1. Introduction ....................................................2
1.1. Emergency Related Data .....................................4
1.1.1. Government Emergency Telecommunications
Service (GETS) ......................................4
1.1.2. International Emergency Preparedness Scheme (IEPS) ..5
1.2. Scope of This Document .....................................5
2. Objective .......................................................7
3. Considerations ..................................................7
4. Protocols and Capabilities ......................................7
4.1. Signaling and State Information ............................8
4.1.1. SIP .................................................8
4.1.2. Diff-Serv ...........................................8
4.1.3. Variations Related to Diff-Serv and Queuing .........9
4.1.4. RTP ................................................10
4.1.5. GCP/H.248 ..........................................11
4.2. Policy ....................................................12
4.3. Traffic Engineering .......................................12
4.4. Security ..................................................13
4.4.1. Denial of Service ..................................13
4.4.2. User Authorization .................................14
4.4.3. Confidentiality and Integrity ......................15
4.5. Alternate Path Routing ....................................16
4.6. End-to-End Fault Tolerance ................................17
5. Key Scenarios ..................................................18
5.1. Single IP Administrative Domain ...........................18
5.2. Multiple IP Administrative Domains ........................19
6. Security Considerations ........................................20
7. Informative References .........................................20
Appendix A: Government Telephone Preference Scheme (GTPS) .........24
A.1. GTPS and the Framework Document ..........................24
Appendix B: Related Standards Work ................................24
B.1. Study Group 16 (ITU) .....................................25
Acknowledgements ..................................................26
The Internet has become the primary target for worldwide communications in terms of recreation, business, and various imaginative reasons for information distribution. A constant fixture in the evolution of the Internet has been the support of Best Effort as the default service model. Best Effort, in general terms, implies that the network will attempt to forward traffic to the destination as best as it can, with no guarantees being made, nor any resources reserved, to support specific measures of Quality of Service (QoS). An underlying goal is to be "fair" to all the traffic in terms of the resources used to forward it to the destination.
互联网已经成为世界范围内娱乐、商业和信息传播的各种想象原因的主要通信目标。在互联网的发展过程中，一个固定不变的东西就是支持尽力而为的默认服务模式。一般来说，最大努力意味着网络将尝试尽可能地将流量转发到目的地，而不做任何保证，也不保留任何资源，以支持服务质量（QoS）的特定度量。一个基本目标是在将流量转发到目的地所使用的资源方面对所有流量“公平”。
In an attempt to go beyond best effort service, [1] presented an overview of Integrated Services (int-serv) and its inclusion into the Internet architecture. This was followed by [2], which specified the RSVP signaling protocol used to convey QoS requirements. With the addition of [3] and [4], specifying controlled load (bandwidth bounds) and guaranteed service (bandwidth & delay bounds), respectively, a design existed to achieve specific measures of QoS for an end-to-end flow of traffic traversing an IP network. In this case, our reference to a flow is one that is granular in definition and applies to specific application sessions.
为了超越尽力而为的服务，[1]概述了集成服务（int-serv）及其在互联网体系结构中的应用。接着是[2]，其中规定了用于传达QoS要求的RSVP信令协议。通过添加[3]和[4]，分别指定受控负载（带宽边界）和保证服务（带宽和延迟边界），存在一种设计，以实现穿越IP网络的端到端流量的QoS的具体措施。在本例中，我们对流的引用在定义上是细粒度的，并且适用于特定的应用程序会话。
From a deployment perspective (as of the date of this document), int-serv has been predominantly constrained to intra-domain paths, at best resembling isolated "island" reservations for specific types of traffic (e.g., audio and video) by stub domains. [5] and [6] will probably contribute to additional deployment of int-serv to Internet Service Providers (ISP) and possibly some inter-domain paths, but it seems unlikely that the original vision of end-to-end int-serv between hosts in source and destination stub domains will become a reality in the near future (the mid- to far-term is a subject for others to contemplate).
从部署角度来看（截至本文档发布之日），int-serv主要局限于域内路径，充其量类似于存根域对特定类型流量（如音频和视频）的孤立“孤岛”保留。[5] [6]可能有助于向互联网服务提供商（ISP）和一些域间路径额外部署int-serv，但源存根域和目标存根域中主机之间端到端int-serv的最初设想似乎不太可能在不久的将来成为现实（中长期是其他人可以考虑的问题）。
In 1998, the IETF produced [7], which presented an architecture for Differentiated Services (diff-serv). This effort focused on a more aggregated perspective and classification of packets than that of [1]. This is accomplished with the recent specification of the diff-serv field in the IP header (in the case of IPv4, it replaced the old ToS field). This new field is used for code points established by IANA, or set aside as experimental. It can be expected that sets of microflows, a granular identification of a set of packets, will correspond to a given code point, thereby achieving an aggregated treatment of data.
1998年，IETF产生了[7]，提出了一种区分服务体系结构（diff-serv）。与[1]相比，这项工作侧重于更聚合的角度和数据包分类。这是通过IP报头中最新的diff-serv字段规范实现的（对于IPv4，它取代了旧的ToS字段）。这个新字段用于IANA建立的代码点，或者作为实验性代码点搁置。可以预期，微流集（一组分组的粒度标识）将对应于给定的码点，从而实现数据的聚合处理。
One constant in the introduction of new service models has been the designation of Best Effort as the default service model. If traffic is not, or cannot be, associated as diff-serv or int-serv, then it is treated as Best Effort and uses what resources are made available to it.
在引入新的服务模型时，一个不变的因素是将尽力而为指定为默认服务模型。如果流量没有或不能关联为diff-serv或int-serv，那么它将被视为尽力而为，并使用提供给它的资源。
Beyond the introduction of new services, the continued pace of additional traffic load experienced by ISPs over the years has continued to place a high importance on intra-domain traffic engineering. The explosion of IETF contributions, in the form of drafts and RFCs produced in the area of Multi-Protocol Label Switching (MPLS), exemplifies the interest in versatile and manageable mechanisms for intra-domain traffic engineering. One interesting observation is the work involved in supporting QoS related traffic engineering. Specifically, we refer to MPLS support
除了引入新的服务外，ISP多年来不断增加的流量负载也继续高度重视域内流量工程。IETF在多协议标签交换（MPLS）领域以草稿和RFC的形式大量投入，这说明了人们对域内流量工程的多功能和可管理机制的兴趣。一个有趣的观察是支持QoS相关流量工程所涉及的工作。具体来说，我们指的是MPLS支持
of differentiated services [8], and the ongoing work in the inclusion of fast bandwidth recovery of routing failures for MPLS [9].
差异化服务[8]，以及正在进行的MPLS路由故障快速带宽恢复工作[9]。
The evolution of the IP service model architecture has traditionally centered on the type of application protocols used over a network. By this we mean that the distinction, and possible bounds on QoS, usually centers on the type of application (e.g., audio video tools) that is being referred to.
传统上，IP服务模型体系结构的发展集中在网络上使用的应用程序协议的类型上。我们的意思是，QoS的区别和可能的界限通常集中在所引用的应用程序类型（例如，音频视频工具）上。
[10] has defined a priority field for SMTP, but it is only for mapping with X.400 and is not meant for general usage. SIP [11] has an embedded field denoting "priority", but it is only targeted toward the end-user and is not meant to provide an indication to the underlying network or end-to-end applications.
[10] 已为SMTP定义了优先级字段，但它仅用于与X.400的映射，不适用于一般用途。SIP[11]有一个表示“优先级”的嵌入式字段，但它只针对最终用户，并不意味着向底层网络或端到端应用程序提供指示。
Given the emergence of IP telephony, a natural inclusion of its service is an ability to support existing emergency related services. Typically, one associates emergency calls with "911" telephone service in the U.S., or "999" in the U.K. -- both of which are attributed to national boundaries and accessible by the general public. Outside of this there exist emergency telephone services that involve authorized usage, as described in the following subsection.
鉴于IP电话的出现，其服务的一个自然组成部分是支持现有应急相关服务的能力。通常，一个急诊科与美国的“911”电话服务或英国的“999”电话服务相联系，这两个电话服务都是由国界划分的，公众可以访问。除此之外，还有涉及授权使用的紧急电话服务，如以下小节所述。
GETS is an emergency telecommunications service available in the U.S. and is overseen by the National Communications System (NCS) -- an office established by the White House under an executive order [27] and now a part of the Department of Homeland Security. Unlike "911", it is only accessible by authorized individuals. The majority of these individuals are from various government agencies like the Department of Transportation, NASA, the Department of Defense, and the Federal Emergency Management Agency (to name a few). In addition, a select set of individuals from private industry (telecommunications companies, utilities, etc.) that are involved in critical infrastructure recovery operations are also provided access to GETS.
GETS是美国可用的紧急电信服务，由国家通信系统（NCS）监督。国家通信系统是白宫根据行政命令[27]设立的一个办公室，现在是国土安全部的一部分。与“911”不同，它只能由授权人员访问。这些人大部分来自不同的政府机构，如交通部、NASA、国防部和联邦应急管理局（仅举几例）。此外，还向参与关键基础设施恢复操作的私营行业（电信公司、公用事业公司等）的一批精选人员提供访问GET的权限。
The purpose of GETS is to achieve a high probability that phone service will be available to selected authorized personnel in times of emergencies, such as hurricanes, earthquakes, and other disasters, that may produce a burden in the form of call blocking (i.e., congestion) on the U.S. Public Switched Telephone Network by the general public.
GETS的目的是在紧急情况下（如飓风、地震和其他灾害）为选定的授权人员提供高概率的电话服务，这些紧急情况可能会对美国公共交换电话网络造成呼叫阻塞（即拥塞）的负担。
GETS is based in part on the ANSI T1.631 standard, specifying a High Probability of Completion (HPC) for SS7 signaling [12][24].
GETS部分基于ANSI T1.631标准，规定了SS7信令的高完成概率（HPC）[12][24]。
[25] is a recent ITU standard that describes emergency-related communications over the international telephone service. While systems like GETS are national in scope, IEPS acts as an extension to local or national authorized emergency call establishment and provides a building block for a global service.
[25] 是国际电联最近制定的一项标准，该标准描述了通过国际电话服务进行的与紧急情况相关的通信。虽然GETS等系统是国家范围内的，但IEPS作为本地或国家授权紧急呼叫建立的扩展，并为全球服务提供构建块。
As in the case of GETS, IEPS promotes mechanisms like extended queuing, alternate routing, and exemption from restrictive management controls in order to increase the probability that international emergency calls will be established. The specifics of how this is to be accomplished are to be defined in future ITU document(s).
与GETS一样，IEPS促进了诸如延长排队、备用路由和免除限制性管理控制等机制，以增加建立国际紧急呼叫的可能性。如何实现这一点的细节将在未来的ITU文件中定义。
The scope of this document centers on the near and mid-term support of ETS within the context of IP telephony versus Voice over IP. We make a distinction between these two by treating IP telephony as a subset of VoIP, where in the former case, we assume that some form of application layer signaling is used to explicitly establish and maintain voice data traffic. This explicit signaling capability provides the hooks from which VoIP traffic can be bridged to the PSTN.
本文件的范围集中在IP电话与IP语音环境下ETS的近期和中期支持。我们通过将IP电话视为VoIP的一个子集来区分这两者，在前一种情况下，我们假设使用某种形式的应用层信令来显式地建立和维护语音数据流量。这种明确的信令能力提供了钩子，VoIP流量可以从钩子桥接到PSTN。
An example of this distinction is when the Robust Audio Tool (RAT) [13] begins sending VoIP packets to a unicast (or multicast) destination. RAT does not use explicit signaling like SIP to establish an end-to-end call between two users. It simply sends data packets to the target destination. On the other hand, "SIP phones" are host devices that use a signaling protocol to establish a call before sending data towards the destination.
这种区别的一个例子是当鲁棒音频工具（RAT）[13]开始向单播（或多播）目的地发送VoIP数据包时。RAT不使用SIP等显式信令在两个用户之间建立端到端呼叫。它只是将数据包发送到目标目的地。另一方面，“SIP电话”是使用信令协议在向目的地发送数据之前建立呼叫的主机设备。
One other aspect we should probably assume exists with IP Telephony is an association of a target level of QoS per session or flow. [28] makes an argument that there is a maximum packet loss and delay for VoIP traffic, and that both are interdependent. For delays of ~200ms, a corresponding drop rate of 5% is deemed acceptable. When delay is lower, a 15-20% drop rate can be experienced and still be considered acceptable. [29] discusses the same topic and makes an argument that packet size plays a significant role in what users tolerate as "intelligible" VoIP. The larger the packet, correlating to a longer sampling rate, the lower the acceptable rate of loss. Note that [28, 29] provide only two of several perspectives in examining VoIP. A more in-depth discussion on this topic is outside
我们可能应该假设IP电话存在的另一个方面是每个会话或流的QoS目标级别的关联。[28]论证了VoIP流量存在最大数据包丢失和延迟，并且两者是相互依存的。对于约200ms的延迟，可接受5%的相应下降率。当延迟较低时，可经历15-20%的下降率，且仍被视为可接受。[29]讨论了同一主题，并论证了数据包大小在用户容忍的“可理解”VoIP中起着重要作用。与较长的采样率相关的数据包越大，可接受的丢失率越低。请注意，[28,29]在研究VoIP时只提供了几个视角中的两个。关于这个话题的更深入的讨论在外面
the scope of this document, though it should be noted that the choice of codec can significantly alter the above results.
本文档的范围，但应注意的是，选择编解码器可能会显著改变上述结果。
Regardless of a single and definitive characteristic for stressed conditions, it would seem that interactive voice has a lower threshold of some combinations of loss/delay/jitter than elastic applications such as email or web browsers. This places a higher burden on the problem of supporting VoIP over the Internet. This problem is further compounded when toll-quality service is expected because it assumes a default service model that is better than best effort. This, in turn, can increase the probability that a form of call-blocking can occur with VoIP or IP telephony traffic.
不管压力条件下的单一和明确特征如何，交互式语音的某些丢失/延迟/抖动组合的阈值似乎比弹性应用程序（如电子邮件或web浏览器）低。这给通过互联网支持VoIP的问题带来了更大的负担。当期望收费服务质量时，这个问题会进一步加剧，因为它假设了一个比尽力而为更好的默认服务模型。这反过来会增加VoIP或IP电话流量发生呼叫阻塞的可能性。
Beyond this, part of our motivation in writing this document is to provide a framework for ISPs and telephony carriers to understand the objectives used to support ETS-related IP telephony traffic. In addition, we also wish to provide a reference point for potential customers in order to constrain their expectations. In particular, we wish to avoid any temptation of trying to replicate the exact capabilities of existing emergency voice service that are currently available in the PSTN to that of IP and the Internet. If nothing else, intrinsic differences between the two communications architectures precludes this from happening. Note, this does not prevent us from borrowing design concepts or objectives from existing systems.
除此之外，我们撰写本文件的部分动机是为ISP和电话运营商提供一个框架，以了解用于支持ETS相关IP电话流量的目标。此外，我们还希望为潜在客户提供一个参考点，以限制他们的期望。特别是，我们希望避免试图将PSTN中现有的紧急语音服务的确切功能复制到IP和Internet上的任何诱惑。如果没有其他原因的话，这两种通信体系结构之间的固有差异将阻止这种情况的发生。注意，这并不妨碍我们从现有系统中借用设计概念或目标。
Section 2 presents several primary objectives that articulate what is considered important in supporting ETS-related IP telephony traffic. These objectives represent a generic set of goals and desired capabilities. Section 3 presents additional value-added objectives, which are viewed as useful, but not critical. Section 4 presents protocols and capabilities that relate or can play a role in support of the objectives articulated in Section 2. Finally, Section 5 presents two scenarios that currently exist or are being deployed in the near term over IP networks. These are not all-inclusive scenarios, nor are they the only ones that can be articulated ([34] provides a more extensive discussion on the topology scenarios related to IP telephony). However, these scenarios do show cases where some of the protocols discussed in Section 4 apply, and where some do not.
第2节介绍了几个主要目标，阐明了支持ETS相关IP电话流量的重要内容。这些目标代表一组通用的目标和期望的能力。第3节介绍了附加值目标，这些目标被视为有用，但并不重要。第4节介绍了与第2节所述目标相关或可在支持第2节所述目标方面发挥作用的协议和能力。最后，第5节介绍了目前存在的或近期正在部署的两种通过IP网络的场景。这些场景并非包罗万象，也不是唯一可以明确表述的场景（[34]对与IP电话相关的拓扑场景进行了更广泛的讨论）。但是，这些场景确实显示了第4节中讨论的一些协议适用的情况，以及一些不适用的情况。
Finally, we need to state that this document focuses its attention on the IP layer and above. Specific operational procedures pertaining to Network Operation Centers (NOC) or Network Information Centers (NIC) are outside the scope of this document. This includes the "bits" below IP, other specific technologies, and service-level agreements between ISPs and telephony carriers with regard to dedicated links.
最后，我们需要声明，本文档将重点放在IP层及以上。与网络运营中心（NOC）或网络信息中心（NIC）相关的具体操作程序不在本文件范围内。这包括IP下的“比特”、其他特定技术以及ISP和电话运营商之间关于专用链路的服务级别协议。
The objective of this document is to present a framework that describes how various protocols and capabilities (or mechanisms) can facilitate and support the traffic from ETS users. In several cases, we provide a bit of background in each area so that the reader is given some context and a more in-depth understanding. We also provide some discussion on aspects about a given protocol or capability that could be explored and potentially advanced to support ETS. This exploration is not to be confused with specific solutions since we do not articulate exactly what must be done (e.g., a new header field, or a new code point).
本文件的目的是提供一个框架，描述各种协议和功能（或机制）如何促进和支持ETS用户的流量。在一些情况下，我们会在每个领域提供一些背景知识，以便读者了解一些背景知识和更深入的理解。我们还提供了一些关于给定协议或功能方面的讨论，这些协议或功能可以被探索并可能被提升以支持ETS。这种探索不应与具体的解决方案混淆，因为我们没有明确说明必须做什么（例如，新的标题字段或新的代码点）。
When producing a solution, or examining existing protocols and mechanisms, there are some things that should be considered. One is that inter-domain ETS communications should not rely on ubiquitous or even widespread support along the path between the end points. Potentially, at the network layer there may exist islands of support realized in the form of overlay networks. There may also be cases where solutions may be constrained on an end-to-end basis (i.e., at the transport or application layer). It is this diversity and possibly partial support that needs to be taken into account by those designing and deploying ETS-related solutions.
在生成解决方案或检查现有协议和机制时，应该考虑一些事情。一是域间ETS通信不应依赖于端点之间路径上无处不在甚至广泛的支持。在网络层，可能存在以覆盖网络形式实现的支持孤岛。在某些情况下，解决方案可能会受到端到端的限制（即，在传输层或应用层）。设计和部署ETS相关解决方案的人员需要考虑到这种多样性和可能的部分支持。
Another aspect to consider is that there are existing architectures and protocols from other standards bodies that support emergency-related communications. The effort in interoperating with these systems, presumably through gateways or similar types of nodes with IETF protocols, would foster a need to distinguish ETS flows from other flows. One reason would be the scenario of triggering ETS service from an IP network.
另一个需要考虑的方面是，存在其他支持急诊科通信的标准体的体系结构和协议。可能通过网关或具有IETF协议的类似类型的节点与这些系统进行互操作的努力将促进区分ETS流和其他流的需要。一个原因是从IP网络触发ETS服务的情况。
Finally, we take into consideration the requirements of [35, 36] in discussing the protocols and mechanisms below in Section 4. In doing this, we do not make a one-to-one mapping of protocol discussion a requirement. Rather, we make sure the discussion of Section 4 does not violate any of the requirements in [35, 36].
最后，在第4节讨论协议和机制时，我们考虑了[35,36]的要求。在这样做时，我们并不要求对协议讨论进行一对一的映射。相反，我们确保第4节的讨论不违反[35,36]中的任何要求。
In this section, we take the objectives presented above and present a set of protocols and capabilities that can be used to achieve them. Given that the objectives are predominantly atomic in nature, the measures used to address them are to be viewed separately with no specific dependency upon each other as a whole. Various protocols and capabilities may be complimentary to each other, but there is no
在本节中，我们将实现上述目标，并介绍一组可用于实现这些目标的协议和功能。鉴于这些目标主要是原子性质的，用于解决这些问题的措施应单独看待，不存在相互依赖的具体整体。各种协议和功能可能相互补充，但没有
need for all to exist, given different scenarios of operation; and ETS support is not expected to be an ubiquitously available service. We divide this section into 5 areas:
考虑到不同的运营场景，所有人都需要存在；预计ETS支持不会是一项无处不在的服务。我们将本节分为5个方面：
1) Signaling 2) Policy 3) Traffic Engineering 4) Security 5) Routing
1) 信令2）策略3）流量工程4）安全5）路由
Signaling is used to convey various information to either intermediate nodes or end nodes. It can be out-of-band of a data flow, and thus in a separate flow of its own, such as SIP messages. It can be in-band and part of the state information in a datagram containing the voice data. This latter example could be realized in the form of diff-serv code points in the IP packet.
信令用于向中间节点或终端节点传送各种信息。它可以位于数据流的带外，因此位于其自身的单独流中，例如SIP消息。它可以是带内的，也可以是包含语音数据的数据报中的部分状态信息。后一个示例可以以IP分组中的diff-serv码点的形式实现。
In the following subsections, we discuss the current state of some protocols and their use in providing support for ETS. We also discuss potential augmentations to different types of signaling and state information to help support the distinction of emergency-related communications in general.
在以下小节中，我们将讨论一些协议的当前状态及其在为ETS提供支持方面的使用。我们还讨论了对不同类型信号和状态信息的潜在增强，以帮助区分与紧急情况相关的通信。
With respect to application-level signaling for IP telephony, we focus our attention on the Session Initiation Protocol (SIP). Currently, SIP has an existing "priority" field in the Request-Header-Field that distinguishes different types of sessions. The five values currently defined are: "emergency", "urgent", "normal", "non-urgent", "other-priority". These values are meant to convey importance to the end-user and have no additional semantics associated with them.
关于IP电话的应用层信令，我们将注意力集中在会话发起协议（SIP）上。目前，SIP在请求头字段中有一个现有的“优先级”字段，用于区分不同类型的会话。目前定义的五个值是：“紧急”、“紧急”、“正常”、“非紧急”、“其他优先级”。这些值旨在向最终用户传达重要性，并且没有与之相关的附加语义。
[14] is an RFC that defines the requirements for a new header field for SIP in reference to resource priority. The requirements are meant to lead to a means of providing an additional measure of distinction that can influence the behavior of gateways and SIP proxies.
[14] 是一个RFC，它根据资源优先级定义SIP的新头字段的要求。这些要求旨在提供一种额外的区分措施，以影响网关和SIP代理的行为。
In accordance with [15], the differentiated services code point (DSCP) field is divided into three sets of values. The first set is assigned by IANA. Within this set, there are currently, three types of Per Hop Behaviors that have been specified: Default (correlating
根据[15]，区分服务代码点（DSCP）字段分为三组值。第一组由IANA分配。在这个集合中，目前已经指定了三种类型的每跳行为：默认（关联）
to best effort forwarding), Assured Forwarding, and Expedited Forwarding. The second set of DSCP values are set aside for local or experimental use. The third set of DSCP values are also set aside for local or experimental use, but may later be reassigned to IANA if the first set has been completely assigned.
尽最大努力转发）、保证转发和快速转发。第二组DSCP值留作本地或实验使用。第三组DSCP值也留作本地或实验使用，但如果第一组值已完全分配，则可随后重新分配给IANA。
One approach discussed on the IEPREP mailing list is the specification of a new Per-Hop Behaviour (PHB) for emergency-related flows. The rationale behind this idea is that it would provide a baseline by which specific code points may be defined for various emergency-related traffic: authorized emergency sessions (e.g., ETS), general public emergency calls (e.g., "911"), Multi-Level Precedence and Preemption (MLPP) [19], etc. However, in order to define a new set of code points, a forwarding characteristic must also be defined. In other words, one cannot simply identify a set of bits without defining their intended meaning (e.g., the drop precedence approach of Assured Forwarding). The one caveat to this statement are the set of DSCP bits set aside for experimental purposes. But as the name implies, experimental is for internal examination and use and not for standardization.
IEPREP邮件列表中讨论的一种方法是为应急相关流指定新的每跳行为（PHB）。这一想法背后的基本原理是，它将提供一个基线，通过该基线可以为各种紧急相关流量定义特定的代码点：授权紧急会话（如ETS）、一般公共紧急呼叫（如“911”）、多级优先和抢占（MLPP）[19]等。然而，为了定义一组新的代码点，还必须定义转发特性。换句话说，在没有定义其预期含义的情况下，不能简单地识别一组位（例如，保证转发的丢弃优先方法）。该语句的一个警告是为实验目的而预留的一组DSCP位。但顾名思义，实验是为了内部检查和使用，而不是为了标准化。
Note:
注:
It is important to note that at the time this document was written, the IETF had been taking a conservative approach in specifying new PHBs. This is because the number of code points that can be defined is relatively small and is understandably considered a scarce resource. Therefore, the possibility of a new PHB being defined for emergency-related traffic is, at best, a long term project that may or may not be accepted by the IETF.
值得注意的是，在编写本文件时，IETF在指定新PHB时一直采取保守的方法。这是因为可以定义的代码点的数量相对较少，可以理解为稀缺资源。因此，为紧急相关流量定义新PHB的可能性充其量是一个长期项目，IETF可能接受也可能不接受。
In the near term, we would initially suggest using the Assured Forwarding (AF) PHB [18] for distinguishing emergency traffic from other types of flows. At a minimum, AF could be used for the different SIP call signaling messages. If the Expedited Forwarding (EF) PHB [40] was also supported by the domain, then it would be used for IP telephony data packets. Otherwise, another AF class would be used for those data flows.
在短期内，我们最初建议使用有保证转发（AF）PHB[18]来区分紧急流量和其他类型的流量。至少，AF可用于不同的SIP呼叫信令消息。如果域也支持加速转发（EF）PHB[40]，那么它将用于IP电话数据包。否则，另一个AF类将用于这些数据流。
Scheduling mechanisms like Weighted Fair Queueing and Class Based Queueing are used to designate a percentage of the output link bandwidth that would be used for each class if all queues were backlogged. Its purpose, therefore, is to manage the rates and delays experienced by each class. But emergency traffic may not necessarily require QoS perform any better or differently than non-
调度机制（如加权公平排队和基于类的排队）用于指定输出链路带宽的百分比，如果所有队列都被积压，这些带宽将用于每个类。因此，它的目的是管理每个类所经历的速率和延迟。但是，紧急流量不一定需要QoS，也不一定需要与非紧急流量相比有更好或不同的性能-
emergency traffic. It may just need higher probability of being forwarded to the next hop, which could be accomplished simply by dropping precedences within a class.
紧急交通。它可能只需要更高的被转发到下一跳的概率，这可以通过简单地删除类中的前导来实现。
To implement preferential dropping between classes of traffic, one of which is emergency traffic, one would probably need to use a more advanced form of Active Queue Management (AQM). Current implementations use an overall queue fill measurement to make decisions; this might cause emergency classified packets to be dropped. One new form of AQM could be a Multiple Average-Multiple Threshold approach, instead of the Single Average-Multiple Threshold approach used today. This allows creation of drop probabilities based on counting the number of packets in the queue for each drop precedence individually.
要在不同类别的流量（其中之一是紧急流量）之间实现优先丢弃，可能需要使用更高级的主动队列管理（AQM）。当前的实现使用整体队列填充度量来做出决策；这可能会导致紧急分类数据包被丢弃。AQM的一种新形式可能是多平均多阈值方法，而不是目前使用的单平均多阈值方法。这允许根据每个丢弃优先级单独计算队列中的数据包数量来创建丢弃概率。
So, it could be possible to use the current set of AF PHBs if each class were reasonably homogenous in the traffic mix. But one might still have a need to differentiate three drop precedences within non-emergency traffic. If so, more drop precedences could be implemented. Also, if one wanted discrimination within emergency traffic, as with MLPP's five levels of precedence, more drop precedences might also be considered. The five levels would also correlate to a recent effort in Study Group 11 of the ITU to define 5 levels for Emergency Telecommunications Service.
因此，如果每个类在流量组合中都相当同质，则可以使用当前的AF PHB集。但是，人们可能仍然需要区分非紧急交通中的三次下降先例。如果是这样，可以实施更多的放弃先例。此外，如果想要在紧急交通中进行歧视，就像MLPP的五个优先级别一样，也可以考虑更多的下降优先级别。这五个级别还将与国际电联第11研究组最近为紧急电信服务确定5个级别的努力相关联。
The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for data with real-time characteristics. The type of data is generally in the form of audio or video type applications, and is frequently interactive in nature. RTP is typically run over UDP and has been designed with a fixed header that identifies a specific type of payload representing a specific form of application media. The designers of RTP also assumed an underlying network providing best effort service. As such, RTP does not provide any mechanism to ensure timely delivery or provide other QoS guarantees. However, the emergence of applications like IP telephony, as well as new service models, present new environments where RTP traffic may be forwarded over networks that support better than best effort service. Hence, the original scope and target environment for RTP has expanded to include networks providing services other than best effort.
实时传输协议（RTP）为具有实时特性的数据提供端到端传递服务。数据类型通常以音频或视频类型的应用程序的形式存在，并且通常是交互式的。RTP通常在UDP上运行，并使用一个固定的报头进行设计，该报头标识表示特定形式的应用程序媒体的特定类型的有效负载。RTP的设计者还假设底层网络提供尽力而为的服务。因此，RTP不提供任何机制来确保及时交付或提供其他QoS保证。然而，IP电话等应用的出现，以及新的服务模式，提供了新的环境，RTP流量可以通过支持优于尽力而为服务的网络进行转发。因此，RTP最初的范围和目标环境已经扩展到包括提供除尽力而为之外的服务的网络。
In 4.1.2, we discussed one means of marking a data packet for emergencies under the context of the diff-serv architecture. However, we also pointed out that diff-serv markings for specific PHBs are not globally unique, and may be arbitrarily removed or even changed by intermediary nodes or domains. Hence, with respect to
在4.1.2中，我们讨论了在diff-serv体系结构的上下文中为紧急情况标记数据包的一种方法。然而，我们也指出，特定PHB的区分服务标记不是全局唯一的，并且可能被中间节点或域任意删除甚至更改。因此，关于
emergency related data packets, we are still missing an in-band marking in a data packet that stays constant on an end-to-end basis.
与紧急情况相关的数据包，我们仍然缺少在端到端基础上保持恒定的数据包中的带内标记。
There are three choices in defining a persistent marking of data packets and thus avoiding the transitory marking of diff-serv code points. One can propose a new PHB dedicated for emergency type traffic as discussed in 4.1.2. One can propose a specification of a new shim layer protocol at some location above IP. Or, one can add a new specification to an existing application layer protocol. The first two cases are probably the "cleanest" architecturally, but they are long term efforts that may not come to pass because of a limited number of diff-serv code points and the contention that yet another shim layer will make the IP stack too large. The third case, placing a marking in an application layer packet, also has drawbacks; the key weakness being the specification of a marking on a per-application basis.
定义数据包的持久标记，从而避免区分服务代码点的临时标记，有三种选择。如第4.1.2节所述，可以提出一个专门用于紧急类型交通的新PHB。可以在IP之上的某个位置提出一个新的垫片层协议规范。或者，可以向现有的应用层协议添加新规范。前两种情况在体系结构上可能是“最干净的”，但它们是长期的努力，可能不会实现，因为diff-serv代码点的数量有限，而且还有另一个垫片层会使IP堆栈过大。第三种情况，在应用层分组中放置标记，也有缺点；关键缺点是每种应用的标记规格。
Discussions have been held in the Audio/Visual Transport (AVT) working group on augmenting RTP so that it can carry a marking that distinguishes emergency-related traffic from that which is not. Specifically, these discussions centered on defining a new extension that contains a "classifier" field indicating the condition associated with the packet (e.g., authorized-emergency, emergency, normal) [26]. The rationale behind this idea was that focusing on RTP would allow one to rely on a point of aggregation that would apply to all payloads that it encapsulates. However, the AVT group has expressed a rough consensus that placing an additional classifier state in the RTP header to denote the importance of one flow over another is not an approach they wish to advance. Objections ranging from relying on SIP to convey the importance of a flow, to the possibility of adversely affecting header compression, were expressed. There was also the general feeling that the extension header for RTP that acts as a signal should not be used.
音频/视频传输（AVT）工作组已就增强RTP进行了讨论，以使其能够携带区分紧急交通和非紧急交通的标志。具体而言，这些讨论集中于定义一个新的扩展，该扩展包含一个“分类器”字段，指示与数据包相关的条件（例如，授权紧急、紧急、正常）[26]。这个想法背后的基本原理是，专注于RTP将允许一个聚合点，该聚合点将应用于它封装的所有有效负载。然而，AVT小组已经表达了一个大致的共识，即在RTP报头中放置一个额外的分类器状态来表示一个流相对于另一个流的重要性，这不是他们希望推进的方法。从依赖SIP来传达流的重要性，到可能对报头压缩产生不利影响，都有人提出了反对意见。还有一种普遍的感觉是，不应该使用RTP作为信号的扩展头。
The Gateway Control Protocol (GCP) [21] defines the interaction between a media gateway and a media gateway controller. [21] is viewed as an updated version of common text with ITU-T Recommendation H.248 [41] and is a result of applying the changes of RFC 2886 (Megaco Errata) [43] to the text of RFC 2885 (Megaco Protocol version 0.8) [42].
网关控制协议（GCP）[21]定义了媒体网关和媒体网关控制器之间的交互。[21]被视为ITU-T建议H.248[41]的通用文本的更新版本，是将RFC 2886（Megaco勘误表）[43]的变更应用于RFC 2885（Megaco协议版本0.8）[42]文本的结果。
In [21], the protocol specifies a Priority and Emergency field for a context attribute and descriptor. The Emergency is an optional boolean (True or False) condition. The Priority value, which ranges from 0 through 15, specifies the precedence handling for a context.
在[21]中，协议为上下文属性和描述符指定了优先级和紧急字段。紧急情况是可选的布尔（真或假）条件。优先级值的范围从0到15，指定上下文的优先级处理。
The protocol does not specify individual values for priority. We also do not recommend the definition of a well known value for the GCP priority as this is out of scope of this document. Any values set should be a function of any SLAs that have been established regarding the handling of emergency traffic.
协议没有为优先级指定单独的值。我们也不建议定义GCP优先级的已知值，因为这超出了本文件的范围。设置的任何值都应该是与紧急交通处理相关的任何SLA的函数。
One of the objectives listed in Section 3 above is to treat ETS signaling, and related data traffic, as non-preemptive in nature. Further, this treatment is to be the default mode of operation or service. This is in recognition that existing regulations or laws of certain countries governing the establishment of SLAs may not allow preemptive actions (e.g., dropping existing telephony flows). On the other hand, the laws and regulations of other countries influencing the specification of SLA(s) may allow preemption, or even require its existence. Given this disparity, we rely on local policy to determine the degree by which emergency-related traffic affects existing traffic load of a given network or ISP. Important note: we reiterate our earlier comment that laws and regulations are generally outside the scope of the IETF and its specification of designs and protocols. However, these constraints can be used as a guide in producing a baseline capability to be supported; in our case, a default policy for non-preemptive call establishment of ETS signaling and data.
上述第3节中列出的目标之一是将ETS信令和相关数据流量视为非抢占性质。此外，这种处理将成为默认的操作或服务模式。这是因为认识到某些国家关于建立SLA的现行法规或法律可能不允许采取先发制人的行动（例如，放弃现有的电话流）。另一方面，影响SLA规范的其他国家的法律法规可能允许优先购买权，甚至要求存在优先购买权。鉴于这种差异，我们依靠本地政策来确定紧急相关流量对给定网络或ISP现有流量负载的影响程度。重要提示：我们重申先前的意见，即法律法规通常不在IETF及其设计和协议规范的范围内。然而，这些约束可作为生成待支持基线能力的指南；在我们的例子中，ETS信令和数据的非抢占式呼叫建立的默认策略。
Policy can be in the form of static information embedded in various components (e.g., SIP servers or bandwidth brokers), or it can be realized and supported via COPS with respect to allocation of a domain's resources [16]. There is no requirement as to how policy is accomplished. Instead, if a domain follows actions outside of the default non-preemptive action of ETS-related communication, then we stipulate that some type of policy mechanism be in place to satisfy the local policies of an SLA established for ETS-type traffic.
策略可以是嵌入在各种组件（例如SIP服务器或带宽代理）中的静态信息的形式，也可以通过与域资源分配相关的COP实现和支持策略[16]。没有关于如何完成政策的要求。相反，如果域遵循ETS相关通信的默认非抢占性操作之外的操作，则我们规定某种类型的策略机制应到位，以满足为ETS类型通信建立的SLA的本地策略。
In those cases where a network operates under the constraints of SLAs, one or more of which pertains to ETS-based traffic, it can be expected that some form of traffic engineering is applied to the operation of the network. We make no recommendations as to which type of traffic engineering mechanism is used, but that such a system exists in some form and can distinguish and support ETS signaling and/or data traffic. We recommend a review of [32] by clients and prospective providers of ETS service that gives an overview and a set of principles of Internet traffic engineering.
在网络在SLA约束下运行的情况下，一个或多个SLA与基于ETS的流量有关，可以预期，某种形式的流量工程应用于网络的运行。我们不建议使用哪种类型的流量工程机制，但这样的系统以某种形式存在，可以区分和支持ETS信令和/或数据流量。我们建议ETS服务的客户和潜在提供商对[32]进行审查，以提供互联网流量工程的概述和一套原则。
MPLS is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. This notion is heightened concerning the subject of IP telephony because of MPLS's ability to permit a quasi-circuit switching capability to be superimposed on the current Internet routing model [30].
MPLS通常是在提到流量工程时想到的第一个协议。由于MPLS能够允许在当前的互联网路由模型上叠加准电路交换能力，因此在IP电话方面，这一概念得到了加强[30]。
However, having cited MPLS, we need to stress that it is an intradomain protocol, and so may or may not exist within a given ISP. Other forms of traffic engineering, such as weighted OSPF, may be the mechanism of choice by an ISP.
然而，在引用了MPLS之后，我们需要强调的是，它是一种域内协议，因此在给定的ISP中可能存在，也可能不存在。其他形式的流量工程，如加权OSPF，可能是ISP选择的机制。
As a counter example of using a specific protocol to achieve traffic engineering, [37] presents an example of one ISP relying on a high amount of overprovisioning within its core to satisfy potentially dramatic spikes or bursts of traffic load. In this approach, any configuring of queues for specific customers (neighbors) to support the target QoS is done on the egress edge of the transit network.
作为使用特定协议来实现流量工程的反例，[37]给出了一个ISP依靠其核心内的大量过度配置来满足潜在的急剧峰值或突发流量负载的示例。在这种方法中，在公交网络的出口边缘为特定客户（邻居）配置队列以支持目标QoS。
Note: As a point of reference, existing SLAs established by the NCS for GETS service tend to focus on a loosely defined maximum allocation of, for example, 1% to 10% of calls allowed to be established through a given LEC using HPC. It is expected, and encouraged, that ETS related SLAs of ISPs will be limited with respect to the amount of traffic distinguished as being emergency related and initiated by an authorized user.
注意：作为一个参考点，NCS为GETS服务建立的现有SLA往往侧重于松散定义的最大分配，例如，允许使用HPC通过给定LEC建立的呼叫的1%到10%。预计并鼓励ISP与ETS相关的服务水平协议将限制由授权用户发起的与紧急情况相关的通信量。
This section provides a brief overview of the security issues raised by ETS support.
本节简要概述ETS支持提出的安全问题。
Any network mechanism that enables a higher level of priority for a specific set of flows could be abused to enhance the effectiveness of denial of service (DoS) attacks. Priority would magnify the effects of attack traffic on bandwidth availability in lower-capacity links, and increase the likelihood of it reaching its target(s). An attack could also tie up resources such as circuits in a PSTN gateway.
任何能够为特定流集提供更高优先级的网络机制都可能被滥用，以增强拒绝服务（DoS）攻击的有效性。优先级将放大攻击流量对低容量链路带宽可用性的影响，并增加其达到目标的可能性。攻击还可能占用资源，如PSTN网关中的电路。
Any provider deploying a priority mechanism (such as the QoS systems described in Section 4.1) must therefore carefully apply the associated access controls and security mechanisms. For example, the priority level for traffic originating from an unauthorized part of a network or ingress point should be reset to normal. Users must also be authenticated before being allowed to use a priority service (see Section 4.4.2). However, this authentication process should be lightweight to minimise opportunities for denial of service attacks
因此，任何部署优先级机制（如第4.1节中描述的QoS系统）的提供商必须仔细应用相关的访问控制和安全机制。例如，来自网络或入口点未经授权部分的流量的优先级应重置为正常。在允许用户使用优先级服务之前，还必须对用户进行身份验证（见第4.4.2节）。但是，此身份验证过程应该是轻量级的，以尽量减少拒绝服务攻击的机会
on the authentication service itself, and ideally should include its own anti-DoS mechanisms. Other security mechanisms may impose an overhead that should be carefully considered to avoid creating other opportunities for DoS attacks.
在身份验证服务本身上，理想情况下应包括其自身的防DoS机制。其他安全机制可能会造成开销，应仔细考虑，以避免造成其他DoS攻击机会。
As mentioned in Section 4.3, SLAs for ETS facilities often contain maximum limits on the level of ETS traffic that should be prioritised in a particular network (say 1% of the maximum network capacity). This should also be the case in IP networks to again reduce the level of resources that a denial of service attack can consume.
如第4.3节所述，ETS设施的SLA通常包含特定网络中应优先考虑的ETS流量水平的最大限制（例如最大网络容量的1%）。在IP网络中也应如此，以再次降低拒绝服务攻击可能消耗的资源水平。
As of this writing, a typical inter-provider IP link uses 1 Gbps Ethernet, OC-48 SONET/SDH, or some similar or faster technology. Also, as of this writing, it is not practical to deploy per-IP packet cryptographic authentication on such inter-provider links, although such authentication might well be needed to provide assurance of IP-layer label integrity in the inter-provider scenario.
在撰写本文时，典型的供应商间IP链路使用1 Gbps以太网、OC-48 SONET/SDH或一些类似或更快的技术。此外，在撰写本文时，在这样的提供商间链路上部署每个IP分组的加密认证是不实际的，尽管在提供商间场景中，很可能需要这样的认证来提供IP层标签完整性的保证。
While Moore's Law will speed up cryptographic authentication, it is unclear whether that is helpful because the speed of the typical inter-domain link is also increasing rapidly.
虽然摩尔定律将加速加密认证，但不清楚这是否有用，因为典型域间链路的速度也在快速增长。
To prevent theft of service and reduce the opportunities for denial of service attacks, it is essential that service providers properly verify the authorization of a specific traffic flow before providing it with ETS facilities.
为了防止服务被盗并减少拒绝服务攻击的机会，服务提供商在向特定流量提供ETS设施之前，必须正确验证其授权。
Where an ETS call is carried from PSTN to PSTN via one telephony carrier's backbone IP network, very little IP-specific user authorization support is required. The user authenticates itself to the PSTN as usual -- for example, using a PIN in the US GETS. The gateway from the PSTN connection into the backbone IP network must be able to signal that the flow has an ETS label. Conversely, the gateway back into the PSTN must similarly signal the call's label. A secure link between the gateways may be set up using IPSec or SIP security functionality to protect the integrity of the signaling information against attackers who have gained access to the backbone network, and to prevent such attackers from placing ETS calls using the egress PSTN gateway. If the destination of a call is an IP device, the signaling should be protected directly between the IP ingress gateway and the end device.
当ETS呼叫通过一家电话运营商的主干IP网络从PSTN传送到PSTN时，只需要很少的特定于IP的用户授权支持。用户像往常一样通过PSTN进行身份验证——例如，在美国使用PIN。从PSTN连接到骨干IP网络的网关必须能够发出流具有ETS标签的信号。相反，回到PSTN的网关必须同样地向呼叫标签发送信号。网关之间的安全链路可以使用IPSec或SIP安全功能来建立，以保护信令信息的完整性，防止攻击者访问主干网，并防止此类攻击者使用出口PSTN网关进行ETS呼叫。如果呼叫的目的地是IP设备，则应在IP入口网关和终端设备之间直接保护信令。
When ETS priority is being provided to a flow within one domain, that network must use the security features of the priority mechanism being deployed to ensure that the flow has originated from an authorized user or process.
当ETS优先级被提供给一个域内的流时，该网络必须使用正在部署的优先级机制的安全特性，以确保该流来自授权用户或进程。
The access network may authorize ETS traffic over a link as part of its user authentication procedures. These procedures may occur at the link, network, or higher layers, but are at the discretion of a single domain network. That network must decide how often it should update its list of authorized ETS users based on the bounds it is prepared to accept on traffic from recently-revoked users.
接入网络可授权链路上的ETS流量，作为其用户认证过程的一部分。这些过程可能发生在链路、网络或更高层，但由单域网络自行决定。该网络必须根据其准备接受来自最近被撤销用户的流量的边界，决定多久更新一次授权ETS用户列表。
If ETS support moves from intra-domain PSTN and IP networks to inter-domain end-to-end IP, verifying the authorization of a given flow becomes more complex. The user's access network must verify a user's ETS authorization if network-layer priority is to be provided at that point.
如果ETS支持从域内PSTN和IP网络转移到域间端到端IP，验证给定流的授权将变得更加复杂。如果要在该点提供网络层优先级，则用户的接入网络必须验证用户的ETS授权。
Administrative domains that agree to exchange ETS traffic must have the means to securely signal to each other a given flow's ETS status. They may use physical link security combined with traffic conditioning measures to limit the amount of ETS traffic that may pass between the two domains. This agreement must require the originating network to take responsibility for ensuring that only authorized traffic is marked with ETS priority, but the recipient network cannot rely on this happening with 100% reliability. Both domains should perform conditioning to prevent the propagation of theft and denial of service attacks. Note that administrative domains that agree to exchange ETS traffic must deploy facilities that perform these conditioning and security services at every point at which they interconnect with one another.
同意交换ETS流量的管理域必须能够安全地向彼此发送给定流的ETS状态信号。他们可以使用物理链路安全和流量调节措施来限制两个域之间可能通过的ETS流量。本协议必须要求始发网络负责确保只有授权流量标记有ETS优先级，但接收方网络不能依赖于100%的可靠性。这两个域都应执行调节，以防止盗窃和拒绝服务攻击的传播。请注意，同意exchange ETS流量的管理域必须部署在彼此互连的每个点上执行这些调节和安全服务的设施。
Processes using application-layer protocols, such as SIP, should use the security functionality in those protocols to verify the authorization of a session before allowing it to use ETS mechanisms.
使用应用层协议（如SIP）的进程应在允许会话使用ETS机制之前，使用这些协议中的安全功能来验证会话的授权。
When ETS communications are being used to respond to a deliberate attack, it is important that they cannot be altered or intercepted to worsen the situation -- for example, by changing the orders to first responders such as firefighters, or by using knowledge of the emergency response to cause further damage.
当ETS通信被用于应对蓄意攻击时，重要的是它们不能被改变或拦截以使情况恶化——例如，将命令更改为消防员等第一响应者，或利用应急响应知识造成进一步损害。
The integrity and confidentiality of such communications should therefore be protected as far as possible using end-to-end security protocols such as IPSec or the security functionality in SIP and SRTP [39]. Where communications involve other types of networks such as the PSTN, the IP side should be protected and any security functionality available in the other network should be used.
因此，应尽可能使用端到端安全协议（如IPSec）或SIP和SRTP中的安全功能来保护此类通信的完整性和机密性[39]。如果通信涉及其他类型的网络，如PSTN，则应保护IP侧，并应使用其他网络中可用的任何安全功能。
This subject involves the ability to discover and use a different path to route IP telephony traffic around congestion points, and thus avoid them. Ideally, the discovery process would be accomplished in an expedient manner (possibly even a priori to the need of its existence). At this level, we make no assumptions as to how the alternate path is accomplished, or even at which layer it is achieved -- e.g., the network versus the application layer. But this kind of capability, at least in a minimal form, would help contribute to increasing the probability of ETS call completion by making use of noncongested alternate paths. We use the term "minimal form" to emphasize the fact that care must be taken in how the system provides alternate paths so that it does not significantly contribute to the congestion that is to be avoided (e.g., via excess control/discovery messages).
本主题涉及发现和使用不同路径在拥塞点周围路由IP电话流量，从而避免拥塞点的能力。理想情况下，发现过程将以一种方便的方式完成（甚至可能是在其存在的需要之前）。在这个层次上，我们不假设替代路径是如何实现的，甚至不假设它是在哪一层实现的——例如，网络层与应用层。但这种能力，至少以最小的形式，将有助于通过使用非阻塞的备用路径来提高ETS呼叫完成的概率。我们使用术语“最小形式”来强调一个事实，即必须注意系统如何提供备用路径，以使其不会对要避免的拥塞产生显著影响（例如，通过过度控制/发现消息）。
Routing protocols at the IP network layer, such as BGP and OSPF, contain mechanisms for determining link failure between routing peers. The discovery of this failure automatically causes information to be propagated to other routers. The form of this information, the extent of its propagation, and the convergence time in determining new routes is dependent on the routing protocol in use. In the example of OSPF's Equal Cost Multiple Path (ECMP), the impact of link failure is minimized because of pre-existing alternate paths to a destination.
IP网络层的路由协议，如BGP和OSPF，包含确定路由对等点之间链路故障的机制。发现此故障会自动将信息传播到其他路由器。该信息的形式、传播范围以及确定新路由时的收敛时间取决于使用的路由协议。在OSPF的等成本多路径（ECMP）示例中，由于预先存在到目的地的备用路径，链路故障的影响被最小化。
At the time this document was written, we can identify two additional areas in the IETF that can be helpful in providing alternate paths for the specific case of call signaling. The first is [9], which is focused on network layer routing and describes a framework for enhancements to the LDP specification of MPLS to help achieve fault tolerance. This, in itself, does not provide alternate path routing, but rather helps minimize loss in intradomain connectivity when MPLS is used within a domain.
在编写本文档时，我们可以确定IETF中的两个附加区域，它们有助于为呼叫信令的特定情况提供备用路径。第一个是[9]，其重点是网络层路由，并描述了一个框架，用于增强MPLS的LDP规范，以帮助实现容错。这本身并不提供备用路径路由，而是有助于在域内使用MPLS时将域内连接的损失降至最低。
The second effort comes from the IP Telephony working group and involves Telephony Routing over IP (TRIP). To date, a framework document [17] has been published as an RFC that describes the discovery and exchange of IP telephony gateway routing tables between providers. The TRIP protocol [20] specifies application level telephony routing regardless of the signaling protocol being used (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises reachability and attributes of destinations. In its current form, several attributes have already been defined, such as LocalPreference and MultiExitDisc. Additional attributes can be registered with IANA.
第二项工作来自IP电话工作组，涉及IP电话路由（TRIP）。迄今为止，框架文档[17]已作为RFC发布，该文档描述了提供商之间IP电话网关路由表的发现和交换。TRIP协议[20]指定应用层电话路由，而不管使用的是何种信令协议（例如，SIP或H.323）。旅行以BGP-4为模型，宣传目的地的可达性和属性。在其当前形式中，已经定义了几个属性，例如LocalPreference和MultiExitDisc。可以向IANA注册其他属性。
Inter-domain routing is not an area that should be considered in terms of additional alternate path routing support for ETS. The Border Gateway Protocol is currently strained in meeting its existing requirements, and thus adding additional features that would generate an increase in advertised routes will not be well received by the IETF. Refer to [38] for a commentary on Inter-Domain routing.
域间路由不是ETS额外备用路径路由支持应考虑的领域。边境网关协议目前难以满足其现有要求，因此，IETF不会很好地接受添加额外功能以增加公布的路由。有关域间路由的说明，请参阅[38]。
This topic involves work that has been done in trying to compensate for lossy networks providing best effort service. In particular, we focus on the use of a) Forward Error Correction (FEC), and b) redundant transmissions that can be used to compensate for lost data packets. (Note that our aim is fault tolerance, as opposed to an expectation of always achieving it.)
本主题涉及为补偿提供尽力而为服务的有损网络所做的工作。特别是，我们着重于a）前向纠错（FEC）和b）冗余传输的使用，这些传输可用于补偿丢失的数据包。（请注意，我们的目标是容错，而不是期望始终实现容错。）
In the former case, additional FEC data packets are constructed from a set of original data packets and inserted into the end-to-end stream. Depending on the algorithm used, these FEC packets can reconstruct one or more of the original set that were lost by the network. An example may be in the form of a 10:3 ratio, in which 10 original packets are used to generate three additional FEC packets. Thus, if the network loses 30% of packets or less, then the FEC scheme will be able to compensate for that loss. The drawback to this approach is that, to compensate for the loss, a steady state increase in offered load has been injected into the network. This makes an argument that the act of protection against loss has contributed to additional pressures leading to congestion, which in turn helps trigger packet loss. In addition, by using a ratio of 10:3, the source (or some proxy) must "hold" all 10 packets in order to construct the three FEC packets. This contributes to the end-to-end delay of the packets, as well as minor bursts of load, in addition to changes in jitter.
在前一种情况下，从一组原始数据分组构造附加FEC数据分组并将其插入到端到端流中。根据使用的算法，这些FEC数据包可以重建网络丢失的一个或多个原始数据集。示例可以是10:3比率的形式，其中10个原始分组用于生成三个额外的FEC分组。因此，如果网络丢失30%或更少的数据包，那么FEC方案将能够补偿该丢失。这种方法的缺点是，为了补偿损失，向网络中注入了提供负载的稳态增加。这就提出了一个论点，即防止丢失的行为造成了导致拥塞的额外压力，而拥塞反过来又有助于触发数据包丢失。此外，通过使用10:3的比率，源（或某些代理）必须“持有”所有10个数据包，以便构造三个FEC数据包。除了抖动的变化外，这还导致了数据包的端到端延迟以及较小的负载突发。
The other form of fault tolerance we discuss involves the use of redundant transmissions. By this we mean the case in which an original data packet is followed by one or more redundant packets. At first glance, this would appear to be even less friendly to the network than that of adding FEC packets. However, the encodings of the redundant packets can be of a different type (or even transcoded into a lower quality) that produce redundant data packets that are significantly smaller than the original packet.
我们讨论的另一种容错形式涉及使用冗余传输。这里我们指的是原始数据包后面跟着一个或多个冗余数据包的情况。乍一看，这似乎比添加FEC数据包对网络更不友好。然而，冗余分组的编码可以是不同类型（或者甚至转码为较低质量），其产生明显小于原始分组的冗余数据分组。
Two RFCs [22, 23] have been produced that define RTP payloads for FEC and redundant audio data. An implementation example of a redundant audio application can be found in [13]. We note that both FEC and redundant transmissions can be viewed as rather specific, and to a degree tangential, solutions regarding packet loss and emergency
已经产生了两个RFC[22,23]，它们定义了FEC和冗余音频数据的RTP有效载荷。冗余音频应用程序的实现示例见[13]。我们注意到，FEC和冗余传输都可以被视为关于数据包丢失和紧急情况的非常具体的、在一定程度上是相切的解决方案
communications. Hence, these topics are placed under the category of value-added objectives.
通讯。因此，这些主题属于增值目标的范畴。
There are various scenarios in which IP telephony can be realized, each of which can imply a unique set of functional requirements that may include just a subset of those listed above. We acknowledge that a scenario may exist whose functional requirements are not listed above. Our intention is not to consider every possible scenario by which support for emergency related IP telephony can be realized. Rather, we narrow our scope using a single guideline; we assume there is a signaling and data interaction between the PSTN and the IP network with respect to supporting emergency-related telephony traffic. We stress that this does not preclude an IP-only end-to-end model, but rather the inclusion of the PSTN expands the problem space and includes the current dominant form of voice communication.
可以实现IP电话的场景有很多种，每种场景都意味着一组独特的功能需求，可能只包括上面列出的功能需求的子集。我们承认可能存在上述功能需求未列出的场景。我们的目的不是考虑支持急诊科IP电话的每一种可能的情景。相反，我们使用单一的指导方针来缩小我们的范围；我们假设PSTN和IP网络之间存在信令和数据交互，以支持与紧急情况相关的电话业务。我们强调，这并不排除仅限IP的端到端模式，而是PSTN的加入扩大了问题空间，并包括当前主要的语音通信形式。
Note: as stated in Section 1.2, [32] provides a more extensive set of scenarios in which IP telephony can be deployed. Our selected set below is only meant to provide a couple of examples of how the protocols and capabilities presented in Section 3 can play a role.
注：如第1.2节所述，[32]提供了一组更广泛的场景，在这些场景中可以部署IP电话。我们在下面选择的一组只是为了提供第3节中介绍的协议和功能如何发挥作用的几个示例。
This scenario is a direct reflection of the evolution of the PSTN. Specifically, we refer to the case in which data networks have emerged in various degrees as a backbone infrastructure connecting PSTN switches at its edges. This scenario represents a single isolated IP administrative domain that has no directly adjacent IP domains connected to it. We show an example of this scenario below in Figure 1. In this example, we show two types of telephony carriers. One is the legacy carrier, whose infrastructure retains the classic switching architecture attributed to the PSTN. The other is the next generation carrier, which uses a data network (e.g., IP) as its core infrastructure, and Signaling Gateways at its edges. These gateways "speak" SS7 externally with peering carriers, and another protocol (e.g., SIP) internally, which rides on top of the IP infrastructure.
这种情况直接反映了PSTN的发展。具体地说，我们指的是数据网络在不同程度上已成为连接其边缘PSTN交换机的主干基础设施的情况。此场景表示一个独立的IP管理域，该域没有直接连接到它的相邻IP域。我们在下面的图1中展示了该场景的一个示例。在这个例子中，我们展示了两种类型的电话载波。一个是传统运营商，其基础设施保留了PSTN的经典交换体系结构。另一个是下一代运营商，它使用数据网络（如IP）作为其核心基础设施，并在其边缘使用信令网关。这些网关在外部通过对等载波“讲”SS7，在内部通过IP基础设施之上的另一个协议（如SIP）讲。
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
SW - Telco Switch, SG - Signaling Gateway
SW-电信交换机，SG-信令网关
Figure 1
图1
The significant aspect of this scenario is that all the resources f each IP "island" falls within a given administrative authority. Hence, there is not a problem in retaining PSTN type QoS for voice traffic (data and signaling) exiting the IP network. Thus, the need for support of mechanisms like diff-serv in the presence of overprovisioning, and an expansion of the defined set of Per-Hop Behaviors, is reduced under this scenario.
此场景的重要方面是，每个IP“岛”的所有资源都属于给定的管理权限。因此，在为退出IP网络的语音业务（数据和信令）保留PSTN类型的QoS方面不存在问题。因此，在这种情况下，在存在过度提供的情况下，对诸如diff-serv之类的机制的支持的需要以及对已定义的每跳行为集的扩展减少了。
Another function that has little or no importance within the closed IP environment of Figure 1 is that of IP security. The fact that each administrative domain peers with each other as part of the PSTN, means that existing security, in the form of Personal Identification Number (PIN) authentication (under the context of telephony infrastructure protection), is the default scope of security. We do not claim that the reliance on a PIN-based security system is highly secure or even desirable. But, we use this system as a default mechanism in order to avoid placing additional requirements on existing authorized emergency telephony systems.
在图1的封闭IP环境中，另一个几乎不重要或根本不重要的功能是IP安全。每个管理域作为PSTN的一部分相互对等这一事实意味着，以个人身份号码（PIN）身份验证形式存在的安全性（在电话基础设施保护的背景下）是默认的安全范围。我们并不认为依赖基于PIN的安全系统是高度安全的，甚至是不可取的。但是，我们使用此系统作为默认机制，以避免对现有授权紧急电话系统提出额外要求。
We view the scenario of multiple IP administrative domains as a superset of the previous scenario. Specifically, we retain the notion that the IP telephony system peers with the existing PSTN. In addition, segments (i.e., portions of the Internet) may exchange signaling with other IP administrative domains via non-PSTN signaling protocols like SIP.
我们将多个IP管理域的场景视为前一个场景的超集。具体而言，我们保留IP电话系统与现有PSTN对等的概念。此外，网段（即，因特网的部分）可经由诸如SIP的非PSTN信令协议与其他IP管理域交换信令。
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
SW - Telco Switch SG - Signaling Gateway
SW-电信交换机SG-信令网关
Figure 2
图2
Given multiple IP domains, and the presumption that SLAs relating to ETS traffic may exist between them, the need for something like diff-serv grows with respect to being able to distinguish the emergency related traffic from other types of traffic. In addition, IP security becomes more important between domains in order to ensure that the act of distinguishing ETS-type traffic is indeed valid for the given source.
考虑到多个IP域，并且假定它们之间可能存在与ETS通信量相关的SLA，因此，对于区分紧急相关通信量与其他类型通信量的需求越来越大。此外，IP安全在域之间变得更加重要，以确保区分ETS类型流量的行为对给定源确实有效。
We conclude this section by mentioning a complementary work in progress in providing ISUP transparency across SS7-SIP interworking [33]. The objective of this effort is to access services in the SIP network and yet maintain transparency of end-to-end PSTN services.
在本节结束时，我们提到了在SS7-SIP互通中提供ISUP透明度的补充工作[33]。这项工作的目标是访问SIP网络中的服务，同时保持端到端PSTN服务的透明度。
Not all services are mapped (as per the design goals of [33]), so we anticipate the need for an additional document to specify the mapping between new SIP labels and existing PSTN code points like NS/EP and MLPP.
并非所有服务都映射（根据[33]的设计目标），因此我们预计需要额外的文档来指定新SIP标签与现有PSTN代码点（如NS/EP和MLPP）之间的映射。
Information on this topic is presented in sections 2 and 4.
第2节和第4节介绍了有关此主题的信息。
[1] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[1] Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[3] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[3] Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[4] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[5] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[5] Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[6] Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[7] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[8] Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[9] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[9] Sharma，V.和F.Hellstrand，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[10] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[10] Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[11] 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.
[11] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[12] ANSI, "Signaling System No. 7(SS7), High Probability of Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999).
[12] ANSI，“第7号信号系统（SS7），高完工概率（HPC）网络能力”，ANSI T1.631-1993，（R1999）。
[13] Robust Audio Tool (RAT): http://www-
mice.cs.ucl.ac.uk/multimedia/software/rat
[13] Robust Audio Tool (RAT): http://www-
mice.cs.ucl.ac.uk/multimedia/software/rat
[14] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[14] Schulzrinne，H.，“会话启动协议（SIP）的资源优先级机制要求”，RFC 3487，2003年2月。
[15] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[15] Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[16] 达勒姆，D.，博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.，和A.萨斯特里，“共同开放政策服务协议”，RFC 2748，2000年1月。
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[17] Rosenberg，J.和H.Schulzrinne，“IP电话路由框架”，RFC 28712000年6月。
[18] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[18] Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[19] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990.
[19] 国际电联，“多级优先和抢占服务”，国际电联，建议，I.255.3，1990年7月。
[20] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[20] Rosenberg，J.，Salama，H.，和M.Squire，“IP电话路由（TRIP）”，RFC 3219，2002年1月。
[21] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[21] Groves，C.，Pantaleo，M.，Anderson，T.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
[22] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[22] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113- 2000, 2000.
[24] ANSI，“第7号信令系统，ISDN用户部分”，ANSI T1.113-20002000。
[25] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002
[25] “国际紧急优惠计划（IEPS）的说明”，ITU-T建议E.106，2002年3月
[26] Carlberg, K., "The Classifier Extension Header for RTP", Work In Progress, October 2001.
[26] Carlberg，K.，“RTP的分类器扩展标题”，正在进行的工作，2001年10月。
[27] National Communications System: http://www.ncs.gov
[27] National Communications System: http://www.ncs.gov
[28] Bansal, R., Ravikanth, R., "Performance Measures for Voice on
IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-
voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997
[28] Bansal, R., Ravikanth, R., "Performance Measures for Voice on
IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-
voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997
[29] Hardman, V., et al, "Reliable Audio for Use over the Internet", Proceedings, INET'95, Aug, 1995.
[29] Hardman，V.等人，“互联网上使用的可靠音频”，会议记录，1995年8月。
[30] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[30] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[31] "Service Class Designations for H.323 Calls", ITU Recommendation H.460.4, November, 2002.
[31] “H.323呼叫的服务等级指定”，国际电联建议H.460.42002年11月。
[32] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[32] Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[33] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[33] Vemuri，A.和J.Peterson，“电话会话启动协议（SIP-T）：上下文和体系结构”，BCP 63，RFC 3372，2002年9月。
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003.
[34] Polk，J.，“互联网应急准备（IEPREP）电话拓扑术语”，RFC 3523，2003年4月。
[35] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[35] Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的一般要求”，RFC 3689，2004年2月。
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[36] Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的IP电话要求”，RFC 36902004年2月。
[37] Meyers, D., "Some Thoughts on CoS and Backbone Networks" http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF Presentation: IEPREP, Dec, 2002.
[37] Meyers，D.，“关于CoS和骨干网络的一些思考”http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF演示：IEPREP，2002年12月。
[38] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[38] Huston，G.“因特网域间路由评论”，RFC 3221，2001年12月。
[39] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[39] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[40] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[40] Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[41] ITU, "Gateway Control Protocol", Version 3, ITU, September, 2005.
[41] 国际电联，“网关控制协议”，第3版，国际电联，2005年9月。
[42] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B., and J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 2000.
[42] Cuervo，F.，Greene，N.，Huitema，C.，Rayhan，A.，Rosen，B.，和J.Segers，“Megaco协议版本0.8”，RFC 28852000年8月。
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
[43] Taylor，T.，“Megaco勘误表”，RFC 2886，2000年8月。
Appendix A: Government Telephone Preference Scheme (GTPS)
附录A：政府电话优惠计划（GTPS）
This framework document uses the T1.631 and ITU IEPS standard as a target model for defining a framework for supporting authorized emergency-related communication within the context of IP telephony. We also use GETS as a helpful model from which to draw experience. We take this position because of the various areas that must be considered; from the application layer to the (inter)network layer, in addition to policy, security (authorized access), and traffic engineering.
本框架文件使用T1.631和ITU IEPS标准作为目标模型，用于定义在IP电话环境下支持授权紧急相关通信的框架。我们还使用GETS作为一个有用的模型，从中汲取经验。我们采取这一立场是因为必须考虑的各个方面；从应用层到（内部）网络层，以及策略、安全（授权访问）和流量工程。
The U.K. has a different type of authorized use of telephony services, referred to as the Government Telephone Preference Scheme (GTPS). At present, GTPS only applies to a subset of the local loop lines within the UK. The lines are divided into Categories 1, 2, and 3. The first two categories involve authorized personnel involved in emergencies such as natural disasters. Category 3 identifies the general public. Priority marks, via C7/NUP, are used to bypass call-gapping for a given Category. The authority to activate GTPS has been extended to either a central or delegated authority.
英国有不同类型的授权使用电话服务，称为政府电话优惠计划（GTPS）。目前，GTPS仅适用于英国境内局部环线的一个子集。这些线分为类别1、2和3。前两类涉及涉及自然灾害等紧急情况的授权人员。第3类识别一般公众。通过C7/NUP的优先级标记用于绕过给定类别的调用间隙。激活GTP的权限已扩展至中央或委托权限。
The design of the current GTPS, with its designation of preference based on physical static devices, precludes the need for several aspects presented in this document. However, one component that can have a direct correlation is the labeling capability of the proposed Resource Priority extension to SIP. A new label mechanism for SIP could allow a transparent interoperation between IP telephony and the U.K. PSTN that supports GTPS.
当前GTP的设计及其基于物理静态装置的优选设计排除了本文件中所述几个方面的需要。然而，一个可能具有直接相关性的组件是所提议的SIP资源优先级扩展的标记能力。一种新的SIP标签机制可以允许IP电话和支持GTPS的英国PSTN之间的透明互操作。
Appendix B: Related Standards Work
附录B：相关标准工作
The process of defining various labels to distinguish calls has been, and continues to be, pursued in other standards groups. As mentioned in Section 1.1.1, the ANSI T1S1 group has previously defined a label in the SS7 ISUP Initial Address Message. This single label or value is referred to as the National Security and Emergency Preparedness (NS/EP) indicator and is part of the T1.631 standard. The following subsections presents a snapshot of parallel, on-going efforts in various standards groups.
定义各种标签以区分呼叫的过程已经并将继续在其他标准组中进行。如第1.1.1节所述，ANSI T1S1组先前在SS7 ISUP初始地址消息中定义了一个标签。该单一标签或值称为国家安全和应急准备（NS/EP）指标，是T1.631标准的一部分。以下小节简要介绍了各种标准组中正在进行的并行工作。
It is important to note that the recent activity in other groups have gravitated to defining 5 labels or levels of priority. The impact of this approach is minimal in relation to this ETS framework document because it simply generates a need to define a set of corresponding labels for the resource priority header of SIP.
重要的是要注意到，其他群体最近的活动已被吸引到定义5个标签或优先级别。这种方法对本ETS框架文档的影响最小，因为它只需要为SIP的资源优先级头定义一组相应的标签。
Study Group 16 (SG16) of the ITU is responsible for studies relating to multimedia service definition and multimedia systems, including protocols and signal processing.
国际电联第16研究小组（SG16）负责有关多媒体服务定义和多媒体系统的研究，包括协议和信号处理。
A contribution [31] has been accepted by this group that adds a Priority Class parameter to the call establishment messages of H.323. This class is further divided into two parts; one for Priority Value and the other is a Priority Extension for indicating subclasses. It is this former part that roughly corresponds to the labels transported via the Resource Priority field for SIP [14].
该组接受了一个贡献[31]，该贡献向H.323的呼叫建立消息中添加了一个优先级类参数。这门课又分为两部分；一个表示优先级值，另一个表示子类的优先级扩展。前一部分大致对应于通过SIP的资源优先级字段传输的标签[14]。
The draft recommendation advocates defining PriorityClass information that would be carried in the GenericData parameter in the H323-UU-PDU or RAS messages. The GenericData parameter contains PriorityClassGenericData. The PriorityClassInfo of the PriorityClassGenericData contains the Priority and Priority Extension fields.
建议草案主张定义H323-UU-PDU或RAS消息中GenericData参数中携带的PriorityClass信息。GenericData参数包含PriorityClassGenericData。PriorityClassGenericData的PriorityClassInfo包含优先级和优先级扩展字段。
At present, 4 levels have been defined for the Priority Value part of the Priority Class parameter: Normal, High, Emergency-Public, Emergency-Authorized. An additional 8-bit priority extension has been defined to provide for subclasses of service at each priority.
目前，优先级等级参数的优先级值部分定义了4个级别：正常、高、紧急公共、紧急授权。另外定义了一个8位优先级扩展，以提供每个优先级的服务子类。
The suggested ASN.1 definition of the service class is the following:
建议的ASN.1服务类定义如下：
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::=
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::=
BEGIN IMPORTS ClearToken, CryptoToken FROM H235-SECURITY-MESSAGES;
BEGIN从H235-SECURITY-MESSAGES导入ClearToken、Cryptoken；
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
priorityExtension INTEGER (0..255) OPTIONAL,
优先级扩展整数（0..255）可选，
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE
{
priorityUnavailable NULL,
priorityUnauthorized NULL,
priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm
...
}
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE
{
priorityUnavailable NULL,
priorityUnauthorized NULL,
priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm
...
}
The advantage of using the GenericData parameter is that an existing parameter is used, as opposed to defining a new parameter and causing subsequent changes in existing H.323/H.225 documents.
使用GenericData参数的优点是使用现有参数，而不是定义新参数并导致现有H.323/H.225文档中的后续更改。
Acknowledgements
致谢
The authors would like to acknowledge the helpful comments, opinions, and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran Atkinson as well as those comments received from the IEPS and IEPREP mailing lists. Additional thanks to Peter Walker of Oftel for private discussions on the operation of GTPS, and Gary Thom on clarifications of the SG16 draft contribution.
作者希望感谢Stu Goldman、James Polk、Dennis Berg和Ran Atkinson的有益评论、意见和澄清，以及从IEPS和IEPREP邮件列表收到的评论。还要感谢Oftel的彼得·沃克（Peter Walker）就GTP的运作进行了私人讨论，以及加里·汤姆（Gary Thom）对SG16草案贡献的澄清。
Authors' Addresses
作者地址
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
肯卡尔堡大学学院伦敦计算机科学系伦敦高尔街，WC1E 6BT英国
EMail: k.carlberg@cs.ucl.ac.uk
EMail: k.carlberg@cs.ucl.ac.uk
Ian Brown University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
伊恩·布朗大学学院伦敦计算机科学系伦敦高尔街，WC1E 6BT英国
EMail: I.Brown@cs.ucl.ac.uk
EMail: I.Brown@cs.ucl.ac.uk
Cory Beard University of Missouri-Kansas City Division of Computer Science Electrical Engineering 5100 Rockhill Road Kansas City, MO 64110-2499 USA
科丽胡尔德密苏里堪萨斯大学堪萨斯市计算机科学工程系堪萨斯市罗克山路5100号美国MO 64 110—2499
EMail: BeardC@umkc.edu
EMail: BeardC@umkc.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。