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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）で定義されているようなcitizen- /ビジター・ツー・権限の呼び出しは、多くの場合、優先アクセスのいくつかの種類を含む公共の通信インフラを利用してレスポンダによって作成されたもの（権限ツー機関）と区別することができます[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潜在的なモビリティ、。例えば、アップリンクなどエボリューションデータオプティマイズド（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は、インターネットマルチメディア緊急ではなく、回線交換のPSAPは、ボイスオーバーIP（VoIP）の呼び出しを扱うことができる方法を説明するよりも、ネイティブ呼び出しを処理する方法に焦点を当てています。多くの場合、パケット交換インターフェイスへの回線交換インターフェイスから遷移するのPSAPは、であり続けるために、例えば、レガシーインターフェイスにパケット交換呼を変換するゲートウェイとの組み合わせで、ここで説明されたメカニズムの一部を使用することができるかもしれません既存のコールの受け手の機器を使用することができ。ほとんどのシステムは、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）などのトンネリングメカニズムを介して接続することができます。トンネルは場所を知っている実際のアクセスネットワークのアイデンティティを不明瞭することができます。これは、大幅に、発信者の位置とルートの緊急コールは、緊急コールの処理のためのさまざまな規則やプロセスで、別の大陸であることができることを第一の要素ので、緊急通話を複雑にします。
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 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.
この文書では、のPSAPと発呼者によってセッション開始プロトコル（SIP）[RFC3261]の使用について説明します。他のドメイン間のコールシグナリングプロトコルは、緊急通報に使用することができるが、SIPは、ユビキタスであり、このユースケースの適切なサポートを持っています。例えばH.323、XMPP /ジングル、ISUPとSIPのような唯一のプロトコルは、メディアゲートウェイ制御プロトコル（MGCP）またはH.248 / Megacoのようなメディアゲートウェイコントローラプロトコルを除外、ドメイン間通信に適しています。後者のプロトコルは、電話をかける企業または事業者によって使用することができるが、そのような呼び出しは、ドメイン間の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メカニズム[RFC3264]を使用して、発信者とPSAPとの間でネゴシエートされ、任意のメディアタイプのセッションの作成をサポートします。
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つのステップがプロセスを呼び出した場合に焦点を当てて位置情報。この場合、呼び出しは、アプリケーション層の通信サービスプロバイダー（例えば、音声サービス・プロバイダ）を介してルーティングされてもよいが、ある必要はありません。基本的なプロトコルは、プロセスの一部は、通信サービスプロバイダに委任された他のモデルをサポートするために使用することができます。この文書では詳細にこれらのモデルまたはそれらと、ここで記述されたモデル間の相互運用性の問題のいずれかに対応していません。
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ヘッダフィールド、要求方法、状態コード、メッセージ本文、またはイベント・パッケージを必要としないが、それは以下に説明するように既存のメカニズムは、ある特定の方法で使用されることを必要はありません。このドキュメントの推奨事項を知らないユーザーエージェント（UAは）緊急コールを発信することができるかもしれませんが、機能が損なわれる可能性があります。例えば、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）受信機を含んでも、位置がワイヤーマップデータベースを使用して、ネットワーク管理者によって決定されてもよいです。
Location Information Server (LIS): A Location Information Server stores location information for retrieval by an authorized entity.
位置情報サーバー（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.
全国緊急番号協会（NENA）：国家緊急番号協会は「北米におけるユニバーサル緊急電話番号システムの技術的進歩、可用性、および実装を促進」するために専門家の組織です。これは、緊急コール仕様と手順を開発しています。
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.
ノマディックデバイス（ユーザー）：遊牧民のユーザーエージェントは、比較的短い期間のために、一時的にネットワークに接続されているが、緊急通話中に著しく移動しません。例としては、別の個室から時折移動した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項）が配備されているか、エンドポイントは、ロケーションの設定プロトコルを使用して、アクセスネットワークの位置情報サーバ（LIS）からその場所で（6.5節）で構成されますか、 （LCP）。ロケーションは、コールとSIPシグナリングに（セクション6.7）に搬送されます。呼がPSAPのURIのセットに位置をマップロケーション・ツー・サービス翻訳（LOST）プロトコル[RFC5222]を使用して、位置に基づく（セクション8）ルーティングされます。各URIは、のPSAPのグループの着信プロキシとして機能PSAPまたは緊急サービスルーティングプロキシ（ESRP）に解決されます。コールは、INVITEリクエストに含まれる位置が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シグナリングを用いた典型的なイーサネット接続された電話のための簡単な概要です。これは、このドキュメントの後半で提示される様々なオプションの選択肢の1セットを示します。
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].
電話ロケーション・コンフィギュレーション・プロトコル（LCP）を介して、例えば、市民[RFC4776]でDHCPサーバからロケーションを取得および/または地理[RFC6225]の形式、HTTP対応ロケーション配信（保持）サーバ[RFC5985]またはO最初のレベルのスイッチのリンク層検出プロトコル（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をその現在の位置については、失われた[RFC5222]サーバからローカル緊急ダイヤル文字列（複数可）を取得します。また、受信して、URIが失わサーバから取得したPSAPをキャッシュします。
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しばらく、利用者は、緊急電話をかけます。電話はダイヤル文字列からの緊急コールを認識し、使用して緊急コールをマークするために、[RFC5031] URN「URN：SOS：サービス」。
o It refreshes its location via DHCP and updates the PSAP's URI by querying the LoST mapping server with its location.
OそれはDHCP経由でその場所をリフレッシュし、その場所で失われたマッピングサーバを照会することにより、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それは、地理位置ヘッダ[RFC6442]にINVITE要求をSIPにその位置を置き、一般アウトバウンドプロキシを含む、その通常の発信呼処理を使用してコールを転送します。
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)
[M1]アリス - > LIS：LCP要求（単数または複数）（位置を求める）LIS - >アリス：LCP応答（s）は（場所で応答）[M2]アリス - >レジストラ：SIP REGISTERレジストラ - >アリス：SIP 200 OK（REGISTER）[M3]アリス - > LOSTサーバ：初期失われたクエリ（場所を含む）ロストサーバー - >アリス：初期LOST応答（PSAP-URIが含まれている文字列をダイヤル）
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)
[M4]アリス - > LIS：LCP要求（アップデートの場所）LIS - >アリス：LCP返信（場所で応答）[M5]アリス - > LOSTサーバー：更新クエリ（位置を含む）ロストサーバーLOST - >アリス：失われた応答をSIP INVITE（含まれているサービスURN、ロケーションおよびPSAP URI）[M7]発信プロキシ - > ESRP：>発信プロキシ - [M6]アリス（PSAP-URIが含まれている）SIPは、（場所およびPSAP URI、サービスURNを含ん）INVITE [M8 ] ESRP - > PSAP：SIPのINVITE（サービスURN、ロケーションおよび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構成のサーバ - サーバおそらく場所価値によって、または場所ごとの参照を含め、アリスのUAのIPアドレスやその他の構成情報を提供します。コンフィギュレーションサーバは、アリスのUAのためのSIPレジストラを含むことができます。ほとんどのSIP UAは登録されますので、緊急時には、発信呼び出して、ネットワーク内のようなサーバに登録する呼び出しを行うのUAのための一般的なシナリオになります。ほとんどの場合、UAは、PSAPが緊急コールが完了した後にコールバックできるようにするために登録する必要があります。すべての設定メッセージは、M3を通じてM1のラベルが付いていますが、簡単に完了するために、以上の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.
ESRPによっておそらくUAからの最初の要求または発信ネットワーク内のプロキシサーバによってにおけるコールルーティング、またはいずれかのために、位置プラスPSAP-URIにサービスURNのために失われた要求を処理する - Oサーバを失いました。
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.
一般的に、アリスのUAは、いずれかの位置を手動で設定した、一体的な位置測定機構を有している、またはアクセス（ブロードバンド）ネットワークから位置を取得するためにLCP [M1]を実行します。その後、アリスのUAは、最も可能性の高いSIPレジストラで、[M2]を登録します。これは彼女が他のSIPエンティティから連絡することができます。次に、彼女のUAは、失われたクエリは、緊急通話中に失敗した場合や緊急呼び出しメカニズムをテストするために使用する場合の使用のためにURIを学ぶための初期失ったクエリ[M3]を実行します。失われた応答は、提供された位置のための適切な緊急コールのダイヤル文字列が含まれています。
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]要求を作成します。場所ごとの値である場合、メッセージボディに示すURL：[RFC6442]は参照による位置-URIまたは[RFC3986]「CID」のいずれかを含む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.
INVITEメッセージは、緊急サービスドメインの最初のインバウンドプロキシですESRP [M7]にルーティングされます。位置および他の情報によって決定されるように、このメッセージは、アリスの位置[M8]のために最も適切なPSAPに向かっESRPによってルーティングされます。
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.
INVITEリクエストに対する200 OK応答は、アリスのUAにネットワークプロキシ発信する通話係UAからPSAPプロキシにESRPに、逆にパスを横断します。 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 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.
PSTNを使用して、緊急時のヘルプは、多くの場合にかかわらず、電話を購入したところの、国指定、広く知られている番号をダイヤルして召喚することができます。適切な数は、電話が接続されているインフラストラクチャによって決定されます。しかし、この数は、それは欧州連合の多くの国であるとして、それは、多くの場合、国または地域のために同じであっても、地域間で異なっています。一部の国では、緊急事態のすべてのタイプのために使用されている唯一の均一な数字列があります。他では、必要なレスポンダのタイプに固有のいくつかのシーケンス、例えば、警察のための1つ、火災のための別があります。エンドシステムのために、一方で、位置情報の自動包含を可能にするために、場所とは無関係に汎用識別子を有するように、呼経路内のデバイスと他のエンティティは、シグナリングプロトコル内の適切な処理を実行できるようにすることが望ましいです。緊急コールセットアップインチ
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.
そのような普遍的な識別子が存在しないので、ここで説明した全体的な緊急コールアーキテクチャは、共通の緊急呼び出し壺[RFC5031]を定義します。すべての緊急サービスは、単一の番号を使用すると、URNは「：サービス：SOS URN」です。ユーザーは、緊急URNを「ダイヤル」することが期待されていません。むしろ、適切な緊急ダイヤル文字列は、INVITEリクエストのRequest-URIで運ば対応するサービスのURNに変換されます。他の理由の中で、緊急の呼び出しが正常にシグナリングが、非緊急の呼び出しで場所を伝えない、ので、そのような翻訳は最高の、エンドポイントによって行われます。デバイスは、緊急コールを認識すると知られているならば、それは、場所を含めることができます。エンドポイントはそうしなかった場合、シグナリング仲介（プロキシサーバー）は、緊急ダイヤル文字列を認識することができます。
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.
失われた[RFC5222]は、所与の位置のダイヤルシーケンスを取得するためのメカニズムを提供します。失われたサーバーは、緊急サービスのためのダイヤル文字列を返す必要があります。エンドポイントはサービス壺にダイヤル文字列の変換をサポートしていない場合は、エンドポイントからそのプロキシへのダイヤルシーケンスは、ダイヤル文字列[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 a more precise value is known prior to dispatch. In this document, we use "routing location" and "dispatch location" when the distinction matters.
発信者を見つけるために使用される多くのメカニズムは、比較的長い「コールドスタート」の時間を持っています。限り30秒かかることがありますディスパッチのための十分な正確な位置を取得します。これは、緊急時を待つには長すぎます。これにより、より正確な値が事前にわかっている場合、コールルーティングの目的のために、例えば、呼にサービスを提供するセルサイト及びセクターが粗い位置を使用すること、及びその後、場所を更新するために、特にモバイルシステムでは、一般的ですディスパッチ。区別が重要ときに、この文書では、「ルーティングの場所」と「派遣先」を使用します。
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つのアパートの間で「demising」や分離壁の近くに、緊急コールを行うデバイスがどのように決定することが必要ですそれは、壁の側面。これはおそらく、3センチメートル精度要件を意味しています。このメモの日付の時点で、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:
市民：シビックの位置情報は、建物又は他の構造に対応する住所によって人や物の位置を記載しています。市民の位置は、床、部屋、及びキュービクル、よりきめの細かい位置情報を含むことができます。シビック情報は、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のプロトコルでは、両方の市民や地理空間形式がサポートされています。市民のフォームは、郵便及び管轄フィールドの両方が含まれます。セルタワー/セクタは、ジオポイントまたはポリゴンや市民の位置として表すことができます。位置表現の他の形態は、緊急コールで使用するための地理又は市民の値のいずれかにマッピングされなければなりません。
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.
緊急呼出のために、前搬送にその逆地理又はために市民からの位置情報の変換は望ましくありません。場所は、それが決定された形式で送信されるべきです。地理と市民の間の変換にはデータベースが必要です。 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.
いくつかのケースでは、エンティティは、おそらくいくつかの部分的に矛盾していること、位置情報の複数のソースを有することができます。位置情報は、エンドシステムと第三者の両方によって決定される場合、これは特にそうです。自己測定場所（例えば、GNSS）が魅力的であるが、アクセスネットワークによって提供される位置情報は、はるかに正確で、より信頼性のような密集した都市エリアでの高層ビルなどの一部の環境であってもよいです。
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に向けて送信することができますが、場所の順序は、使用する1（S）の受信者を導くために、送信者の最善の試みでなければなりません。
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.
位置情報は、位置データベース（「ワイヤデータベース」）へのエンドユーザまたはデバイスのための識別子のいくつかのフォームを関連付ける、アクセスネットワークによって維持することができます。企業内LAN、ワイヤーマップデータベースマップイーサネットスイッチポートで場所を構築します。 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 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.11ワイヤレス・アクセス・ポイントのため、ワイヤデータベースは、十分な位置分解能を提供することができます。ワイヤーマップによって決定されるように、アクセスポイントの位置は、アクセスポイントのクライアントのそれぞれの場所として供給してもよいです。しかし、これは、典型的には、IEEE 802.11のものよりも大きいセルを有するそのようなIEEE 802.16（WiMAXの）およびIEEE 802.22のような大規模システムのための真ではないかもしれません。エンドポイントが数キロメートル離れた基地局からであってもよいので、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及びガリレオ）受信機は、エンドデバイス内に直接埋め込むことができます。 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
U-TDOA - アップリンク到達時間差O
o Angle of Arrival - AOA
到着のO角度 - AOA
o Radio Frequency (RF) fingerprinting
O無線周波数（RF）フィンガープリンティング
o Advanced Forward Link Trilateration - AFLT
O高度順方向リンク三角測量 - AFLT
o Enhanced Forward Link Trilateration - EFLT
Oの拡張フォワードリンク三辺測量 - EFLT
Sometimes multiple mechanisms are combined, for example A-GPS with AFLT.
時には複数のメカニズムは、例えばAFLTとA-GPSのために、組み合わされます。
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節で述べたように、ローカルダイヤル文字列は、発信者の位置に依存します。デバイスは、独自の場所を知らない場合は、ローカルの緊急ダイヤル文字列を学ぶために失われたサービスを使用することはできません。発呼ネットワークデバイスがローカルダイヤル文字列を学習し、ユーザがダイヤル文字列（S）変化場所に移動したときにそれを更新し、またはダイヤル文字列決定自体を行うための別の方法を提供しなければなりません。
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など、この目的のために使用することができ、いくつかの場所の構成プロトコル（LCPの）があります。
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.
HELD [RFC5985]は、レイヤ7プロトコルを介して、値または参照することにより、市民又はジオロケーション・オブジェクトを送達することができます。クエリは、典型的には、識別子として要求元のIPアドレスを使用して、その識別子に関連付けられた位置値または参照を返します。 HELDは、一般的に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.
リンク層ディスカバリプロトコル[LLDP]メディアエンドポイントデバイス（MED）拡張[LLDP-MED]はレイヤ2ネットワークインフラストラクチャから直接位置情報を配信するために使用され、また、DHCPの方法と形式で同じ市民及び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をサポートするために使用されています。アクセスネットワークがリストに載っていないプロトコルをサポートし、緊急呼び出しのため、そのプロトコルを使用するために、そのネットワーク内のすべての携帯電話を必要とする可能性があります。しかしながら、イーサネット接続された電話機は、位置を取得することができなくなり、電話のユーザは、その携帯電話に緊急呼を配置することから思いとどまらされにくいです。ゲートウェイ、ルータ、およびその他のネットワーク・広がり・デバイスの広範な可用性は、間接的に接続されたエンドポイントは、ほぼすべてのネットワーク上で可能であることを意味します。ネットワークオペレータとベンダは、この要件を満たすためのショートカットはほとんど成功していると警告しています。
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アドレスを割り当てる）は、特にHELDため、位置を決定するためのLCPによって使用される識別子を不明瞭にすることができます。
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アドレスを不明瞭することができます。 LCPへのクエリがトンネルを通って、正しいIPアドレスを使用して、なく、直接IPパスを通過するように指定できるように、いくつかのVPNメカニズムをバイパスすることができます。他の場合には、何のバイパスは不可能であるが、VPNが確立される前に場所を構成することができます。彼らは場所を求めているデバイスの識別子としてIPアドレスを使用していないので、当然のことながら、レイヤ2つのメカニズム（DHCPの場所のオプションおよびLLDP-MED）を使用するLCPは、通常、このような問題から免疫があります。
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回、各さわやか万人の加入者をサポートしている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.
それは、ルーティング場所と入手精度（技術的には、自信と不確実性）を取得するのにかかる時間とのトレードオフがあります。すぐに必要とされる緊急コールをルーティングします。位置は、実質的に短い時間を待機することによって改善することができる場合は、（例えば、「クイック（位置）FIX」のいくつかの並べ替えのために）、待機することが好ましいです。 3秒、簡単な修正のための現在の公称の時間は、非常に長い時間がポストダイヤル遅延に追加されます。 NENAは、最後のダイヤルを押してから2秒でIPベースのシステムの完全な呼び出しがPSAPにリングしていること[NENAi3TRD]をお勧めします。
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.
取得プロトコルによって得られた位置情報の形式は、LCPフォームからPIDFにエンドポイントによってマッピングが必要になることがあり、搬送プロトコル用途（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は値によって提供される位置の更新を要求する方法がありません。ユーザエージェントクライアント（UAC）は、新たな位置情報を取得する場合、それは新たな場所を供給するために、新しい地理位置ヘッダフィールドにINVITE新規または更新トランザクションを使用して、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は知りません。好ましい機構は、正確な位置がLISへPSAPからのポーリング動作を必要とするのではなく、利用可能である場合に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.
HELD間接参照を使用する場合、PSAPはRESPONSETIMEパラメータの値「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に向けて複数の場所を送信するために許容されますが、ルートを選択要素が失わで使用するために正確に一つの場所を選択する必要があります。
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から最も一般的に変換するために使用し、非常に正確なデータベースを持っています。 1つのデータベースが地理に市民、たとえば、から変換するために使用し、市民へのGEOから別の変換されている場合は、データベースがわずかに異なる場合、エラーが頻繁に発生します。それは間違った建物への最初の応答を引き起こすこととしても、単一家屋番号のエラーは深刻です。派生場所は「由来する」方法トークン[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 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.
アドレスが有効であるかどうかを決定することは困難な場合があります。市内で、同じ通りには2つの名前の例については、多くの場合、または同じ名前を持つ2つの通りが異なる「接尾辞」（アベニュー、ストリート、サークル）があります。一部の国では、現在のシステムは、検証を提供します。例えば、米国では、マスター・ストリート・アドレス・ガイド（MSAG）は、全ての有効な住所を記録し、携帯電話の課金レコードにおけるサービスアドレスが有効な緊急サービス住所に対応するように使用されています。所与の地理は、少なくとも一つの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.
失われた[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）のデフォルトの場所は、提供され得るCMTS 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を返さなかった場合、それはPIDF-LOの形態にLCPから受ける場所の任意の形式をマッピングする責任があります。
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].
エンドポイントは、HELDプロトコルが使用されている場合は、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が第一、第二の値をプロビジョニングされ、そしてSIPドメインの第三の内のDNS SRVクエリ。
Emergency calls are routed based on one or more of the following criteria expressed in the call setup request (INVITE):
緊急コールは呼設定要求（INVITE）で表され、以下の基準の一つ以上に基づいてルーティングされます。
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とは別のものです。 ESRPsはメディアに基づいてルーティングを提供することができると期待されています。また、メディア機能は、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]を失っています。失われたが市民又はジオフォーム、プラスサービス識別子のいずれかで（による値）位置でクエリを受け付け、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及び/又は含まれる場所を提供し、プロキシサーバを容易にマッピングを行うことができました。
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]で提供メカニズムはありません。プロキシは、デバイスが重要性を認識した場合、デバイスからリダイレクトされたコール内の場所を含むことになる、サービス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.
アクセスネットワークまたは呼び出しネットワークが緊急当局によって提供されるデータを使用して独自のサーバーを実行するかもしれませんが失われたサーバーは、通常、地域の緊急当局によって提供されることになります。いくつかの企業は、社内の「のPSAP」にURIを提供し、地元の応答およびコール・センターを有していてもよく、そして自分自身の失われたサーバーを動作することが可能です。地域の規制は、社内サービスへの緊急の呼び出しを指示する企業の能力が制限される場合があります。
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ためには、最初のINVITE要求は、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]の要件の対象となっています。特に、シグナリング情報、すなわち、AESなどの強力な暗号化を含む暗号スイートと「SIPS」モードでは、トランスポート層セキュリティ（TLS）で実施すべきです。緊急通話のための[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のセキュア/多目的インターネットメール拡張（S / MIME）暗号化シグナル[RFC3261]などの機密性のメカニズムがあるため、それら曖昧場所を使用することができません。 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 UAは、場所を挿入し、SIPがRequest-URI内のサービスURNとINVITEメッセージを作成する緊急呼のルーティングを行う、ロスト判定ジオロケーションでRouteヘッダにPSAP、および場所のURIをヘッダ。 INVITE要求は（連絡先にし、Fromヘッダー）適切なコールバック識別子をも持っている必要があります。メディア感受性ルーティングを可能にするために、コールは、セッション記述プロトコル（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を引き起こすためのヒントとして使用することができるのAccept-Languageヘッダーに発現しました。 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プロキシサーバは、ロケーションベースのルーティングステップとダイヤル文字列の認識のいずれかを提供することができないのUAを支援することができなければなりません。プロキシは、地理位置ヘッダの欠如により、位置認識の欠如を認識することができます。これは、サービスURNが存在することのないFromヘッダー内のローカル緊急コールのダイヤル文字列の存在によって、ダイヤル文字列認識の欠如を認識することができます。これらは、可能な場合、エンドポイントの位置を取得し、それらは、地理位置ヘッダに挿入することができない場合、デフォルトの場所を使用する必要があります。彼らは場所を失っを照会し、要求URIで適切なサービスURNで、ルートが得られURIを置く必要があります。いずれにしても、それらはまた、SIPアイデンティティ又はP-アサート・アイデンティティを使用して発信者の情報を提供することが期待されます。多くの場合、彼らが緊急コールであるとき、通常は匿名としてマークされた呼び出しは匿名として渡されているかどうか、規制の問題です。プロキシは、ローカルの規制や慣行に準拠する必要があります。
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 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.
呼び出し受け手は元のコールが切断された場合は、緊急発信者に到達できる必要があります。伝統的な緊急通話では、有線と無線の緊急コールは、この目的のためにコールバック識別子を含みます。コールバックの2種類があります。コールがドロップされる、またはコールの受け手は、いくつかの重要な情報が、それは持っていないことが必要であることを認識した場合、それは緊急コールを発信し、デバイスをコールバックする必要があります。 PSAP、またはレスポンダは、ずっと後の発信者をコールバックする必要があるかもしれない、そしてその目的のために、それは、レコード（AOR）の通常のSIPアドレスを望んでいます。 SIPシステムでは、発信者がグローバルにルーティング可能なURI、おそらくグローバルにルーティング可能なユーザエージェントURI（GRUU）[RFC5627]を含む緊急呼でContactヘッダーフィールドを含まなければなりません。この識別子は、例えば、通話が途中で破棄され、場合コール受け手によってすぐにコールバックを開始するために使用されるだろう。懸念は、連絡先ヘッダを操作するバックツーバックユーザエージェント（型B2BUA）で発生します。そのような型B2BUAは常に同じデバイスにルーティングContactヘッダを含むべきです。
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）のアドレスとしてコールバック識別子はURIとしてヘッダフィールドから[RFC3261] SIPアイデンティティによって検証[RFC4474]またはネットワークアサート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は、REFER要求[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は、BYE要求を有する、すなわち通常のSIPの着信手順を使用して通話を終了します。
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.
コールが緊急コールであるとき、通常の通話がアクティブな状態で呼び出すことができるいくつかの特徴が許可されていません。そのようなコールウェイティング、コール転送、三者通話、および保持などのサービスを無効にする必要があります。
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コールを決定することができます。緊急コールが置かれた後、それが妥当な時間内に発生した場合、緊急コールの後に任意の同一ドメインから呼び出して供給ContactヘッダまたはのAoRを対象は、PSAPからのコールバックとして受け入れられるべきです。
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]を受け入れる必要があります。伝統的に、声がのPSAPが受け付けるだけメディアストリームとなっています。一部の国では、テキストは、ボドーコードまたは音声帯域内の同様のトーンエンコードされたシグナリングの形で聴覚障害を持つ人のために（「TTY」）受け入れられています。 SIPシグナリングを使用してメディアを交渉する能力を含みます。通常のSIPオファー/ [RFC3264]の交渉は、使用するメディアストリームに同意するために使用されるべきで答えます。 PSAPは、リアルタイムのテキスト[RFC4103]を受け入れる必要があります。 [RFC3551]で説明したようにすべてのPSAPは、符号化された音声を（北米におけるおよびmu-法則）G.711 A-法律を受け入れる必要があります。新しいテキストフォームが急速に今非常に一般的なインスタントメッセージングと、のPSAPは、少なくとも「ポケットベル・モード」MESSAGE要求[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.
例えば、大規模な停電が電源が回復する、というエンドポイントの数が多い、おそらく、再起動とするすべての試み、テストに影響を与え、いわゆる「雪崩再始動」イベント中に、試験に関連した懸念があります。デバイスは、この問題を回避するために、ブート時のテストの彼らの開始をランダム化する必要があります。
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コールにホップバイホップを使用することを示唆しています。また、セキュリティアソシエーションを作成する試みが失敗した場合、呼び出しは、セキュリティなしで再試行することを示唆しています。データを保護するために、よりを通じて、緊急コールを取得することがより重要です。緊急呼び出しを行う際に、実際、多くの国でプライバシーが明示的に免除されます。セキュリティなしで呼び出しを配置する場所など、ユーザー情報を公開してもよいです。セキュリティが確立できない場合、コールが失敗代替は、容認できないと考えられています。
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).
この文書は、一緒に（ポーク、2006）、「インターネット技術アーキテクチャの考慮事項の緊急コンテキストルーティング」からのセクションで、「インターネットテレフォニーシステムのための緊急サービス」（Schulzrinneと、2004）から作成されました。
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.
この文書作成に参加するデザインチームのメンバーは、マーティン・ドリー、スチューゴールドマン、テッドハーディー、マルク・Linsner、ロジャー・マーシャル、志田シューベルト、トム・テイラー、およびハンネスTschofenigが含まれます。また、コメントや入力はリチャード・バーンズ、バーバラ・スターク、そしてジェームズ・ウィンターボトムによって提供されました。
[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規格、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]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（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]キャンベル、B.、ローゼンバーグ、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]スパークス、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.、フレデリック、R.、およびV.ヤコブソン、 "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]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（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]ローゼンバーグ、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]ローゼンバーグ、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[RFC4190]カールバーグ氏、K.、ブラウン、I.、およびC.ベアード、 "IPテレフォニーで緊急通信サービス（ETS）をサポートするためのフレームワーク"、RFC 4190、2005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[RFC4504] Sinnreich、H.、小娘、S.、およびC. Stredicke、 "SIPテレフォニーデバイスの要件と構成"、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.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007.
[RFC4967]ローゼン、B.は、RFC 4967、2007年7月、「セッション開始プロトコルユニフォームリソース識別子のための文字列パラメータをダイヤル」。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（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.マーシャル、 "インターネット技術との緊急コンテキスト解決のための要件"、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]テイラー、T.、Tschofenig、H.、Schulzrinneと、H.、およびM・シャンミューガム、 "セキュリティの脅威と緊急マーキングコールとマッピングのための要件"、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.、周、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]トムソン、M.及びJ.ウィンター、RFC 5139、2008年2月 "プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）のための改訂シビックロケーションフォーマット"。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、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.、ポーク、J.、およびH. Tschofenig、RFC 5223、2008年8月 "動的ホスト構成プロトコルを（DHCP）を使用する場所・ツー・サービス翻訳（LOST）サーバーの検出"。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]ジョンストン、A.、スパークス、R.、カニンガム、C.、ドノバン、S.、およびK.サマーズ、 "セッション開始プロトコルサービス例"、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]ウィンターボトム、J.、トムソン、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]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）の取得と使用" を参照してください。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630] Audet、F.、RFC 5630 "セッション開始プロトコル（SIP）におけるSIPS URIスキームの使用"、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]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]バーンズ、M.、 "HTTP対応の場所デリバリー（保持）"、RFC 5985、2010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]トムソン、M.とJ.ウィンターボトム、 "ローカル位置情報サーバー（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]ポーク、J.、Linsner、M.、トムソン、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]バーンズ、R.、Lepinski、M.、クーパー、A.、モリス、J.、Tschofenig、H.、およびH. Schulzrinneと、 "インターネットアプリケーションにおける場所と場所のプライバシーのためのアーキテクチャ"、BCP 160、RFC 6280、2011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442]ポーク、J.、ローゼン、B.、およびJ.ピーターソン、 "セッション開始プロトコルのための場所搬送"、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の世界測地系1984、その定義とローカル測地系との関係」、技術報告書TR8350.2、第3版、1997年7月。
Authors' Addresses
著者のアドレス
Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 USA
ブライアン・ローゼンNeuStar、Inc.の470コンラッド博士火星、PA 16046 USA
EMail: br@brianrosen.net
メールアドレス：br@brianrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027 USAのヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7042 Eメール：hgs@cs.columbia.edu URI：http://www.cs.columbia.edu
James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034 USA
ジェームズ・ポークシスコシステムズ3913 Treemontサークルコリーヴィル、テキサス州76034 USA
Phone: +1-817-271-3552 EMail: jmpolk@cisco.com
電話：+ 1-817-271-3552 Eメール：jmpolk@cisco.com
Andrew Newton TranTech/MediaSolv 4900 Seminary Road Alexandria, VA 22311 USA
アンドリュー・ニュートンTranTech / MediaSolv 4900神学校道路アレクサンドリア、VA 22311 USA
Phone: +1 703 845 0656 EMail: andy@hxr.us
電話：+1 703 845 0656 Eメール：andy@hxr.us