この文書はRFC3690の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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)
緊急通信サービス（ＥＴＳ）のＩＰ電話要求条件
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.
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.
この文書はＩＰ電話環境での緊急離通信サービス（ＥＴＳ）をサポートする
要求条件のリストを提出します。これはＲＦＣ３６８９で提出される一般的
要求条件の拡張です。これらの要求条件に対する解決策はこの文書で提出さ
れません。
1. Introduction
1. はじめに
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.
効果的通信能力は、ハリケーンや洪水や地震やテロリスト攻撃などの大災害
からの当面の復興事業の促進を命令され得ます。大災害がいつでもどこでも
不意に起こりえます。素早い復興事業には公共通信能力への即刻のアクセス
を必要とします。これらの能力は次を含みます：従来の電話、携帯電話、オ
ンラインの端末やＩＰ電話や無線パーソナル・ディジタルアシスタント（Ｐ
ＤＡ）からのインターネット・アクセス。商用通信基盤はインターネットベー
スの技術で急速に進展しています。それ故に、インターネット共同体はどの
ように緊急管理と復興事業をサポートするか考える必要があります。
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].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と
"OPTIONAL"は[1]で記述されるように解釈します。
1.1. Problem
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]で論じられ
るように、T１.６３１[5]のような、いくつかの標準が信号システム７（ＳＳ
７）ネットワークで信号を送る際の緊急通信固有の表示やラベルを定義しま
す。混成のネットワーク（ＩＰと、公衆交換電話網のような他のネットワー
クの間で通信をするネットワーク）でサービス相互接続を成し遂げるために、
接続の要求条件が定義されなくてはならないことが確かです。
2. Scope
2. 範囲
[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]は緊急通信サービス（ＥＴＳ）をサポートする一般的なシステム要求条件
を定義しました。この文書はＩＰ電話固有のＥＴＳサポートを成し遂げるた
めの追加のシステム要求条件を定義します（この文書がエンドエンドアプリ
ケーションレイヤサービスの意味でＩＰ電話の見る事に注意して下さい）。
要求条件に対する解決策が定義されません。この文書はプロトコル拡張や仕
様を指定しません。
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]がこの文書といくつかの重複のあるＲＦＣであることに注意してく
ださい。しかしながら、[4]はＳＩＰにだけ適用し、ＥＴＳに関連している
ような、ＩＰ電話のより一般的な見地に適用されることを意図しません。
2.1. Out of Scope
2.1. 範囲外
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.
この文書の示す要求条件の受入れとサポートの義務化はこの文書の範囲外で
す。ＩＥＴＦはインターネットを含む他に依存しないネットワークの要求条
件あるいは能力を義務化しません。例えば、インターネット・サービスプロ
バイダ（ＩＳＰ）が電話関連ゲートウェイあるいはサービスを運用しないと
決めるかもしれません。ＩＥＴＦはＩＳＰが電話関連ゲートウェイや電話関
連サービスを配置することを命令できなく、そしてしません。サービスプロ
バイダに適用する以下の要求条件を満たすため、サービスレベル協定（ＳＬ
Ａ）のようなビジネス契約が使われる期待があります。ＳＬＡがないのは最
善努力サービスの用意を暗示します。
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.
あるＩＳＰがＥＴＳサービスを供給することに決めるであろう、そして他の
キャリアがＥＴＳサービスを供給しないことに決めるであろうと想定されま
す。これらの要求条件はＥＴＳサービスを供給しないことに決めたＩＳＰに
当てはまりません。
3. IP Telephony Requirements
3. ＩＰ電話要求条件
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]で指定される一般的要求条件への
拡張です。次の要求条件は明示的に、区分サービスあるいはインテグレイテ
ドサービスのような、ＩＰ層メカニズムに関連していません。
1) Telephony signaling applications used with Internet-based
telephony MUST be able to carry labels.
1) インターネットベースの電話で使われた電話信号アプリケーションはラベ
ルを伴うことができなければなりません(MUST)。
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) ラベルを運ぶ能力は種々なタイプとラベルの数をサポートするために拡張
可能であるに違いありません(MUST)。ひとつのバイナリ値は今日存在する
種々なラベル標準下で十分ではないでしょう。
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) 電話信号ラベルは、公衆交換電話網（ＰＳＴＮ）のような、他の電話で使
われた様々な緊急関連したラベル／マークとの対応をです(SHOULD)。これ
は（伝統的ＰＳＴＮがパスの一部で、インターネットがパスの他の部分の）
混成インフラ上の電話が伝統ＰＳＴＮ／インターネット境界を含むエンド
エンドでのラベル運搬を保障します。対応がなければ信号がデフォルトサー
ビスに逆戻りを意味します（多分属性が一般公衆に戻る）。
4) Application layer IP telephony capabilities MUST NOT preclude the
ability to do application layer accounting.
4) アプリケーションレイヤＩＰ電話能力がアプリケーションレイヤ課金能力
を妨げてはなりません(MUST NOT)。
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).
課金がサービス乱用の追跡と請求処理をサポートする有用な機能です。も
しＥＴＳをサポートする特定の解決策やプロトコルが課金を必要とするな
ら、これは未来の文書で明瞭に表現されるでしょう。
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) ＥＴＳタイプラベルを認識するために置かれたゲートウェイとステートフ
ルプロキシのアプリケーションレイヤ機構は「最良利用」サービスをサポー
トできなければなりません(MUST)（これは恐らく最善努力よりよいと理解
されるでしょう）。これらのラベルはデータ（すなわち、ベアラ）トラ
フィックのアプリケーションレイヤヘッダ、あるいは呼完了のために使う
信号トラヒックに存在するかもしれません(MAY)。
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).
最良利用サービスのサポートはパケット転送の可能性に焦点を合わせるべ
きです(SHOULD)。ラベルと結び付けられたローカルポリシによって確率は
１００％に達するかもしれません(MAY)。ローカルポリシが最善努力より
良いが特定ラベル（あるいはラベル集合）に適用されるかどうか決定する
ために使われなくてはなりません(MUST)。
Additional comments on this topic are presented below in item 2 of
section 4.
このトピックについての追加のコメントが下記の４章の項目２にあります。
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.
上記の段落は全部しなければなりません(MUST)。最良利用サービスをサポー
トする能力はアプリケーション層メカニズムが動作することを期待するこ
とを意味しません。さらに、我々は最良利用サービスの実現手段を定義し
ません。ＥＴＳタイプラベルを認識しないアプリケーション層メカニズム
はこの要求条件を適用されません。
4. Issues
4. 問題
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.
この章はＥＴＳで定義された電話の要求条件に関する解決策を考える際に起
こる問題を示します。この章は解決策は指定せず、要求条件と混同しないで
ください。特定のサービスのためのより特定の要求条件を明言する次の文書
が次の問題を宣言するかもしれません。
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.
ＰＳＴＮ上の政府緊急通信サービス（GETS)の経験から、宛先への代わり
のパス機能が緊急関連通信を容易にすることを示しました。インターネッ
トの観点で、このパス機能を作ることが難しく、より限定された機能を
持つかもしれません。電話設定フェーズで固定パスを作るＰＳＴＮと異
なり、インターネットはＩＰパケットにダイナミックルーティングを使
います。このダイナミックルーティング能力は自動的にＩＰパケットを
現在の最良パスに送ります。ＩＰ電話アプリケーションが呼出しや呼設
定の概念を持っているかもしれないが、インターネットネットワーク基
盤は「呼」の概念や「呼設定」の概念を持っていません。
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).
上記の３章の項目５で、我々は最良利用サービスの要求条件を論じます。
我々はこの文書で、サポート範囲がアプリケーションレイヤとそのレイ
ヤの流れに限定されることを指摘します。これはＥＴＳタイプラベルを
含むフローの直接あるいは間接サポートを伴ってもよいです（例えば、
対応するデータかベアラフローにに対して効果がある信号メッセージの
ＥＴＳラベル）。
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.
最良利用サービスに対するサポートが実現される方法がこの文書の範囲外
であると理解することは重要です。加えて、所定の方法や実行の有効性は
この文書の範囲外です。
5. Security
5. セキュリティ
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).
ただ認可ユーザやオペレータだけが普通でないラベル（すなわち、デフォル
ト最善努力サービスを変えてもよいラベル）を作ることが可能であるべきで
す(SHOULD)。ラベルが電話システムを通しての転送の間の強いエンドエンド
完全性を供給するメカニズムと結び付けられるべきです(SHOULD)。最終的に、
ラベルがオペレータで動作することを期待する場合に、これらのオペレータ
はサービス盗難と（例えば、制限された資源を消費する無許可ユーザーによ
る）サービス妨害の危険を減らすために、受信メッセージや転送でのラベル
を認証する能力を持つべきです(SHOULD)。
Security is also discussed in the general requirements of [3], which
applies to section 3 above.
セキュリティが[3]の一般的要求条件でも論じられ、そしてこれは上記3章に
当てはまります。
6. References
6. 参考文献
6.1. Normative Reference
6.1. 参照する参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
6.2. 有益な参考文献
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] Carlberg, K. and R. Atkinson, "General System Requirements for
Emergency Telecommunications Service", RFC 3689, February 2004.
[4] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[5] ANSI, "Signaling System No. 7(SS7): High Probability of
Completion (HPC) Network Capability", ANSI T1.631, 1993.
7. Authors' Addresses
7. 著者のアドレス
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: k.carlberg@cs.ucl.ac.uk
Ran Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
95051 USA
EMail: rja@extremenetworks.com
8. Full Copyright Statement
8. 著作権表示全文
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００４）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。