[要約] RFC 3690は、緊急通信サービス（ETS）のためのIP電話の要件に関する規格です。このRFCの目的は、緊急通信サービスにおけるIP電話の信頼性と機能性を確保するためのガイドラインを提供することです。
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）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
[4]、セッション開始プロトコル（SIP）のリソース優先メカニズムの要件は、このドキュメントと何らかの重複を共有するRFCであることに注意してください。ただし、[4]はSIPにのみ適用され、ETSに関連するIPテレフォニーのより一般的な視点に適用されることを意図したものではありません。
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) ゲートウェイのアプリケーションレイヤーメカニズムと、ETSタイプラベルを認識するために特に整備されているステートフルなプロキシは、「最適な」サービスをサポートできる必要があります（これはおそらく最善の努力よりも優れていると実現するでしょう）。これらのラベルは、データのアプリケーションレイヤーヘッダー（つまり、ベアラー）トラフィックまたは通話完了に使用される信号トラフィックに存在する場合があります。
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とは異なり、インターネットはIPパケットに動的ルーティングを使用します。この動的なルーティング機能により、IPパケットが自動的に最適な現在のパスを移動させます。インターネットネットワークインフラストラクチャには、「通話」または「コールセットアップ」の概念の概念はありませんが、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、「シグナリングシステムNo. 7（SS7）：完了の高い確率（HPC）ネットワーク機能」、ANSI T1.631、1993。
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
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
ランアトキンソンエクストリームネットワーク3585モンローストリートサンタクララ、カリフォルニア95051 USA
EMail: rja@extremenetworks.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。