[要約] RFC 6443は、インターネットマルチメディアを使用した緊急通報のためのフレームワークに関するものです。その目的は、インターネットを介して緊急通報を行うための標準化された手法を提供することです。
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6443 NeuStar
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia U.
J. Polk
Cisco Systems
A. Newton
TranTech/MediaSolv
December 2011
Framework for Emergency Calling Using Internet Multimedia
インターネットマルチメディアを使用した緊急通話のフレームワーク
Abstract
概要
The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities.
IETFは、緊急電話の配置のさまざまな側面を標準化しています。この文書では、これらのコンポーネント部品のすべてが、市民と当局への訪問者からの緊急電話をサポートするためにどのように使用されているかについて説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6443.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6443で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
信頼の法的規定のセクション4.Eで説明されているように、簡略化されたBSDライセンステキストを含め、簡素化されたBSDライセンスに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................6
3. Overview of How Emergency Calls Are Placed ......................8
4. Which Devices and Services Should Support Emergency Calls? .....12
5. Identifying an Emergency Call ..................................12
6. Location and Its Role in an Emergency Call .....................14
6.1. Types of Location Information .............................16
6.2. Location Determination ....................................17
6.2.1. User-Entered Location Information ..................17
6.2.2. Access Network "Wire Database" Location
Information ........................................18
6.2.3. End System Measured Location Information ...........19
6.2.4. Network Measured Location Information ..............19
6.3. Who Adds Location, Endpoint, or Proxy? ....................20
6.4. Location and References to Location .......................20
6.5. End System Location Configuration .........................21
6.6. When Location Should Be Configured ........................22
6.7. Conveying Location ........................................23
6.8. Location Updates ..........................................24
6.9. Multiple Locations ........................................24
6.10. Location Validation ......................................25
6.11. Default Location .........................................26
6.12. Location Format Conversion ...............................26
7. LIS and LoST Discovery .........................................26
8. Routing the Call to the PSAP ...................................27
9. Signaling of Emergency Calls ...................................29
9.1. Use of TLS ................................................29
9.2. SIP Signaling Requirements for User Agents ................30
9.3. SIP Signaling Requirements for Proxy Servers ..............30
10. Call Backs ....................................................30
11. Mid-Call Behavior .............................................31
12. Call Termination ..............................................31
13. Disabling of Features .........................................32
14. Media .........................................................32
15. Testing .......................................................32
16. Security Considerations .......................................33
17. Acknowledgments ...............................................33
18. Informative References ........................................34
Requesting help in an emergency using a communications device such as a telephone (landline or mobile) is an accepted practice in many parts of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will expect to use such devices to request help. This document describes establishment of a communications session by a user to a "Public Safety Answering Point" (PSAP), that is, a call center established by response agencies to accept emergency calls. Such citizen-/ visitor-to-authority calls can be distinguished from those that are created by responders (authority-to-authority) using public communications infrastructure often involving some kind of priority access as defined in Emergency Telecommunications Service (ETS) in IP Telephony [RFC4190]. They can also be distinguished from emergency warning systems that are authority-to-citizen.
電話（固定電話やモバイル）などの通信デバイスを使用した緊急時にヘルプを要求することは、世界の多くの地域で受け入れられている慣行です。通信デバイスがますますインターネットを利用して相互接続と通信を使用すると、ユーザーはそのようなデバイスを使用してヘルプを要求することを期待します。このドキュメントでは、ユーザーによる「公共の安全回答ポイント」（PSAP）への通信セッションの確立、つまり、緊急電話を受け入れるために対応機関によって設立されたコールセンターについて説明しています。このような市民/訪問者への呼びかけは、IPテレフォニーの緊急通信サービス（ETS）で定義されている何らかの優先アクセスを含むパブリックコミュニケーションインフラストラクチャを使用して、レスポンダー（権限から権威への権限）によって作成されたものと区別できます。[RFC4190]。また、権限への緊急警告システムと区別することもできます。
Supporting emergency calling requires cooperation by a number of elements, their vendors, and service providers. This document discusses how end devices and applications create emergency calls, how access networks supply location for some of these devices, how service providers assist the establishment and routing, and how PSAPs receive calls from the Internet.
緊急通話をサポートするには、多くの要素、そのベンダー、およびサービスプロバイダーによる協力が必要です。このドキュメントでは、エンドデバイスとアプリケーションが緊急通話を作成する方法、アクセスネットワークがこれらのデバイスの一部に場所を提供する方法、サービスプロバイダーが確立とルーティングを支援する方法、およびPSAPがインターネットから電話を受信する方法について説明します。
The emergency response community will have to upgrade their facilities to support a wider range of communications services, but cannot be expected to handle wide variations in device and service capability. New devices and services are being made available that could be used to make a request for help that are not traditional telephones, and users are increasingly expecting to use them to place emergency calls. However, many of the technical advantages of Internet multimedia require re-thinking the traditional emergency calling architecture. This challenge also offers an opportunity to improve the operation of emergency calling technology, while potentially lowering its cost and complexity.
緊急対応コミュニティは、幅広い通信サービスをサポートするために施設をアップグレードする必要がありますが、デバイスとサービス機能の幅広いバリエーションを処理することは期待できません。新しいデバイスとサービスが利用可能になっており、従来の電話ではないヘルプを要求するために使用できるようになり、ユーザーは緊急電話を行うためにそれらを使用することをますます期待しています。ただし、インターネットマルチメディアの技術的な利点の多くは、従来の緊急通話アーキテクチャを再考する必要があります。また、この課題は、緊急通話技術の運用を改善する機会を提供し、そのコストと複雑さを潜在的に削減する可能性があります。
It is beyond the scope of this document to enumerate and discuss all the differences between traditional (Public Switched Telephone Network) and IP-based telephony, but calling on the Internet is characterized by:
このドキュメントの範囲を超えて、従来の（パブリックスイッチ付き電話ネットワーク）とIPベースのテレフォニーのすべての違いを列挙して議論しますが、インターネットでの呼び出しは以下によって特徴付けられます。
o interleaving over the same infrastructure of a wider variety of services;
o 幅広いサービスの同じインフラストラクチャにおけるインターリーブ。
o separation of the access provider from the application provider;
o アプリケーションプロバイダーからのアクセスプロバイダーの分離。
o media other than voice (for example, video and text in several forms);
o 音声以外のメディア（たとえば、いくつかの形式のビデオやテキスト）;
o potential mobility of all end systems, including endpoints nominally thought of as fixed systems and not just those using radio access technology. For example, consider a wired phone connected to a router using a mobile data network such as Evolution Data Optimized (EV-DO) as an uplink.
o エンドポイントを含むすべてのエンドシステムの潜在的なモビリティは、ラジオアクセステクノロジーを使用しているものだけでなく、固定システムと名目的に考えられていました。たとえば、Uplinkとして最適化（EV-DO）などのモバイルデータネットワークを使用して、ルーターに接続された有線電話を検討してください。
This document focuses on how devices using the Internet can place emergency calls and how PSAPs can handle Internet multimedia emergency calls natively, rather than describing how circuit-switched PSAPs can handle Voice over IP (VoIP) calls. In many cases, PSAPs making the transition from circuit-switched interfaces to packet-switched interfaces may be able to use some of the mechanisms described here, in combination with gateways that translate packet-switched calls into legacy interfaces, e.g., to continue to be able to use existing call taker equipment. There are many legacy telephone networks that will persist long after most systems have been upgraded to IP origination and termination of emergency calls. Many of these legacy systems route calls based on telephone numbers. Gateways and conversions between existing systems and newer systems defined by this document will be required. Since existing systems are governed primarily by local government regulations and national standards, the gateway and conversion details will be governed by national standards and thus are out of scope for this document.
このドキュメントでは、インターネットを使用してデバイスが緊急通話を配置する方法と、回路が切り替えられたPSAPがVoice over IP（VOIP）コールを処理する方法を説明するのではなく、PSAPがインターネットマルチメディアの緊急通話をネイティブに処理する方法に焦点を当てています。多くの場合、回路でスイッチされたインターフェイスからパケットスイッチインターフェイスへの移行を行うPSAPは、ここで説明するメカニズムの一部を使用できる場合があります。既存のコールTaker機器を使用できます。ほとんどのシステムがIPの起源と緊急通話の終了にアップグレードされた後もずっと持続するレガシー電話ネットワークがたくさんあります。これらのレガシーシステムの多くは、電話番号に基づいて呼び出しをルーティングしています。既存のシステムとこのドキュメントで定義された新しいシステム間のゲートウェイと変換が必要です。既存のシステムは主に地方自治体の規制と国家基準によって管理されているため、ゲートウェイと変換の詳細は国家基準に準拠しているため、この文書の範囲外です。
Existing emergency call systems are organized locally or nationally; there are currently few international standards. However, the Internet crosses national boundaries, and thus Internet standards are required. To further complicate matters, VoIP endpoints can be connected through tunneling mechanisms such as virtual private networks (VPNs). Tunnels can obscure the identity of the actual access network that knows the location. This significantly complicates emergency calling, because the location of the caller and the first element that routes emergency calls can be on different continents, with different conventions and processes for handling of emergency calls.
既存の緊急通話システムは、地元または全国で組織されています。現在、国際的な基準はほとんどありません。ただし、インターネットは国境を越えているため、インターネット標準が必要です。問題をさらに複雑にするために、VoIPエンドポイントは、仮想プライベートネットワーク（VPN）などのトンネリングメカニズムを介して接続できます。トンネルは、場所を知っている実際のアクセスネットワークのIDを曖昧にする可能性があります。これは、発信者の位置と緊急電話をルーティングする最初の要素が異なる大陸にある可能性があり、緊急コールの処理のための異なる慣習とプロセスがあるため、緊急通話を大幅に複雑にします。
The IETF has historically not created national variants of its standards. Thus, this document attempts to take into account best practices that have evolved for circuit-switched PSAPs, but it makes no assumptions on particular operating practices currently in use, numbering schemes, or organizational structures.
IETFは、歴史的にその基準の国家的バリアントを作成していません。したがって、このドキュメントは、回路が切り替えられたPSAPのために進化したベストプラクティスを考慮に入れようとしますが、現在使用されている特定の運用慣行、番号付けスキーム、または組織構造については仮定しません。
This document discusses the use of the Session Initiation Protocol (SIP) [RFC3261] by PSAPs and calling parties. While other inter-domain call signaling protocols may be used for emergency calling, SIP is ubiquitous and possesses the proper support of this use case. Only protocols such as H.323, XMPP/Jingle, ISUP, and SIP are suitable for inter-domain communications, ruling out Media Gateway Controller
このドキュメントでは、PSAPおよびCalling Partiesによるセッション開始プロトコル（SIP）[RFC3261]の使用について説明します。他のドメイン間コールシグナル伝達プロトコルは緊急通話に使用される場合がありますが、SIPはユビキタスであり、このユースケースの適切なサポートを持っています。H.323、XMPP/Jingle、ISUP、SIPなどのプロトコルのみが、ドメイン間通信に適しており、メディアゲートウェイコントローラーを除外します
protocols such as the Media Gateway Control Protocol (MGCP) or H.248/ Megaco. The latter protocols can be used by the enterprise or carrier placing the call, but any such call would reach the PSAP through a media gateway controller, similar to how inter-domain VoIP calls would be placed. Other signaling protocols may also use protocol translation to communicate with a SIP-enabled PSAP. Peer-to-peer SIP (p2psip) is not considered in this document.
メディアゲートウェイ制御プロトコル（MGCP）やH.248/メガコなどのプロトコル。後者のプロトコルは、コールを配置するエンタープライズまたはキャリアで使用できますが、そのような呼び出しは、ドメイン間VoIPコールの配置方法と同様に、メディアゲートウェイコントローラーを介してPSAPに到達します。他のシグナル伝達プロトコルは、プロトコル翻訳を使用してSIP対応PSAPと通信することもできます。このドキュメントでは、ピアツーピアSIP（P2PSIP）は考慮されていません。
Existing emergency services rely exclusively on voice and conventional text telephony ("TTY") media streams. However, more choices of media offer additional ways to communicate and evaluate the situation as well as to assist callers and call takers in making and handling emergency calls, respectively. For example, instant messaging and video could improve the ability to communicate and evaluate the situation and to provide appropriate instruction prior to arrival of emergency crews. Thus, the architecture described here supports the creation of sessions of any media type, negotiated between the caller and PSAP using existing SIP mechanisms [RFC3264].
既存の緊急サービスは、音声および従来のテキストテレフォニー（「TTY」）メディアストリームにのみ依存しています。ただし、メディアの選択肢が増えると、状況を伝えて評価するための追加の方法があり、それぞれ発信者やテイカーに電話をかけるのを支援し、それぞれ緊急通話を行い、処理します。たとえば、インスタントメッセージングとビデオは、状況を通信および評価し、緊急乗組員が到着する前に適切な指導を提供する能力を向上させることができます。したがって、ここで説明するアーキテクチャは、既存のSIPメカニズムを使用して発信者とPSAPの間で交渉された、あらゆるメディアタイプのセッションの作成をサポートしています[RFC3264]。
This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement -- can be and are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. In this case, calls may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider) but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here.
このドキュメントは、緊急通話プロセスの3つの3つのステップ（位置構成、通話ルーティング、通話配置）が呼び出しエンドポイントによって実行される場合に焦点を当てています。位置情報。この場合、通話はアプリケーション層通信サービスプロバイダー（音声サービスプロバイダーなど）を介してルーティングされる場合がありますが、必要はありません。基礎となるプロトコルは、プロセスの一部が通信サービスプロバイダーに委任される他のモデルをサポートするためにも使用できます。このドキュメントでは、これらのモデルと、ここで説明するモデルの間の相互運用性の問題の詳細については詳しく説明していません。
Since this document is a framework document, it does not include normative behavior. [PHONEBCP] describes the best current practice for this subject and contains normative language for devices as well as access and calling network elements.
このドキュメントはフレームワークドキュメントであるため、規範的な動作は含まれません。[PhoneBCP]は、この主題の最良の現在の練習を説明し、デバイスの規範的言語と、アクセスおよび呼び出しのネットワーク要素を含んでいます。
Supporting emergency calling does not require any specialized SIP header fields, request methods, status codes, message bodies, or event packages, but it does require that existing mechanisms be used in certain specific ways, as described below. User agents (UAs) unaware of the recommendations in this document may be able to place emergency calls, but functionality may be impaired. For example, if the UA does not implement the location mechanisms described, an emergency call may not be routed to the correct PSAP, and if the caller is unable to supply his exact location, dispatch of emergency responders may be delayed. Suggested behavior for both endpoints and servers is provided.
緊急通話をサポートするには、特殊なSIPヘッダーフィールド、要求方法、ステータスコード、メッセージ本文、またはイベントパッケージは必要ありませんが、以下に説明するように、既存のメカニズムを特定の方法で使用する必要があります。このドキュメントの推奨事項に気付いていないユーザーエージェント（UAS）は、緊急コールを配置できる場合がありますが、機能が損なわれる可能性があります。たとえば、UAが説明されているロケーションメカニズムを実装していない場合、緊急コールは正しいPSAPにルーティングされない可能性があり、発信者が正確な場所を提供できない場合、緊急対応者の派遣が遅れる場合があります。エンドポイントとサーバーの両方の推奨動作が提供されます。
From the point of view of the PSAP, three essential elements characterize an emergency call:
PSAPの観点から、3つの重要な要素が緊急呼び声を特徴づけています。
o The call is routed to the most appropriate PSAP, based primarily on the location of the caller.
o この呼び出しは、主に発信者の場所に基づいて、最も適切なPSAPにルーティングされます。
o The PSAP must be able to automatically obtain the location of the caller with sufficient accuracy to dispatch a responder to help the caller.
o PSAPは、発信者を支援するために応答者を派遣するのに十分な精度で発信者の位置を自動的に取得できる必要があります。
o The PSAP must be able to re-establish a session to the caller if for any reason the original session is disrupted.
o 何らかの理由で元のセッションが破壊された場合、PSAPは発信者にセッションを再確立できる必要があります。
This document uses terms from [RFC3261], [RFC5222], and [RFC5012]. In addition, the following terms are used:
この文書は、[RFC3261]、[RFC5222]、および[RFC5012]の用語を使用しています。さらに、次の用語が使用されます。
Access network: The access network supplies IP packet service to an endpoint. Examples of access networks include digital subscriber lines (DSLs), cable modems, IEEE 802.11, WiMaX, enterprise local area networks, and cellular data networks.
アクセスネットワーク：アクセスネットワークは、IPパケットサービスをエンドポイントに提供します。アクセスネットワークの例には、デジタルサブスクライバーライン（DSL）、ケーブルモデム、IEEE 802.11、Wimax、エンタープライズローカルエリアネットワーク、およびセルラーデータネットワークが含まれます。
Confidence: Confidence is an estimate indicating how sure the measuring system is that the actual location of the endpoint is within the bounds defined by the uncertainty value, expressed as a percentage. For example, a value of 90% indicates that the actual location is within the uncertainty nine times out of ten.
信頼性：信頼とは、測定システムがエンドポイントの実際の位置が不確実性値によって定義された境界内にあることを確実にすることを示す推定であり、パーセンテージとして表されます。たとえば、90％の値は、実際の場所が10のうち9回不確実性内にあることを示しています。
Dispatch location: The dispatch location is the location used for dispatching responders to the person in need of assistance. The dispatch location must be sufficiently precise to easily locate the caller; typically, it needs to be more accurate than the routing location.
発送場所：派遣場所は、支援が必要な人にレスポンダーを派遣するために使用される場所です。発信者を簡単に見つけるには、ディスパッチの場所が十分に正確でなければなりません。通常、ルーティングの場所よりも正確である必要があります。
Location configuration: During location configuration, an endpoint learns its physical location.
位置構成：場所の構成中、エンドポイントは物理的な場所を学習します。
Location Configuration Protocol (LCP): A protocol used by an endpoint to learn its location.
位置構成プロトコル（LCP）：エンドポイントがその場所を学習するために使用されるプロトコル。
Location conveyance: Location conveyance delivers location information to another element.
位置搬送：位置搬送は、別の要素に位置情報を提供します。
Location determination: Location determination finds where an endpoint is physically located. For example, the endpoint may contain a Global Navigation Satellite System (GNSS) receiver used to measure its own location or the location may be determined by a network administrator using a wiremap database.
場所の決定：場所の決定エンドポイントが物理的に配置されている場所を見つけます。たとえば、エンドポイントには、独自の場所を測定するために使用されるグローバルナビゲーション衛星システム（GNSS）レシーバーが含まれている場合があります。または、場所をWireMapデータベースを使用してネットワーク管理者によって決定できます。
Location Information Server (LIS): A Location Information Server stores location information for retrieval by an authorized entity.
Location Information Server（LIS）：位置情報サーバーは、認可されたエンティティによる検索のために位置情報を保存します。
Mobile device: A mobile device is a user agent that may change its physical location and possibly its network attachment point during an emergency call.
モバイルデバイス：モバイルデバイスは、緊急通話中に物理的な場所と、場合によってはネットワーク添付ポイントを変更する可能性のあるユーザーエージェントです。
National Emergency Number Association (NENA): The National Emergency Number Association is an organization of professionals to "foster the technological advancement, availability and implementation of a universal emergency telephone number system in North America". It develops emergency calling specifications and procedures.
National Emergency Number Association（NENA）：National Emergency Number Associationは、「北米の普遍的な緊急電話番号システムの技術的進歩、利用可能性、および実施を促進する」専門家の組織です。緊急通話の仕様と手順を開発します。
Nomadic device (user): A nomadic user agent is connected to the network temporarily, for relatively short durations, but does not move significantly during the emergency call. Examples include a laptop using an IEEE 802.11 hotspot or a desk IP phone that is moved occasionally from one cubicle to another.
Nomadic Device（ユーザー）：NOMADICユーザーエージェントは、比較的短い期間で一時的にネットワークに接続されていますが、緊急通話中はそれほど移動しません。例には、IEEE 802.11ホットスポットを使用したラップトップや、あるキュービクルから別のキュービクルに時折移動するデスクIP電話を使用するラップトップが含まれます。
Physical location: A physical location describes where a person or device is located in physical space, described by a coordinate system. It is distinguished from the network location, described by a network address.
物理的な場所：物理的な場所は、座標系によって記述された物理空間のどこにあるかを説明します。ネットワークアドレスで記述されたネットワークの場所から区別されます。
Public Safety Answering Point (PSAP): A PSAP is a call center that answers emergency calls.
公共安全留守ポイント（PSAP）：PSAPは、緊急電話に応答するコールセンターです。
Routing location: The routing location of a device is used for routing an emergency call and may not be as precise as the dispatch location.
ルーティングの場所：デバイスのルーティング場所は、緊急通話のルーティングに使用され、ディスパッチの場所ほど正確ではない場合があります。
Stationary device: An stationary device is not mobile and is connected to the network at a fixed, long-term-stable physical location. Examples include home PCs or pay phones.
固定装置：固定されたデバイスはモバイルではなく、固定された長期的な物理的位置でネットワークに接続されています。例には、自宅のPCまたはペイホンが含まれます。
Uncertainty: Uncertainty is an estimate, expressed in a unit of length, indicating the diameter of a circle that contains the endpoint with the probability indicated by the confidence value.
不確実性：不確実性は推定であり、長さの単位で表され、信頼値で示される確率を持つエンドポイントを含む円の直径を示します。
An emergency call can be distinguished (Section 5) from any other call by a unique service URN [RFC5031] that is placed in the call setup signaling when a home or visited emergency dial string is detected. Because emergency services are local to specific geographic regions, a caller obtains his location (Section 6) prior to making emergency calls. To get this location, either a form of measuring, for example, GNSS (Section 6.2.3) is deployed or the endpoint is configured (Section 6.5) with its location from the access network's Location Information Server (LIS) using a Location Configuration Protocol (LCP). The location is conveyed (Section 6.7) in the SIP signaling with the call. The call is routed (Section 8) based on location using the Location-to-Service Translation (LoST) protocol [RFC5222], which maps a location to a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that serves as an incoming proxy for a group of PSAPs. The call arrives at the PSAP with the location included in the INVITE request.
緊急通話は、家庭や訪問した緊急ダイヤルストリングが検出されたときにコールセットアップシグナリングに配置される一意のサービスURN [RFC5031]によって、他のコールと区別できます（セクション5）。緊急サービスは特定の地理的地域からローカルであるため、発信者は緊急電話を行う前に自分の位置を取得します（セクション6）。この場所を取得するには、たとえばGNSS（セクション6.2.3）が展開されるか、Access Networkの位置情報サーバー（LIS）からの場所構成プロトコルを使用してその場所でエンドポイントが展開されるか（セクション6.2.3）、測定の形式が展開されます（セクション6.5） （LCP）。場所は、呼び出しでSIPシグナリングで伝達されます（セクション6.7）。呼び出しは、場所からサービスへの翻訳（失われた）プロトコル[RFC5222]を使用した場所に基づいてルーティングされます（セクション8）。これは、場所をPSAP URISのセットにマッピングします。各URIは、PSAPまたはPSAPのグループの着信プロキシとして機能するPSAPまたは緊急サービスルーティングプロキシ（ESRP）に解決します。コールは、招待状リクエストに含まれる場所でPSAPに到着します。
The following is a quick overview for a typical Ethernet-connected telephone using SIP signaling. It illustrates one set of choices for various options presented later in this document.
以下は、SIPシグナリングを使用した典型的なイーサネット接続電話の簡単な概要です。このドキュメントで後述したさまざまなオプションの選択肢のセットを示しています。
o The phone "boots" and connects to its access network.
o 電話は「ブーツ」で、アクセスネットワークに接続します。
o The phone gets location via a Location Configuration Protocol (LCP), for example, from the DHCP server in civic [RFC4776] and/or geo [RFC6225] forms, a HTTP-Enabled Location Delivery (HELD) server [RFC5985] or the first-level switch's Link-Layer Discovery Protocol (LLDP) server [LLDP].
o 電話は、Civic [RFC4776]および/またはGeo [RFC6225]フォームのDHCPサーバーから、HTTP対応の位置配信（Held）サーバー[RFC5985]または最初の場所から、位置構成プロトコル（LCP）を介して場所を取得します。-Level Switchのリンク層ディスカバリープロトコル（LLDP）サーバー[LLDP]。
o The phone obtains the local emergency dial string(s) from the LoST [RFC5222] server for its current location. It also receives and caches the PSAP URI obtained from the LoST server.
o 電話は、現在の場所について、Lost [RFC5222]サーバーからローカル緊急ダイヤル文字列を取得します。また、失われたサーバーから取得したPSAP URIを受け取り、キャッシュします。
o Some time later, the user places an emergency call. The phone recognizes an emergency call from the dial strings and uses the "urn:service:sos" [RFC5031] URN to mark an emergency call.
o しばらくして、ユーザーは緊急通話を行います。電話は、ダイヤル文字列からの緊急通話を認識し、「urn：service：sos」[rfc5031] urnを使用して緊急コールをマークします。
o It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with its location.
o DHCPを介して位置を更新し、Lost Mappingサーバーをその場所で照会することにより、PSAPのURIを更新します。
o It puts its location in the SIP INVITE request in a Geolocation header [RFC6442] and forwards the call using its normal outbound call processing, which commonly involves an outbound proxy.
o その場所は、Geolocation Header [RFC6442]にSIP Inviteリクエストに配置し、通常のアウトバウンドプロキシを含む通常のアウトバウンドコール処理を使用してコールを転送します。
o The proxy recognizes the call as an emergency call and routes the call using normal SIP routing mechanisms to the URI specified.
o プロキシは、コールを緊急通話として認識し、指定されたURIへの通常のSIPルーティングメカニズムを使用してコールをルーティングします。
o The call routing commonly traverses an incoming proxy server (ESRP) in the emergency services network. That proxy then routes the call to the PSAP.
o 通話ルーティングは通常、緊急サービスネットワークで着信プロキシサーバー（ESRP）を通過します。そのプロキシは、PSAPへの呼び出しをルーティングします。
o The call is established with the PSAP and mutually agreed upon media streams are created.
o 呼び出しはPSAPで確立され、相互に合意されたメディアストリームが作成されます。
o The location of the caller is displayed to the call taker.
o 発信者の場所は、コールテイカーに表示されます。
Configuration Servers
. . . . . . . . . . . . . . . . .
. .
. +--------+ +----------+ .
. +--------+ | +----------+ | .
. | LIS | | | SIP | | .
. | |-+ | Registrar|-+ .
. +--------+ +----------+ .
. ^ ^ .
. . | . . . . . . . | . . . . . .
| |
|[M1][M4] |[M2]
| | +--------+
|+--------------+ +--------+ |
|| | LoST | |
||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+
||| | PSAP2 |
||| +-------+
|||
||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
Figure 1: Emergency Call Component Topology
図1：緊急コールコンポーネントトポロジ
The typical message flow for this example using Alice as the caller:
この例の典型的なメッセージフローは、アリスを発信者として使用しています。
[M1] Alice -> LIS: LCP Request(s) (ask for location)
LIS -> Alice: LCP Reply(s) (replies with location)
[M2] Alice -> Registrar: SIP REGISTER
Registrar -> Alice: SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server: Initial LoST Query (contains location)
Lost Server -> Alice: Initial LoST Response (contains
PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call:
しばらくして、アリスはダイヤルしたり、緊急電話を開始したりします。
[M4] Alice -> LIS: LCP Request (updates location)
LIS -> Alice: LCP Reply (replies with location)
[M5] Alice -> LoST Server: Update LoST Query (contains location)
Lost Server -> Alice: LoST Response (contains PSAP-URI)
[M6] Alice -> Outgoing Proxy: SIP INVITE (contains service URN,
Location and PSAP URI)
[M7] Outgoing Proxy -> ESRP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M8] ESRP -> PSAP: SIP INVITE (contains service URN,
Location and PSAP URI)
The 200 OK response is propagated back from the PSAP to Alice and the ACK response is propagated from Alice to the PSAP.
200 OK応答はPSAPからアリスに伝播され、ACK応答はアリスからPSAPに伝播されます。
Figure 2: Message Flow
図2：メッセージフロー
Figure 1 shows emergency call component topology and the text above shows call establishment. These include the following components:
図1は緊急コールコンポーネントトポロジーを示しており、上記のテキストはコール確立を示しています。これらには、次のコンポーネントが含まれます。
o Alice - the user of a UA that places the emergency call.
o アリス - 緊急電話をかけるUAのユーザー。
o Configuration servers - Servers providing Alice's UA its IP address and other configuration information, perhaps including location-by-value or location-by-reference. Configuration servers also may include a SIP registrar for Alice's UA. Most SIP UAs will register, so it will be a common scenario for UAs that make emergency calls to be registered with such a server in the originating calling network. In most cases, a UA would have to register in order for the PSAP to be able to call it back after an emergency call has been completed. All the configuration messages are labeled M1 through M3, but could easily require more than three messages to complete.
o 構成サーバー-AliceのUAのIPアドレスとその他の構成情報を提供するサーバー、おそらく価値ごとまたは場所ごとに含まれるものです。構成サーバーには、アリスのUAのSIPレジストラも含まれます。ほとんどのSIP UASが登録されるため、発信元の呼び出しネットワークでそのようなサーバーに登録されるように緊急通話を行うUASの一般的なシナリオになります。ほとんどの場合、PSAPが緊急電話が完了した後にPSAPを呼び戻すことができるように、UAは登録する必要があります。すべての構成メッセージには、M1からM3というラベルが付いていますが、完了するには3つ以上のメッセージが簡単に必要になる場合があります。
o LoST server - Processes the LoST request for location plus a service URN to a PSAP-URI, either for an initial request from a UA or an in-call routing by the proxy server in the originating network, or possibly by an ESRP.
o 失われたサーバー - ロケーションの失われた要求とPSAP-URIへのサービスURNを処理します。これは、UAからの初期リクエストまたは発信ネットワークのプロキシサーバー、またはESRPによるコール内ルーティングのいずれかです。
o ESRP - Emergency Services Routing Proxy, a SIP proxy server that is the incoming call proxy in the emergency services domain. The ESRP makes further routing decisions (e.g., based on PSAP state and the location of the caller) to choose the actual PSAP that handles the call. In some jurisdictions, this may involve another LoST query.
o ESRP-緊急サービスルーティングプロキシ、緊急サービスドメインの着信コールプロキシであるSIPプロキシサーバー。ESRPは、コールを処理する実際のPSAPを選択するために、さらにルーティングの決定（例えば、PSAP状態と発信者の場所に基づいて）を行います。一部の管轄区域では、これには別の失われたクエリが含まれる場合があります。
o PSAP - Emergency calls are answered at a Public Safety Answering Point, a call center.
o PSAP-緊急通話は、コールセンターである公共の安全の応答ポイントで回答されます。
Generally, Alice's UA either has location configured manually, has an integral location measurement mechanism, or runs an LCP [M1] to obtain location from the access (broadband) network. Then, Alice's UA will most likely register [M2] with a SIP registrar. This allows her to be contacted by other SIP entities. Next, her UA will perform an initial LoST query [M3] to learn a URI for use if the LoST query fails during an emergency call or to use to test the emergency call mechanism. The LoST response contains the dial string for emergency calls appropriate for the location provided.
一般的に、AliceのUAには、位置が手動で構成されているか、積分位置測定メカニズムがあるか、LCP [M1]を実行してアクセス（ブロードバンド）ネットワークから場所を取得します。その後、アリスのUAは、おそらく[M2]がSIPレジストラに登録します。これにより、彼女は他のSIPエンティティから連絡を受けることができます。次に、彼女のUAは、初期の失われたクエリ[M3]を実行して、緊急通話中に失われたクエリが失敗した場合、または緊急通話メカニズムのテストに使用する場合に使用するURIを学習します。失われた応答には、提供される場所に適した緊急通話のダイヤル文字列が含まれています。
At some time after her device has booted, Alice initiates an emergency call. She may do this by dialing an emergency dial string valid for her current ("local") location or for her "home" location.
彼女のデバイスが起動した後の時点で、アリスは緊急電話を開始します。彼女は、現在の（「ローカル」）場所または彼女の「家」の場所に有効な緊急ダイヤル文字列をダイヤルすることにより、これを行うことができます。
The UA recognizes either dial string. The UA attempts to refresh its location [M4], and with that location, to refresh the LoST mapping [M5], in order to get the most accurate information to use for routing the call. If the location request or the LoST request fails, or takes too long, the UA uses values it has cached.
UAはどちらのダイヤル文字列を認識します。UAは、その場所[M4]を更新し、その場所で、コールのルーティングに使用する最も正確な情報を取得するために、失われたマッピング[M5]を更新しようとします。ロケーションリクエストまたは失われた要求が失敗した場合、または時間がかかりすぎると、UAはキャッシュされた値を使用します。
The UA creates a SIP INVITE [M6] request that includes the location. [RFC6442] defines a SIP Geolocation header that contains either a location-by-reference URI or a [RFC3986] "cid:" URL indicating where in the message body the location-by-value is.
UAは、場所を含むSIP Invite [M6]リクエストを作成します。[RFC6442]は、ロケーションごとのURIまたは[RFC3986] "cid："メッセージ本文のどこにあるかを示す[rfc3986]のいずれかを含むSIPジオロケーションヘッダーを定義します。
The INVITE message is routed to the ESRP [M7], which is the first inbound proxy for the emergency services domain. This message is then routed by the ESRP towards the most appropriate PSAP for Alice's location [M8], as determined by the location and other information.
招待メッセージは、ESRP [M7]にルーティングされます。これは、緊急サービスドメインの最初のインバウンドプロキシです。このメッセージは、ESRPによって、場所やその他の情報によって決定されるように、Aliceの場所[M8]の最も適切なPSAPに向かってルーティングされます。
A proxy in the PSAP chooses an available call taker and extends the call to its UA.
PSAPのプロキシは、利用可能なコールテイカーを選択し、その呼び出しをUAに拡張します。
The 200 OK response to the INVITE request traverses the path in reverse, from call taker UA to PSAP proxy to ESRP to originating network proxy to Alice's UA. The ACK request completes the call setup and the emergency call is established, allowing the PSAP call taker to talk to Alice about Alice's emergency.
招待リクエストに対する200 OK応答は、コールテイカーUAからPSAPプロキシ、ESRP、アリスのUAへのネットワークプロキシまで、逆のパスを逆に横断します。ACKリクエストはコールセットアップを完了し、緊急コールが確立され、PSAPコールテイカーはアリスの緊急事態についてアリスと話すことができます。
Current PSAPs support voice calls and real-time text calls placed through PSTN facilities or systems connected to the PSTN. However, future PSAPs will support Internet connectivity and a wider range of media types and provide higher functionality. In general, if a user could reasonably expect to be able to place a call for help with the device, then the device or service should support emergency calling. Certainly, any device or service that looks like and works like a telephone (wired or mobile) should support emergency calling, but increasingly, users have expectations that other devices and services should work.
現在のPSAPは、PSTN施設またはPSTNに接続されたシステムを介して配置された音声通話とリアルタイムテキストコールをサポートしています。ただし、将来のPSAPは、インターネット接続と幅広いメディアタイプをサポートし、より高い機能を提供します。一般に、ユーザーがデバイスの支援を求めることができると合理的に期待できる場合、デバイスまたはサービスは緊急通話をサポートする必要があります。確かに、電話（有線またはモバイル）のように見えるデバイスやサービスは、緊急通話をサポートする必要がありますが、ますますユーザーが他のデバイスやサービスが機能することを期待しています。
Devices that create media sessions and exchange audio, video, and/or text and that have the capability to establish sessions to a wide variety of addresses and communicate over private IP networks or the Internet should support emergency calls.
メディアセッションを作成し、オーディオ、ビデオ、および/またはテキストを交換し、セッションをさまざまなアドレスに確立し、プライベートIPネットワークまたはインターネットを介して通信する機能を備えたデバイスは、緊急通話をサポートする必要があります。
Traditionally, enterprise support of emergency calling is provided by the telephony service provider to the enterprise. In some more recent systems, the enterprise Private Branch Exchange (PBX) assists emergency calling by providing more fine-grained location in larger enterprises. In the future, the enterprise may provide the connection to emergency services itself, not relying on the telephony service provider.
従来、緊急通話のエンタープライズサポートは、テレフォニーサービスプロバイダーによってエンタープライズに提供されています。いくつかの最近のシステムでは、エンタープライズプライベートブランチエクスチェンジ（PBX）は、大規模な企業でよりきめ細かい場所を提供することにより、緊急通話を支援します。将来的には、企業は、テレフォニーサービスプロバイダーに依存せずに、緊急サービス自体との接続を提供する場合があります。
Using the PSTN, emergency help can often be summoned by dialing a nationally designated, widely known number, regardless of where the telephone was purchased. The appropriate number is determined by the infrastructure to which the telephone is connected. However, this number differs between localities, even though it is often the same for a country or region, as it is in many countries in the European Union. In some countries, there is only one uniform digit sequence that is used for all types of emergencies. In others, there are several sequences that are specific to the type of responder needed, e.g., one for police, another for fire. For end systems, on the other hand, it is desirable to have a universal identifier, independent of location, to allow the automated inclusion of location
PSTNを使用して、電話がどこで購入されたかに関係なく、全国的に指定された広く知られている数字をダイヤルすることにより、緊急支援を召喚することができます。適切な番号は、電話が接続されているインフラストラクチャによって決定されます。ただし、この数は、欧州連合の多くの国であるため、国や地域で同じであることが多い場合でも、地域間で異なります。一部の国では、あらゆる種類の緊急事態に使用される均一な数字シーケンスは1つだけです。他の人には、必要な応答者のタイプに固有のいくつかのシーケンスがあります。たとえば、警察用、もう1つは火災のためです。一方、エンドシステムの場合、場所を自動化することを可能にするために、場所とは無関係にユニバーサル識別子を持つことが望ましいです
information and to allow the device and other entities in the call path to perform appropriate processing within the signaling protocol in an emergency call setup.
情報と、コールパス内のデバイスおよびその他のエンティティが、緊急コールセットアップでシグナリングプロトコル内で適切な処理を実行することを許可します。
Since no such universal identifier existed, the overall emergency calling architecture described here defines common emergency call URNs [RFC5031]. When all emergency services use a single number, the URN is "urn:service:sos". Users are not expected to "dial" an emergency URN. Rather, appropriate emergency dial strings are translated to corresponding service URNs, carried in the Request-URI of the INVITE request. Such translation is best done by the endpoint, because, among other reasons, emergency calls convey location in the signaling but non-emergency calls normally do not. If the device recognizes the emergency call, it can include location, if known. A signaling intermediary (proxy server) can also recognize emergency dial strings if the endpoint fails to do so.
このような普遍的な識別子は存在しないため、ここで説明する全体的な緊急呼び出しアーキテクチャは、一般的な緊急呼び出しのurns [RFC5031]を定義しています。すべての緊急サービスが単一の数値を使用する場合、urは「urn：service：sos」です。ユーザーは、緊急urを「ダイヤル」することは期待されていません。むしろ、適切な緊急ダイヤル文字列が対応するサービスURNに翻訳され、招待リクエストのリクエスト-URIに携帯されています。このような翻訳は、他の理由の中でも、緊急コールが信号の場所を伝えているが、通常は緊急の呼び出しではないため、エンドポイントで行うのが最適です。デバイスが緊急通話を認識した場合、既知の場合は場所を含めることができます。シグナリング仲介（プロキシサーバー）は、エンドポイントがそうしなかった場合、緊急ダイヤル文字列を認識することもできます。
For devices that are mobile or nomadic, an issue arises of whether the home or visited dial strings should be used. Many users would prefer that their home dialing sequences work no matter where they are. However, local laws and regulations may require that the visited dialing sequence(s) work. Therefore, the visited dial string must work. Devices may have a way to be configured or learn home dial strings.
モバイルまたは遊牧民のデバイスの場合、自宅または訪問したダイヤル文字列を使用するかどうかの問題が発生します。多くのユーザーは、自宅のダイヤルシーケンスがどこにいても機能することを好むでしょう。ただし、現地の法律と規制では、訪問されたダイヤルシーケンスが機能することが必要になる場合があります。したがって、訪問されたダイヤル文字列は機能する必要があります。デバイスには、ホームダイヤル文字列を構成または学習する方法がある場合があります。
LoST [RFC5222] provides the mechanism for obtaining the dialing sequences for a given location. LoST servers must return dial strings for emergency services. If the endpoint does not support the translation of dial strings to service URNs, the dialing sequence from the endpoint to its proxy is represented as a dial string [RFC4967] and the outgoing proxy must recognize the dial string and translate it to the equivalent service URN. To determine the local emergency dial string, the proxy needs the location of the endpoint. This may be difficult in situations where the user can roam or be nomadic. Endpoint recognition of emergency dial strings is therefore preferred. If a service provider is unable to guarantee that it can correctly determine local emergency dial strings, wherever its subscribers may be, then it is required that the endpoint do the recognition.
Lost [RFC5222]は、特定の位置のダイヤルシーケンスを取得するメカニズムを提供します。紛失したサーバーは、緊急サービスのためにダイヤル文字列を返す必要があります。エンドポイントがダイヤル文字列のサービスURNをサポートしていない場合、エンドポイントからそのプロキシへのダイヤルシーケンスはダイヤル文字列[RFC4967]として表され、発信プロキシはダイヤル文字列を認識し、同等のサービスURNに変換する必要があります。。ローカルの緊急ダイヤル文字列を決定するには、プロキシにエンドポイントの位置が必要です。これは、ユーザーが歩き回ったり遊牧民になることができる状況では難しいかもしれません。したがって、緊急ダイヤル文字列のエンドポイント認識が推奨されます。サービスプロバイダーが、地元の緊急ダイヤル文字列を正しく決定できることを保証できない場合、サブスクライバーがどこにいても、エンドポイントが認識を行う必要があります。
Note: The emergency call practitioners consider it undesirable to have a single-button emergency call user interface element. These mechanisms tend to result in a very high rate of false or accidental emergency calls. In order to minimize this issue, practitioners recommend that devices should only initiate emergency calls based on entry of specific emergency call dial strings. Speed dial mechanisms may effectively create single-button emergency call invocation and practitioners recommend they not be permitted.
注：緊急コールプラクティショナーは、単一ボタンの緊急通話ユーザーインターフェイス要素を持つことは望ましくないと考えています。これらのメカニズムは、誤ったまたは偶発的な緊急呼び出しの割合が非常に高い傾向があります。この問題を最小限に抑えるために、実務家は、特定の緊急コールダイヤル文字列の入力に基づいて、デバイスが緊急通話のみを開始することを推奨します。スピードダイヤルメカニズムは、シングルボタンの緊急通話呼び出しの呼び出しを効果的に作成する可能性があり、開業医は許可されないことを推奨します。
Location is central to the operation of emergency services. Location is used for two purposes in emergency call handling: routing of the call and dispatch of responders. It is frequently the case that the callers reporting an emergency are unable to provide a unique, valid location themselves. For this reason, location provided by the endpoint or the access network is needed. For practical reasons, each PSAP generally handles only calls for a certain geographic area, with overload arrangements between PSAPs to handle each others' calls. Other calls that reach it by accident must be manually re-routed (transferred) to the more appropriate PSAP, increasing call handling delay and the chance for errors. The area covered by each PSAP differs by jurisdiction, where some countries have only a small number of PSAPs, while others decentralize PSAP responsibilities to the level of counties or municipalities.
場所は、緊急サービスの運用の中心です。場所は、緊急通話処理の2つの目的に使用されます。通話のルーティングとレスポンダーの派遣。多くの場合、緊急事態を報告している発信者が独自の有効な場所自体を提供できない場合があります。このため、エンドポイントまたはアクセスネットワークによって提供される場所が必要です。実際的な理由から、各PSAPは通常、特定の地理的領域の呼び出しのみを処理し、互いの呼び出しを処理するためのPSAP間の過負荷の配置を備えています。偶然に到達するその他の呼び出しは、より適切なPSAPに手動で再ルーティング（転送）する必要があり、コール処理の遅延とエラーの可能性を増加させる必要があります。各PSAPでカバーされているエリアは管轄区域によって異なり、一部の国では少数のPSAPしかありませんが、他の国ではPSAPの責任を郡または自治体のレベルに分散させています。
In most cases, PSAPs cover at least a city or town, but there are some areas where PSAP coverage areas follow old telephone rate center boundaries and may straddle more than one city. Irregular boundaries are common, often due to historical reasons. Routing must be done based on actual PSAP service boundaries -- the closest PSAP, or the PSAP that serves the nominal city name provided in the location, may not be the correct PSAP.
ほとんどの場合、PSAPは少なくとも都市または町をカバーしていますが、PSAPのカバレッジエリアが古い電話料金の中心境界をたどり、複数の都市にまたがる可能性があるエリアがいくつかあります。不規則な境界は一般的であり、多くの場合、歴史的な理由によるものです。ルーティングは、実際のPSAPサービスの境界（最も近いPSAP、またはその場所で提供される名目上の都市名を提供するPSAP）に基づいて行う必要がありますが、正しいPSAPではない場合があります。
Accuracy of routing location is a complex subject. Calls must be routed quickly, but accurately, and location determination is often a time/accuracy trade-off, especially with mobile devices or self-measuring mechanisms. If a more accurate routing location is not available, it is considered acceptable to base a routing decision on an accuracy equal to the area of one sector of a mobile cell site.
ルーティング場所の精度は複雑な主題です。呼び出しは迅速に、しかし正確にルーティングする必要があり、場所の決定は、特にモバイルデバイスまたは自己測定メカニズムの場合、時間/精度のトレードオフであることがよくあります。より正確なルーティングの場所が利用できない場合、モバイルセルサイトの1つのセクターの面積に等しい精度に基づいてルーティング決定を下すことは許容されると見なされます。
Routing to the most appropriate PSAP is always based on the location of the caller, despite the fact that some emergency calls are placed on behalf of someone else, and the location of the incident is sometimes not the location of the caller. In some cases, there are other factors that enter into the choice of the PSAP that gets the call, such as time of day, caller media requests, language preference, and call load. However, location of the caller is the primary input to the routing decision.
最も適切なPSAPへのルーティングは、いくつかの緊急電話が他の誰かに代わって配置され、インシデントの場所が発信者の場所ではないという事実にもかかわらず、常に発信者の場所に基づいています。場合によっては、時間の時間、発信者のメディアリクエスト、言語選好、コールロードなど、通話を受けるPSAPの選択に入る他の要因があります。ただし、発信者の場所は、ルーティング決定への主要な入力です。
Many mechanisms used to locate a caller have a relatively long "cold start" time. To get a location accurate enough for dispatch may take as much as 30 seconds. This is too long to wait for emergencies. Accordingly, it is common, especially in mobile systems, to use a coarse location, for example, the cell site and sector serving the call, for call-routing purposes, and then to update the location when
発信者を見つけるために使用される多くのメカニズムには、比較的長い「コールドスタート」時間があります。ディスパッチに十分な正確な場所を取得するには、30秒もかかる場合があります。これは緊急事態を待つには長すぎます。したがって、特にモバイルシステムでは、コールルーティングの目的で、コールにサービスを提供するセルサイトとセクターなど、粗い場所を使用し、その後、場所を更新することが一般的です。
a more precise value is known prior to dispatch. In this document, we use "routing location" and "dispatch location" when the distinction matters.
ディスパッチの前に、より正確な値が知られています。このドキュメントでは、区別が重要な場合は、「ルーティング場所」と「ディスパッチ場所」を使用します。
Accuracy of dispatch location is sometimes determined by local regulation, and is constrained by available technology. The actual requirement is more stringent than available technology can deliver: It is required that a device making an emergency call close to the "demising" or separation wall between two apartments in a high-rise apartment building report location with sufficient accuracy to determine on what side of the wall it is. This implies perhaps a 3 cm accuracy requirement. As of the date of this memo, assisted GNSS uncertainty in mobile phones with 95% confidence cannot be relied upon to be less than hundreds of meters. As technology advances, the accuracy requirements for location will need to be tightened. Wired systems using wire-tracing mechanisms can provide location to a wall jack in specific room on a floor in a building, and may even specify a cubicle or even smaller resolution. As this discussion illustrates, emergency call systems demand the most stringent location accuracy available.
ディスパッチの場所の精度は、現地の規制によって決定されることがあり、利用可能な技術によって制約されます。実際の要件は、利用可能なテクノロジーが提供できるよりも厳しいものです。高層アパートメントの建物レポートの場所にある2つのアパート間の「デミス」または分離壁の近くに緊急通話を行うデバイスが十分な精度で、何を決定するのに十分な精度を決定することが必要です。壁の側面です。これは、おそらく3 cmの精度要件を意味します。このメモの日付の時点で、95％の自信を持つ携帯電話でのGNSSの不確実性を支援することは、数百メートル未満に頼ることはできません。テクノロジーが進むにつれて、場所の精度要件を強化する必要があります。ワイヤトレースメカニズムを使用した有線システムは、建物の床にある特定の部屋の壁ジャックに位置を提供し、キュービクルまたはより小さな解像度を指定することもできます。この議論が示すように、緊急通話システムには、利用可能な最も厳しい場所の精度が必要です。
In Internet emergency calling, where the endpoint is located is determined using a variety of measurement or wire-tracing methods. Endpoints may be configured with their own location by the access network. In some circumstances, a proxy server may insert location into the signaling on behalf of the endpoint. The location is mapped to the URI to send the call to, and the location is conveyed to the PSAP (and other elements) in the signaling. The terms "determination", "configuration", "mapping", and "conveyance" are used for specific aspects of location handling in IETF protocols. Likewise, we employ Location Configuration Protocols, Location Mapping Protocols, and Location Conveyance Protocols for these functions.
インターネットの緊急通話では、エンドポイントが配置されている場所は、さまざまな測定またはワイヤトレースの方法を使用して決定されます。エンドポイントは、アクセスネットワークによって独自の場所で構成される場合があります。状況によっては、プロキシサーバーがエンドポイントに代わって信号に位置を挿入する場合があります。場所はURIにマッピングされて電話を送信し、その場所はシグナリングのPSAP（およびその他の要素）に伝えられます。「決定」、「構成」、「マッピング」、および「搬送」という用語は、IETFプロトコルの位置処理の特定の側面に使用されます。同様に、これらの機能には、位置構成プロトコル、ロケーションマッピングプロトコル、およびロケーションキャベサンスプロトコルを採用しています。
This document provides guidance for generic network configurations with respect to location. It is recognized that unique issues may exist in some network deployments. The IETF will continue to investigate these unique situations and provide further guidance, if warranted, in future documents.
このドキュメントは、場所に関する一般的なネットワーク構成のガイダンスを提供します。一部のネットワーク展開には、一意の問題が存在する可能性があることが認識されています。IETFは、これらのユニークな状況を引き続き調査し、将来の文書において、保証された場合、さらなるガイダンスを提供します。
Location can be specified in several ways:
場所はいくつかの方法で指定できます。
Civic: Civic location information describes the location of a person or object by a street address that corresponds to a building or other structure. Civic location may include more fine-grained location information such as floor, room, and cubicle. Civic information comes in two forms:
CIVIC：市民の位置情報は、建物やその他の構造に対応する通りの住所による人または物の場所を説明しています。市民の場所には、床、部屋、キュービクルなどのよりきめ細かい場所情報が含まれます。市民情報には2つの形式があります。
"Jurisdictional" refers to a civic location using actual political subdivisions, especially for the community name.
「管轄区域」とは、特にコミュニティ名の実際の政治的下位区分を使用した市民の場所を指します。
"Postal" refers to a civic location for mail delivery. The name of the post office sometimes does not correspond to the community name and a postal address may contain post office boxes or street addresses that do not correspond to an actual building. Postal addresses are generally unsuitable for emergency call dispatch because the post office conventions (for community name, for example) do not match those known by the responders. The fact that they are unique can sometimes be exploited to provide a mapping between a postal address and a civic address suitable to which to dispatch a responder. In IETF location protocols, there is an element (Postal Community Name) that can be included in a location to provide the post office name as well as the actual jurisdictional community name. There is also an element for a postal code. There is no other accommodation for postal addresses in these protocols.
「郵便」とは、郵便配達のための市民の場所を指します。郵便局の名前はコミュニティ名に対応せず、郵便住所には実際の建物に対応しない郵便局の箱または路上住所が含まれる場合があります。郵便局の条約（たとえば、コミュニティ名など）はレスポンダーが既知のものと一致しないため、郵便住所は一般に緊急コールディスパッチには適さない。それらがユニークであるという事実は、郵便住所と応答者を派遣するのに適した市民住所との間のマッピングを提供するために悪用されることがあります。IETFロケーションプロトコルには、郵便局の名前と実際の管轄コミュニティ名を提供するために場所に含めることができる要素（郵便コミュニティ名）があります。郵便番号の要素もあります。これらのプロトコルには、郵便アドレスのための他の宿泊施設はありません。
Geospatial (geo): Geospatial addresses contain longitude, latitude, and altitude information based on an understood datum and earth shape model (datum). While there have been many datums developed over time, most modern systems are using or moving towards the WGS84 [WGS84] datum.
地理空間（GEO）：地理空間住所には、理解されたデータムと地球形状モデル（データム）に基づいて、経度、緯度、高度情報が含まれています。時間の経過とともに開発された多くのデータムがありましたが、ほとんどの最新のシステムはWGS84 [WGS84]データムを使用または移動しています。
Cell tower/sector: Cell tower/sector is often used for identifying the location of a mobile handset, especially for routing of emergency calls. Cell tower and sectors identify the cell tower and the antenna sector that a mobile device is currently using. Traditionally, the tower location is represented as a point chosen to be within a certain PSAP service boundary that agrees to take calls originating from that tower/sector, and routing decisions are made on that point. Cell tower/sector information could also be represented as an irregularly shaped polygon of geospatial coordinates reflecting the likely geospatial location of the mobile device. Whatever representation is used must route correctly in the LoST database, where "correct" is determined by local PSAP management.
セルタワー/セクター：セルタワー/セクターは、特に緊急電話のルーティングのために、モバイルハンドセットの場所を特定するためによく使用されます。セルタワーとセクターは、モバイルデバイスが現在使用しているセルタワーとアンテナセクターを特定します。伝統的に、タワーの場所は、そのタワー/セクターから発信された呼び出しを行うことに同意する特定のPSAPサービス境界内にあるように選択されたポイントとして表され、その点でルーティングの決定がなされます。セルタワー/セクターの情報は、モバイルデバイスの地理空間的位置を反映した地理空間座標の不規則な形状のポリゴンとして表現することもできます。使用される表現はすべて、「正しい」がローカルPSAP管理によって決定される失われたデータベースに正しくルーティングする必要があります。
In IETF protocols, both civic and geospatial forms are supported. The civic forms include both postal and jurisdictional fields. A cell tower/sector can be represented as a geo point or polygon or civic location. Other forms of location representation must be mapped into either a geo or civic value for use in emergency calls.
IETFプロトコルでは、市民と地理空間の両方の形態がサポートされています。市民形式には、郵便および管轄区域の両方が含まれます。セルタワー/セクターは、ジオポイント、ポリゴン、または市民の場所として表すことができます。他の形式の場所表現は、緊急通話で使用するためのGEOまたは市民価値のいずれかにマッピングする必要があります。
For emergency call purposes, conversion of location information from civic to geo or vice versa prior to conveyance is not desirable. The location should be sent in the form it was determined. Conversion between geo and civic requires a database. Where PSAPs need to convert from whatever form they received to another for responder purposes, they have a suitable database. However, if a conversion is done before the PSAP's, and the database used is not exactly the same one the PSAP uses, the double conversion has a high probability of introducing an error.
緊急コールの目的では、輸送前の市民情報情報の変換、またはその逆の逆の変換は望ましくありません。場所は、決定された形式で送信する必要があります。GEOとCivicの間の変換には、データベースが必要です。PSAPは、レスポンダーの目的で受け取ったフォームから別のフォームに変換する必要がある場合、適切なデータベースがあります。ただし、PSAPの前に変換が行われ、使用されるデータベースがPSAPが使用するデータベースとはまったく同じではない場合、二重変換はエラーを導入する可能性が高いです。
As noted above, location information can be entered by the user or installer of a device ("manual configuration"), measured by the end system, be delivered to the end system by some protocol or measured by a third party, and be inserted into the call signaling.
上記のように、場所情報は、エンドシステムによって測定されたデバイスのユーザーまたはインストーラー（「手動構成」）によって入力され、一部のプロトコルによってエンドシステムに配信されるか、サードパーティによって測定され、挿入されます。コールシグナリング。
In some cases, an entity may have multiple sources of location information, possibly some that are partially contradictory. This is particularly likely if the location information is determined both by the end system and a third party. Although self-measured location (e.g., GNSS) is attractive, location information provided by the access network could be much more accurate, and more reliable in some environments such as high-rise buildings in dense urban areas.
場合によっては、エンティティには複数の位置情報源があり、おそらく部分的に矛盾しているものもあります。これは、位置情報が最終システムと第三者の両方によって決定される場合に特にありそうです。自己測定の場所（GNSなど）は魅力的ですが、アクセスネットワークが提供する位置情報は、密集した都市部の高層ビルなどの環境でははるかに正確で、より信頼性が高くなる可能性があります。
The closer an entity is to the source of location, the more likely it is able to determine which location is most appropriate for a particular purpose when there is more than one location determination for a given endpoint. In emergency calling, the PSAP is the least likely to be able to appropriately choose which location to use when multiple conflicting locations are presented to it. While all available locations can be sent towards the PSAP, the order of the locations should be the sender's best attempt to guide the recipient of which one(s) to use.
エンティティが場所のソースに近いほど、特定のエンドポイントに複数の場所を決定する場合、特定の目的に最も適している場所を決定できる可能性が高くなります。緊急通話では、PSAPは、複数の競合する場所が表示されている場合に使用する場所を適切に選択できる可能性が最も低くなります。利用可能なすべての場所はPSAPに向けて送信できますが、場所の順序は、使用する受信者をガイドするための送信者の最良の試みである必要があります。
Location information can be maintained by the end user or the installer of an endpoint in the endpoint itself, or in a database.
位置情報は、エンドユーザーまたはエンドポイント自体のエンドポイントのインストーラー、またはデータベースによって維持できます。
Location information routinely provided by end users is almost always less reliable than measured or wire database information, as users may mistype location information or may enter civic address information that does not correspond to a recognized (i.e., valid, see Section 6.10) address. Users can forget to change the data when the location of a device changes.
エンドユーザーが日常的に提供する位置情報は、ユーザーが位置情報を間違えるか、認識されている（つまり、有効、セクション6.10を参照）アドレスに対応していない市民アドレス情報を入力する場合があるため、測定またはワイヤーデータベース情報よりもほとんど常に信頼性が低くなります。ユーザーは、デバイスの場所が変更されたときにデータを変更するのを忘れることができます。
However, there are always a small number of cases where the automated mechanisms used by the access network to determine location fail to accurately reflect the actual location of the endpoint. For example, the user may deploy his own WAN behind an access network, effectively removing an endpoint some distance from the access network's notion of its location. To handle these exceptional cases, there must be some mechanism provided to manually provision a location for an endpoint by the user or by the access network on behalf of a user. The use of the mechanism introduces the possibility of users falsely declaring themselves to be somewhere they are not. However, this is generally not a problem in practice. Commonly, if an emergency caller insists that he is at a location different from what any automatic location determination system reports he is, responders will always be sent to the user's self-declared location.
ただし、アクセスネットワークで使用される自動化されたメカニズムが、エンドポイントの実際の位置を正確に反映できないと判断するためにアクセスネットワークで使用される自動メカニズムが常にあります。たとえば、ユーザーはアクセスネットワークの後ろに自分のWANを展開し、アクセスネットワークの場所の概念からエンドポイントを効果的に削除することができます。これらの例外的なケースを処理するには、ユーザーまたはユーザーに代わってアクセスネットワークによってエンドポイントの場所を手動で提供するためのメカニズムが提供されなければなりません。メカニズムの使用は、ユーザーが自分がそうでない場所に誤って自分自身を宣言する可能性を導入します。ただし、これは一般的に実際には問題ではありません。一般的に、緊急発信者が、自動位置決定システムが報告する場所とは異なる場所にいると主張する場合、レスポンダーは常にユーザーの自己宣言的な場所に送られます。
Location information can be maintained by the access network, relating some form of identifier for the end subscriber or device to a location database ("wire database"). In enterprise LANs, wiremap databases map Ethernet switch ports to building locations. In DSL installations, the local telephone carrier maintains a mapping of wire-pairs to subscriber addresses.
位置情報は、アクセスネットワークによって維持でき、エンドサブスクライバーまたはデバイスの何らかの識別子をロケーションデータベース（「ワイヤーデータベース」）に関連付けます。Enterprise LANSでは、WireMapデータベースは、イーサネットスイッチポートを建物の場所にマッピングします。DSLのインストールでは、地元の電話キャリアは、サブスクライバーアドレスへのワイヤーペアのマッピングを維持しています。
Accuracy of location historically has been to a street-address level. However, this is not sufficient for larger structures. The Presence Information Data Format (PIDF) Location Object [RFC4119], extended by [RFC5139] and [RFC5491], permits interior building, floor, and room and even finer specification of location within a street address. When possible, interior location should be supported.
歴史的に場所の正確性は、ストリートアドレスレベルにありました。ただし、これはより大きな構造には十分ではありません。[RFC5139]および[RFC5491]で拡張された存在情報データ形式（PIDF）ロケーションオブジェクト[RFC4119]は、インテリアの建物、床、部屋、さらには通りの住所内の場所の仕様を可能にします。可能であれば、内部の場所をサポートする必要があります。
The threshold for when interior location is needed is approximately 650 square meters. This value is derived from US fire brigade recommendations of spacing of alarm pull stations. However, interior space layout, construction materials, and other factors should be considered.
内部の場所が必要な場合のしきい値は、約650平方メートルです。この値は、アラームプルステーションの間隔に関する米国の消防隊の推奨事項から派生しています。ただし、内部スペースのレイアウト、建設資材、その他の要因を考慮する必要があります。
Even for IEEE 802.11 wireless access points, wire databases may provide sufficient location resolution. The location of the access point as determined by the wiremap may be supplied as the location for each of the clients of the access point. However, this may not
IEEE 802.11ワイヤレスアクセスポイントであっても、ワイヤーデータベースは十分な場所解像度を提供する場合があります。WireMapによって決定されるアクセスポイントの位置は、アクセスポイントの各クライアントの場所として提供される場合があります。ただし、これはそうではないかもしれません
be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE 802.22 that typically have larger cells than those of IEEE 802.11. The civic location of an IEEE 802.16 base station may be of little use to emergency personnel, since the endpoint could be several kilometers away from the base station.
IEEE 802.16（WIMAX）やIEEE 802.22などの大規模システムには、IEEE 802.11の細胞よりも大きな細胞がある場合は真実です。エンドポイントは基地局から数キロ離れている可能性があるため、IEEE 802.16の基地局の市民の場所は緊急職員にとってほとんど役に立たない場合があります。
Wire databases are likely to be the most promising solution for residential users where a service provider knows the customer's service address. The service provider can then perform address validation (see Section 6.10), similar to the current system in some jurisdictions.
ワイヤーデータベースは、サービスプロバイダーが顧客のサービスアドレスを知っている住宅ユーザーにとって最も有望なソリューションである可能性があります。サービスプロバイダーは、一部の管轄区域の現在のシステムと同様に、アドレス検証（セクション6.10を参照）を実行できます。
Global Positioning System (GPS) and similar Global Navigation Satellite Systems (e.g., GLONAS and Galileo) receivers may be embedded directly in the end device. GNSS produces relatively high precision location fixes in open-sky conditions, but the technology still faces several challenges in terms of performance (time-to-fix and time-to-first-fix), as well as obtaining successful location fixes within shielded structures, or underground. It also requires all devices to be equipped with the appropriate GNSS capability. Many mobile devices require using some kind of "assist", that may be operated by the access network (A-GPS) or by a government (WAAS). A device may be able to use multiple sources of assist data.
グローバルポジショニングシステム（GPS）および同様のグローバルナビゲーション衛星システム（GlonasやGalileoなど）レシーバーは、エンドデバイスに直接埋め込むことができます。GNSSは、オープンスキー条件で比較的高い精度の位置固定を生成しますが、テクノロジーはパフォーマンス（時間からフィックスまでの時間とフィックスまでの時間）の点でいくつかの課題に直面しており、シールド構造内の位置修正を成功させることができます。、または地下。また、すべてのデバイスに適切なGNSS機能を装備する必要があります。多くのモバイルデバイスは、アクセスネットワーク（A-GPS）または政府（WAAS）によって運用される可能性のある何らかの「アシスト」を使用する必要があります。デバイスは、複数のアシストデータのソースを使用できる場合があります。
The GNSS satellites are active continuously; thus, location will always be available as long as the device can "see" enough satellites. However, mobile devices may not be able to afford the power levels required to keep the measuring system active. In such circumstances, when location is needed, the device has to start up the measurement mechanism. Typically, this takes tens of seconds, far too long to wait to be able to route an emergency call. For this reason, devices that have end system measured location mechanisms but need a cold start period lasting more than a couple seconds need another way to get a routing location. Typically, this would be a location associated with a radio link (cell tower/sector).
GNSS衛星は継続的にアクティブです。したがって、デバイスが十分な衛星を「見る」ことができる限り、場所は常に利用可能です。ただし、モバイルデバイスは、測定システムをアクティブに保つために必要な電力レベルを購入できない場合があります。このような状況では、場所が必要な場合、デバイスは測定メカニズムを起動する必要があります。通常、これには数秒かかりますが、緊急電話をルーティングできるのを待つには長すぎます。このため、エンドシステムを備えたデバイスは位置メカニズムを測定しましたが、数秒以上続くコールドスタート期間が必要です。ルーティングの場所を取得するための別の方法が必要です。通常、これは無線リンク（セルタワー/セクター）に関連する場所です。
The access network may locate end devices. Techniques include various forms of triangulation. Elements in the network infrastructure triangulate end systems based on signal strength, angle of arrival or time of arrival. Common mechanisms deployed include the following:
アクセスネットワークは、エンドデバイスを見つける場合があります。技術には、さまざまな形態の三角形が含まれます。ネットワークインフラストラクチャの要素は、信号強度、到着角または到着時間に基づいてエンドシステムを三角測量します。展開された一般的なメカニズムには、以下が含まれます。
o Time Difference Of Arrival - TDOA
o 到着の時差-TDOA
o Uplink Time Difference Of Arrival - U-TDOA
o アップリンク到着時差-U -TDOA
o Angle of Arrival - AOA
o 到着角度-AOA
o Radio Frequency (RF) fingerprinting
o 無線周波数（RF）フィンガープリント
o Advanced Forward Link Trilateration - AFLT
o Advanced Forward Link Trilateration -aflt
o Enhanced Forward Link Trilateration - EFLT
o 強化されたフォワードリンク三重量 - EFLT
Sometimes multiple mechanisms are combined, for example A-GPS with AFLT.
たとえば、A-GPSをAFLTと組み合わせることができる場合があります。
The IETF emergency call architecture prefers endpoints to learn their location and supply it on the call. Where devices do not support location, proxy servers may have to add location to emergency calls. Some calling networks have relationships with all access networks the device may be connected to, and that may allow the proxy to accurately determine the location of the endpoint. However, NATs and other middleboxes often make it impossible to determine a reference identifier the access network could provide to a LIS to determine the location of the device. System designers are discouraged from relying on proxies to add location. The technique may be useful in some limited circumstances as devices are upgraded to meet the requirements of this document, or where relationships between access networks and calling networks are feasible and can be relied upon to get accurate location.
IETFの緊急通話アーキテクチャは、エンドポイントを好み、場所を学習し、コールでそれを提供します。デバイスが場所をサポートしていない場合、プロキシサーバーは緊急通話に場所を追加する必要がある場合があります。一部の呼び出しネットワークには、デバイスが接続されているすべてのアクセスネットワークとの関係があり、プロキシがエンドポイントの位置を正確に決定できる場合があります。ただし、NATやその他のミドルボックスは、アクセスネットワークがLISに提供してデバイスの位置を決定できる参照識別子を決定することを不可能にすることがよくあります。システム設計者は、プロキシに頼って場所を追加することを思いとどまらせます。この手法は、このドキュメントの要件を満たすためにデバイスがアップグレードされるため、またはアクセスネットワークと呼び出しネットワーク間の関係が実行可能であり、正確な場所を取得するために信頼できる場合、いくつかの限られた状況で有用である可能性があります。
Proxy insertion of location complicates dial-string recognition. As noted in Section 6, local dial strings depend on the location of the caller. If the device does not know its own location, it cannot use the LoST service to learn the local emergency dial strings. The calling network must provide another way for the device to learn the local dial string, and update it when the user moves to a location where the dial string(s) change, or do the dial-string determination itself.
場所のプロキシ挿入は、ダイヤルストリング認識を複雑にします。セクション6で述べたように、ローカルダイヤル文字列は発信者の場所に依存します。デバイスが独自の場所を知らない場合、ロストサービスを使用してローカルの緊急ダイヤル文字列を学習することはできません。通話ネットワークは、デバイスがローカルダイヤル文字列を学習し、ユーザーがダイヤルストリングが変更される場所に移動するときに更新するか、ダイヤルストリングの決定自体を実行するときにそれを更新する別の方法を提供する必要があります。
Location information may be expressed as the actual civic or geospatial value but can be transmitted as by value, i.e., wholly contained within the signaling message, or by reference, i.e., as a URI pointing to the value residing on a remote node waiting to be dereferenced.
位置情報は実際の市民または地理空間値として表される場合がありますが、価値によって、つまりシグナリングメッセージ内または参照によって、つまり、リモートノードに存在する価値を指しているURIとして、価値によって送信できます。参照されます。
When location is transmitted by value, the location information is available to entities in the call path. On the other hand, location objects can be large and only represent a single snapshot of the device's location. Location references are small and can be used to represent a time-varying location, but the added complexity of the dereference step introduces a risk that location will not be available to parties that need it if the dereference transaction were to fail.
場所が価値によって送信される場合、位置情報はコールパス内のエンティティが利用できます。一方、ロケーションオブジェクトは大きくなり、デバイスの場所の単一のスナップショットのみを表します。場所の参照は小さく、時代の場所を表すために使用できますが、繰り返しのステップの追加された複雑さは、控えめなトランザクションが失敗した場合にそれを必要とする関係者が場所を利用できないというリスクを導入します。
Unless a user agent has access to provisioned or locally measured location information, it must obtain it from the access network. There are several Location Configuration Protocols (LCPs) that can be used for this purpose including DHCP, HELD, and LLDP:
ユーザーエージェントがプロビジョニング済みまたはローカルで測定された位置情報にアクセスできる場合を除き、アクセスネットワークから取得する必要があります。DHCP、保有、LLDPを含むこの目的に使用できる場所構成プロトコル（LCPS）がいくつかあります。
DHCP can deliver civic [RFC4776] or geospatial [RFC6225] information. User agents need to support both formats. Note that a user agent can use DHCP, via the DHCP REQUEST or INFORM messages, even if it uses other means to acquire its IP address.
DHCPは、市民[RFC4776]または地理空間[RFC6225]情報を提供できます。ユーザーエージェントは両方の形式をサポートする必要があります。他の手段を使用してIPアドレスを取得する場合でも、ユーザーエージェントはDHCPリクエストを介してDHCPを使用したり、メッセージを通知したりできることに注意してください。
HELD [RFC5985] can deliver a civic or geo location object, by value or by reference, via a Layer 7 protocol. The query typically uses the IP address of the requester as an identifier and returns the location value or reference associated with that identifier. HELD is typically carried in HTTP.
[RFC5985]は、レイヤー7プロトコルを介して、値または参照によってCivicまたはGeoの位置オブジェクトを配信できます。クエリは通常、要求者のIPアドレスを識別子として使用し、その識別子に関連付けられた位置値または参照を返します。保有は通常、httpで運ばれます。
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device (MED) extensions [LLDP-MED] can be used to deliver location information directly from the Layer 2 network infrastructure and also supports both civic and geo formats identical in format to DHCP methods.
Media Endpoint Device（MED）拡張機能[LLDP-MED]を使用したLink-Layer Discovery Protocol [LLDP]を使用して、Layer 2ネットワークインフラストラクチャから直接位置情報を配信でき、DHCPメソッドと同一のCIVICとGEOの両方の形式もサポートできます。
Each LCP has limitations in the kinds of networks that can reasonably support it. For this reason, it is not possible to choose a single mandatory-to-deploy LCP. For endpoints with common network connections, such as an Ethernet jack or a WiFi connection, location determination could easily fail unless every network supported every protocol, or alternatively, every device supported every protocol. For this reason, a mandatory-to-implement list of LCPs is established in [PHONEBCP]. Every endpoint that could be used to place emergency calls must implement all of the protocols on the list. Every access network must deploy at least one of them. Since it is the variability of the networks that prevent a single protocol from being acceptable, it must be the endpoints that implement all of them, and to accommodate a wide range of devices, networks must deploy at least one of them.
各LCPには、合理的にサポートできるネットワークの種類に制限があります。このため、単一の必須のデプロイLCPを選択することはできません。イーサネットジャックやWiFi接続などの一般的なネットワーク接続を備えたエンドポイントの場合、すべてのネットワークがすべてのプロトコルをサポートしていない場合、またはすべてのデバイスがすべてのプロトコルをサポートしていない限り、位置決定が簡単に失敗する可能性があります。このため、LCPの義務的なプルメントリストが[PhoneBCP]に確立されています。緊急通話を配置するために使用できるすべてのエンドポイントは、リストにすべてのプロトコルを実装する必要があります。すべてのアクセスネットワークは、少なくとも1つを展開する必要があります。単一のプロトコルが受け入れられないようにするのはネットワークの変動性であるため、それらすべてを実装し、幅広いデバイスに対応するためには、少なくとも1つを展開する必要があります。
Often, network operators and device designers believe that they have a simpler environment and some other network specific mechanism can be used to provide location. Unfortunately, it is very rare to actually be able to limit the range of devices that may be connected to a network. For example, existing mobile networks are being used to support routers and LANs behind the WAN connection of a wireless data network, with Ethernet connected phones connected to that. It is possible that the access network could support a protocol not on the list and require every handset in that network to use that protocol for emergency calls. However, the Ethernet-connected phone will not be able to acquire location, and the user of the phone is unlikely to be dissuaded from placing an emergency call on that phone. The widespread availability of gateways, routers, and other network-broadening devices means that indirectly connected endpoints are possible on nearly every network. Network operators and vendors are cautioned that shortcuts to meeting this requirement are seldom successful.
多くの場合、ネットワークオペレーターとデバイス設計者は、より単純な環境があり、他のネットワーク固有のメカニズムを使用して場所を提供できると考えています。残念ながら、ネットワークに接続される可能性のあるデバイスの範囲を実際に制限できることは非常にまれです。たとえば、既存のモバイルネットワークは、ワイヤレスデータネットワークのWAN接続の背後にあるルーターとLANをサポートするために使用されており、それに接続されているイーサネット接続の電話があります。 Access Networkは、リスト上ではなくプロトコルをサポートし、そのネットワーク内のすべてのハンドセットに緊急コールにそのプロトコルを使用する必要がある可能性があります。ただし、イーサネットに接続された電話は場所を取得することができず、電話のユーザーがその電話に緊急電話をかけることを思いとどまらせることはほとんどありません。ゲートウェイ、ルーター、およびその他のネットワークブロードデバイスの広範な可用性は、ほぼすべてのネットワークで間接的に接続されたエンドポイントが可能であることを意味します。ネットワークオペレーターとベンダーは、この要件を満たすためのショートカットがめったに成功することはないと警告されています。
Location for non-mobile devices is normally expected to be acquired at network attachment time and retained by the device. It should be refreshed when the cached value expires. For example, if DHCP is the acquisition protocol, refresh of location may occur when the IP address lease is renewed. At the time of an emergency call, the location should be refreshed, with the retained location used if the location acquisition does not immediately return a value. Mobile devices may determine location at network attachment time and periodically thereafter as a backup in case location determination at the time of call does not work. Mobile device location may be refreshed when a Time-to-Live (TTL) expires or the device moves beyond some boundaries (as provided by [RFC5222]). Normally, mobile devices will acquire their location at call time for use in an emergency call routing. See Section 6.8 for a further discussion on location updates for dispatch location.
非モバイルデバイスの場所は、通常、ネットワーク添付時間で取得され、デバイスによって保持されると予想されます。キャッシュされた値が期限切れになったら更新する必要があります。たとえば、DHCPが取得プロトコルである場合、IPアドレスリースが更新されたときに場所の更新が発生する可能性があります。緊急通話の時点では、場所をリフレッシュする必要があります。場所を保持した場所は、場所の取得がすぐに値を返さない場合に使用されます。モバイルデバイスは、ネットワークの添付時に位置を決定する場合があり、その後定期的には、通話時のケースの決定が機能しない場合のバックアップとして定期的に決定できます。モバイルデバイスの位置は、寿命までの時間（TTL）の有効期限が切れたり、デバイスがいくつかの境界を超えて移動したりすると更新される場合があります（[RFC5222]によって提供されます）。通常、モバイルデバイスは、緊急通話ルーティングで使用するために、コール時に場所を取得します。ディスパッチの場所の場所の更新に関する詳細については、セクション6.8を参照してください。
There are many examples of endpoints that are user agent applications running on a more general purpose device, such as a personal computer. On some systems, Layer 2 protocols like DHCP and LLDP may not be directly accessible to applications. It is desirable for an operating system to have an API that provides the location of the device for use by any application, especially those supporting emergency calls.
パーソナルコンピューターなど、より一般的な目的のデバイスで実行されているユーザーエージェントアプリケーションであるエンドポイントの例がたくさんあります。一部のシステムでは、DHCPやLLDPなどのレイヤー2プロトコルには、アプリケーションに直接アクセスできない場合があります。オペレーティングシステムが、アプリケーションが使用するためのデバイスの場所、特に緊急通話をサポートするAPIを提供することが望ましいです。
Devices should get routing location immediately after obtaining local network configuration information. The presence of NAT and VPN tunnels (that assign new IP addresses to communications) can obscure identifiers used by LCPs to determine location, especially for HELD.
デバイスは、ローカルネットワーク構成情報を取得した直後にルーティングの場所を取得する必要があります。NATおよびVPNトンネルの存在（新しいIPアドレスを通信に割り当てる）は、LCPSが使用する識別子を不明瞭にして、特に保持される場所を決定することができます。
In some cases, such as residential NAT devices, the NAT is placed between the endpoint and the access network demarcation point and thus the IP address seen by the access network is the right identifier for location of the residence. However, in many enterprise environments, VPN tunnels can obscure the actual IP address. Some VPN mechanisms can be bypassed so that a query to the LCP can be designated to go through the direct IP path, using the correct IP address, and not through the tunnel. In other cases, no bypass is possible, but location can be configured before the VPN is established. Of course, LCPs that use Layer 2 mechanisms (DHCP location options and LLDP-MED) are usually immune from such problems because they do not use the IP address as the identifier for the device seeking location.
場合によっては、住宅用NATデバイスなど、NATはエンドポイントとアクセスネットワークの境界点の間に配置されているため、アクセスネットワークで見られるIPアドレスが居住地の適切な識別子です。ただし、多くのエンタープライズ環境では、VPNトンネルは実際のIPアドレスを曖昧にする可能性があります。一部のVPNメカニズムをバイパスできるため、LCPへのクエリを指定して、トンネルを介してではなく、正しいIPアドレスを使用して直接IPパスを通過するように指定できます。それ以外の場合は、バイパスは不可能ですが、VPNが確立される前に場所を構成できます。もちろん、レイヤー2メカニズム（DHCPロケーションオプションとLLDP-MED）を使用するLCPは、通常、そのような問題から免疫があります。これは、場所を探す場所の識別子としてIPアドレスを使用しないためです。
It is desirable that routing location information be periodically refreshed. A LIS supporting a million subscribers each refreshing once per day would need to support a query rate of 1,000,000 / (24 * 60 * 60) = 12 queries per second. For networks with mobile devices, much higher refresh rates could be expected.
ルーティングの位置情報を定期的に更新することが望ましいです。1日に1回リフレッシュする100万人のサブスクライバーをサポートするLISは、1,000,000 /（24 * 60 * 60）= 12クエリのクエリレートをサポートする必要があります。モバイルデバイスを備えたネットワークの場合、はるかに高いリフレッシュレートが予想されます。
It is desirable for routing location information to be requested immediately before placing an emergency call. However, if there is any significant delay in getting more recent location, the call should be placed with the most recent location information the device has. In mobile handsets, routing is often accomplished with the cell site and sector of the tower serving the call, because it can take many seconds to start up the location determination mechanism and obtain an accurate location.
緊急電話をかける直前に、位置情報をルーティングすることが望ましいです。ただし、最近の場所を取得することに大きな遅れがある場合は、デバイスが持っている最新の位置情報を使用して通話を配置する必要があります。モバイルハンドセットでは、場所の決定メカニズムを起動して正確な場所を取得するのに何秒もかかるため、コールを提供するタワーのセルサイトとセクターでルーティングが行われることがよくあります。
There is a trade-off between the time it takes to get a routing location and the accuracy (technically, confidence and uncertainty) obtained. Routing an emergency call quickly is required. However, if location can be substantially improved by waiting a short time (e.g., for some sort of "quick (location) fix"), it is preferable to wait. Three seconds, the current nominal time for a quick fix, is a very long time add to post-dial delay. NENA recommends [NENAi3TRD] that IP-based systems complete calls in two seconds from last dial press to ring at the PSAP.
ルーティングの場所を取得するのにかかる時間と、得られた精度（技術的、信頼性、不確実性）の間にはトレードオフがあります。緊急通話をすばやくルーティングする必要があります。ただし、短時間待つことで場所を大幅に改善できる場合（たとえば、ある種の「Quick（Location）Fix」の場合）、待つことが望ましいです。迅速な修正のための現在の名目時間である3秒は、ダイヤル後の遅延に非常に長い時間を追加します。Nenaは、[Nenai3trd]は、IPベースのシステムが最後のダイヤルプレスからPSAPでのリングまで2秒で完全な呼び出しを完了することを推奨しています。
When an emergency call is placed, the endpoint should include location in the call signaling. This is referred to as "conveyance" to distinguish it from "configuration". In SIP, the location information is conveyed following the procedures in [RFC6442]. Since
緊急通話が配置されると、エンドポイントには、コールシグナリングの位置を含める必要があります。これは、「構成」と区別するための「運搬」と呼ばれます。SIPでは、[RFC6442]の手順に従って位置情報が伝えられます。以来
the form of the location information obtained by the acquisition protocol may not be the same as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the endpoint from the LCP form to PIDF may be required.
取得プロトコルによって取得された位置情報の形式は、輸送プロトコルが使用するものと同じではない場合があります（PIDF-LO [RFC4119]）。
As discussed above, it may take some time for some measurement mechanisms to get a location accurate enough for dispatch, and a routing location with less accuracy may be provided to get the call established quickly. The PSAP needs the dispatch location before it sends the call to the responder. This requires an update of the location. In addition, the location of some mobile callers, e.g., in a vehicle or aircraft, can change significantly during the emergency call.
上記で説明したように、いくつかの測定メカニズムがディスパッチに十分な正確な場所を取得するには時間がかかる場合があります。また、コールを迅速に確立するために、より少ない精度のあるルーティングの場所を提供できます。PSAPは、レスポンダーに通話を送信する前に、ディスパッチの場所が必要です。これには、場所の更新が必要です。さらに、一部のモバイル発信者、たとえば車両や航空機の場所は、緊急電話中に大幅に変化する可能性があります。
A PSAP has no way to request an update of a location provided by value. If the User Agent Client (UAC) gets new location information, it must signal the PSAP using a new INVITE or an UPDATE transaction with a new Geolocation header field to supply the new location.
PSAPには、Valueが提供する場所の更新をリクエストする方法がありません。ユーザーエージェントクライアント（UAC）が新しい位置情報を取得した場合、新しい招待状または新しいジオロケーションヘッダーフィールドを使用した更新トランザクションを使用してPSAPを信号して、新しい場所を提供する必要があります。
With the wide variation in determination mechanisms, the PSAP does not know when accurate location may be available. The preferred mechanism is that the LIS notifies the PSAP when an accurate location is available rather than requiring a poll operation from the PSAP to the LIS. The SIP Presence subscription [RFC3856] provides a suitable mechanism.
決定メカニズムの幅広いバリエーションにより、PSAPは正確な場所がいつ利用できるかを知りません。好ましいメカニズムは、PSAPからLISへの投票操作を要求するのではなく、正確な場所が利用可能な場合、LISがPSAPに通知することです。SIPプレゼンスサブスクリプション[RFC3856]は、適切なメカニズムを提供します。
When using a HELD dereference, the PSAP must specify the value "emergencyDispatch" for the ResponseTime parameter. Since, typically, the LIS is local relative to the PSAP, the LIS can be aware of the update requirements of the PSAP.
保持された規制を使用する場合、PSAPは応答パラメーターの値「EmergencyDispatch」を指定する必要があります。通常、LISはPSAPに対してローカルであるため、LISはPSAPの更新要件を認識できます。
Getting multiple locations all purported to describe the location of the caller is confusing to all, and should be avoided. Handling multiple locations at the point where a PIDF is created is discussed in [RFC5491]. Conflicting location information is particularly harmful if different routes (PSAPs) result from LoST queries for the multiple locations. When they occur anyway, the general guidance is that the entity earliest in the chain generally has more knowledge than later elements to make an intelligent decision, especially about which location will be used for routing. It is permissible to send multiple locations towards the PSAP, but the element that chooses the route must select exactly one location to use with LoST.
複数の場所を取得すると、発信者の位置を説明するように主張されているすべての人が混乱しているため、避ける必要があります。[RFC5491]でPIDFが作成されるポイントで複数の場所を処理します。競合する位置情報は、複数の場所の失われたクエリから異なるルート（PSAP）が生じる場合、特に有害です。とにかくそれらが発生する場合、一般的なガイダンスは、チェーンの最も早いエンティティは一般に、特にどの場所がルーティングに使用されるかについて、インテリジェントな決定を下すために、後の要素よりも多くの知識を持っているということです。複数の場所をPSAPに向けて送信することは許可されますが、ルートを選択する要素は、失われた状態で使用する場所を正確に1つ選択する必要があります。
Guidelines for dealing with multiple locations are also given in [RFC5222]. If a UA gets multiple locations, it must choose the one to use for routing, but it may send all of the locations it has in the signaling. If a proxy is inserting location and has multiple locations, it must choose exactly one to use for routing and send it as well as any other locations it has that correspond to this UA.
複数の場所を扱うためのガイドラインも[RFC5222]に記載されています。UAが複数の場所を取得した場合、ルーティングに使用する場所を選択する必要がありますが、信号にある場所をすべて送信する場合があります。プロキシが場所を挿入し、複数の場所がある場合、ルーティングに使用するために1つを選択して、このUAに対応する他の場所と同様に送信する必要があります。
The UA or proxy should have the ability to understand how and from whom it learned its location, and should include this information in the location objects that are sent to the PSAP. That labeling provides the call taker with information to make decisions upon, as well as guidance for, what to ask the caller and what to tell the responders.
UAまたはプロキシは、その場所をどのように、誰から学習したかを理解する能力を持ち、PSAPに送信される場所オブジェクトにこの情報を含める必要があります。そのラベル付けは、コールテイカーに、発信者に何を尋ねるべきか、応答者に何を伝えるかについてのガイダンスを行うための情報を呼び出します。
Endpoints or proxies may be tempted to send multiple versions of the same location. For example a database may be used to "geocode" or "reverse geocode", that is, convert from civic to geo or vice versa. It is very problematic to use derived locations in emergency calls. The PSAP and the responders have very accurate databases that they use to convert most commonly from a reported geo to a civic suitable for dispatching responders. If one database is used to convert from, say, civic to geo, and another converts from geo to civic, errors will often occur where the databases are slightly different. Errors of even a single house number are serious as it may lead first responders to the wrong building. Derived locations should be marked with a "derived" method token [RFC4119]. If an entity gets a location that has a measured or other original method, and another with a derived method, it must use the original value for the emergency call.
エンドポイントまたはプロキシは、同じ場所の複数のバージョンを送信するように誘惑される場合があります。たとえば、データベースは、「ジオコード」または「逆ジオコード」に使用できます。つまり、シビックからジオに変換されます。緊急通話で派生した場所を使用することは非常に問題があります。PSAPとレスポンダーには、報告されたGEOからレスッチの派遣に適した市民に最も一般的に変換するために使用する非常に正確なデータベースがあります。たとえば、シビックからGEOに変換するために1つのデータベースが使用され、別のデータベースがGEOからCivicに変換されると、データベースがわずかに異なる場合にエラーが発生することがよくあります。単一の家番号でさえも、間違った建物に最初の対応者を導く可能性があるため、深刻です。導出された場所には、「派生」メソッドトークン[RFC4119]でマークされる必要があります。エンティティが測定されたまたは他の元の方法を備えた場所を取得し、派生方法を備えた別の場所を取得した場合、緊急コールに元の値を使用する必要があります。
Validation, in this context, means that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. It is recommended that location be validated prior to a device placing an actual emergency call; some jurisdictions require that this be done.
このコンテキストでの検証は、アドレスからPSAPへのマッピングがあり、PSAPが応答者を場所に向ける方法を理解していることを意味します。デバイスが実際の緊急電話を配置する前に、場所を検証することをお勧めします。一部の管轄区域では、これを行う必要があります。
Determining whether an address is valid can be difficult. There are, for example, many cases of two names for the same street, or two streets with the same name but different "suffixes" (Avenue, Street, Circle) in a city. In some countries, the current system provides validation. For example, in the United States of America, the Master Street Address Guide (MSAG) records all valid street addresses and is used to ensure that the service addresses in phone billing records correspond to valid emergency service street addresses. Validation is normally only a concern for civic addresses, although there could
アドレスが有効かどうかを判断するのは難しい場合があります。たとえば、同じ通りには2つの名前の多くのケース、または同じ名前の2つの通りがありますが、都市には異なる「サフィックス」（通り、円）が異なります。一部の国では、現在のシステムは検証を提供します。たとえば、アメリカ合衆国では、マスターストリートアドレスガイド（MSAG）はすべての有効な通りの住所を記録し、電話請求記録のサービスアドレスが有効な緊急サービスの住所に対応することを確認するために使用されます。通常、検証は市民の演説の懸念にすぎませんが、
be some determination that a given geo is within at least one PSAP service boundary; that is, a "valid" geo is one where there is a mapping in the LoST server.
特定のGEOが少なくとも1つのPSAPサービス境界内にあるという決定に注意してください。つまり、「有効な」GEOは、失われたサーバーにマッピングがある場合です。
LoST [RFC5222] includes a location validation function. Validation is normally performed when a location is entered into a Location Information Server. It should be confirmed periodically, because the mapping database undergoes slow change and locations that previously validated may eventually fail validation. Endpoints may wish to validate locations they receive from the access network, and will need to validate manually entered locations. Proxies that insert location may wish to validate locations they receive from a LIS. When the test functions (Section 15) are invoked, the location used should be validated.
LOST [RFC5222]には、位置検証機能が含まれています。場所が位置情報サーバーに入力されたときに、検証は通常実行されます。マッピングデータベースは遅い変更を受けるため、定期的に確認する必要があり、以前に検証された場所が最終的に検証に失敗する可能性があるためです。エンドポイントは、アクセスネットワークから受け取った場所を検証したい場合があり、手動で入力された場所を検証する必要があります。場所を挿入するプロキシは、LISから受け取った場所を検証したい場合があります。テスト機能（セクション15）が呼び出される場合、使用される場所を検証する必要があります。
When validation fails, the location given should not be used for an emergency call, unless no other valid location is available. Bad location is better than no location. If validation is completed when location is first loaded into a LIS, any problems can be found and fixed before devices could get the bad location. Failure of validation arises because an error is made in determining the location, although occasionally the LoST database is not up to date or has faulty information. In either case, the problem must be identified and should be corrected before using the location.
検証が失敗した場合、他の有効な場所が利用できない限り、指定された場所を緊急通話に使用しないでください。悪い場所は場所がないよりも優れています。場所が最初にLISにロードされたときに検証が完了した場合、デバイスが悪い場所を取得する前に、問題を見つけて修正することができます。失われたデータベースが最新ではない場合や誤った情報がない場合、場所を決定する際にエラーが発生するため、検証の障害が発生します。どちらの場合でも、問題を特定する必要があり、場所を使用する前に修正する必要があります。
Occasionally, the access network cannot determine the actual location of the caller. In these cases, it must supply a default location. The default location should be as accurate as the network can determine. For example, in a cable network, a default location for each Cable Modem Termination System (CMTS), with a representative location for all cable modems served by that CMTS could be provided if the network is unable to resolve the subscriber to anything more precise than the CMTS. Default locations must be marked as such so that the PSAP knows that the location is not accurate.
場合によっては、アクセスネットワークが発信者の実際の位置を決定できない場合があります。これらの場合、デフォルトの場所を提供する必要があります。デフォルトの場所は、ネットワークが決定できるのと同じくらい正確でなければなりません。たとえば、ケーブルネットワークでは、各ケーブルモデム終了システム（CMTS）のデフォルトの場所で、ネットワークがサブスクライバーをより正確なものに解決できない場合、CMTが提供するすべてのケーブルモデムの代表的な場所を提供できます。CMTS。PSAPが場所が正確ではないことを知っているように、デフォルトの場所にそのようにマークする必要があります。
The endpoint is responsible for mapping any form of location it receives from an LCP into PIDF-LO form if the LCP did not directly return a PIDF-LO.
エンドポイントは、LCPがPIDF-LOを直接戻さなかった場合、LCPからPIDF-LO形式に受信するあらゆる形式の場所をマッピングする責任があります。
Endpoints must be able to discover a LIS, if the HELD protocol is used and a LoST server. DHCP options are defined for this purpose, namely [RFC5986] and [RFC5223].
保有プロトコルが使用されている場合、エンドポイントはLISを発見できる必要があります。DHCPオプションは、この目的のために定義されています。つまり、[RFC5986]および[RFC5223]です。
Until such DHCP records are widely available, it may be necessary for the service provider to provision a LoST server address in the device. The endpoint can also do a DNS SRV query to find a LoST server. In any environment, more than one of these mechanisms may yield a LoST server, and they may be different. The recommended priority is DHCP first, provisioned value second, and DNS SRV query in the SIP domain third.
このようなDHCPレコードが広く利用可能になるまで、サービスプロバイダーがデバイス内の失われたサーバーアドレスをプロビジョニングする必要がある場合があります。エンドポイントは、DNS SRVクエリを実行して、失われたサーバーを見つけることもできます。どの環境でも、これらのメカニズムの複数が失われたサーバーを生成する可能性があり、それらは異なる場合があります。推奨される優先度は、DHCP 1番目、プロビジョニング値が2番目、SIPドメイン3番目のDNS SRVクエリです。
Emergency calls are routed based on one or more of the following criteria expressed in the call setup request (INVITE):
緊急通話は、コールセットアップリクエスト（招待）で表された以下の基準の1つ以上に基づいてルーティングされます。
Location: Since each PSAP serves a limited geographic region and transferring existing calls delays the emergency response, calls need to be routed to the most appropriate PSAP. In this architecture, emergency call setup requests contain location information, expressed in civic or geospatial coordinates, that allows such routing.
場所：各PSAPは限られた地理的領域を提供し、既存の呼び出しを転送するため、緊急対応が遅れているため、コールは最も適切なPSAPにルーティングする必要があります。このアーキテクチャでは、緊急コールのセットアップリクエストには、そのようなルーティングを可能にする市民または地理空間座標で表現された位置情報が含まれています。
Type of emergency service: In some jurisdictions, emergency calls for specific emergency services such as fire, police, ambulance, or mountain rescue are directed to just those emergency-specific PSAPs. This mechanism is supported by marking emergency calls with the proper service identifier [RFC5031]. Even in single-number jurisdictions, not all services are dispatched by PSAPs and may need alternate URNs to route calls to the appropriate call center.
緊急サービスの種類：一部の管轄区域では、火災、警察、救急車、山岳救助などの特定の緊急サービスの緊急要求が、これらの緊急特有のPSAPだけに向けられています。このメカニズムは、適切なサービス識別子[RFC5031]で緊急コールをマークすることによってサポートされています。単一数の管轄区域でさえ、すべてのサービスがPSAPによって派遣されているわけではなく、適切なコールセンターへの呼び出しをルーティングするために代替URNが必要になる場合があります。
Media capabilities of caller: In some cases, emergency call centers for specific caller media preferences, such as typed text or video, are separate from PSAPs serving voice calls. ESRPs are expected to be able to provide routing based on media. Also, even if media capability does not affect the selection of the PSAP, there may be call takers within the PSAP that are specifically trained, e.g., in real-time text or sign language communications, where routing within the PSAP based on the media offer would be provided.
発信者のメディア機能：場合によっては、タイプされたテキストやビデオなどの特定の発信者メディア設定の緊急コールセンターは、音声通話を提供するPSAPとは別のものです。ESRPは、メディアに基づいてルーティングを提供できることが期待されています。また、メディア機能がPSAPの選択に影響を与えない場合でも、メディアオファーに基づいてPSAP内でルーティングするリアルタイムテキストや手話通信など、特別にトレーニングされたPSAP内のコールテイカーが存在する場合があります。提供されます。
Providing a URL to route emergency calls by location and by type of service is the primary function LoST [RFC5222] provides. LoST accepts a query with location (by-value) in either civic or geo form, plus a service identifier, and returns a URI (or set of URIs) to which to route the call. Normal SIP [RFC3261] routing functions are used to resolve the URI to a next-hop destination.
場所とサービスの種類ごとに緊急コールをルーティングするためのURLを提供することは、失われた主要な機能[RFC5222]が提供します。Lostは、CIVICまたはGEOフォームのいずれかの場所（価値）を使用したクエリ（価値）に加えて、サービス識別子を受け入れ、コールをルーティングするためにURI（またはURIのセット）を返します。通常のSIP [RFC3261]ルーティング関数は、URIを次のホップの宛先に解決するために使用されます。
The endpoint can complete the LoST mapping from its location at boot time, and periodically thereafter. It should attempt to obtain a "fresh" location, and from that a current mapping when it places an emergency call. If accessing either its location acquisition or its mapping functions fail, it should use its cached value. The call would follow its normal outbound call processing.
エンドポイントは、起動時にその場所から失われたマッピングを完了し、その後定期的に完了することができます。「新鮮な」場所を取得しようとするはずであり、それから緊急電話をかけるときの現在のマッピングが試みるはずです。位置取得またはマッピング関数のいずれかにアクセスすると、そのキャッシュ値を使用する必要があります。呼び出しは、通常のアウトバウンドコール処理に従います。
Determining when the device leaves the area provided by the LoST service can tax small mobile devices. For this reason, the LoST server should return a simple (small number of points) polygon for geospatial location. This can be a simple enclosing rectangle of the PSAP service area when the reported point is not near an edge, or a smaller polygonal edge section when the reported location is near an edge. Civic location is uncommon for mobile devices, but reporting that the same mapping is good within a community name, or even a street, may be very helpful for WiFi connected devices that roam and obtain civic location from the access point to which they are connected.
失われたサービスによって提供されるエリアをデバイスがいつ離れるかを判断すると、小さなモバイルデバイスに課税できます。このため、失われたサーバーは、地理空間位置の単純な（少数のポイント）ポリゴンを返す必要があります。これは、報告されたポイントがエッジに近づいていない場合のPSAPサービスエリアの単純な囲いの長方形、または報告された場所がエッジに近い場合の小角エッジセクションです。市民の場所はモバイルデバイスでは珍しいことですが、コミュニティ名、または通りの中で同じマッピングが良いと報告することは、接続されているアクセスポイントから市民の場所を歩き回って取得するWiFi接続デバイスにとって非常に役立つかもしれません。
Networks that support devices that do not implement LoST mapping themselves may need the outbound proxy do the mapping. If the endpoint recognized the call was an emergency call, provided the correct service URN and/or included location on the call in a Geolocation header, a proxy server could easily accomplish the mapping.
失われたマッピング自体を実装しないデバイスをサポートするネットワークでは、アウトバウンドプロキシがマッピングを行う必要があります。エンドポイントがコールが緊急通話であることを認識した場合、正しいサービスのurnおよび/またはGeolocationヘッダーの呼び出しの場所が含まれている場合、プロキシサーバーはマッピングを簡単に達成できます。
However, if the endpoint did not recognize the call was an emergency call, and thus did not include location, the proxy's task is more difficult. It is often difficult for the calling network to accurately determine the endpoint's location. The endpoint may have its own location, but would not normally include it on the call signaling unless it knew it was an emergency call. There is no mechanism provided in [RFC6442] for a proxy to request the endpoint supply its location, because that would open the endpoint to an attack by any proxy on the path to get it to reveal location. The proxy can attempt to redirect a call to the service URN, which, if the device recognizes the significance, would include location in the redirected call from the device. All network elements should detect emergency calls and supply default location and/or routing if it is not already present.
ただし、エンドポイントがコールが緊急通話であり、したがって場所が含まれていなかった場合、プロキシのタスクはより困難です。呼び出しネットワークがエンドポイントの位置を正確に決定することはしばしば困難です。エンドポイントには独自の位置がある場合がありますが、通常、緊急通話であることがわかっていない限り、通常はコールシグナリングには含まれません。[RFC6442]には、エンドポイントの供給を要求するプロキシのために[RFC6442]に提供されているメカニズムはありません。これにより、パスのプロキシによる攻撃のエンドポイントが開かれ、場所が表示されるためです。プロキシは、サービスURNへの呼び出しをリダイレクトしようとすることができます。これは、デバイスが重要性を認識した場合、デバイスからのリダイレクトコールに場所を含めることができます。すべてのネットワーク要素は、緊急通話を検出し、デフォルトの場所やルーティングをまだ存在していない場合は、供給する必要があります。
The LoST server would normally be provided by the local emergency authorities, although the access network or calling network might run its own server using data provided by the emergency authorities. Some enterprises may have local responders and call centers, and could operate their own LoST server, providing URIs to in-house "PSAPs". Local regulations might limit the ability of enterprises to direct emergency calls to in-house services.
失われたサーバーは通常、地元の緊急当局によって提供されますが、アクセスネットワークまたは呼び出しネットワークは、緊急当局が提供するデータを使用して独自のサーバーを実行する場合があります。一部の企業には地元のレスポンダーとコールセンターがあり、独自の失われたサーバーを運用して、urisを社内で「PSAP」に提供することができます。現地の規制により、企業が社内サービスに緊急電話を向ける能力が制限される場合があります。
The ESRP, which is a normal SIP proxy server in the signaling path of the call, may use a variety of PSAP state information, the location of the caller, and other criteria to route onward the call to the PSAP. In order for the ESRP to route on media choice, the initial INVITE request has to supply an SDP offer.
コールの信号パスにある通常のSIPプロキシサーバーであるESRPは、PSAPへの呼び出しを前進させるために、さまざまなPSAP状態情報、発信者の場所、およびその他の基準を使用する場合があります。ESRPがメディアの選択にルーティングするためには、最初の招待リクエストはSDPオファーを提供する必要があります。
Best current practice for SIP user agents [RFC4504] including handling of audio, video, and real-time text [RFC4103] should be applied. As discussed above, location is carried in all emergency calls in the call signaling. Since emergency calls carry privacy-sensitive information, they are subject to the requirements for geospatial protocols [RFC3693]. In particular, signaling information should be carried in Transport Layer Security (TLS), i.e., in 'sips' mode with a ciphersuite that includes strong encryption, such as AES. There are exceptions in [RFC3693] for emergency calls. For example, local policy may dictate that location is sent with an emergency call even if the user's policy would otherwise prohibit that. Nevertheless, protection from eavesdropping of location by encryption should be provided.
オーディオ、ビデオ、リアルタイムテキスト[RFC4103]の取り扱いを含む、SIPユーザーエージェント[RFC4504]の最良の現在のプラクティスを適用する必要があります。上記で説明したように、場所はコールシグナリングのすべての緊急通話で運ばれます。緊急コールはプライバシーに敏感な情報を保持するため、地理空間プロトコルの要件が依存しています[RFC3693]。特に、シグナリング情報は、輸送層のセキュリティ（TLS）、つまり、AEなどの強力な暗号化を含む「SIPS」モードで実施する必要があります。[RFC3693]には緊急電話には例外があります。たとえば、ローカルポリシーは、ユーザーのポリシーがそれを禁止する場合でも、場所が緊急電話で送信されることを決定する場合があります。それにもかかわらず、暗号化による場所の盗聴からの保護を提供する必要があります。
It is unacceptable to have an emergency call fail to complete because a TLS connection was not created for any reason. Thus, the call should be attempted with TLS, but if the TLS session establishment fails, the call should be automatically retried without TLS. [RFC5630] recommends that to achieve this effect, the target specify a sip URI, but use TLS on the outbound connection. An element that receives a request over a TLS connection should attempt to create a TLS connection to the next hop.
TLS接続が何らかの理由で作成されなかったため、緊急コールが完了しないことは受け入れられません。したがって、TLSでコールを試みる必要がありますが、TLSセッションの確立が失敗した場合、TLSなしでコールを自動的に再試行する必要があります。[RFC5630]は、この効果を達成するために、ターゲットがSIP URIを指定することを推奨していますが、アウトバウンド接続でTLSを使用します。TLS接続を介してリクエストを受信する要素は、次のホップへのTLS接続を作成しようとする必要があります。
In many cases, persistent TLS connections can be maintained between elements to minimize the time needed to establish them [RFC5626]. In other circumstances, use of session resumption [RFC5077] is recommended. IPsec [RFC4301] is an acceptable alternative to TLS when used with an equivalent crypto suite.
多くの場合、永続的なTLS接続を要素間で維持し、それらを確立するのに必要な時間を最小限に抑えることができます[RFC5626]。他の状況では、セッション再開[RFC5077]の使用が推奨されます。IPSEC [RFC4301]は、同等の暗号スイートで使用する場合、TLSの許容可能な代替手段です。
Location may be used for routing by multiple proxy servers on the path. Confidentiality mechanisms such as Secure/Multipurpose Internet Mail Extensions (S/MIME) encryption of SIP signaling [RFC3261] cannot be used because they obscure location. Only hop-by-hop mechanisms such as TLS should be used. Implementing location conveyance in SIP mandates inclusion of TLS support.
場所は、パス上の複数のプロキシサーバーによるルーティングに使用できます。SIPシグナリング[RFC3261]の安全/多目的インターネットメールエクステンション（S/MIME）暗号化などの機密性メカニズムは、位置を不明瞭にするため使用できません。TLSなどのホップバイホップメカニズムのみを使用する必要があります。SIPでロケーションキャンベニアを実装すると、TLSサポートが含まれます。
SIP UAs that recognize local dial strings, insert location, and perform emergency call routing will create SIP INVITE messages with the service URN in the Request-URI, the LoST-determined URI for the PSAP in a Route header, and the location in a Geolocation header. The INVITE request must also have appropriate callback identifiers (in Contact and From headers). To enable media-sensitive routing, the call should include a Session Description Protocol (SDP) offer [RFC3264].
ローカルダイヤル文字列を認識し、場所を挿入し、緊急通話ルーティングを実行するSIP UASは、リクエストウリ内のサービスURNを使用したSIP招待メッセージ、ルートヘッダーのPSAPの紛失したURI、およびジオロケーション内の場所を作成します。ヘッダ。招待リクエストには、適切なコールバック識別子（接触中およびヘッダーから）も必要です。メディアに敏感なルーティングを有効にするには、通話にセッション説明プロトコル（SDP）オファー[RFC3264]を含める必要があります。
SIP caller preferences [RFC3841] can be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. SIP caller preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the call.
SIP発信者の設定[RFC3841]を使用して、PSAPがコールを処理する方法を示すことができます。たとえば、受け入れ言語ヘッダーで表現された言語選好は、PSAPが要求された言語を話すコールテイカーにコールをルーティングするヒントとして使用できます。SIP発信者の好みを使用して、コールで障害のある人とのコミュニケーションのためにリレーサービスを呼び出す必要性を示すこともできます。
At least one SIP proxy server in the path of an emergency call must be able to assist UAs that are unable to provide any of the location-based routing steps and recognition of dial strings. A proxy can recognize the lack of location awareness by the lack of a Geolocation header. It can recognize the lack of dial-string recognition by the presence of the local emergency call dial string in the From header without the service URN being present. They should obtain the location of the endpoint if possible, and use a default location if they cannot, inserting it in a Geolocation header. They should query LoST with the location and put the resulting URI in a route, with the appropriate service URN in the Request-URI. In any event, they are also expected to provide information for the caller using SIP Identity or P-Asserted-Identity. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls. Proxies must conform to the local regulation or practice.
緊急通話のパスにある少なくとも1つのSIPプロキシサーバーは、ロケーションベースのルーティングステップとダイヤル文字列の認識を提供できないUASを支援できる必要があります。プロキシは、地理的ヘッダーの欠如により、場所の認識の欠如を認識できます。それは、サービスのurnが存在することなく、ヘッダーからのローカル緊急コールダイヤル文字列の存在により、ダイヤルストリングの認識がないことを認識できます。可能であれば、エンドポイントの場所を取得し、できない場合はデフォルトの場所を使用して、ジオロケーションヘッダーに挿入する必要があります。彼らは、場所で紛失したクエリを照会し、結果のURIをルートに配置する必要があり、適切なサービスURNをリクエスト-URIにします。いずれにせよ、彼らはまた、SIP IDまたはP asserted-Identityを使用して発信者に情報を提供することが期待されています。通常、匿名としてマークされた呼び出しが緊急電話であるときに匿名として渡されるかどうかは、規制上の問題です。プロキシは、現地の規制または実践に準拠する必要があります。
The call taker must be able to reach the emergency caller if the original call is disconnected. In traditional emergency calls, wireline and wireless emergency calls include a callback identifier for this purpose. There are two kinds of call backs. When a call is dropped, or the call taker realizes that some important information is needed that it doesn't have, it must call back the device that placed the emergency call. The PSAP, or a responder, may need to call back the caller much later, and for that purpose, it wants a
元の呼び出しが切断されている場合、コールテイカーは緊急発信者に到達できる必要があります。従来の緊急コールでは、ワイヤーラインとワイヤレスの緊急通話には、この目的のためのコールバック識別子が含まれます。コールバックには2種類あります。通話が削除された場合、またはコールテイカーが、それが持っていない重要な情報が必要であることに気付いたとき、緊急通話を配置したデバイスを呼び戻す必要があります。PSAP、またはレスポンダーは、より後で発信者を呼び戻す必要がある場合があり、その目的のために、それは
normal SIP address of record (AOR). In SIP systems, the caller must include a Contact header field in an emergency call containing a globally routable URI, possibly a Globally Routable User Agent URI (GRUU) [RFC5627]. This identifier would be used to initiate callbacks immediately by the call taker if, for example, the call is prematurely dropped. A concern arises with back-to-back user agents (B2BUAs) that manipulate Contact headers. Such B2BUAs should always include a Contact header that routes to the same device.
記録の通常のSIPアドレス（AOR）。SIPシステムでは、発信者は、グローバルにルーティング可能なURI、場合によってはグローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]を含む緊急コールにコンタクトヘッダーフィールドを含める必要があります。この識別子は、たとえばコールが早めに削除された場合、コールテイカーによってすぐにコールバックを開始するために使用されます。連絡先ヘッダーを操作する連続したユーザーエージェント（B2BUA）には懸念が生じます。このようなB2BUAには、常に同じデバイスにルートするコンタクトヘッダーを含める必要があります。
In addition, a callback identifier as an address of record (AoR) must be included either as the URI in the From header field [RFC3261] verified by SIP Identity [RFC4474] or as a network-asserted URI [RFC3325]. If the latter, the PSAP will need to establish a suitable spec(t) with the proxies that send it emergency calls. This identifier would be used to initiate a callback at a later time and may reach the caller, not necessarily on the same device (and at the same location) as the original emergency call as per normal SIP rules. It is often a regulatory matter whether calls normally marked as anonymous are passed as anonymous when they are emergency calls. Proxies must conform to the local regulation or practice.
さらに、レコードのアドレス（AOR）としてのコールバック識別子は、SIP ID [RFC4474]によって検証されたFrom Headerフィールド[RFC3261]のURIとして、またはネットワークアサートURI [RFC3325]として含める必要があります。後者の場合、PSAPは、緊急電話を送信するプロキシで適切な仕様（t）を確立する必要があります。この識別子は、後でコールバックを開始するために使用され、通常のSIPルールと同じデバイス（および同じ場所）で必ずしも同じデバイス（および同じ場所）で発信者に到達する場合があります。通常、匿名としてマークされた呼び出しが緊急電話であるときに匿名として渡されるかどうかは、規制上の問題です。プロキシは、現地の規制または実践に準拠する必要があります。
Some PSAPs often include dispatchers, responders, or specialists on a call. Some responders' dispatchers are not located in the primary PSAP, the call may have to be transferred to another PSAP. Most often, this will be an attended transfer, or a bridged transfer. Therefore, a PSAP may need to a REFER request [RFC3515] a call to a bridge for conferencing. Devices that normally involve the user in transfer operations should consider the effect of such interactions when a stressed user places an emergency call. Requiring user interface manipulation during such events may not be desirable. Relay services for communication with people with disabilities may be included in the call with the bridge. The UA should be prepared to have the call transferred (usually attended, but possibly blind) per [RFC5359].
一部のPSAPには、多くの場合、コールのディスパッチャー、レスポンダー、または専門家が含まれます。一部のレスポンダーのディスパッチャーはプライマリPSAPにありません。呼び出しを別のPSAPに転送する必要がある場合があります。ほとんどの場合、これは出席した転送、または橋渡しされた転送になります。したがって、PSAPは、紹介要求[RFC3515]が会議のためのブリッジへの呼び出しを必要とする場合があります。通常、転送操作にユーザーが関与するデバイスは、ストレスを受けたユーザーが緊急通話を行う場合、そのような相互作用の効果を考慮する必要があります。このようなイベント中にユーザーインターフェイスの操作が必要な場合があります。障害のある人とのコミュニケーションのためのリレーサービスは、ブリッジとの呼び出しに含まれる場合があります。UAは、[RFC5359]ごとに、コールを転送（通常は盲目）に転送する準備をする必要があります。
It is undesirable for the caller to terminate an emergency call. A PSAP terminates a call using the normal SIP call termination procedures, i.e., with a BYE request.
発信者が緊急電話を終了することは望ましくありません。PSAPは、通常のSIPコール終了手順を使用して、つまりByeリクエストを使用してコールを終了します。
Certain features that can be invoked while a normal call is active are not permitted when the call is an emergency call. Services such as call waiting, call transfer, three-way calling, and hold should be disabled.
コールが緊急通話である場合、通常の呼び出しがアクティブになっている間に呼び出すことができる特定の機能は許可されません。コール待機、コール転送、3方向通話、および保留などのサービスは無効にする必要があります。
Certain features such as call forwarding can interfere with calls from a PSAP and should be disabled. There is no way to reliably determine a PSAP call back. A UA may be able to determine a PSAP call back by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. Any call from the same domain and directed to the supplied Contact header or AoR after an emergency call should be accepted as a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed.
コール転送などの特定の機能は、PSAPからの呼び出しを妨げる可能性があり、無効にする必要があります。PSAPコールバックを確実に決定する方法はありません。UAは、緊急コールを配置した後に着信コールのドメインを調べ、それを緊急コールから応答PSAPのドメインと比較することにより、PSAPコールバックを決定できる場合があります。同じドメインからの呼び出しは、緊急電話が行われた後に妥当な時間内に発生した場合、PSAPからのコールバックとして、緊急電話後に提供された連絡先ヘッダーまたはAORに向けられています。
PSAPs should always accept RTP media streams [RFC3550]. Traditionally, voice has been the only media stream accepted by PSAPs. In some countries, text, in the form of Baudot codes or similar tone encoded signaling within a voiceband is accepted ("TTY") for persons who have hearing disabilities. Using SIP signaling includes the capability to negotiate media. Normal SIP offer/answer [RFC3264] negotiations should be used to agree on the media streams to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs should accept G.711 A-law (and mu-law in North America) encoded voice as described in [RFC3551]. Newer text forms are rapidly appearing, with instant messaging now very common, PSAPs should accept IM with at least "pager-mode" MESSAGE request [RFC3428] as well as Message Session Relay Protocol [RFC4975]. Video media in emergency calling is required to support Video Relay Service (sign language interpretation) as well as modern video phones.
PSAPは常にRTPメディアストリーム[RFC3550]を受け入れる必要があります。伝統的に、VoiceはPSAPによって受け入れられている唯一のメディアストリームでした。一部の国では、ボードコードまたは同様のトーンエンコードされた音声帯域内のシグナル伝達の形でテキストが受け入れられます（「TTY」）聴覚障害のある人が受け入れられます。SIPシグナリングの使用には、メディアをネゴシエートする機能が含まれます。通常のSIPオファー/回答[RFC3264]交渉は、使用するメディアストリームに同意するために使用する必要があります。PSAPはリアルタイムテキスト[RFC4103]を受け入れる必要があります。すべてのPSAPは、[RFC3551]に記載されているように、G.711 A-Law（および北米のMU-LAW）エンコードされた音声を受け入れる必要があります。新しいテキストフォームが急速に表示されており、インスタントメッセージングが非常に一般的になっているため、PSAPは少なくとも「ページモード」メッセージ要求[RFC3428]とメッセージセッションリレープロトコル[RFC4975]を備えたIMを受け入れる必要があります。ビデオリレーサービス（手話の解釈）と最新のビデオ電話をサポートするには、緊急通話のビデオメディアが必要です。
It is desirable for media to be kept secure by the use of Secure RTP [RFC3711], using DTLS [RFC5764] for keying.
キーイングのためにDTLS [RFC5764]を使用して、安全なRTP [RFC3711]を使用することにより、メディアを安全に保つことが望ましいです。
Since the emergency calling architecture consists of a number of pieces operated by independent entities, it is important to be able to test whether an emergency call is likely to succeed without actually occupying the human resources at a PSAP. Both signaling and media paths need to be tested since NATs and firewalls may allow the session setup request to reach the PSAP, while preventing the exchange of media.
緊急通話アーキテクチャは、独立したエンティティが運営する多数の作品で構成されているため、PSAPで実際に人的資源を占有することなく緊急電話が成功する可能性があるかどうかをテストできることが重要です。NATとファイアウォールでは、メディアの交換を防ぎながらセッションセットアップリクエストがPSAPに到達する可能性があるため、シグナリングパスとメディアパスの両方をテストする必要があります。
[PHONEBCP] includes a description of an automated test procedure that validates routing, signaling, and media path continuity. This test should be used within some random interval after boot time, and whenever the device location changes enough that a new PSAP mapping is returned by the LoST server.
[PhoneBCP]は、ルーティング、シグナル、およびメディアパスの継続性を検証する自動テスト手順の説明を含みます。このテストは、起動時間後にランダム間隔内で使用する必要があります。また、デバイスの位置が十分に変更されるたびに、新しいPSAPマッピングが失われたサーバーによって返されるようにします。
The PSAP needs to be able to control frequency and duration of the test, and since the process could be abused, it may temporarily or permanently suspend its operation.
PSAPは、テストの頻度と期間を制御できる必要があり、プロセスが乱用される可能性があるため、動作を一時的または永続的に停止する場合があります。
There is a concern associated with testing during a so-called "avalanche-restart" event where, for example, a large power outage affects a large number of endpoints, that, when power is restored, all attempt to reboot and, possibly, test. Devices need to randomize their initiation of a boot time test to avoid the problem.
たとえば、大規模な停電が多数のエンドポイントに影響を与える、いわゆる「雪崩 - restart」イベント中のテストに関連する懸念があります。。デバイスは、問題を回避するためにブートタイムテストの開始をランダム化する必要があります。
Security considerations for emergency calling have been documented in [RFC5069] and [RFC6280].
緊急呼び出しのセキュリティ上の考慮事項は、[RFC5069]および[RFC6280]で文書化されています。
This document suggests that security (TLS or IPsec) be used hop-by-hop on a SIP call to protect location information, identity, and other privacy-sensitive call data. It also suggests that if the attempt to create a security association fails, the call be retried without the security. It is more important to get an emergency call through than to protect the data; indeed, in many jurisdictions privacy is explicitly waived when making emergency calls. Placing a call without security may reveal user information, including location. The alternative, failing the call if security cannot be established, is considered unacceptable.
このドキュメントは、セキュリティ（TLSまたはIPSEC）をSIPコールでホップバイホップで使用して、位置情報、ID、その他のプライバシーに敏感なコールデータを保護することを示唆しています。また、セキュリティ協会を作成しようとする試みが失敗した場合、セキュリティなしで呼び出しが再試行されることも示唆されます。データを保護するよりも、緊急電話を通過することが重要です。実際、多くの管轄区域では、緊急電話を行う際にプライバシーが明示的に免除されます。セキュリティなしで電話をかけると、場所を含むユーザー情報が明らかになる場合があります。セキュリティを確立できない場合、代替手段がコールに失敗すると、受け入れられないと見なされます。
This document was created from "Emergency Services for Internet Telephony Systems" (Schulzrinne, 2004) together with sections from "Emergency Context Routing of Internet Technologies Architecture Considerations" (Polk, 2006).
このドキュメントは、「インターネットテレフォニーシステムの緊急サービス」（Schulzrinne、2004）から作成され、「インターネットテクノロジーアーキテクチャの考慮事項の緊急コンテキストルーティング」（Polk、2006）のセクションとともに作成されました。
Design Team members participating in this document creation include Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Shida Schubert, Tom Taylor, and Hannes Tschofenig. Further comments and input were provided by Richard Barnes, Barbara Stark, and James Winterbottom.
このドキュメント作成に参加するデザインチームのメンバーには、マーティンドリー、スチュゴールドマン、テッドハーディ、マークリンナー、ロジャーマーシャル、シーダシューベルト、トムテイラー、ハンネスツコフェニグが含まれます。さらなるコメントと入力は、リチャード・バーンズ、バーバラ・スターク、ジェームズ・ウィンターボトムによって提供されました。
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", December 2004.
[LLDP] IEEE、「IEEE802.1ABステーションおよびメディアアクセス制御」、2004年12月。
[LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006.
[LLDP-MED] ANSI/TIA、「リンクレイヤーディスカバリープロトコル - メディアエンドポイントディスカバリー」、TIA Standard、TIA-1057、2006年4月。
[NENAi3TRD] NENA, "08-751 v1 - i3 Technical Requirements (Long Term Definition)", 2006.
[Nenai3trd] Nena、「08-751 V1 -I3技術要件（長期定義）」、2006。
[PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, September 2011.
[PhoneBCP] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、2011年9月、作業中。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「即座のメッセージのためのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）の発信者の好み」、RFC 3841、2004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190] Carlberg、K.、Brown、I。、およびC. Beard、「IPテレフォニーでの緊急通信サービス（ETS）をサポートするためのフレームワーク」、RFC 4190、2005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[RFC4504] Sinnreich、H.、Lass、S。、およびC. Stredicke、「SIP Telephony Device要件と構成」、RFC 4504、2006年5月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Dynamic Host Configuration Protocol（DHCPV4およびDHCPV6）CIVICアドレス構成情報のオプション」、RFC 4776、2006年11月。
[RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007.
[RFC4967] Rosen、B。、「セッション開始プロトコルユニフォームリソース識別子のダイヤル文字列パラメーター」、RFC 4967、2007年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[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., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069] Taylor、T.、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「緊急コールマーキングとマッピングのセキュリティの脅威と要件」、RFC 5069、2008年1月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしでの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、2008年1月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson、M。およびJ. Winterbottom、「存在情報データ形式の市民ロケーション形式の改訂場所オブジェクト（PIDF-LO）」、RFC 5139、2008年2月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「Lost：A Location-s-Service Translation Protocol」、RFC 5222、2008年8月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「ダイナミックホスト構成プロトコル（DHCP）を使用した場所からサービスへの翻訳（Lost）サーバーの発見」、RFC 5223、2008年8月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359] Johnston、A.、Sparks、R.、Cunningham、C.、Donovan、S。、およびK. Summers、「セッション開始プロトコルサービスの例」、BCP 144、RFC 5359、2008年10月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv存在情報データ形式の場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項」、RFC 5491、2009年3月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）の取得と使用」、RFC 5627、2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630] Audet、F。、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP対応の位置配信（保有）」、RFC 5985、2010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M。およびJ. Winterbottom、「Local Location Information Server（LIS）の発見」、RFC 5986、2010年9月。
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6225] Polk、J.、Linsner、M.、Thomson、M.、およびB. Aboba、「座標ベースの位置構成情報の動的ホスト構成プロトコルオプション」、RFC 6225、2011年7月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「インターネットアプリケーションの場所と場所のプライバシーのアーキテクチャ」、BCP 160、RFC6280、2011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルの位置輸送」、RFC 6442、2011年12月。
[WGS84] NIMA, "NGA: DoD World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", Technical Report TR8350.2, Third Edition, July 1997.
[WGS84] NIMA、「NGA：DOD World Geodetic System 1984、その定義とローカル測地システムとの関係」、テクニカルレポートTR8350.2、第3版、1997年7月。
Authors' Addresses
著者のアドレス
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 USA
Brian Rosen Neustar、Inc。470 Conrad Dr Mars、PA 16046 USA
EMail: br@brianrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027 USA
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034 USA
ジェームズ・ポーク・シスコ・システム3913 Treemont Circle Colleyville、Texas 76034 USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Andrew Newton TranTech/MediaSolv 4900 Seminary Road Alexandria, VA 22311 USA
Andrew Newton Trantech/MediaSolv 4900 Seminary Road Alexandria、VA 22311 USA
Phone: +1 703 845 0656
EMail: andy@hxr.us