RFC3690 日本語訳
3690 IP Telephony Requirements for Emergency Telecommunication Service(ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT=13919 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Carlberg Request for Comments: 3690 UCL Category: Informational R. Atkinson Extreme Networks February 2004
Carlbergがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3690年のUCLカテゴリ: 情報のR.アトキンソン極端は2004年2月をネットワークでつなぎます。
IP Telephony Requirements for Emergency Telecommunication Service (ETS)
非常時の電気通信サービスのためのIP電話要件(エッツ)
Status of this Memo
この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.
Copyright(C)インターネット協会(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電話技術の文脈の中のEmergency Telecommunications Service(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電話、およびワイヤレスのパーソナルDigitalを通してAssistants(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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
Carlberg & Atkinson Informational [Page 1] RFC 3690 ETS Telephony Requirements February 2004
[1ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
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]などのこれらの規格のいくつかが非常時のコミュニケーションのためにSignaling System7(SS7)ネットワークで特定のインディケータかラベルを定義します。 サービスを織り込むことを達成するためにハイブリッド回路網の向こう側のじっと見ることを達成する(IPと他のタイプのPublic Switched Telephone Networkによって実感されたそれなどのネットワークの間で交信するネットワーク)ためにある要件を定義しなければなりません。
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]はEmergency Telecommunications Service(ETS)をサポートするという1セットの一般的なシステム要求を定義しました。 このドキュメントはIP電話技術(これが終わりから終わりに対する応用層サービスの文脈の中でIP電話技術を見ると記録する注意)の特定の文脈の中のETSのサポートを達成するという追加システム要求を定義します。 要件のソリューションは定義されません。 ドキュメントはプロトコル増進か仕様を指定しません。
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](Session Initiationプロトコル(SIP)のためのResource Priority MechanismsのためのRequirements)がこのドキュメントとの何らかのオーバラップを共有するRFCであることに注意してください。 しかしながら、ETSに関連して、[4]だけがSIPに申し込んで、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が電話関連のゲートウェイか電話関連のサービスのどちらかを配布するのを強制できません。 ビジネス契約、例えばサービス・レベル・アグリーメント(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に適用されません。
Carlberg & Atkinson Informational [Page 2] RFC 3690 ETS Telephony Requirements February 2004
[2ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
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.
このセクションの要件はインターネットを利用する電話サービスに使用されるようにTelephony Signalingだけに関連します。 それらは[3]で指定された一般的な要件への拡大です。 以下の要件は明らかにDifferentiated ServicesかIntegrated Servicesなどの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) ラベルを運ぶ能力は様々なタイプと数のラベルを支えるのにおいて広げることができるに違いありません。 今日現存する様々なラベリング規格を考えて、ただ一つの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) 電話シグナリングラベルSHOULDには、様々な非常時の関連するラベル/印が他の電話に基づいているネットワークに使用されているマッピングがあります、Public Switched Telephone Network(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がラベルをタイプすると認めるために明確に適所にあるゲートウェイとstatefulプロキシの応用層メカニズムは「最もよく利用可能な」サービスをサポートすることができなければなりません(これはたぶんベストエフォート型であるより良いとして実感されるでしょう)。 これらのラベルはデータ(すなわち、運搬人)通信か呼び出し完成に使用されるシグナリングトラフィックの応用層ヘッダーに存在するかもしれません。
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%に達するかもしれません。 また、ローカルの方針は決定するのにおいて中古ですが、ベストエフォート型であるより良いのが、特定のラベル(または、ラベルのセットを関係づける)に適用されることであるということであるに違いありません。
Carlberg & Atkinson Informational [Page 3] RFC 3690 ETS Telephony Requirements February 2004
[3ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
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がラベルをタイプすると認めない応用層メカニズムはこの要件を受けることがありません。
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の上の政府Emergency Telecommunications Service(GETS)の経験は、非常時の関連のコミュニケーションを容易にするのを助けるために代替パスに関するユーティリティを目的地に案内しました。 インターネットの見解から、このユーティリティは、より限られた利益を達成して、持っているのは難しいかもしれません。 PSTNと異なって、インターネットはIPパケットにダイナミックルーティングを使用します。PSTNは呼び出しセットアップ段階の間、固定経路を作成します。 このダイナミックルーティング能力で、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ラベル)にかかわるかもしれません。
Carlberg & Atkinson Informational [Page 4] RFC 3690 ETS Telephony Requirements February 2004
[4ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
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だけ、非普通のLabels(すなわち、デフォルトのベストエフォート型サービスを変更するかもしれないラベル)を作成できてください。 ラベルSHOULDは強い終わりから終わりに. 最終的にラベルがオペレータによって作用されると予想される場合における受信されたメッセージかトランスミッションのときに窃盗を防止するためにラベルを認証するSHOULDが能力を持っているこれらのオペレータを電話技術システムを通した彼らのトランスミッションの間の保全に提供するためにサービスについてメカニズムに関連づけられて、サービス(例えば、どんな限りある資源も消費する権限のないユーザによる)の否定の危険を減少させます。
Security is also discussed in the general requirements of [3], which applies to section 3 above.
また、[3]の一般的な要件でセキュリティについて議論します。([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.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[3] Carlberg, K. and R. Atkinson, "General System Requirements for Emergency Telecommunications Service", RFC 3689, February 2004.
[3]CarlbergとK.とR.アトキンソン、「非常時のテレコムサービスのための一般システム要求」、RFC3689、2004年2月。
[4] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[4]Schulzrinne、H.、「セッション開始プロトコル(一口)のためのリソース優先権メカニズムのための要件」、RFC3487、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。
Carlberg & Atkinson Informational [Page 5] RFC 3690 ETS Telephony Requirements February 2004
[5ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
7. Authors' Addresses
7. 作者のアドレス
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
ガウアー・ストリートロンドン、ケンCarlbergユニバーシティ・カレッジロンドンコンピュータサイエンス学部WC1E 6BTイギリス
EMail: k.carlberg@cs.ucl.ac.uk
メール: k.carlberg@cs.ucl.ac.uk
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
アトキンソン極端なネットワーク3585モンロー・通りサンタクララ、カリフォルニア95051米国を経営していました。
EMail: rja@extremenetworks.com
メール: rja@extremenetworks.com
Carlberg & Atkinson Informational [Page 6] RFC 3690 ETS Telephony Requirements February 2004
[6ページ]RFC3690ETS電話要件2004年2月の情報のCarlbergとアトキンソン
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Carlberg & Atkinson Informational [Page 7]
CarlbergとアトキンソンInformationalです。[7ページ]
一覧
スポンサーリンク