Network Working Group K. Carlberg
Request for Comments: 3690 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
Network Working Group K. Carlberg
Request for Comments: 3690 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
IP Telephony Requirements for Emergency Telecommunication Service (ETS)
应急电信服务（ETS）的IP电话要求
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document.
本文件列出了在IP电话环境下支持紧急电信服务（ETS）的要求清单。它是RFC 3689中提出的一般要求的扩展。本文件未提供这些要求的解决方案。
Effective telecommunications capabilities can be imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen unexpectedly, at any time or place. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless Personal Digital Assistants (PDAs). The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.
有效的电信能力对于促进飓风、洪水、地震和恐怖袭击等严重灾害事件的立即恢复行动至关重要。灾难可能在任何时间或地点意外发生。对恢复操作的快速响应要求立即访问手头的任何公共电信功能。这些功能包括：通过在线终端、IP电话和无线个人数字助理（PDA）的传统电话、手机和互联网接入。商业电信基础设施正在迅速演变为基于互联网的技术。因此，互联网社区需要考虑如何能够最好地支持急诊科管理和恢复操作。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
Standards have been developed by other standards bodies concerning emergency communications. As discussed in [3], some of these standards, such as T1.631 [5], define specific indicators or labels for emergency communications in Signaling System 7 (SS7) networks. Certain requirements must be defined in order to achieve peering across hybrid networks (networks that communicate between IP and other types of networks, such as that realized by the Public Switched Telephone Network) in order to achieve an interworking of services.
其他标准机构已经制定了有关应急通信的标准。如[3]所述，其中一些标准（如T1.631[5]）定义了信号系统7（SS7）网络中紧急通信的特定指示器或标签。必须定义某些要求，以便在混合网络（IP和其他类型网络之间通信的网络，如公共交换电话网络实现的网络）之间实现对等，以便实现服务的互通。
[3] has defined a set of general system requirements to support Emergency Telecommunications Service (ETS). This document defines an additional set of system requirements to achieve support for ETS within the specific context of IP telephony (note that this document views IP telephony within the context of an end-to-end application layer service). Solutions to requirements are not defined. The document does not specify protocol enhancements or specifications.
[3] 定义了一套通用系统要求，以支持紧急电信服务（ETS）。本文档定义了一组额外的系统要求，以在IP电话的特定上下文中实现对ETS的支持（注意，本文档在端到端应用层服务的上下文中查看IP电话）。未定义需求的解决方案。本文档未指定协议增强功能或规范。
Note that [4], Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP), is an RFC that shares some overlap with this document. However, [4] only applies to SIP and is not meant to be applied to a more general perspective of IP telephony as it relates to ETS.
请注意，会话启动协议（SIP）的资源优先级机制要求[4]是一个RFC，与本文档有一些重叠。然而，[4]仅适用于SIP，并不意味着应用于IP电话的更一般的视角，因为它与ETS有关。
An item that is not in scope of this document is mandating acceptance and support of the requirements presented in this document. The IETF does not mandate requirements or capabilities to independent networks that comprise the Internet. As an example, Internet Service Providers (ISP) may choose not to operate any telephony-related gateways or services. The IETF cannot and does not mandate that an ISP deploy either telephony-related gateways or telephony-related services. There is an expectation that business contracts, for example Service Level Agreements (SLA), will be used to satisfy those following requirements that apply to service providers. Absence of an SLA implies best effort service is provided.
不在本文件范围内的项目要求接受和支持本文件中提出的要求。IETF不强制要求构成互联网的独立网络具备要求或能力。例如，互联网服务提供商（ISP）可以选择不运营任何与电话相关的网关或服务。IETF不能也不要求ISP部署电话相关网关或电话相关服务。人们期望业务合同（例如服务级别协议（SLA））将用于满足以下适用于服务提供商的要求。缺少SLA意味着提供了尽力而为的服务。
It is assumed that some ISPs will choose to offer ETS services and that other carriers will choose not to offer ETS services. These requirements do not apply to ISPs that have chosen not to offer ETS services.
假设一些ISP将选择提供ETS服务，而其他运营商将选择不提供ETS服务。这些要求不适用于选择不提供ETS服务的ISP。
The requirements in this section relate only to Telephony Signaling as used in Internet-based telephony services. They are an extension to the general requirements specified in [3]. The following requirements explicitly do not relate to IP-layer mechanisms, such as Differentiated Services or Integrated Services.
本节中的要求仅涉及基于互联网的电话服务中使用的电话信令。它们是[3]中规定的一般要求的扩展。以下要求明确地与IP层机制（如区分服务或集成服务）无关。
1) Telephony signaling applications used with Internet-based telephony MUST be able to carry labels.
1) 与基于互联网的电话一起使用的电话信令应用程序必须能够携带标签。
2) The ability to carry labels MUST be extensible to support various types and numbers of labels. A single binary value will not be sufficient given the various labeling standards in existence today.
2) 携带标签的能力必须是可扩展的，以支持各种类型和数量的标签。考虑到目前存在的各种标签标准，单个二进制值是不够的。
3) Telephony signaling labels SHOULD have a mapping with the various emergency related labels/markings used in other telephony based networks, such as the Public Switched Telephone Network (PSTN). This ensures that a telephone call placed over a hybrid infrastructure (traditional PSTN over some portion(s) of the path, Internet telephony over some other portion(s) of the path) can carry the labels end-to-end with appropriate translation at PSTN/Internet boundaries. Absence of a mapping means that the signaling reverts to a default service (presumably one attributed to the general public).
3) 电话信号标签应与其他基于电话的网络（如公共交换电话网（PSTN））中使用的各种应急相关标签/标记进行映射。这确保了通过混合基础设施（路径某些部分上的传统PSTN，路径某些其他部分上的互联网电话）进行的电话呼叫可以通过PSTN/互联网边界上的适当转换端到端携带标签。缺少映射意味着信令将恢复为默认服务（可能是属于一般公众的服务）。
4) Application layer IP telephony capabilities MUST NOT preclude the ability to do application layer accounting.
4) 应用层IP电话功能不得排除执行应用层记帐的能力。
Accounting is a useful feature in support of billing and tracking down abuse of service. If specific solutions or protocols in support of ETS require accounting, then this will be articulated in future document(s).
会计是支持计费和跟踪服务滥用的有用功能。如果支持ETS的特定解决方案或协议需要核算，则这将在未来的文件中详细说明。
5) Application layer mechanisms in gateways and stateful proxies that are specifically in place to recognize ETS type labels MUST be able to support "best available" service (this will probably be realized as better than best effort). These labels MAY exist in the application layer headers of data (i.e., bearer) traffic or signaling traffic used for call completion.
5) Application layer mechanisms in gateways and stateful proxies that are specifically in place to recognize ETS type labels MUST be able to support "best available" service (this will probably be realized as better than best effort). These labels MAY exist in the application layer headers of data (i.e., bearer) traffic or signaling traffic used for call completion.translate error, please retry
The support for best available service SHOULD focus on probability of forwarding packets. Probability MAY reach 100% depending on the local policy associated with the label. Local policy MUST also be used to determine if better than best effort is to be applied to a specific label (or related set of labels).
对最佳可用服务的支持应侧重于转发数据包的概率。概率可能达到100%，具体取决于与标签相关的本地策略。还必须使用本地策略来确定是否对特定标签（或相关标签集）应用优于最佳努力的方法。
Additional comments on this topic are presented below in item 2 of section 4.
关于这一主题的其他评论见下文第4节第2项。
The above paragraphs MUST be taken in their entirety. The ability to support best available service does not mean that the application layer mechanism is expected to be activated. Further, we do not define the means by which best available service is realized. Application layer mechanisms that do not recognize ETS type labels are not subject to this requirement.
以上各段必须完整理解。支持最佳可用服务的能力并不意味着应用层机制将被激活。此外，我们没有定义实现最佳可用服务的方法。不识别ETS类型标签的应用层机制不受此要求的约束。
This section presents issues that arise in considering solutions for the telephony requirements that have been defined for ETS. This section does not specify solutions, nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues.
本节介绍了在考虑为ETS定义的电话要求解决方案时出现的问题。本节不指定解决方案，也不应与需求混淆。阐明特定服务的更具体需求集的后续文档可能会对以下问题进行说明。
1) Alternate paths
1) 交替路径
Experience with The Government Emergency Telecommunications Service (GETS) over the PSTN has shown the utility of alternate paths to a destination to help facilitate emergency-related communications. From the perspective of the Internet, this utility may be difficult to achieve and have a more limited benefit. Unlike the PSTN, which creates a fixed path during call setup phase, the Internet uses dynamic routing for IP packets. This dynamic routing capability automatically causes IP packets to travel the best current path. The Internet network infrastructure does not have the concept of a "call" or the concept of "call setup", though IP telephony applications might have application layer awareness of calls or the call setup concept.
通过PSTN提供政府紧急电信服务（GETS）的经验表明，通往目的地的备用路径有助于促进与紧急情况相关的通信。从互联网的角度来看，这一效用可能很难实现，而且收益也比较有限。与PSTN不同，PSTN在呼叫设置阶段创建固定路径，Internet对IP数据包使用动态路由。这种动态路由功能会自动使IP数据包沿着当前最佳路径传输。Internet网络基础设施没有“呼叫”或“呼叫设置”的概念，尽管IP电话应用程序可能具有呼叫的应用层感知或呼叫设置概念。
2) Application of Best Available Service
2) 最佳可用服务的应用
In item 5 of section 3 above, we discuss the requirement of supporting best available service. We note that in this document, the scope of that support is constrained to the application layer and flows that traverse that layer. This may involve direct support for the flow containing the ETS type label, or may involve indirect support (e.g., ETS labels in signaling messages that cause an effect on corresponding data or bearer flows).
在上述第3节第5项中，我们讨论了支持最佳可用服务的要求。我们注意到，在本文档中，该支持的范围仅限于应用程序层和穿过该层的流。这可能涉及对包含ETS类型标签的流的直接支持，或者可能涉及间接支持（例如，信令消息中的ETS标签对相应的数据或承载流造成影响）。
It is critical to understand that how the support for best available service can be realized is outside the scope of this document. In addition, the perceived effectiveness of a given approach or implementation is also outside the scope of this document.
了解如何实现对最佳可用服务的支持超出了本文档的范围，这一点至关重要。此外，给定方法或实施的感知有效性也不在本文件范围内。
Only authorized users or operators SHOULD be able to create non-ordinary Labels (i.e., labels that may alter the default best effort service). Labels SHOULD be associated with mechanisms to provide strong end-to-end integrity during their transmission through the telephony systems. Finally, in cases where labels are expected to be acted upon by operators, these operators SHOULD have the capability of authenticating the label on a received message or transmission in order to prevent theft of service and reduce risk of denial of service (e.g., by unauthorized users consuming any limited resources).
只有授权用户或操作员才能创建非普通标签（即，可能会改变默认尽力而为服务的标签）。标签应与在通过电话系统传输期间提供强端到端完整性的机制相关联。最后，如果预计运营商将对标签采取行动，则这些运营商应能够在收到的消息或传输上对标签进行认证，以防止服务被盗并降低拒绝服务的风险（例如，未经授权的用户使用任何有限的资源）。
Security is also discussed in the general requirements of [3], which applies to section 3 above.
[3]的一般要求中也讨论了安全性，适用于上述第3节。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[3] Carlberg, K. and R. Atkinson, "General System Requirements for Emergency Telecommunications Service", RFC 3689, February 2004.
[3] Carlberg，K.和R.Atkinson，“应急电信服务的一般系统要求”，RFC 3689，2004年2月。
[4] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[4] Schulzrinne，H.，“会话启动协议（SIP）的资源优先级机制要求”，RFC 3487，2003年2月。
[5] ANSI, "Signaling System No. 7(SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993.
[5] ANSI，“第7号信号系统（SS7）：高完工概率（HPC）网络能力”，ANSI T1.6311993。
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
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
美国加利福尼亚州圣克拉拉门罗街3585号阿特金森极端网络公司，邮编95051
EMail: rja@extremenetworks.com
EMail: rja@extremenetworks.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。