この文書はRFC3690の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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.

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)をサポートする
   要求条件のリストを提出します。これはRFC3689で提出される一般的
   要求条件の拡張です。これらの要求条件に対する解決策はこの文書で提出さ
   れません。

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.
   効果的通信能力は、ハリケーンや洪水や地震やテロリスト攻撃などの大災害
   からの当面の復興事業の促進を命令され得ます。大災害がいつでもどこでも
   不意に起こりえます。素早い復興事業には公共通信能力への即刻のアクセス
   を必要とします。これらの能力は次を含みます:従来の電話、携帯電話、オ
   ンラインの端末やIP電話や無線パーソナル・ディジタルアシスタント(P
   DA)からのインターネット・アクセス。商用通信基盤はインターネットベー
   スの技術で急速に進展しています。それ故に、インターネット共同体はどの
   ように緊急管理と復興事業をサポートするか考える必要があります。

   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]で論じられ
   るように、T1.631[5]のような、いくつかの標準が信号システム7(SS
   7)ネットワークで信号を送る際の緊急通信固有の表示やラベルを定義しま
   す。混成のネットワーク(IPと、公衆交換電話網のような他のネットワー
   クの間で通信をするネットワーク)でサービス相互接続を成し遂げるために、
   接続の要求条件が定義されなくてはならないことが確かです。

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]は緊急通信サービス(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にだけ適用し、ETSに関連している
   ような、IP電話のより一般的な見地に適用されることを意図しません。

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.
   この文書の示す要求条件の受入れとサポートの義務化はこの文書の範囲外で
   す。IETFはインターネットを含む他に依存しないネットワークの要求条
   件あるいは能力を義務化しません。例えば、インターネット・サービスプロ
   バイダ(ISP)が電話関連ゲートウェイあるいはサービスを運用しないと
   決めるかもしれません。IETFはISPが電話関連ゲートウェイや電話関
   連サービスを配置することを命令できなく、そしてしません。サービスプロ
   バイダに適用する以下の要求条件を満たすため、サービスレベル協定(SL
   A)のようなビジネス契約が使われる期待があります。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に
   当てはまりません。

3.  IP Telephony Requirements
3.  IP電話要求条件

   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) インターネットベースの電話で使われた電話信号アプリケーションはラベ
      ルを伴うことができなければなりません(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) 電話信号ラベルは、公衆交換電話網(PSTN)のような、他の電話で使
      われた様々な緊急関連したラベル/マークとの対応をです(SHOULD)。これ
      は(伝統的PSTNがパスの一部で、インターネットがパスの他の部分の)
      混成インフラ上の電話が伝統PSTN/インターネット境界を含むエンド
      エンドでのラベル運搬を保障します。対応がなければ信号がデフォルトサー
      ビスに逆戻りを意味します(多分属性が一般公衆に戻る)。

   4) Application layer IP telephony capabilities MUST NOT preclude the
      ability to do application layer accounting.
   4) アプリケーションレイヤIP電話能力がアプリケーションレイヤ課金能力
      を妨げてはなりません(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).
      課金がサービス乱用の追跡と請求処理をサポートする有用な機能です。も
      し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タイプラベルを認識するために置かれたゲートウェイとステートフ
      ルプロキシのアプリケーションレイヤ機構は「最良利用」サービスをサポー
      トできなければなりません(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)。ラベルと結び付けられたローカルポリシによって確率は
      100%に達するかもしれません(MAY)。ローカルポリシが最善努力より
      良いが特定ラベル(あるいはラベル集合)に適用されるかどうか決定する
      ために使われなくてはなりません(MUST)。

      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.
      上記の段落は全部しなければなりません(MUST)。最良利用サービスをサポー
      トする能力はアプリケーション層メカニズムが動作することを期待するこ
      とを意味しません。さらに、我々は最良利用サービスの実現手段を定義し
      ません。ETSタイプラベルを認識しないアプリケーション層メカニズム
      はこの要求条件を適用されません。

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.
   この章は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.
      最良利用サービスに対するサポートが実現される方法がこの文書の範囲外
      であると理解することは重要です。加えて、所定の方法や実行の有効性は
      この文書の範囲外です。

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.
   著作権(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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So