Network Working Group H. Schulzrinne
Request for Comments: 5012 Columbia U.
Category: Informational R. Marshall, Ed.
TCS
January 2008
Requirements for Emergency Context Resolution with
Internet Technologies
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end.
この文書では、用語を定義し、インターネット・プロトコルは、エンドツーエンドを使用しているボイスオーバーIP（VoIP）を使用してパブリックで置かれた緊急呼び出しのコンテキスト解像度と一般的なインターネットマルチメディアシステム、の要件を列挙します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Emergency Services . . . . . . . . . . . . . . . . . . . . 3
3.2. Service Providers . . . . . . . . . . . . . . . . . . . . 3
3.3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Call Routing Entities . . . . . . . . . . . . . . . . . . 5
3.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Identifiers, Numbers, and Dial Strings . . . . . . . . . . 6
3.7. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10
6. Identifying the Caller's Location . . . . . . . . . . . . . . 12
7. Emergency Service Identifier . . . . . . . . . . . . . . . . . 14
8. Mapping Protocol . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Users of both voice-centric (telephone-like) and non-voice services, such as text communication for hearing-disabled users (see [RFC3351] and [toip]), expect to be able to initiate a request for help in case of an emergency.
音声中心（電話など）や、聴覚障害を持つユーザーのためのテキスト通信などの非音声サービス、（[RFC3351]と[TOIP]を参照）の両方のユーザーは、の場合に助けを求める要求を開始できることを期待します緊急事態。
Unfortunately, the existing mechanisms to support emergency calls that have evolved within the public circuit-switched telephone network (PSTN) are not appropriate to handle evolving IP-based voice, text, and real-time multimedia communications. This document outlines the key requirements that IP-based end systems and network elements, such as Session Initiation Protocol (SIP) [RFC3261] proxies, need to satisfy in order to provide emergency call services, which at a minimum, offer the same functionality as existing PSTN services, with the additional overall goal of making emergency calling more robust, less costly to implement, and multimedia-capable.
残念ながら、公衆回線交換電話網（PSTN）の中に進化してきた緊急コールをサポートするために、既存のメカニズムは、IPベースの音声、テキスト、およびリアルタイムのマルチメディア通信を進化扱うことは適切ではありません。この文書では、このようなセッション開始プロトコル（SIP）などの主要な要件IPベースのエンドシステムとネットワーク要素、[RFC3261]プロキシを概説し、最低でも、同じ機能を提供しており、緊急通話サービスを提供するために満たす必要がありますより実装する低コスト、堅牢、およびマルチメディア対応の呼び出し緊急を作るの追加の全体的な目標と、PSTNサービスを既存の。
This document only focuses on end-to-end IP-based calls, i.e., where the emergency call originates from an IP end system and terminates in an IP-capable public safety answering point (PSAP), conveyed entirely over an IP network.
この文書は、緊急呼がIPエンドシステムに由来し、IP対応の公共安全応答ポイント（PSAP）で終端するエンドツーエンドのIPベースのコール、すなわち、に焦点を当てて、IPネットワークを介して完全に搬送されます。
We first define terminology in Section 3. The document then outlines various functional issues that relate to placing an IP-based emergency call, including a description of baseline requirements (Section 5), identification of the emergency caller's location (Section 6), use of a service identifier to declare a call to be an emergency call (Section 7), and finally, the mapping function required to route the call to the appropriate PSAP (Section 8).
我々は、緊急発呼者の場所の識別（第6節）、ドキュメントは、次にベースライン要件（セクション5）の記述を含むIPベースの緊急呼を配置することに関連する様々な機能の問題を、アウトラインの使用を第3の用語を最初に定義します緊急呼（第7節）、およびルート適切なPSAP（セクション8）への呼び出しに必要な最後に、マッピング関数であることが呼び出しを宣言するためのサービス識別子。
The primary purpose of the mapping protocol is to produce a PSAP URI drawn from a preferred set of URI schemes such as SIP or SIPS URIs, based on both location information [RFC4119] and a service identifier in order to facilitate the IP end-to-end completion of an emergency call.
マッピング・プロトコルの主な目的は、IPエンドツーを容易にするために、位置情報[RFC4119]及びサービス識別子の両方に基づいて、例えばSIPまたはSIPS URIのようなURIスキームの好ましいセットから引き出されたPSAPのURIを生成することです緊急通話の終了完了。
Aside from obtaining a PSAP URI, the mapping protocol is useful for obtaining other information as well. There may be a case, for example, where an appropriate emergency number is not known, only the location. The mapping protocol can then return a geographically appropriate emergency number based on the input.
脇PSAP URIを取得するから、マッピング・プロトコルは、他の情報を得るために有用です。適切な緊急番号は、唯一の場所を知らないが、例えば場合、存在してもよいです。マッピングプロトコルは、入力に基づいて、地理的に適切な緊急番号を返すことができます。
Since some PSAPs may not immediately support IP, or because some user equipment (UE) may not initially support emergency service identifiers, it may be necessary to also support emergency service identifiers that utilize less-preferred URI schemes, such as a tel URI in order to complete an emergency call via the PSTN.
いくつかのPSAPは、直ちにIPをサポートしないかもしれない、またはいくつかのユーザ機器（UE）は、最初の緊急サービス識別子をサポートしないかもしれないので、またために、このようなTEL URIとしてあまり好ましいURIスキームを利用する緊急サービス識別子をサポートする必要があるかもしれないのでPSTN経由で緊急コールを完了します。
Identification of the caller, while not incompatible with the requirements for messaging outlined within this document, is considered to be outside the scope of this document.
発呼者の識別は、この文書内概説メッセージングのための要件と互換性がないが、この文書の範囲外であると考えられます。
Location is required for two separate purposes: first, to support the routing of the emergency call to the appropriate PSAP and second, to display the caller's location to the call taker to help in dispatching emergency assistance to the appropriate location.
適切な場所に緊急援助を派遣して支援するために呼び出し係に、発信者の位置を表示するために、適切なPSAPと第二に、緊急コールのルーティングをサポートするために、最初：場所は、2つの別々の目的のために必要とされます。
This latter use, the display of location information to the PSAP, is orthogonal to the mapping protocol, and is outside the scope of this document.
この後者の使用、PSAPへの位置情報の表示は、マッピング・プロトコルに直交であり、この文書の範囲外です。
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 RFC 2119 [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of the mapping protocol, not its implementation or application.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります特に明記しない限り、これらの用語は、マッピングプロトコルの設計に適用される重要な資格ではなく、その実施またはアプリケーションと、RFC 2119 [RFC2119]に記載されているように解釈されます。
Basic emergency service: Basic emergency service allows a caller to reach a PSAP serving its current location, but the PSAP may not be able to determine the identity or geographic location of the caller, except by the call taker asking the caller.
基本的な緊急サービス：基本的な緊急サービスは、発信者は、現在の場所にサービスを提供するPSAPに到達することができますが、PSAPは、発信者を求めて呼び出し受け手による場合を除いて、呼び出し元のIDまたは地理的位置を決定することができない場合があります。
Enhanced emergency service: In enhanced emergency service, the PSAP call taker can determine the caller's current location.
強化された緊急サービス：強化緊急サービスでは、PSAPコール受け手は、発信者の現在位置を決定することができます。
Internet Access Provider (IAP): An organization that provides physical and data link (layer 2) network connectivity to its customers or users, e.g., through digital subscriber lines, cable TV plants, Ethernet, leased lines, or radio frequencies. Examples of such organizations include telecommunication carriers, municipal utilities, larger enterprises with their own network infrastructure, and government organizations, such as the military.
インターネット・アクセス・プロバイダ（IAP）：デジタル加入者回線、ケーブルテレビの植物、イーサネット、専用回線、または無線周波数によって、例えば、顧客やユーザー、物理およびデータリンク（レイヤ2）ネットワーク接続を提供する組織。そのような組織の例としては、軍事などの通信事業者、自治体のユーティリティ、独自のネットワークインフラストラクチャと大企業、および政府機関が含まれます。
Internet Service Provider (ISP): An organization that provides IP network-layer services to its customers or users. This entity may or may not provide the physical-layer and data link (layer-2) connectivity, such as fiber or Ethernet, i.e., it may or may not play the role of an IAP.
インターネットサービスプロバイダ（ISP）：顧客やユーザーにIPネットワークレイヤサービスを提供する組織。このエンティティは、または、そのようなファイバ又はイーサネット（登録商標）として、すなわち、それは、またはしない場合がありIAPの役割を果たしている可能性を物理層とデータリンク（レイヤ2）接続を提供してもしなくてもよいです。
Application Service Provider (ASP): The organization or entity that provides application-layer services, which may include voice (see "Voice Service Provider"). This entity can be a private individual, an enterprise, a government, or a service provider. An ASP is more general than a Voice Service Provider, since emergency calls may use other media beyond voice, including text and video. For a particular user, the ASP may or may not be the same organization as his IAP or ISP.
アプリケーション・サービス・プロバイダ（ASP）：アプリケーション層のサービスを提供する組織や団体、音声を含むこともできる（「音声サービスプロバイダ」を参照）。このエンティティは、民間の個人、企業、政府機関、またはサービスプロバイダになることができます。緊急通話は、テキストやビデオなどの音声以外の他のメディアを使用することができるので、ASPは、音声サービスプロバイダよりも一般的です。特定のユーザーのために、ASPは、あるいは彼のIAPやISPと同じ組織であってもなくてもよいです。
Voice Service Provider (VSP): A specific type of Application Service Provider that provides voice related services based on IP, such as call routing, a SIP URI, or PSTN termination. In this document, unless noted otherwise, any reference to "Voice Service Provider" or "VSP" may be used interchangeably with "Application/Voice Service Provider" or "ASP/VSP".
音声サービスプロバイダ（VSP）：このようなコールルーティング、SIP URI、またはPSTN終端としてIPに基づく音声関連サービスを提供するアプリケーション・サービス・プロバイダの特定のタイプ。特に断りのない限り、本書では、「ボイスサービスプロバイダー」または「VSP」への参照は、「アプリケーション/音声サービスプロバイダー」または「ASP / VSP」と交換可能に使用され得ます。
(Emergency) caller: The term "caller" or "emergency caller" refers to the person placing an emergency call or sending an emergency instant message (IM).
（緊急）、呼び出し元：用語「発信元」または「緊急呼び出し側は」緊急電話をかけるか、緊急インスタントメッセージ（IM）を送信した人を指します。
User Equipment (UE): User equipment is the device or software operated by the caller to place an emergency call. A SIP user agent (UA) is an example of user equipment.
ユーザ装置（UE）：ユーザ装置は、緊急電話をかけるために、発信者が運営するデバイスまたはソフトウェアです。 SIPユーザエージェント（UA）、ユーザ機器の一例です。
Call taker: A call taker is an agent at the PSAP that accepts calls and may dispatch emergency help. Sometimes the functions of call taking and dispatching are handled by different groups of people, but these divisions of labor are not generally visible to the caller and thus do not concern us here.
通話記録係：呼び出し受け手は、呼び出しを受け入れ、緊急援助をディスパッチすることができるPSAPのエージェントです。時にはコール取って、ディスパッチの機能は、人々の異なるグループによって処理されているが、労働者のこれらの部門は、一般的に、発信者には見えないので、ここで私たちを気にしないでください。
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity that invokes the location-to-PSAP URI mapping function, to return an appropriate PSAP URI, or the URI for another ESRP. Client mapping requests could also be performed by a number of entities, including entities that instantiate the SIP proxy role and the SIP user agent client role.
緊急サービスルーティングプロキシ（ESRP）：ESRPは別のESRPに適切なPSAP URI、またはURIを返すように、位置対PSAP URIマッピング関数を呼び出すサポートエンティティのルーティング緊急呼です。クライアントのマッピング要求はまた、SIPプロキシの役割とSIPユーザエージェントクライアントの役割をインスタンス化するエンティティを含むエンティティの数、によって実行することができます。
Public Safety Answering Point (PSAP): A PSAP is a facility where emergency calls are received under the responsibility of a public authority. (This terminology is used by both the European Telecommunications Standards Institute (ETSI), in ETSI SR 002 180, and the National Emergency Number Association (NENA).) In the United Kingdom, PSAPs are called Operator Assistance Centres; in New Zealand, Communications Centres. Within this document, it is assumed, unless stated otherwise, that PSAPs support the receipt of emergency calls over IP, using appropriate application layer protocols, such as SIP for call signaling and RTP for media.
公安は、ポイント（PSAP）の応答：PSAPは、緊急呼び出しが公共機関の責任の下で受信されている施設です。 （この用語は、欧州電気通信標準化機構（ETSI）、ETSIのSR 002 180、国立緊急番号協会（NENA）の両方で使用されている）英国では、のPSAPは、オペレータ支援センターと呼ばれています。ニュージーランドでは、コミュニケーションセンター。特に明記しない限り、この文書内で、のPSAPは、メディアのコールシグナリングとRTPのために、SIPなどの適切なアプリケーション層プロトコルを使用して、IP上緊急呼の受信をサポートすることを、想定されます。
Location: A geographic identification assigned to a region or feature based on a specific coordinate system, or by other precise information such as a street number and name. It can be either a civic or geographic location.
場所：特定の座標系に基づいて、領域または特徴、またはそのような街路番号と名前のような他の正確な情報によって割り当てられた地理的同定。これは、市民や地理的な位置のいずれかになります。
Civic location: A described location based on some reference system, such as jurisdictional region or postal delivery grid. A street address is a common example of a civic location.
シビック場所：いくつかの参照システムに基づいて説明した位置、例えば管轄領域または郵便配達グリッドとして。住所が都市ロケーションの一般的な例です。
Geographic location: A reference to a point that is able to be located, as described by a set of defined coordinates within a geographic coordinate system, such as latitude and longitude within the WGS-84 datum. For example, a 2-D geographic location is defined as an (x,y) coordinate value pair according to the distance north or south of the equator and east or west of the prime meridian.
地理的位置：例えばWGS-84基準内の緯度と経度のような地理座標系内で定義された座標の組によって記載されるように、配置することが可能である点を基準。例えば、2-Dの地理的位置は、本初子午線の赤道及び東または西の距離北または南に応じた値のペアの座標（X、Y）として定義されます。
Location validation: A caller location is considered valid if the civic or geographic location is recognizable within an acceptable location reference system (e.g., United States Postal Address or the WGS-84 datum) and can be mapped to one or more PSAPs. While it is desirable to determine that a location exists, validation may not ensure that such a location exists, but rather may only ensure that the location falls within some range of known values. Location validation ensures that a location is able to be referenced for mapping, but makes no assumption about the association between the caller and the caller's location.
位置検証：発信者の位置は、市民または地理的位置が許容位置参照システム内で認識可能である場合に有効であると考えられる（例えば、米国郵便住所またはWGS-84基準）および1つのまたは複数のPSAPにマッピングすることができます。それは場所が存在することを決定することが望ましいが、検証は、このような場所が存在することを確認しないことがあり、むしろだけ位置が既知の値のある範囲内に収まることを保証することができます。場所の検証は場所をマッピングするために参照することが可能であることを保証しますが、呼び出し元と呼び出し側の位置との間の関連性についての仮定を行いません。
(Emergency) service number: The (emergency) service number is a string of digits used to reach the (emergency) service. The emergency service number is often just called the emergency number. It is the number typically dialed on devices directly connected to the PSTN and the number reserved for emergency calls by national or regional numbering authorities. It only contains the digits 0 through 9, #, and *. The service number may depend on the location of the caller. For example, the general emergency service number in the United States is 911 and the poison control service number is 18002221222. In most cases, the service number and dial string are the same; they may differ in some private phone networks. A service number may be carried in tel URLs [RFC3966], along with a context identifier. In the North American numbering plan, some service numbers are three-digit N11 or service codes, but not all emergency numbers have three digits. A caller may have to dial a service dial string (below) that differs from the service number when using a PBX.
（緊急）サービス番号：（緊急）サービス番号（緊急）サービスに到達するために使用される数字の文字列です。緊急サービス番号は、多くの場合、単に緊急番号と呼ばれています。それは、典型的には、直接PSTNや国または地域のナンバリング当局による緊急通報のために予約番号に接続されたデバイスにダイヤルした番号です。それだけの数字0〜9、＃、および*が含まれています。サービス番号は、発信者の位置に依存してもよいです。例えば、米国では一般的な緊急サービス番号は911で、毒物管理サービス番号が同じで、ほとんどのケースで18002221222.、サービス番号とダイヤルする文字列です。彼らはいくつかのプライベート電話ネットワークに異なる場合があります。サービス番号は、コンテキスト識別子と共に、TEL URLを[RFC3966]に実施することができます。北米番号計画では、いくつかのサービス番号は3桁N11またはサービスコードは、すべてではない緊急番号は3桁の数字を持っています。発信者は、PBXを使用する場合、サービス番号と異なる（下記）サービスダイヤル文字列をダイヤルする必要があります。
(Emergency) service dial string: The service dial string identifies the string of digits that a caller must dial to reach a particular (emergency) service. In devices directly connected to the PSTN, the service dial string is the same as the service number and may thus depend on the location of the caller. However, in private phone networks, such as in PBXs, the service dial string consists of a dialing prefix to reach an outside line, followed by the emergency number. For example, in a hotel, the dial string for emergency services in the United States might be 9911. Dial strings may contain indications of pauses or wait-for-secondary-dial-tone indications. Service dial strings are outside the scope of this document.
（緊急）サービスダイヤル文字列：サービスダイヤル文字列、発信者が特定の（緊急）サービスに到達するためにダイヤルしなければならない数字の文字列を識別します。直接PSTNに接続されたデバイスでは、サービスダイヤル文字列はサービス番号と同じであるので、発信者の位置に依存してもよいです。しかし、そのような構内交換機のようなプライベート電話ネットワークで、サービスダイヤル文字列は、緊急番号に続いて外線に到達するためにダイヤルプレフィックスで構成されています。例えば、ホテルでは、米国での緊急サービスのためのダイヤル文字列は9911.ダイヤル文字列は一時停止の兆候や待ち二次ダイヤルトーン兆候が含まれていてもよいかもしれません。サービスダイヤル文字列は、この文書の範囲外です。
(Emergency) service identifier: The (emergency) service identifier describes the emergency service, independent of the user interface mechanism, the signaling protocol that is used to reach the service, or the caller's geographic location. It is a protocol constant and used within the mapping and signaling protocols. An example is the service URN [RFC5031].
（緊急）サービス識別子（緊急）サービス識別子は、ユーザインターフェース機構とは無関係に、緊急サービス、サービス、または発信者の地理的位置に到達するために使用されるシグナリングプロトコルを記載しています。これは定数とマッピング及びシグナリングプロトコル内で使用されるプロトコルです。例では、サービスURN [RFC5031]です。
(Emergency) service URL: The service URL is a protocol-specific (e.g., SIP) or protocol-agnostic (e.g., im: [RFC3860]) identifier that contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service.
（緊急）サービスURL：サービスのURLは、プロトコル固有である（例えば、SIP）またはプロトコルに依存しない（例えば、IM：[RFC3860]）PSAPまたは他の緊急サービスのアドレスを含む識別子。これは、緊急サービスに到達するために使用される特定のシグナリングまたはデータ転送プロトコルに依存します。
Service URN: A service URN is an implementation of a service identifier, which can be applied to both emergency and non-emergency contexts, e.g., urn:service:sos or urn:service:counseling. Within this document, service URNs are referred to as 'emergency service URNs' [RFC5031].
サービスURN：サービス：SOS又はURN：サービス：カウンセリングサービスURNは、緊急及び非緊急の両方の状況、例えば、骨壷に適用することができるサービス識別子の実装です。この文書の中で、サービスURNのは、「緊急サービスURNの」[RFC5031]と呼ばれています。
Home emergency number: A home emergency number is the emergency number valid at the caller's customary home location, e.g., his permanent residence. The home location may or may not coincide with the service area of the caller's VSP.
ホーム緊急番号：自宅の緊急番号、発信者の慣習ホームの場所、例えば、彼の永住権の有効な緊急番号です。ホームの場所は、または、発信者のVSPのサービスエリアと一致しない場合があります。
Home emergency dial string: A home dial string is the dial string valid at the caller's customary home location, e.g., his permanent residence.
ホーム緊急ダイヤル文字列：ホームダイヤル文字列ダイヤル例えば、発信者の慣習自宅の場所で有効な文字列、彼の永住権です。
Visited emergency number: A visited emergency number is the emergency number valid at the caller's current physical location. We distinguish the visited emergency number if the caller is traveling outside his home region.
緊急番号を訪問：訪問した緊急番号は、発信者の現在の物理的な場所で、有効な緊急番号です。呼び出し側が彼の家の領域外に移動している場合我々は、訪問した緊急番号を区別する。
Visited emergency dial string: A visited emergency dial string is the dial string number valid at the caller's current physical location.
緊急ダイヤル文字列を訪問：訪問した緊急ダイヤル文字列は、呼び出し元の現在の物理的な場所で有効なダイヤル文字列番号です。
Mapping: Mapping is the process of resolving a location to one or more PSAP URIs that directly identify a PSAP, or point to an intermediary that knows about a PSAP and that is designated as responsible for serving that location.
マッピング：マッピングは直接PSAPについて知っており、それは、その場所にサービスを提供する責任として指定され、中間にPSAP、またはポイントを識別する1つのまたは複数のPSAPのURIにロケーションを解決するプロセスです。
Mapping client: A mapping client interacts with the mapping server to learn one or more PSAP URIs for a given location.
マッピングクライアント：マッピング・クライアントは、指定された場所のための一つ以上のPSAP URIを学ぶためにマッピングサーバと対話します。
Mapping protocol: A protocol used to convey the mapping request and response.
マッピングプロトコル：マッピング要求および応答を搬送するために使用されるプロトコル。
Mapping server: The mapping server holds information about the location-to-PSAP URI mapping.
マッピングサーバー：マッピングサーバは、場所・ツー・PSAP URIのマッピングに関する情報を保持しています。
Mapping service: A network service that uses a distributed mapping protocol to perform a mapping between a location and a PSAP, or intermediary that knows about the PSAP, and is used to assist in routing an emergency call.
マッピングサービス、場所及びPSAPまたはPSAP知っている中間との間のマッピングを実行する分散マッピングプロトコルを使用して、緊急コールをルーティングするのを助けるために使用されるネットワークサービス。
In order to support emergency services covering a large physical area, various infrastructure elements are necessary, including Internet Access Providers (IAPs), Application/Voice Service Providers (ASP/VSPs), Emergency Service Routing Proxy (ESRP) providers, mapping service providers, and PSAPs.
大きな物理的領域をカバーする緊急サービスをサポートするために、さまざまなインフラストラクチャ要素は、アプリケーション/音声サービスプロバイダ（ASP /のVSP）、緊急サービスルーティングプロキシ（ESRP）プロバイダ、マッピングサービスプロバイダ、インターネット・アクセス・プロバイダ（IAPに）を含め、必要であり、そして、のPSAP。
This section outlines which entities will be considered in the routing scenarios discussed.
このセクションでは、議論のルーティングシナリオで考慮されるエンティティの概要を説明します。
Location
Information +-----------------+
|(1) |Internet | +-----------+
v |Access | | |
+-----------+ |Provider | | Mapping |
| | | (3) | | Service |
| Emergency |<---+-----------------+-->| |
| Caller | | (2) | +-----------+
| |<---+-------+ | ^
+-----------+ | +----|---------+------+ |
^ | | Location | | |
| | | Information<-+ | |
| +--+--------------+ |(5) | | (6)
| | | | |
| | +-----------v+ | |
| (4) | | | | |
+--------------+--->| ESRP |<--+---+
| | | | |
| | +------------+ |
| | ^ |
| | (7) | | +----+--+
| (8) | +------------>| |
+--------------+----------------------->| PSAP |
| | | |
|Application/ | +----+--+
|Voice |
|Service |
|Provider |
+---------------------+
Figure 1: Framework for Emergency Call Routing
図1：緊急コールルーティングのためのフレームワーク
Figure 1 shows the interaction between the entities involved in the call. There are a number of different deployment choices, as can be easily seen from the figure.
図1は、コールに関与するエンティティ間の相互作用を示します。簡単に図から分かるように、さまざまな展開の選択肢の数があります。
Is the Internet Access Provider also the Application/Voice Service Provider? In the Internet today, the roles of Internet access provider and application/voice service provider are typically provided by different entities. As a consequence, the Application/ Voice Service Provider is typically not able to directly determine the physical location of the emergency caller.
また、インターネットアクセスプロバイダは、アプリケーション/音声サービスプロバイダーですか？インターネット、今日では、インターネットアクセスプロバイダとアプリケーション/音声サービスプロバイダの役割は、一般的に異なるエンティティによって提供されています。その結果、アプリケーション/音声サービスプロバイダは、一般的に、直接、緊急の呼び出し元の物理的な位置を決定することができません。
The overlapping squares in the figure indicate that some functions can be collapsed into a single entity. As an example, the Application/Voice Service Provider might be the same entity as the Internet Access Provider. There is, however, no requirement that this must be the case. Additionally, we consider that end systems might act as their own ASP/VSP, e.g., either for enterprises or for residential users.
図中の重複正方形は、いくつかの機能は、単一のエンティティにまとめることができることを示しています。例として、アプリケーション/音声サービスプロバイダは、インターネットアクセスプロバイダと同じエンティティであるかもしれません。このような場合でなければならないという要件は、しかし、ありません。さらに、当社は、エンドシステムは、例えば、企業のためか、住宅のユーザーのためのいずれか、自分のASP / VSPとしての役割を果たす可能性があることを考えます。
Various potential interactions between the entities depicted in Figure 1 are described below:
図1に示すエンティティ間の種々の潜在的な相互作用は、以下に記載されています。
2. Location information might, however, also be obtained from the Internet Access Provider.
2.位置情報は、しかし、また、インターネットアクセスプロバイダから取得される可能性があります。
3. The emergency caller might need to consult a mapping service to determine the PSAP (or other relevant information) that is appropriate for the physical location of the emergency caller, possibly considering other attributes, such as appropriate language support by the emergency call taker.
3.緊急呼び出し側は、おそらく、このような緊急通報受け手によって適切な言語サポートなどの他の属性を、考慮して、緊急時の呼び出し元の物理的な場所に適切なPSAP（またはその他の関連情報）を決定するマッピング・サービスに相談する必要がある場合があります。
4. The emergency caller might get assistance for emergency call routing by infrastructure elements that are emergency call routing support entities, such as an Emergency Service Routing Proxy (ESRP) in SIP.
4.緊急呼び出し側は、このようなSIPにおける緊急サービスルーティングプロキシ（ESRP）などの緊急コールルーティングをサポートエンティティ、あるインフラストラクチャ要素によってルーティング緊急通話のための支援を得る可能性があります。
5. Location information is used by emergency call routing support entities for subsequent mapping requests.
5.位置情報は、後続のマッピング要求のためのサポートエンティティをルーティング緊急通話で使用されています。
6. Emergency call routing support entities might need to consult a mapping service to determine where to route the emergency call.
サポートエンティティをルーティング6.緊急コールがどこルート緊急コールをするかを決定するためにマッピングサービスに相談する必要がある場合があります。
7. For infrastructure-based emergency call routing (in contrast to UE-based emergency call routing), the emergency call routing support entity needs to forward the call to the PSAP.
7.（UEベースの緊急呼のルーティングとは対照的に）インフラストラクチャベースの緊急呼ルーティングのために、サポートエンティティのルーティング緊急呼をPSAPにコールを転送する必要があります。
8. The emergency caller may interact directly with the PSAP, where the UE invokes mapping, and initiates a connection, without relying on any intermediary emergency call routing support entities.
8.緊急発信者がサポートエンティティのルーティング任意の中間緊急呼に依存することなく、UEは、マッピングを呼び出し、接続を開始PSAPと直接相互作用することができます。
Below, we summarize high-level architectural requirements that guide some of the component requirements detailed later in the document.
以下では、ドキュメントの後半で詳しく説明コンポーネント要件の一部を案内する高レベルのアーキテクチャ要件をまとめます。
Re1. Application/Voice service provider existence: The initiation of an IP-based emergency call SHOULD NOT assume the existence of an Application/Voice Service Provider (ASP/VSP).
RE1。アプリケーション/音声サービスプロバイダの有無：IPベースの緊急呼の開始は、アプリケーション/音声サービス・プロバイダ（ASP / VSP）の存在を仮定するべきではありません。
Motivation: The caller may not have an application/voice service provider. For example, a residence may have its own DNS domain and run its own SIP proxy server for that domain. On a larger scale, a university might provide voice services to its students and staff, but might not be a telecommunication provider.
動機：呼び出し側がアプリケーション/音声サービスプロバイダを持っていないかもしれません。例えば、居住地は、独自のDNSドメインを有していてもよく、そのドメインの独自のSIPプロキシサーバを実行します。大規模に、大学はその学生や職員に音声サービスを提供するかもしれないが、電気通信プロバイダではないかもしれません。
Re2. International applicability: Regional, political, and organizational aspects MUST be considered during the design of protocols and protocol extensions that support IP-based emergency calls.
RE2。国際適用性：地域、政治的、そして組織的な側面は、IPベースの緊急通話をサポートするプロトコルとプロトコル拡張の設計時に考えなければなりません。
Motivation: It must be possible for a device or software developed or purchased in one country to place emergency calls in another country. System components should not be biased towards a particular set of emergency numbers or languages. Also, different countries have evolved different ways of organizing emergency services, e.g., either centralizing them or having smaller regional subdivisions, such as the United States or municipalities, handle emergency calls within their jurisdiction.
動機：デバイスまたはソフトウェアが開発されたり、他の国での緊急コールを発信するためにある国で購入のためにそれが可能でなければなりません。システム・コンポーネントは、緊急番号や言語の特定のセットに偏ってはいけません。また、さまざまな国のいずれか、例えば、緊急サービスを整理して集中や、米国や自治体などの小さな地域の細分化は、その管轄区域内の緊急コールを処理持つのさまざまな方法を進化させてきました。
Re3. Distributed administration: Deployment of IP-based emergency services MUST NOT depend on a single central administrative authority.
RE3。分散管理：IPベースの緊急サービスの展開は、単一の中央行政機関に依存してはなりません。
Motivation: The design of the mapping protocol must make it possible to deploy and administer emergency calling features on a regional or national basis without requiring coordination with other regions or nations. The system cannot assume, for example, that there is a single global entity issuing certificates for PSAPs, ASP/VSPs, IAPs, or other participants.
動機：マッピングプロトコルの設計は、それが可能他の地域や国との調整を必要とせずに、地域や全国規模での緊急呼び出し機能を展開して管理するようにする必要があります。システムはのPSAP、ASP /のVSP、IAPは、または他の参加者の証明書を発行する単一のグローバルエンティティがあることが、例えば、仮定することはできません。
Re4. Multi-mode communication: IP-based emergency calls MUST support multiple communication modes, including, for example, audio, video, and text.
RE4。マルチモード通信：IPベースの緊急コールは、例えば、オーディオ、ビデオ、およびテキストを含む複数の通信モードを、サポートしなければなりません。
Motivation: Within the PSTN, voice and text telephony (often called TTY or text-phone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [RFC4103]), instant messaging, and video.
動機：PSTN、音声およびテキスト電話の中には、（多くの場合、北米でTTYまたはテキスト電話と呼ばれる）だけで一般的にサポートされているメディアです。緊急呼び出しは、様々なメディアをサポートしている必要があります。このようなメディアは、音声、会話テキスト（RFC 4103 [RFC4103]）、インスタントメッセージング、およびビデオを含める必要があります。
Re5. Mapping result usability: The mapping protocol MUST return one or more URIs that are usable within a standard signaling protocol (i.e., without special emergency extensions).
RE5。マッピング結果ユーザビリティ：マッピング・プロトコル（すなわち、特別な緊急拡張なし）標準のシグナリングプロトコル内で使用可能である1つ以上のURIを返さなければなりません。
Motivation: For example, a SIP URI that is returned by the mapping protocol needs to be usable by any SIP-capable phone within a SIP-initiated emergency call. This is in contrast to a "special purpose" URI, which may not be recognizable by a legacy SIP device.
モチベーション：例えば、マッピング・プロトコルによって返されるSIP URIは、SIP-開始緊急呼内の任意のSIP対応の電話機で使用可能である必要があります。これは、従来のSIPデバイスが認識できない場合があり、「特別目的」URIとは対照的です。
Re6. PSAP URI accessibility: The mapping protocol MUST support interaction between the client and server where no enrollment to a mapping service exists or is required.
RE6。 PSAP URIアクセシビリティ：マッピングプロトコルはマッピングサービスへの登録が存在しないか、必要とされ、クライアントとサーバー間の対話をサポートしなければなりません。
Motivation: The mapping server may well be operated by a service provider, but access to the server offering the mapping must not require use of a specific ISP or ASP/VSP.
動機：マッピングサーバはよく、サービスプロバイダによって操作されてもよいが、マッピングを提供するサーバへのアクセスは、特定のISPやASP / VSPの使用を要求してはなりません。
Re7. Common data structures and formats: The mapping protocol SHOULD support common formats (e.g., PIDF-LO) for location data.
RE7。共通のデータ構造およびフォーマット：マッピングプロトコルは、位置データのための一般的なフォーマット（例えば、PIDF-LO）をサポートすべきです。
Motivation: Location databases should not need to be transformed or modified in any unusual or unreasonable way in order for the mapping protocol to use the data. For example, a database that contains civic addresses used by location servers may be used for multiple purposes and applications beyond emergency service location-to-PSAP URI mapping.
動機：場所データベースは、データを使用するには、マッピングプロトコルのために、形質転換または異常なまたは不当な方法で修正する必要はありません。例えば、ロケーションサーバによって使用される市民のアドレスが含まれているデータベースは、複数の目的や緊急サービスロケーションツーPSAP URIのマッピングを超えた用途に使用することができます。
Re8. Anonymous mapping: The mapping protocol MUST NOT require the true identity of the target for which the location information is attributed.
RE8。匿名マッピング：マッピングプロトコルは、位置情報が起因しているため、ターゲットの真のアイデンティティを要求してはなりません。
Motivation: Ideally, no identity information is provided via the mapping protocol. Where identity information is provided, it may be in the form of an unlinked pseudonym (RFC 3693 [RFC3693]).
動機：理想的には、ID情報がマッピングプロトコルを介して提供されていません。識別情報が提供される場合、それがリンクされていない匿名（RFC 3693 [RFC3693]）の形態であってもよいです。
Location can either be provided directly (by value), or via a pointer (by reference), and represents either a civic location, or a geographic location. An important question is how and when to attach location information to the VoIP emergency signaling messages. In general, we can distinguish three modes of operation of how a location is associated with an emergency call:
位置のいずれか缶（値によって）直接提供され、または（参照によって）ポインタを介して、及び市民の位置、または地理的な場所のいずれかを表します。重要な問題は、いつシグナリングメッセージのVoIP緊急に位置情報を付加する方法です。一般的に、我々は場所が緊急呼に関連する方法の3つの動作モードを区別することができます。
UA-inserted: The caller's user agent inserts the location information into the call-signaling message.
UA-挿入：呼び出し側のユーザエージェントは、呼シグナリングメッセージに位置情報を挿入します。
UA-referenced: The caller's user agent provides a pointer (i.e., a location reference), via a permanent or temporary identifier, to the location information, which is stored by a location server somewhere else and then retrieved by the PSAP, ESRP, or other authorized entity.
UA-参照：呼び出し側のユーザエージェントは、ポインタ（すなわち、位置参照）を提供し、永続的または一時的な識別子を介して、どこか他のロケーションサーバによって格納され、その後、PSAPによって取得された位置情報に、ESRP、又は他の権限のある機関。
Proxy-inserted: A proxy along the call path inserts the location or location reference.
プロキシ挿入：コール経路に沿ってプロキシは、場所または位置参照を挿入します。
The following requirements apply:
次の要件が適用されます。
Lo1. Reference datum: The mapping protocol MUST support the WGS-84 coordinate reference system and MAY support other coordinate reference systems.
LO1。参照データ：マッピングプロトコルは、基準座標系および他の座標参照系をサポートするかもしれWGS-84をサポートしなければなりません。
Motivation: Though many different datums exist around the world, this document recommends the WGS-84 datum since it is designed to describe the whole earth, rather than a single continent or other region, and is commonly used to represent Global Positioning System coordinates.
動機は：多くの異なる測地系は世界中に存在するが、なく、1つの大陸や他の地域よりも、地球全体を記述するために設計されており、一般的に全地球測位システム座標を表すために使用されているので、この文書では、WGS-84測地系を推奨しています。
Lo2. Location delivery by-value: The mapping protocol MUST support the delivery of location information using a by-value method, though it MAY also support de-referencing a URL that references a location object.
LO2。また、位置オブジェクトを参照するURLをデ参照をサポートしてもよいがマッピングプロトコルは、バイ値法を用いた位置情報の配信をサポートしなければならない： - 値によってロケーション・デリバリー。
Motivation: The mapping protocol is not required to support the ability to de-reference specific location references.
モチベーション：マッピングプロトコルは、特定の場所への参照参照を解除する機能をサポートするために必要とされません。
Lo3. Alternate community names: The mapping protocol MUST support both the jurisdictional community name and the postal community name fields within the PIDF-LO [RFC4119] data.
LO3。代替コミュニティ名：マッピングプロトコルは管轄コミュニティ名とPIDF-LO [RFC4119]データ内の郵便コミュニティネームフィールドの両方をサポートしなければなりません。
Motivation: The mapping protocol must accept queries with either a postal or jurisdictional community name field, or both, and provide appropriate responses. If a mapping query contains only one community name and the database contains both jurisdictional and postal community names, the mapping protocol response SHOULD return both community names.
動機：マッピングプロトコルは、郵便または管轄コミュニティ名フィールド、またはその両方のいずれかを使用してクエリを受け入れ、適切な応答を提供しなければなりません。マッピングクエリは1つのコミュニティ名しか含まれており、データベースが管轄し、郵便の両方のコミュニティ名が含まれている場合は、マッピングプロトコル応答は、両方のコミュニティ名を返すべきです。
Lo4. Validation of civic location: The mapping protocol MUST be able to report the results of validating civic locations (street addresses).
LO4。都市ロケーションのバリデーション：マッピングプロトコルは、市民の場所（住所）を検証した結果を報告することができなければなりません。
Motivation: Location validation provides an opportunity to help ascertain ahead of time whether or not a successful mapping to the appropriate PSAP will likely occur when it is required. Validation may also help to avoid delays during emergency call setup due to invalid location data.
動機：場所の検証は、それが必要なときに適切なPSAPに成功したマッピングはおそらく発生するかどうかを事前に把握するのに役立つ機会を提供します。検証はまた、無効な位置データへの緊急コールセットアップ時の遅延を回避するのを助けることができます。
Lo5. Information about location data used for mapping: The mapping protocol MUST support the ability to provide ancillary information about the resolution of location data used to retrieve a PSAP URI.
LO5。マッピングに使用される位置データに関する情報：マッピングプロトコルは、PSAPのURIを取得するために使用される位置データの解像度についての補助的な情報を提供する能力をサポートしなければなりません。
Motivation: The mapping server may not use all the data elements in the provided location information to determine a match, or may be able to find a match based on all of the information except for some specific data elements. The uniqueness of this information set may be used to differentiate among emergency jurisdictions. Precision or resolution in the context of this requirement might mean, for example, explicit identification of the data elements that were used successfully in the mapping.
モチベーション：マッピングサーバが一致を決定するために提供された位置情報のすべてのデータ要素を使用しないことがあり、またはいくつかの特定のデータ要素を除いたすべての情報に基づいて一致を見つけることができるかもしれません。この情報セットの一意性は、緊急管轄区域を区別するために使用することができます。この要件の文脈における精度または分解能は、例えば、マッピングに首尾よく使用されたデータ要素の明示的な識別を意味するかもしれません。
Lo6. Contact for location problems: The mapping protocol MUST support a mechanism to contact an appropriate authority to resolve mapping-related issues for the queried location. For example, the querier may want to report problems with the response values or indicate that the mapping database is mistaken on declaring a civic location as non-existent.
LO6。場所の問題のための連絡先：マッピングプロトコルは、照会の場所のマッピング関連の問題を解決するための適切な権限を連絡するメカニズムをサポートしなければなりません。例えば、クエリアは、応答値の問題を報告したいか、マッピングデータベースが存在しないとして、市民の場所を宣言するに間違っていることを示してもよいです。
Motivation: Initially, authorities may provide URLs where a human user can report problems with an address or location. In addition, web services may be defined to automate such reporting. For example, the querier may wish to report that the mapping database may be missing a newly built or renamed street or house number.
動機：当初、当局は、人間のユーザが住所や場所の問題を報告できるURLを提供することができます。また、Webサービスは、このような報告を自動化するように定義することができます。例えば、クエリアは、マッピングデータベースが新しく建てられたか、名前が変更され、通りや家の番号が欠落することができることを報告したいと思うかもしれません。
Lo7. Limits to validation: Successful validation of a civic location MUST NOT be required to place an emergency call.
Lo7。検証の限界：市民の場所の成功の検証は、緊急電話をかけるために必須ではありません。
Motivation: In some cases, a civic location may not be considered valid. This fact should not result in the call being dropped or rejected by any entity along the call setup signaling path to the PSAP.
動機：いくつかのケースでは、市民の場所が有効と見なされない場合があります。この事実は、PSAPへのコールセットアップシグナリングパスに沿って任意のエンティティによって削除または拒否されているコールになってはなりません。
Lo8. 3D sensitive mapping: The mapping protocol MUST implement support for both 2D and 3D location information, and MAY accept either a 2D or 3D mapping request as input.
Lo8。 3D敏感マッピング：マッピングプロトコルは、2Dと3Dの両方の位置情報のサポートを実装しなければなりません、そして入力として2Dまたは3Dマッピング要求のいずれかを受け入れることができます。
Motivation: It is expected that queriers may provide either 2D or 3D data. When a 3D request is presented within an area only defined by 2D data within the mapping server, the mapping result would be the same as if the height or altitude coordinate had been omitted from the mapping request.
動機：クエリアは、2Dまたは3Dのいずれかのデータを提供することができることが期待されます。 3D要求のみマッピング・サーバ内の2Dデータによって規定される領域内に提示されたときの高さ又は高度座標かのように、マッピング結果は同じであろうマッピング要求から省略されていました。
Lo9. Database type indicator: The mapping protocol MAY support a mechanism that provides an indication describing a specific type of location database used.
Lo9。データベースタイプインジケータ：マッピング・プロトコルが使用される場所のデータベースの特定のタイプを記述する指標を提供するメカニズムをサポートするかもしれません。
Motivation: It is useful to know the source of the data stored in the database used for location validation, either for civic or geographic location matching. In the United States, sources of data could include the United States Postal Service, the Master Street Address Guide (MSAG), or commercial map data providers.
動機：いずれかの市民又は地理的位置合わせのために、位置確認のために使用されるデータベースに格納されたデータのソースを知ることが有用です。米国では、データのソースは、米国郵政公社、マスター住所ガイド（MSAG）、または、市販の地図データプロバイダを含めることができます。
Emergency service identifiers are protocol constants that allow protocol entities, such as SIP proxy servers, to distinguish emergency calls from non-emergency calls and to identify the specific emergency service desired. Emergency service identifiers are a subclass of service identifiers that more generally identify services reachable by callers. An example of a service identifier is the service URN [RFC5031], but other identifiers, such as tel URIs [RFC3966], may also serve this role during a transition period.
緊急サービス識別子は、SIPプロキシサーバなどのプロトコルエンティティは、非緊急呼出から緊急呼を区別するために、所望の特定の緊急サービスを識別することを可能にするプロトコル定数です。緊急サービス識別子は、より一般的に発信者が到達可能なサービスを特定のサービス識別子のサブクラスです。サービス識別子の例は、サービスURN [RFC5031]であるが、TEL URIは[RFC3966]などの他の識別子は、また、遷移期間中にこの役割を果たし得ます。
Since this document only addresses emergency services, we use the terms "emergency service identifier" and "service identifier" interchangeably. Requirements for these identifiers include:
この文書は唯一の緊急サービスを扱っているので、我々は、交換可能に、「緊急サービス識別子」と「サービス識別子」という用語を使用します。これらの識別子のための要件は次のとおりです。
Id1. Multiple emergency services: The mapping protocol MUST be able to support different emergency services distinguished by different service identifiers.
ID1。複数の緊急サービス：マッピングプロトコルは異なるサービス識別子で区別異なる緊急サービスをサポートすることができなければなりません。
Motivation: Some jurisdictions may offer multiple types of emergency services that operate independently and can be contacted directly; for example, fire, police, and ambulance services.
動機：一部の管轄区域は独立して動作し、直接接触させることができる緊急サービスの複数の種類を提供することがあります。例えば、火災、警察、救急車サービスを提供しています。
Id2. Extensible emergency service identifiers: The mapping protocol MUST support an extensible list of emergency identifiers, though it is not required to provide mappings for every possible service.
ID2。拡張可能な緊急サービス識別子：すべての可能なサービスのマッピングを提供する必要がありませんが、マッピングプロトコルは、緊急識別子の拡張可能なリストをサポートしなければなりません。
Motivation: Extensibility is required since new emergency services may be introduced over time, either globally or in some jurisdictions. The availability of emergency services depends on the locations. For example, the Netherlands are unlikely to offer a mountain rescue service.
動機：新しい緊急サービスは、時間をかけて導入することができるので、拡張性は、グローバルにも、いくつかの法域では、必要とされます。緊急サービスの可用性は、場所に依存します。例えば、オランダは、山岳救助サービスを提供する可能性は低いです。
Id3. Discovery of emergency number: The mapping protocol MUST be able to return the location-dependent emergency number for the location indicated in the query.
ID3。緊急番号の発見：マッピングプロトコルは、クエリに示されている場所の位置依存緊急番号を返すことができなければなりません。
Motivation: Users are trained to dial the appropriate emergency number to reach emergency services. There needs to be a way to figure out the emergency number at the current location of the caller.
動機：ユーザーは、緊急サービスに到達するために、適切な緊急番号をダイヤルするように訓練されています。呼び出し元の現在の場所で緊急番号を把握する方法が必要です。
Id4. Home emergency number recognition: User equipment MUST be able to translate a home emergency number into an emergency service identifier.
ID4。ホーム緊急番号認識：ユーザ装置は、緊急サービス識別子に自宅の緊急番号を変換することができなければなりません。
Motivation: The UE could be pre-provisioned with the appropriate information in order to perform such a translation or could discover the emergency number by querying the mapping protocol with its home location.
モチベーション：UEがこのような変換を実行するか、そのホーム位置とのマッピングプロトコルを照会することにより、緊急電話番号を発見できたために、適切な情報を事前にプロビジョニングすることができます。
Id5. Emergency number replacement: There SHOULD be support for replacement of the emergency number with the appropriate emergency service identifier for each signaling protocol used for an emergency call, based on local conventions, regulations, or preference (e.g., as in the case of an enterprise).
ID5。緊急番号の交換は：（企業の場合のように、例えば）局所規則、規制、または嗜好に基づいて、緊急呼のために使用される各シグナリングプロトコルのための適切な緊急サービス識別子を有する緊急番号の交換のためのサポートがあるべきです。
Motivation: Any signaling protocol requires the use of some identifier to indicate the called party, and the user equipment may lack the capability to determine the actual service URL (PSAP URI). The use of local conventions may be required as a transition mechanism. Since relying on recognizing local numbering conventions makes it difficult for devices to be used outside their home context and for external devices to be introduced into a network, protocols should use standardized emergency service identifiers.
動機：任意のシグナリングプロトコルは、着信側を示すために、いくつかの識別子を使用する必要があり、ユーザ機器は、実際のサービスのURL（PSAP URI）を決定するための能力を欠いている可能性があります。ローカル規則の使用は、移行機構として必要とされ得ます。デバイスは自宅のコンテキスト外と外部デバイスがネットワークに導入するために使用されるために地元の番号付け規則を認識に依存することが困難になりますので、プロトコルが標準化された緊急サービス識別子を使用する必要があります。
Id6. Emergency service identifier marking: Signaling protocols MUST support emergency service identifiers to mark a call as an emergency call.
ID6。マーキング緊急サービス識別子：シグナリングプロトコルは、緊急呼び出しとして呼び出しをマークするために、緊急サービス識別子をサポートしなければなりません。
Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address. This marking mechanism is related to, but independent of, marking calls for prioritized call handling [RFC4412].
動機：マーキングは、例えば、論理緊急アドレスのローカルバリアントを認識しないかもしれない下流の要素によって、緊急コールなどの適切な取り扱いを保証します。このマーキング機構はハンドリング優先順位コール[RFC4412]のための呼び出しをマーキングに関連しますが、とは独立しています。
Id7. Handling unrecognized emergency service identifiers: There MUST be support for calls that are initiated as emergency calls even if the specific emergency service requested is not recognized by the ESRP. Such calls will then be routed to a generic emergency service.
ID7。未認識の緊急サービス識別子の扱い：緊急事態が要求された特定の緊急サービスは、ESRPによって認識されていない場合でも呼び出すとして開始されたコールのためのサポートがあるに違いありません。このような呼び出しは、その後、一般的な緊急サービスにルーティングされます。
Motivation: Fallback routing allows new emergency services to be introduced incrementally, while avoiding non-routable emergency calls. For example, a call for marine rescue services would be routed to a general PSAP if the caller's location does not offer marine rescue services yet.
動機：フォールバックルーティングはルーティング不可能な緊急コールを回避しながら、新たな緊急サービスは、インクリメンタルに導入することができます。発信者の場所がまだ海洋救助サービスを提供していない場合たとえば、海洋救助サービスの呼び出しは、一般的なPSAPにルーティングされることになります。
Id8. Return fallback service identifier: The mapping protocol MUST be able to report back the actual service mapped if the mapping protocol substitutes another service for the one requested.
ID8。フォールバックサービス識別子を返します：マッピングプロトコルは要求されたいずれかの他のサービスを代入した場合、マッピングプロトコルはマッピングされた実際のサービスを折り返し報告することができなければなりません。
Motivation: A mapping server may be configured to automatically look up the PSAP for another service if the user-requested service is not available for that location. For example, if there is no marine rescue service, the mapping protocol might return the PSAP URL for general emergencies and include the "urn:service.sos" identifier in the response to alert the querier to that fact.
動機：マッピングサーバは、ユーザが要求されたサービスは、その場所のために利用できない場合、自動的に別のサービスのためにPSAPを検索するように構成することができます。その事実にクエリアを警告する応答：「service.sos壷」識別子なし海洋救助サービスが存在しない場合、例えば、マッピングプロトコルは、一般的な緊急事態のためにPSAPのURLを返し、含まれる場合があります。
Id9. Discovery of visited emergency numbers: The mapping protocol MUST support a mechanism to allow the end device to learn visited emergency numbers.
ID9。訪問した緊急番号の発見：マッピングプロトコルは、エンドデバイスが訪問した緊急番号を学ぶことを可能にするメカニズムをサポートしなければなりません。
Motivation: Travelers visiting a foreign country may observe the local emergency number, e.g., seeing it painted on the side of a fire truck, and then rightfully expect to be able to dial that emergency number. Similarly, a local "good Samaritan" may use a tourist's cell phone to summon help.
動機：外国を訪問する旅行者は、それは消防車の側に描かれ、その後、当然その緊急番号をダイヤルできることを期待し見て、例えば、地域の緊急番号を観察することができます。同様に、地元の「良いサマリヤ人は、」助けを召喚するために観光客の携帯電話を使用することができます。
There are two basic approaches to invoke the mapping protocol. We refer to these as caller-based and mediated. In each case, the mapping client initiates a request to a mapping server via a mapping protocol. A proposed mapping protocol, LoST, is outlined in [lost].
マッピングプロトコルを起動するには、2つの基本的なアプローチがあります。私たちは、発信者ベースと媒介としてこれらを参照してください。それぞれの場合に、マッピング・クライアントは、マッピング・プロトコルを介してマッピング・サーバに要求を開始します。提案されたマッピングプロトコル、失われたが、[紛失]に概説されています。
For caller-based resolution, the caller's user agent invokes the mapping protocol to determine the appropriate PSAP based on the location provided. The resolution may take place well before the actual emergency call is placed, or at the time of the call.
発信者ベースの解決のために、呼び出し側のユーザエージェントは、提供された位置に基づいて適切なPSAPを決定するために、マッピング・プロトコルを呼び出します。実際の緊急コールが置かれ、またはコールの時にされる前に、解像度はよく行われてもよいです。
For mediated resolution, an emergency call routing support entity, such as a SIP (outbound) proxy or redirect server, invokes the mapping service.
そのようなサーバをリダイレクトまたはSIP（アウトバウンド）プロキシとして媒介される解像度、緊急呼のルーティングをサポートエンティティのために、マッピングサービスを呼び出します。
Since servers may be used as outbound proxy servers by clients that are not in the same geographic area as the proxy server, any proxy server has to be able to translate any caller location to the appropriate PSAP. (A traveler may, for example, accidentally or intentionally configure its home proxy server as its outbound proxy server, even while far away from home.)
サーバは、プロキシサーバーと同じ地理的エリア内にないクライアントによってアウトバウンドプロキシサーバとして使用することができるので、任意のプロキシサーバは、適切なPSAPに任意の発信者の位置を変換することができなければなりません。 （旅行者は、例えば、偶然または故意にさえながら、遠く離れた自宅から、そのアウトバウンドプロキシサーバとしてそのホームプロキシサーバーを設定することができます。）
Ma1. Baseline query protocol: A mandatory-to-implement protocol MUST be specified.
MA1。ベースラインの問い合わせプロトコル：実装に必須のプロトコルを指定する必要があります。
Motivation: An over-abundance of similarly capable choices appears undesirable for interoperability.
動機：オーバー豊富同様に可能な選択肢の相互運用性のために望ましくない表示されます。
Ma2. Extensible protocol: The mapping protocol MUST be designed to support the extensibility of location data elements, both for new and existing fields.
MA2。拡張可能プロトコル：マッピングプロトコルは、新規および既存のフィールドに、位置データ要素の拡張性をサポートするように設計されなければなりません。
Motivation: This is needed, for example, to accommodate future extensions-to-location information that might be included in the PIDF-LO ([RFC4119]).
動機：これは、PIDF-LOに含まれるかもしれない将来の拡張対位置情報を収容するために、例えば、必要とされる（[RFC4119]）。
Ma3. Incrementally deployable: The mapping protocol MUST be designed to support its incremental deployment.
MA3。増分展開可能：マッピングプロトコルは、その増分の展開をサポートするように設計されなければなりません。
Motivation: It must not be necessary, for example, to have a global street level database before deploying the system. It is acceptable to have some misrouting of calls when the database does not (yet) contain accurate PSAP service area information.
動機：それは、例えば、必要であってはならないシステムを展開する前に、グローバルなストリートレベルのデータベースを持っています。データベースが（まだ）正確なPSAPサービスエリア情報が含まれていないときのコールの一部misroutingを持つことが可能です。
Ma4. Any time mapping: The mapping protocol MUST support the ability of the mapping function to be invoked at any time, including while an emergency call is in process and before an emergency call is initiated.
MA4。いつでもマッピング：マッピングプロトコルはマッピング機能の能力をサポートしなければならないが、緊急コールが進行中で、緊急コールが開始される前にいる間を含め、いつでも呼び出すことができます。
Motivation: If the mapping query fails at call time, it may be advantageous to be able to fall back to the result of an earlier mapping query. This prior knowledge would be obtained by performing a mapping query at any time prior to an emergency call.
動機：マッピングクエリが呼び出し時に失敗した場合、それは以前のマッピングクエリの結果にフォールバックすることができることが有利であり得ます。この予備知識は、緊急コールの前に任意の時点でマッピングクエリを実行することによって得られるであろう。
Ma5. Anywhere mapping: The mapping protocol MUST support the ability to provide mapping information in response to an individual query from any (earthly) location, regardless of where the mapping client is located, either geographically or by network location.
MA5。どこにもマッピング：マッピング・プロトコルにかかわらずマッピングクライアントがいずれかの地理的にまたはネットワーク上の場所によって、ある場所の、いずれかの（地上の）場所から個々のクエリに応じてマッピング情報を提供する能力をサポートしなければなりません。
Motivation: The mapping client, such as an ESRP, may not necessarily be anywhere close to the caller or the appropriate PSAP, but must still be able to obtain mapping information.
モチベーション：マッピング・クライアントは、ESRPとして、必ずしも発信者または適切なPSAPにどこでも近くではないかもしれないが、それでもマッピング情報を取得することができなければなりません。
Ma6. Appropriate PSAP: The mapping protocol MUST support the routing of an emergency call to the PSAP responsible for a particular geographic area.
MA6。適切なPSAP：マッピングプロトコルは、特定の地理的領域を担当するPSAPへの緊急コールのルーティングをサポートしなければなりません。
Motivation: Routing to the wrong PSAP will result in delays in handling emergencies as calls are redirected, and therefore will also result in inefficient use of PSAP resources at the initial point of contact. It is important that the location determination mechanism not be fooled by the location of IP telephony gateways or dial-in lines into a corporate LAN (and dispatch emergency help to the gateway or campus, rather than the caller), multi-site LANs and similar arrangements.
動機：間違ったPSAPへのルーティングは、コールがリダイレクトされるよう緊急事態を処理する際の遅延が発生しますので、また接触の最初のポイントでPSAPリソースの非効率的な使用になります。場所の決意メカニズムがまたはIPテレフォニーゲートウェイの場所にだまされてはいけないことが重要であるダイヤルイン、マルチサイトのLANと同様の（ゲートウェイまたはキャンパスではなく、呼び出し元に、発送の緊急ヘルプ）社内LANへのラインアレンジ。
Ma7. Multiple PSAP URIs: The mapping protocol MUST support a method to return multiple PSAP URIs, which cover the same geographic area.
MA7。複数のPSAP URIを：マッピングプロトコルは、同じ地理的領域をカバーする複数のPSAP URIを、返すようにメソッドをサポートしなければなりません。
Motivation: Different contact protocols (e.g., PSTN via tel URIs and IP via SIP URIs) may be routed to different PSAPs. Less likely, two PSAPs may overlap in their coverage region.
モチベーション：異なる接触プロトコル（例えば、SIP URIを介しTEL URIとIPを介してPSTN）が異なるのPSAPにルーティングすることができます。にくく、2つのPSAPは、そのカバレッジ領域にオーバーラップしてもよいです。
Ma8. Single primary URI per contact protocol: Though the mapping protocol may be able to include multiple URIs in the response, it SHOULD return only one primary URI per contact protocol used, so that clients are not required to select among different targets for the same contact protocol.
MA8。接触プロトコルごとに単一のプライマリURI：マッピングプロトコルは応答して複数のURIを含めることができるかもしれけれどもクライアントが同じ接触プロトコルの異なるターゲットの中から選択する必要がないように、それは、使用されるコンタクトプロトコルごとに1つだけのプライマリURIを返すべきです。
Motivation: There may be two or more URIs returned when multiple contact protocols are available (e.g., SIP and SMS). The client may select among multiple contact protocols based on its capabilities, preference settings, or availability.
動機は：複数の接触プロトコル（例えば、SIPおよびSMS）利用可能であるときに、2つの以上のURIを返すがあってもよいです。クライアントはその機能、環境設定、または可用性に基づいて複数のコンタクトのプロトコルの中から選択することができます。
Ma9. Non-preferred URI schemes: The mapping protocol MAY support the return of a less-preferred URI scheme, such as a tel URI.
MA9。非優先URIスキーム：マッピングプロトコルは、TEL URIとしてあまり好ましいURIスキームの復帰をサポートするかもしれません。
Motivation: In order to provide incremental support to non-IP PSAPs, it may be necessary to be able to complete an emergency call via the PSTN.
動機：非IPのPSAPへの増分サポートを提供するためには、PSTNを経由して、緊急コールを完了できるようにする必要があるかもしれません。
Ma10. URI properties: The mapping protocol MUST support the ability to provide ancillary information about a contact that allows the mapping client to determine relevant properties of the PSAP URI.
MA10。 URIプロパティ：マッピングプロトコルはマッピングクライアントは、PSAP URIの関連特性を決定することを可能にする連絡先に関する補助的な情報を提供する能力をサポートしなければなりません。
Motivation: In some cases, the same geographic area is served by several PSAPs; for example, a corporate campus might be served by both a corporate security department and the municipal PSAP. The mapping protocol should then return URIs for both, with information allowing the querying entity to choose one or the other. This determination could be made by either an ESRP, based on local policy, or by direct user choice, in the case of caller-based methods.
動機：いくつかのケースでは、同じ地理的領域は、いくつかのPSAPで提供しています。例えば、企業のキャンパスは、企業のセキュリティ部門や自治体PSAPの両方で提供される可能性があります。マッピングプロトコルは、情報を照会エンティティが、どちらか一方を選択することを可能にすると、両方のURIを返すべきです。この決意は、発信者ベースの方法の場合には、ローカルポリシーに基づいてESRP、いずれかによって、または直接ユーザの選択によって行うことができます。
Ma11. Mapping referral: The mapping protocol MUST support a mechanism for the mapping client to contact any mapping server and be referred to another mapping server that is more qualified to answer the query.
MA11。マッピング紹介：マッピングプロトコルは、任意のマッピングサーバーに接続するためのマッピング・クライアントのためのメカニズムをサポートしなければならないし、クエリに答えるために、より修飾されている他のマッピングサーバと呼ばれます。
Motivation: Referrals help mitigate the impact of incorrect configuration that directs a client to the wrong initial mapping server.
動機：紹介は、間違った初期のマッピングサーバにクライアントに指示誤った構成の影響を軽減するのに役立ちます。
Ma12. Split responsibility: The mapping protocol MUST support the division of data subset handling between multiple mapping servers within a single level of a civic location hierarchy.
MA12。スプリット責任：マッピングプロトコルは都市ロケーション階層の単一レベル内の複数のマッピング・サーバとの間でデータ処理のサブセットの分割をサポートしなければなりません。
Motivation: For example, two mapping servers for the same city or county may handle different streets within that city or county.
動機：たとえば、同じ都市や郡のための2台のマッピングサーバは、その都市や郡内の異なる街を処理することができます。
Ma13. URL for error reporting: The mapping protocol MUST support the ability to return a URL that can be used to report a suspected or known error within the mapping database.
MA13。エラー報告用URL：マッピングプロトコルはマッピングデータベース内の疑いまたは既知のエラーを報告するために使用することができるURLを返す機能をサポートしなければなりません。
Motivation: If an error is returned, for example, there needs to be a URL that points to a resource that can explain or potentially help resolve the error.
動機：エラーが返された場合、例えば、説明したり、潜在的なエラーを解決するのに役立つことができ、リソースを指すURLが必要です。
Ma14. Resilience to mapping server failure: The mapping protocol MUST support a mechanism that enables the client to fail over to different (replica) mapping server.
MA14。マッピングサーバの障害に対する回復力：マッピングプロトコルが異なる（レプリカ）マッピングサーバにフェイルオーバーするようにクライアントを可能にするメカニズムをサポートしなければなりません。
Motivation: The failure of a mapping server should not preclude the mapping client from receiving an answer to its query.
動機：マッピングサーバの障害は、そのクエリに対する回答を受けてから、マッピング・クライアントを排除すべきではありません。
Ma15. Traceable resolution: The mapping protocol SHOULD support the ability of the mapping client to be able to determine the entity or entities that provided the emergency address resolution information.
MA15。トレーサブル解像度：マッピングプロトコルは緊急アドレス解決情報を提供するエンティティを決定することができるようにするマッピング・クライアントの能力をサポートする必要があります。
Motivation: To improve reliability and performance, it is important to be able to trace which servers contributed to the resolution of a query.
動機：信頼性とパフォーマンスを向上させるためには、クエリの解決に貢献しているサーバ追跡できることが重要です。
Ma16. Minimal additional delay: Mapping protocol execution SHOULD minimize the amount of delay within the overall call-setup time.
MA16。最小限の追加の遅延：マッピングプロトコルの実行は、全体的な呼設定時間内に遅延量を最小にしなければなりません。
Motivation: Since outbound proxies will likely be asked to resolve the same geographic coordinates repeatedly, a suitable time-limited caching mechanism should be supported.
動機：アウトバウンドプロキシがありそうな、繰り返し同じ地理座標を解決するよう求められますので、適した期間限定のキャッシュメカニズムをサポートしなければなりません。
Ma17. Freshness indication: The mapping protocol SHOULD support an indicator describing how current the information provided by the mapping source is.
MA17。鮮度表示：マッピングプロトコルはマッピング・ソースによって提供された情報がどのように現在の記述インジケータをサポートしなければなりません。
Motivation: This is especially useful when an alternate mapping is requested, and alternative sources of mapping data may not have been created or updated with the same set of information or within the same time frame. Differences in currency between mapping data contained within mapping sources should be minimized.
モチベーション：代替のマッピングが要求されたとき、これは特に有用であり、マッピングデータの代替ソースは、情報の同じセットで、または同じ時間枠内に作成または更新されていなくてもよいです。マッピング・ソース内に含まれたマッピングデータとの間の通貨の差が最小化されるべきです。
Threats and security requirements are discussed in a separate document [RFC5069].
脅威とセキュリティ要件は、別の文書[RFC5069]で議論されています。
The information in this document is partially derived from text written by the following contributors:
このドキュメントの情報は、部分的に、次の貢献者によって書かれたテキストから導出されます。
Nadine Abbott nabbott@telcordia.com
ナディーヌアボットnabbott@telcordia.com
Hideki Arai arai859@oki.com
ひでき あらい あらい８５９＠おき。こｍ
Martin Dawson Martin.Dawson@andrew.com
マーティン・ドーソンMartin.Dawson@andrew.com
Motoharu Kawanishi kawanishi381@oki.com
もとはる かわにし かわにし３８１＠おき。こｍ
Brian Rosen br@brianrosen.net
ブライアン・ローゼンbr@brianrosen.net
Richard Stastny Richard.Stastny@oefeg.at
リチャードStastny Richard.Stastny@oefeg.at
Martin Thomson Martin.Thomson@andrew.com
マーティン・トムソンMartin.Thomson@andrew.com
James Winterbottom James.Winterbottom@andrew.com
ジェームズ・ウィンターボトムJames.Winterbottom@andrew.com
In addition to thanking those listed above, we would like to also thank Guy Caron, Barry Dingle, Keith Drage, Tim Dunn, Patrik Faltstrom, Clive D.W. Feather, Raymond Forbes, Randall Gellens, Michael Haberler, Michael Hammer, Ted Hardie, Gunnar Hellstrom, Cullen Jennings, Marc Linsner, Rohan Mahy, Patti McCalmont, Don Mitchell, John Morris, Andrew Newton, Steve Norreys, Jon Peterson, James Polk, Benny Rodrig, John Rosenberg, Jonathan Rosenberg, John Schnizlein, Shida Schubert, James Seng, Byron Smith, Barbara Stark, Richard Stastny, Tom Taylor, Hannes Tschofenig, and Nate Wilcox for their helpful input.
上記に挙げたものに感謝することに加えて、我々はガイ・キャノン、バリー・ディングル、キース糖剤、ティム・ダン、パトリックFaltstrom、クライヴD.W.をも感謝したいと思いますフェザー、レイモンド・フォーブス、ランドールGellens、マイケルHaberler、マイケル・ハマー、テッドハーディー、グンナー・ヘルストローム、カレン・ジェニングス、マルク・Linsner、ロハンマーイ、パティMcCalmont、ドン・ミッチェル、ジョン・モリス、アンドリュー・ニュートン、スティーブNorreys、ジョンピーターソン、ジェームズ・ポーク、彼らの有益入力のためのベニーRodrig、ジョン・ローゼンバーグ、ジョナサン・ローゼンバーグ、ジョン・Schnizlein、志田シューベルト、ジェームズ・ハンセン、バイロン・スミス、バーバラ・スターク、リチャードStastny、トム・テイラー、ハンネスTschofenig、そしてネイトウィルコックス。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.
聴覚障害、難聴および音声のサポートに[RFC3351]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件-impaired個人」、RFC 3351、2002年8月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[RFC3860]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412] Schulzrinneと、H.とJ.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031] Schulzrinneと、H.、 "ユニフォームリソース名救急およびその他のよく知られているサービスのための（URN）"、RFC 5031、2008年1月。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]テイラー、T.、エド。、Tschofenig、H.、Schulzrinneと、H.、およびM・シャンミューガム、 "セキュリティの脅威と緊急マーキングコールとマッピングのための要件"、RFC 5069、2008年1月。
[lost] Hardie, T., "LoST: A Location-to-Service Translation Protocol", Work in Progress, August 2007.
ハーディ、T.を[失われた]、「失われた：場所・ツー・サービス翻訳・プロトコル」、進歩、2007年8月に作業。
[toip] Wijk, A. and G. Gybels, "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", Work in Progress, August 2006.
[TOIP] Wijk、A.およびG. Gybels、 "SIP（Session Initiation Protocol）を使用してIP経由のリアルタイムのテキストのためのフレームワーク" が進歩、2006年8月に作業。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+ecrit@cs.columbia.edu URI：http://www.cs.columbia.edu
Roger Marshall (editor) TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US
ロジャー・マーシャル（エディタ）通信システム株式会社2401年エリオットアベニュー2階シアトル、WA 98121米国
Phone: +1 206 792 2424 EMail: rmarshall@telecomsys.com URI: http://www.telecomsys.com
電話：+1 206 792 2424 Eメール：rmarshall@telecomsys.com URI：http://www.telecomsys.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。