[要約] RFC 6881は、緊急通報をサポートするための通信サービスのベストカレントプラクティスを提供しています。その目的は、緊急通報システムの信頼性と効果を向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 6881 NeuStar
BCP: 181 J. Polk
Category: Best Current Practice Cisco Systems
ISSN: 2070-1721 March 2013
Best Current Practice for Communications Services in Support of Emergency Calling
緊急通報をサポートする通信サービスの現在のベストプラクティス
Abstract
概要
The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.
IETFおよびその他の標準化組織は、IPネットワークに緊急通話を発信するさまざまな側面を標準化することを目的とした取り組みを行っています。このメモは、IETFプロトコルを使用するデバイス、ネットワーク、およびサービスが緊急呼び出しを行うためにそのような標準をどのように使用する必要があるかに関する現在のベストプラクティスについて説明しています。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化しています。
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). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc6881.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6881で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of How Emergency Calls Are Placed ......................3
4. Which Devices and Services Should Support Emergency Calls? ......4
5. Identifying an Emergency Call ...................................4
6. Location and Its Role in an Emergency Call ......................5
6.1. Types of Location Information ..............................6
6.2. Location Determination .....................................6
6.2.1. User-Entered Location Information ...................6
6.2.2. Access Network "Wire Database" Location
Information .........................................6
6.2.3. End System Measured Location Information ............7
6.2.4. Network Measured Location Information ...............7
6.3. Who Adds Location? The Endpoint, or the Proxy? ............8
6.4. Location and References to Location ........................8
6.5. End System Location Configuration ..........................8
6.6. When Location Should Be Configured ........................10
6.7. Conveying Location ........................................11
6.8. Location Updates ..........................................11
6.9. Multiple Locations ........................................12
6.10. Location Validation ......................................12
6.11. Default Location .........................................13
6.12. Other Location Considerations ............................13
7. LIS and LoST Discovery .........................................13
8. Routing the Call to the PSAP ...................................14
9. Signaling of Emergency Calls ...................................15
9.1. Use of TLS ................................................15
9.2. SIP Signaling Requirements for User Agents ................16
9.3. SIP Signaling Requirements for Proxy Servers ..............17
10. Callbacks .....................................................18
11. Mid-Call Behavior .............................................19
12. Call Termination ..............................................19
13. Disabling of Features .........................................19
14. Media .........................................................20
15. Testing .......................................................21
16. Security Considerations .......................................22
17. IANA Considerations ...........................................22
17.1. Test Service URN .........................................22
17.2. 'test' Subregistry .......................................23
18. Acknowledgements ..............................................23
19. References ....................................................23
19.1. Normative References .....................................23
19.2. Informative References ...................................27
This document describes how access networks, Session Initiation Protocol [RFC3261] user agents, proxy servers, and Public Safety Answering Points (PSAPs) support emergency calling, as outlined in [RFC6443], which is designed to complement the present document in section headings, numbering, and content. Understanding [RFC6443] is necessary to understand this document. This Best Current Practice (BCP) succinctly describes the requirements of end devices and applications (requirements prefaced by "ED-"), access networks (including enterprise access networks) (requirements prefaced by "AN-"), service providers (requirements prefaced by "SP-"), and PSAPs to achieve globally interoperable emergency calling on the Internet.
このドキュメントでは、[RFC6443]で概説されているように、アクセスネットワーク、Session Initiation Protocol [RFC3261]ユーザーエージェント、プロキシサーバー、Public Safety Answering Point（PSAP）が緊急通話をサポートする方法について説明します。番号付け、および内容。このドキュメントを理解するには、[RFC6443]を理解する必要があります。このベストカレントプラクティス（BCP）は、エンドデバイスとアプリケーションの要件（「ED-」で始まる要件）、アクセスネットワーク（エンタープライズアクセスネットワークを含む）（「AN-」で始まる要件）、サービスプロバイダー（以下で始まる要件）を簡潔に説明しています「SP-」）、およびPSAPは、インターネット上でグローバルに相互運用可能な緊急通話を実現します。
This document also defines requirements for "intermediate" devices that exist between end devices or applications and the access network. For example, a home router is an intermediate device. Reporting location on an emergency call (see Section 6) may depend on the ability of such intermediate devices to meet the requirements prefaced by "INT-".
このドキュメントでは、エンドデバイスまたはアプリケーションとアクセスネットワークの間に存在する「中間」デバイスの要件も定義しています。たとえば、ホームルーターは中間デバイスです。緊急通報（セクション6を参照）での場所の報告は、「INT-」で始まる要件を満たす中間デバイスの能力に依存する場合があります。
The access network requirements apply to those networks that may be used to place emergency calls using IETF protocols. Local regulations may impact the need to support this document's access network requirements.
アクセスネットワークの要件は、IETFプロトコルを使用して緊急コールを発信するために使用できるネットワークに適用されます。地域の規制により、このドキュメントのアクセスネットワーク要件をサポートする必要性が影響を受ける場合があります。
Other organizations, such as the National Emergency Number Association (NENA), define the PSAP interface. NENA's documents reference this document.
National Emergency Number Association（NENA）などの他の組織がPSAPインターフェイスを定義しています。 NENAのドキュメントはこのドキュメントを参照しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document uses terms from [RFC3261], [RFC5012], and [RFC6443].
このドキュメントでは、[RFC3261]、[RFC5012]、および[RFC6443]の用語を使用しています。
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 must obtain his location (Section 6) prior to making emergency calls. To get this location, either a form of measuring (e.g., GPS) ([RFC6443] Section 6.2.3) device location in the endpoint is deployed or the endpoint is configured (Section 6.5) with its location from the access network's Location Information Server (LIS). 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 a group of PSAPs. The call arrives at the PSAP with the location included in the SIP INVITE request.
緊急コールは、ホームまたは訪問済みの緊急ダイヤルストリングが検出されたときにコールセットアップシグナリングに配置される一意のサービスURN [RFC5031]によって、他のコールと区別できます（セクション5）。緊急サービスは特定の地理的地域に限定されているため、発信者は緊急電話をかける前に自分の場所（セクション6）を取得する必要があります。この場所を取得するには、エンドポイント内のデバイスの場所を測定する形式（GPSなど）（[RFC6443]セクション6.2.3）を展開するか、アクセスネットワークのロケーション情報サーバーからの場所を使用してエンドポイントを構成します（セクション6.5）。 （LIS）。ロケーションは、コールを伴うSIPシグナリングで伝達されます（6.7項）。呼び出しは、ロケーションからサービスへの変換（LoST）プロトコル[RFC5222]を使用するロケーションに基づいてルーティングされます（セクション8）。これは、ロケーションをPSAP URIのセットにマップします。各URIは、PSAPまたはPSAPのグループにサービスを提供する緊急サービスルーティングプロキシ（ESRP）に解決されます。コールは、SIP INVITE要求に含まれている場所でPSAPに到着します。
ED-1: A device or application that implements SIP calling SHOULD support emergency calling. Some jurisdictions have regulations governing which devices need to support emergency calling, and developers are encouraged to ensure that devices they develop meet relevant regulatory requirements. Unfortunately, the natural variation in those regulations also makes it impossible to accurately describe the cases when developers do or do not have to support emergency calling.
ED-1：SIP通話を実装するデバイスまたはアプリケーションは、緊急通話をサポートする必要があります（SHOULD）。一部の法域では、緊急通話をサポートする必要のあるデバイスを管理する規制があります。開発者は、開発したデバイスが関連する規制要件を満たすようにすることをお勧めします。残念ながら、これらの規制の自然な変化により、開発者が緊急通報をサポートする必要がある場合とサポートする必要がない場合を正確に説明することも不可能になります。
SP-1: If a device or application expects to be able to place a call for help, the service provider that supports it MUST facilitate emergency calling. Some jurisdictions have regulations governing this.
SP-1：デバイスまたはアプリケーションが助けを求めることができると期待する場合、それをサポートするサービスプロバイダーは緊急通話を促進する必要があります。一部の法域では、これを管理する規制があります。
ED-2: Devices that create media sessions and exchange real-time 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. Some jurisdictions have regulations governing this.
ED-2：メディアセッションを作成し、リアルタイムのオーディオ、ビデオ、テキストを交換し、さまざまなアドレスへのセッションを確立し、プライベートIPネットワークまたはインターネット経由で通信するデバイスは、緊急通話をサポートする必要があります（SHOULD）。一部の法域では、これを管理する規制があります。
ED-3: Endpoints SHOULD recognize dial strings of emergency calls. If the service provider always knows the location of the device (the correct dial string depends on which country a caller is in), the service provider may recognize them; see SP-2.
ED-3：エンドポイントは緊急コールのダイヤル文字列を認識する必要があります。サービスプロバイダーがデバイスの場所を常に知っている場合（正しいダイヤル文字列は発信者がいる国によって異なります）、サービスプロバイダーはそれらを認識できます。 SP-2を参照してください。
SP-2: Proxy servers SHOULD recognize emergency dial strings if for some reason the endpoint does not recognize them.
SP-2：何らかの理由でエンドポイントが緊急ダイヤル文字列を認識しない場合、プロキシサーバーは緊急ダイヤル文字列を認識する必要があります（SHOULD）。
ED-4/SP-3: Emergency calls MUST be marked with a service URN in the Request-URI of the INVITE.
ED-4 / SP-3：緊急コールは、INVITEのRequest-URIでサービスURNでマークする必要があります。
ED-5/SP-4: Geographically local dial strings MUST be recognized.
ED-5 / SP-4：地理的にローカルなダイヤル文字列を認識する必要があります。
ED-6/SP-5: Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined.
ED-6 / SP-5：デバイスは、ホームダイヤル文字列を決定できる母国で設定できる必要があります。
ED-7/SP-6: Emergency dial strings SHOULD be determined from LoST [RFC5222]. Dial strings MAY be configured directly into the device.
ED-7 / SP-6：緊急ダイヤル文字列はLoST [RFC5222]から決定する必要があります。ダイヤル文字列は、デバイスに直接構成できます。
AN-1: LoST servers MUST return dial strings for emergency services.
AN-1：LoSTサーバーは、緊急サービスのダイヤル文字列を返さなければなりません。
ED-8: Endpoints that do not recognize emergency dial strings SHOULD send dial strings as per [RFC4967].
ED-8：緊急ダイヤル文字列を認識しないエンドポイントは、[RFC4967]に従ってダイヤル文字列を送信する必要があります（SHOULD）。
SP-7: If a proxy server recognizes dial strings on behalf of its clients, it MUST recognize emergency dial strings represented by [RFC4967] and SHOULD recognize the emergency dial strings represented by a tel URI [RFC3966].
SP-7：プロキシサーバーがクライアントに代わってダイヤル文字列を認識する場合、[RFC4967]で表される緊急ダイヤル文字列を認識しなければならず（MUST）、Tel URI [RFC3966]で表される緊急ダイヤル文字列を認識する必要があります（SHOULD）。
ED-9: Endpoints SHOULD be able to have home dial strings provisioned.
ED-9：エンドポイントは、ホームダイヤル文字列をプロビジョニングできる必要があります（SHOULD）。
SP-8: Service providers MAY provision home dial strings in devices.
SP-8：サービスプロバイダーは、デバイスにホームダイヤル文字列をプロビジョニングできます（MAY）。
ED-10: Devices SHOULD NOT have one-button emergency calling initiation.
ED-10：デバイスには、ボタン1つで緊急通話を開始しないでください。
ED-11/SP-9: All sub-services for the 'sos' service specified in [RFC5031] MUST be recognized.
ED-11 / SP-9：[RFC5031]で指定された「sos」サービスのすべてのサブサービスを認識しなければなりません（MUST）。
Handling location for emergency calling usually involves several steps to process, and multiple entities are involved. In Internet emergency calling, where the endpoint is located is determined using a variety of measurement or wire-tracing methods. Endpoints can be configured with their own location by the access network. In some circumstances, a proxy server can 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 entities) in the signaling. Likewise, we employ Location Configuration Protocols (LCPs), the Location-to-Service Mapping Protocol, and Location Conveyance Protocols for these functions. The Location-to-Service Translation protocol [RFC5222] is the Location Mapping Protocol defined by the IETF.
緊急通報の場所の処理には通常、いくつかの処理ステップが含まれ、複数のエンティティが関与します。インターネット緊急通話では、エンドポイントの場所は、さまざまな測定方法またはワイヤートレース方法を使用して決定されます。エンドポイントは、アクセスネットワークによって独自の場所で設定できます。状況によっては、プロキシサーバーがエンドポイントに代わってシグナリングに場所を挿入できます。ロケーションは、コールを送信するURIにマッピングされ、ロケーションはシグナリングでPSAP（および他のエンティティ）に伝達されます。同様に、これらの機能には、ロケーション構成プロトコル（LCP）、ロケーションからサービスへのマッピングプロトコル、およびロケーション伝達プロトコルを採用しています。ロケーションからサービスへの変換プロトコル[RFC5222]は、IETFによって定義されたロケーションマッピングプロトコルです。
There are several forms of location. All IETF location configuration and location conveyance protocols support both civic and geospatial (geo) forms. The civic forms include both postal and jurisdictional fields. A cell tower/sector can be represented as a point (geo or civic) or polygon. Endpoints, intermediate devices, and service providers receiving other forms of location representation MUST map them into either a geo or civic for use in emergency calls.
ロケーションにはいくつかの形式があります。すべてのIETFロケーション構成およびロケーション伝達プロトコルは、市民および地理空間（ジオ）フォームの両方をサポートします。市民形態には、郵便および管轄区域の両方が含まれます。セルタワー/セクターは、ポイント（地理または市民）またはポリゴンとして表すことができます。エンドポイント、中間デバイス、およびその他の形式のロケーション表現を受信するサービスプロバイダーは、緊急コールで使用するために、それらを地理または市民のいずれかにマップする必要があります。
ED-12/INT-1/SP-10: Endpoints, intermediate devices, and service providers MUST be prepared to handle location represented in either civic or geo form.
ED-12 / INT-1 / SP-10：エンドポイント、中間デバイス、およびサービスプロバイダーは、市民または地理形式で表される場所を処理できるように準備する必要があります。
ED-13/INT-2/SP-11/AN-2: Entities MUST NOT convert (civic to geo or geo to civic) from the form of location that the determination mechanism (see Section 6.2) supplied prior to receipt by the PSAP.
ED-13 / INT-2 / SP-11 / AN-2：エンティティは、PSAPによる受信前に決定メカニズム（セクション6.2を参照）が提供した場所の形式から（市民から地理または地理から市民）に変換してはなりません（MUST NOT） 。
ED-14/INT-3/AN-3: Any location determination mechanism MAY be used, provided the accuracy of the location meets local requirements.
ED-14 / INT-3 / AN-3：位置の精度が地域の要件を満たす場合は、位置決定メカニズムを使用できます。
ED-15/INT-4/AN-4: Devices, intermediate devices, and/or access networks SHOULD support a manual method to override the location the access network determines. When the override location is supplied in civic form, it MUST be possible for the resultant Presence Information Data Format Location Object (PIDF-LO) received at the PSAP to contain any of the elements specified in [RFC4119] and [RFC5139].
ED-15 / INT-4 / AN-4：デバイス、中間デバイス、および/またはアクセスネットワークは、アクセスネットワークが決定する場所を上書きする手動の方法をサポートする必要があります（SHOULD）。オーバーライドの場所が公的な形式で提供される場合、PSAPで受信した結果のプレゼンス情報データ形式の場所オブジェクト（PIDF-LO）に、[RFC4119]および[RFC5139]で指定された要素を含めることが可能でなければなりません。
AN-5: Access networks supporting copper, fiber, or other hard-wired IP packet services SHOULD support location configuration. If the network does not support location configuration, it MUST require every device or intermediate device that connects to the network to support end system measured location.
AN-5：銅線、ファイバー、またはその他の有線IPパケットサービスをサポートするアクセスネットワークは、ロケーション構成をサポートする必要があります（SHOULD）。ネットワークがロケーション構成をサポートしていない場合は、ネットワークに接続するすべてのデバイスまたは中間デバイスが、エンドシステムで測定されたロケーションをサポートする必要があります。
AN-6/INT-5: Access networks and intermediate devices providing wire database location information SHOULD provide interior location data (building, floor, room, cubicle) where possible. It is RECOMMENDED that interior location be provided when spaces exceed approximately 650 square meters. See [RFC6443] Section 6.2.2 for a discussion of how this value was determined.
AN-6 / INT-5：ワイヤーデータベースの位置情報を提供するアクセスネットワークと中間デバイスは、可能な場合は内部の位置データ（建物、床、部屋、キュービクル）を提供する必要があります（SHOULD）。スペースが約650平方メートルを超える場合は、内部の場所を指定することをお勧めします。この値がどのように決定されたかについては、[RFC6443]セクション6.2.2を参照してください。
AN-7/INT-6: Access networks and intermediate devices (including enterprise networks) that support intermediate range wireless connections (typically 100 m or less of range) and that do not support a more accurate location determination mechanism such as triangulation MUST support location configuration where the location of the access point is reflected as the location of the clients of that access point.
AN-7 / INT-6：中距離無線接続（通常は100 m以下）をサポートし、三角測量などのより正確な位置決定メカニズムをサポートしないアクセスネットワークと中間デバイス（エンタープライズネットワークを含む）は、位置をサポートする必要がありますアクセスポイントの場所がそのアクセスポイントのクライアントの場所として反映される構成。
AN-8/INT-7: Where the access network provides location configuration, intermediate devices MUST either be transparent to it or provide an interconnected client for the supported configuration mechanism and a server for a configuration protocol supported by end devices downstream of the intermediate device such that the location provided by the access network is available to clients as if the intermediate device was not in the path.
AN-8 / INT-7：アクセスネットワークが場所の構成を提供する場合、中間デバイスはそれに対して透過的であるか、サポートされている構成メカニズムに相互接続されたクライアントと、中間デバイスの下流のエンドデバイスによってサポートされる構成プロトコルにサーバーを提供する必要があります中間デバイスがパスにないかのように、アクセスネットワークによって提供される場所をクライアントが利用できるようにします。
ED-16/INT-8: Devices MAY support end system measured location. See [RFC6443] Section 6 for a discussion of accuracy of location.
ED-16 / INT-8：デバイスは、エンドシステムの測定位置をサポートする場合があります。位置の正確さについては、[RFC6443]セクション6をご覧ください。
ED-17/INT-9/AN-9: Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1 km accuracy) for the routing of calls. The location mechanism MAY be a service provided by the access network.
ED-17 / INT-9 / AN-9：位置のエンドポイント測定をサポートするデバイスは、コールのルーティングに対して少なくとも粗い位置機能（通常は1 km未満の精度）を備えている必要があります。ロケーションメカニズムは、アクセスネットワークによって提供されるサービスであるかもしれません。
AN-10: Access networks MAY provide network measured location determination. Wireless access networks that do not supply network measured location MUST require every device or intermediate device connected to the network to support end system measured location. Uncertainty and confidence may be specified by local regulation. Where not specified, uncertainty of less than 100 meters with 95% confidence is RECOMMENDED for dispatch location.
AN-10：アクセスネットワークは、ネットワークで測定された位置決定を提供する場合があります。ネットワーク測定位置を提供しないワイヤレスアクセスネットワークは、ネットワークに接続されたすべてのデバイスまたは中間デバイスがエンドシステム測定位置をサポートすることを要求する必要があります。不確実性と信頼性は、地域の規制によって指定される場合があります。特に明記されていない場合、ディスパッチロケーションには100メートル未満の不確実性と95％の信頼性が推奨されます。
AN-11: Access networks that provide network measured location MUST have at least a coarse location (typically <1 km when not location hiding) capability at all times for the routing of calls.
AN-11：ネットワーク測定位置を提供するアクセスネットワークは、コールのルーティングのために、常に粗い位置（通常、位置非表示でない場合は1 km未満）の機能を備えている必要があります。
AN-12: Access networks with a range of <10 meters (e.g., personal area networks such as Bluetooth) MUST provide a location to mobile devices connected to them. The location provided SHOULD be that reported by the upstream access network unless a more accurate mechanism is available.
AN-12：範囲が10メートル未満のアクセスネットワーク（Bluetoothなどのパーソナルエリアネットワークなど）は、接続されているモバイルデバイスに場所を提供する必要があります。提供される場所は、より正確なメカニズムが利用可能でない限り、アップストリームアクセスネットワークによって報告される場所である必要があります。
ED-18/INT-10: Endpoints SHOULD attempt to configure their own location using the Location Configuration Protocols (LCPs) listed in ED-21.
ED-18 / INT-10：エンドポイントは、ED-21に記載されているロケーション構成プロトコル（LCP）を使用して、独自のロケーションを構成する必要があります（SHOULD）。
SP-12: Proxies MAY provide location on behalf of devices if:
SP-12：次の場合、プロキシはデバイスに代わって位置を提供できます。
o The proxy has a relationship with all access networks the device could connect to, and the relationship allows it to obtain location.
o プロキシには、デバイスが接続できるすべてのアクセスネットワークとの関係があり、その関係によってデバイスは場所を取得できます。
o The proxy has an identifier, such as an IP address, that can be used by the access network to determine the location of the endpoint, even in the presence of NAT and VPN tunnels that may obscure the identifier between the access network and the service provider.
o プロキシにはIPアドレスなどの識別子があり、アクセスネットワークとサービスプロバイダーの間の識別子を不明瞭にする可能性があるNATおよびVPNトンネルが存在する場合でも、エンドポイントの場所を特定するためにアクセスネットワークで使用できます。 。
ED-19/INT-11/SP-13: Where proxies provide location on behalf of endpoints, the service provider MUST ensure that either the end device is provided with the local dial strings for its current location (where the end device recognizes dial strings) or the service provider proxy MUST detect the appropriate local dial strings at the time of the call.
ED-19 / INT-11 / SP-13：プロキシがエンドポイントの代わりに場所を提供する場合、サービスプロバイダーは、エンドデバイスに現在の場所のローカルダイヤル文字列が提供されるようにする必要があります（エンドデバイスがダイヤル文字列を認識する場所） ）またはサービスプロバイダープロキシは、呼び出し時に適切なローカルダイヤル文字列を検出する必要があります。
ED-20/INT-12: Devices SHOULD be able to accept and forward location-by-value or location-by-reference. An end device that receives location-by-reference (and does not also get the corresponding value) MUST be able to perform a dereference operation to obtain a value.
ED-20 / INT-12：デバイスは、値によるロケーションまたは参照によるロケーションを受け入れて転送できる必要があります（SHOULD）。参照による位置情報を受け取る（対応する値も取得しない）エンドデバイスは、逆参照操作を実行して値を取得できなければなりません（MUST）。
Obtaining location from the access network may be preferable even if the device can measure its own location, especially indoors where most measurement mechanisms are not accurate enough. The requirements listed in this section do not apply to devices that can accurately measure their own location.
デバイスが自身の位置を測定できる場合でも、特にほとんどの測定メカニズムが十分に正確ではない屋内では、アクセスネットワークから位置を取得することをお勧めします。このセクションに記載されている要件は、自分の位置を正確に測定できるデバイスには適用されません。
ED-21/INT-13: Devices MUST support both the Dynamic Host Configuration Protocol (DHCP) location options [RFC4776] [RFC6225] and HTTP-Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a specific access network interface for which location configuration mechanisms such as Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device SHOULD support the additional respective access network specific location configuration mechanism.
ED-21 / INT-13：デバイスは、動的ホスト構成プロトコル（DHCP）ロケーションオプション[RFC4776] [RFC6225]とHTTP対応ロケーション配信（HELD）[RFC5985]の両方をサポートする必要があります。デバイスが、リンク層検出プロトコル-メディアエンドポイント検出（LLDP-MED）[LLDP-MED]または802.11vなどの場所構成メカニズムが指定されている特定のアクセスネットワークインターフェイスを展開する場合、デバイスは追加のそれぞれのアクセスネットワーク固有の場所をサポートする必要があります（SHOULD）構成メカニズム。
AN-13/INT-14: The access network MUST support either DHCP location options or HELD. The access network SHOULD support other location configuration technologies that are specific to the type of access network.
AN-13 / INT-14：アクセスネットワークは、DHCPロケーションオプションまたはHELDのいずれかをサポートする必要があります。アクセスネットワークは、アクセスネットワークのタイプに固有のその他のロケーション構成テクノロジーをサポートする必要があります（SHOULD）。
AN-14/INT-15: Where a router is employed between a LAN and WAN in a small (less than approximately 650 square meters) area, the router MUST be transparent to the location provided by the WAN to the LAN. This may mean the router must obtain location as a client from the WAN and supply an LCP server to the LAN with the location it obtains. Where the area is larger, the LAN MUST have a location configuration mechanism satisfying the requirements of this document.
AN-14 / INT-15：ルーターがLANとWANの間の狭いエリア（約650平方メートル未満）で採用されている場合、ルーターはWANからLANに提供された場所に対して透過的でなければなりません。これは、ルーターがWANからクライアントとして場所を取得し、取得した場所でLCPサーバーをLANに提供する必要があることを意味します。エリアがより大きい場合、LANはこのドキュメントの要件を満たすロケーション設定メカニズムを備えている必要があります。
ED-22/INT-16: Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location MUST be used.
ED-22 / INT-16：エンドポイントは、デバイスでサポートされているすべてのLCPを任意の順序または並列で試行する必要があります（SHOULD）。ロケーションの提供に成功した最初のものを使用する必要があります。
AN-15/INT-17: Access networks that support more than one LCP MUST reply with the same location information (within the limits of the data format for the specific LCP) for all LCPs it supports.
AN-15 / INT-17：複数のLCPをサポートするアクセスネットワークは、サポートするすべてのLCPについて（特定のLCPのデータ形式の制限内で）同じ位置情報で応答する必要があります。
ED-23/INT-18/SP-14: When HELD is the LCP, the request MUST specify a value of "emergencyRouting" for the "responseTime" parameter and use the resulting location for routing. If a value for dispatch location will be sent, another request with the "responseTime" parameter set to "emergencyDispatch" must be completed, with the result sent for dispatch purposes.
ED-23 / INT-18 / SP-14：HELDがLCPの場合、リクエストは「responseTime」パラメーターに「emergencyRouting」の値を指定し、ルーティングの結果の場所を使用する必要があります。ディスパッチロケーションの値が送信される場合、「responseTime」パラメータが「emergencyDispatch」に設定された別のリクエストが完了し、ディスパッチ目的で結果が送信される必要があります。
ED-24: Where the operating system supporting application programs that need location for emergency calls does not allow access to Layer 2 and Layer 3 functions necessary for a client application to use DHCP location options and/or other location technologies that are specific to the type of access network, the operating system MUST provide a published API conforming to ED-12 through ED-23 and ED-25 through ED-32. It is RECOMMENDED that all operating systems provide such an API.
ED-24：緊急コールの場所を必要とするアプリケーションプログラムをサポートするオペレーティングシステムが、クライアントアプリケーションがDHCPロケーションオプションやタイプに固有のその他のロケーションテクノロジーを使用するために必要なレイヤー2およびレイヤー3機能へのアクセスを許可しない場合アクセスネットワークの場合、オペレーティングシステムは、ED-12からED-23およびED-25からED-32に準拠した公開APIを提供する必要があります。すべてのオペレーティングシステムがこのようなAPIを提供することをお勧めします。
If an endpoint is manually configured, the requirements in this section are not applicable.
エンドポイントが手動で構成されている場合、このセクションの要件は適用されません。
ED-25/INT-19: Endpoints SHOULD obtain location immediately after obtaining local network configuration information.
ED-25 / INT-19：ローカルネットワーク構成情報を取得した直後に、エンドポイントは場所を取得する必要があります（SHOULD）。
ED-26/INT-20: If the device is configured to use DHCP for bootstrapping and does not use its own measurement to determine location, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively.
ED-26 / INT-20：デバイスがブートストラップにDHCPを使用するように構成されており、独自の測定値を使用して位置を特定しない場合、位置取得の両方のオプション（市民および測地）、LIS検出のオプション、および[RFC4776]、[RFC6225]、[RFC5986]、および[RFC5223]でそれぞれ定義されているLoST検出のオプション。
ED-27/INT-21: If the device sends a DHCPINFORM message, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively.
ED-27 / INT-21：デバイスがDHCPINFORMメッセージを送信する場合、[RFC4776]、[ RFC6225]、[RFC5986]、および[RFC5223]、それぞれ。
ED-28/INT-22: To minimize the effects of VPNs that do not allow packets to be sent via the native hardware interface rather than via the VPN tunnel, location configuration SHOULD be attempted before such tunnels are established.
ED-28 / INT-22：パケットがVPNトンネル経由ではなくネイティブハードウェアインターフェイス経由で送信されることを許可しないVPNの影響を最小限に抑えるために、そのようなトンネルが確立される前にロケーション構成を試行する必要があります。
ED-29/INT-23: Software that uses LCPs SHOULD locate and use the actual hardware network interface rather than a VPN tunnel interface to direct LCP requests to the LIS in the actual access network.
ED-29 / INT-23：LCPを使用するソフトウェアは、VPNトンネルインターフェイスではなく実際のハードウェアネットワークインターフェイスを見つけて使用し、実際のアクセスネットワークのLISにLCP要求を送信する必要があります。
AN-16: Network administrators MUST take care in assigning IP addresses such that VPN address assignments can be distinguished from local devices (by subnet choice, for example), and LISs SHOULD NOT attempt to provide location to addresses that arrive via VPN connections unless they can accurately determine the location for such addresses.
AN-16：ネットワーク管理者は、IPアドレスの割り当てに注意する必要があります。これにより、VPNアドレスの割り当てをローカルデバイスと（サブネットの選択などによって）区別できるようになり、LISは、VPN接続経由で到着するアドレスに場所を提供しないでください。このような住所の場所を正確に特定できます。
AN-17: Placement of NAT devices where an LCP uses an IP address for an identifier SHOULD consider the effect of the NAT on the LCP. The address used to query the LIS MUST be able to correctly identify the record in the LIS representing the location of the querying device.
AN-17：LCPが識別子にIPアドレスを使用するNATデバイスの配置は、LCPに対するNATの影響を考慮する必要があります。 LISの照会に使用されるアドレスは、照会するデバイスの場所を表すLIS内のレコードを正しく識別できなければなりません（MUST）。
ED-30/INT-24: For devices that are not expected to change location, refreshing location on the order of once per day is RECOMMENDED.
ED-30 / INT-24：場所の変更が予期されていないデバイスの場合、1日1回程度の場所の更新が推奨されます。
ED-31/INT-25: For devices that roam, refresh of location information SHOULD be more frequent, with the frequency related to the mobility of the device and the ability of the access network to support the refresh operation. If the device detects a link state change that might indicate having moved, for example, when it changes access points, the device SHOULD refresh its location.
ED-31 / INT-25：ローミングするデバイスの場合、位置情報の更新はより頻繁に行う必要があり、頻度はデバイスのモビリティと更新操作をサポートするアクセスネットワークの能力に関連しています。デバイスがアクセスポイントを変更するときなど、移動したことを示すリンク状態の変化を検出した場合、デバイスはその場所を更新する必要があります（SHOULD）。
ED-32/INT-26/AN-18: It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location, and systems SHOULD be designed such that the typical response time is under 100 ms. However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can be substantially improved over what can be obtained in 250 ms.
ED-32 / INT-26 / AN-18：ルーティングの場所を取得するために場所の決定に250ミリ秒以上かかることはお勧めできません。また、システムは通常の応答時間が100ミリ秒未満になるように設計する必要があります。ただし、位置精度を250ミリ秒で取得できる精度よりも大幅に改善できる場合は、ルーティング位置を取得するのに3秒も許容される場合があります。
ED-33/SP-15: Location sent between SIP entities MUST be conveyed using the extension described in [RFC6442].
ED-33 / SP-15：SIPエンティティ間で送信される場所は、[RFC6442]で説明されている拡張機能を使用して伝達する必要があります。
ED-34/AN-19: Where the absolute location or the accuracy of location of the endpoint may change between the time the call is received at the PSAP and the time dispatch is completed, location update mechanisms MUST be implemented and used.
ED-34 / AN-19：コールがPSAPで受信されてからディスパッチが完了するまでの間にエンドポイントの絶対位置または位置の精度が変化する可能性がある場合、位置更新メカニズムを実装して使用する必要があります。
ED-35/AN-20: Mobile devices MUST be provided with a mechanism to get repeated location updates to track the motion of the device during the complete processing of the call.
ED-35 / AN-20：モバイルデバイスには、コールの完全な処理中にデバイスの動きを追跡するために繰り返し位置更新を取得するメカニズムが提供されている必要があります。
ED-36/AN-21: The LIS SHOULD provide a location reference that permits a subscription with appropriate filtering.
ED-36 / AN-21：LISは、適切なフィルタリングを使用したサブスクリプションを許可するロケーション参照を提供する必要があります（SHOULD）。
ED-37/AN-22: For calls sent with location-by-reference, with a SIP or Session Initiation Protocol Secure (SIPS) scheme, the server resolving the reference MUST support a SUBSCRIBE [RFC6665] to the presence event [RFC3856]. For other location-by-reference schemes that do not support subscription, the PSAP will have to repeatedly dereference the URI to determine if the device moved.
ED-37 / AN-22：参照によるロケーション、SIPまたはセッション開始プロトコルセキュア（SIPS）スキームで送信されたコールの場合、参照を解決するサーバーは、プレゼンスイベント[RFC3856]へのサブスクライブ[RFC6665]をサポートする必要があります。サブスクリプションをサポートしていない他のロケーションバイリファレンス方式の場合、PSAPは、デバイスが移動したかどうかを判断するために、URIを繰り返し逆参照する必要があります。
ED-38: If location was sent by value and the endpoint gets an updated location, it MUST send the updated location to the PSAP via a SIP re-INVITE or UPDATE request. Such updates SHOULD be limited to no more than one update every 10 seconds, a value selected to keep the load on a large PSAP manageable, and yet provide sufficient indication to the PSAP of motion.
ED-38：ロケーションが値によって送信され、エンドポイントが更新されたロケーションを取得した場合、SIP re-INVITEまたはUPDATE要求を介してPSAPに更新されたロケーションを送信する必要があります。このような更新は、10秒ごとに1回の更新に制限する必要があります。この値は、大きなPSAPの負荷を管理可能に保ち、PSAPの動きを十分に示すために選択された値です。
ED-39/SP-16: If the LIS has more than one location for an endpoint, it MUST conform to the rules in Section 3 of [RFC5491].
ED-39 / SP-16：LISにエンドポイントの場所が複数ある場合は、[RFC5491]のセクション3のルールに準拠する必要があります。
ED-40: If an endpoint has more than one location available to it, it MUST choose one location to route the call towards the PSAP. If multiple locations are in a single Presence Information Data Format (PIDF), the procedures in [RFC5491] MUST be followed. If the endpoint has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.
ED-40：エンドポイントで使用可能なロケーションが複数ある場合、1つのロケーションを選択して、コールをPSAPにルーティングする必要があります。複数の場所が単一の存在情報データ形式（PIDF）にある場合、[RFC5491]の手順に従う必要があります。エンドポイントに複数のPIDFがあり、それらの中から選択するための合理的な根拠がない場合、ランダムな選択が許容されます。
SP-17: If a proxy inserts location on behalf of an endpoint and it has multiple locations available for the endpoint, it MUST choose one location to use to route the call towards the PSAP. If multiple locations are in a single PIDF, the procedures in [RFC5491] MUST be followed. If the proxy has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable.
SP-17：プロキシがエンドポイントに代わって場所を挿入し、エンドポイントに利用可能な複数の場所がある場合、PSAPに向けて通話をルーティングするために使用する場所を1つ選択する必要があります。 1つのPIDFに複数の場所がある場合、[RFC5491]の手順に従う必要があります。プロキシに複数のPIDFがあり、その中から選択する合理的な根拠がない場合は、ランダムに選択できます。
SP-18: If a proxy is attempting to insert location but the endpoint conveyed a location to it, the proxy MUST use the endpoint's location for routing in the initial INVITE and MUST convey that location towards the PSAP. It MAY also include what it believes the location to be in a separate Geolocation header.
SP-18：プロキシが場所を挿入しようとしているが、エンドポイントがそこに場所を伝えた場合、プロキシは最初のINVITEでのルーティングにエンドポイントの場所を使用しなければならず、その場所をPSAPに伝えなければなりません。また、その場所が別のGeolocationヘッダーにあると考えるものも含まれる場合があります。
SP-19: All location objects received by a proxy MUST be delivered to the PSAP.
SP-19：プロキシによって受信されたすべてのロケーションオブジェクトは、PSAPに配信される必要があります。
ED-41/SP-20: Location objects MUST be created with information about the method by which the location was determined, such as GPS, manually entered, or based on access network topology included in a PIDF-LO "method" element. In addition, the source of the location information MUST be included in a PIDF-LO "provided-by" element.
ED-41 / SP-20：GPSなどの場所が決定された方法に関する情報を使用して、または手動で入力された、またはPIDF-LOの「メソッド」要素に含まれるアクセスネットワークトポロジに基づいて、場所オブジェクトを作成する必要があります。さらに、位置情報のソースは、PIDF-LOの「provided-by」要素に含まれている必要があります。
ED-42/SP-21: A location with a method of "derived" MUST NOT be used unless no other location is available.
ED-42 / SP-21：他の場所が利用できない場合を除いて、「派生」のメソッドを持つ場所は使用してはなりません。
AN-23: A LIS SHOULD perform location validation of civic locations via LoST before entering a location in its database.
AN-23：LISは、データベースに場所を入力する前に、LoSTを介して市民の場所の場所の検証を実行する必要があります（SHOULD）。
ED-43: Endpoints SHOULD validate civic locations when they receive them from their LCP. Validation SHOULD be performed in conjunction with the LoST route query to minimize load on the LoST server.
ED-43：エンドポイントは、LCPからそれらを受け取ったときに、市民の場所を検証する必要があります。検証は、LoSTサーバーへの負荷を最小限に抑えるために、LoSTルートクエリと組み合わせて実行する必要があります（SHOULD）。
AN-24: When the access network cannot determine the actual location of the caller, it MUST supply a default location. The default SHOULD be chosen to be as close to the probable location of the device as the network can determine. See [RFC6443].
AN-24：アクセスネットワークが発信者の実際の場所を特定できない場合、デフォルトの場所を提供する必要があります。デフォルトのSHOULDは、ネットワークが決定できる限り、デバイスの推定位置にできるだけ近くなるように選択する必要があります。 [RFC6443]を参照してください。
SP-22: Proxies handling emergency calls MUST insert a default location in the INVITE if the incoming INVITE does not contain a location and the proxy does not have a method for obtaining a better location.
SP-22：着信INVITEに場所が含まれておらず、プロキシに適切な場所を取得する方法がない場合、緊急呼び出しを処理するプロキシは、INVITEにデフォルトの場所を挿入する必要があります。
AN-25/SP-23: Default locations MUST be marked with method=Default, and the proxy MUST be identified in a PIDF-LO "provided-by" element.
AN-25 / SP-23：デフォルトの場所はmethod = Defaultでマークする必要があり、プロキシはPIDF-LOの "provided-by"要素で識別される必要があります。
ED-44: If the LCP does not return location in the form of a PIDF-LO [RFC4119], the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO.
ED-44：LCPがPIDF-LO [RFC4119]の形式で位置を返さない場合、エンドポイントは、構成プロトコルから受信した位置情報をPIDF-LOにマップする必要があります。
ED-45/AN-26: To prevent against spoofing of the DHCP server, entities implementing DHCP for location configuration SHOULD use DHCPv4 message authentication [RFC3118] or DHCPv6 message authentication [RFC3315], although the difficulty in providing appropriate credentials is significant.
ED-45 / AN-26：DHCPサーバーのなりすましを防ぐために、ロケーション構成にDHCPを実装するエンティティは、DHCPv4メッセージ認証[RFC3118]またはDHCPv6メッセージ認証[RFC3315]を使用する必要があります（SHOULD）。
ED-46: If S/MIME [RFC5751] is used, the INVITE message MUST provide enough information unencrypted for intermediate proxies to route the call based on the location information included. This would include the Geolocation header and any bodies containing location information. Use of S/MIME with emergency calls is NOT RECOMMENDED for this reason.
ED-46：S / MIME [RFC5751]を使用する場合、INVITEメッセージは、含まれる位置情報に基づいて中間プロキシが通話をルーティングするために、暗号化されていない十分な情報を提供する必要があります。これには、Geolocationヘッダーと位置情報を含むボディが含まれます。このため、緊急通話でS / MIMEを使用することはお勧めしません。
ED-47/SP-24: Transport Layer Security (TLS) [RFC5746] MUST be used to protect location (but see Section 9.1). All SIP implementations of this specification MUST support TLS.
ED-47 / SP-24：トランスポート層セキュリティ（TLS）[RFC5746]を使用して場所を保護する必要があります（ただし、セクション9.1を参照）。この仕様のすべてのSIP実装はTLSをサポートする必要があります。
ED-48: Endpoints MUST support one or more mechanisms that allow them to determine their public IP address, for example, Session Traversal Utilities for NAT (STUN) [RFC5389].
ED-48：エンドポイントは、NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]など、パブリックIPアドレスを決定できる1つ以上のメカニズムをサポートする必要があります。
ED-49: Endpoints MUST support LIS discovery as described in [RFC5986] and LoST discovery as described in [RFC5223].
ED-49：エンドポイントは、[RFC5986]で説明されているLIS検出と、[RFC5223]で説明されているLoST検出をサポートする必要があります。
ED-50: The device MUST have a configurable default LoST server parameter.
ED-50：デバイスには、構成可能なデフォルトのLoSTサーバーパラメーターが必要です。
ED-51: DHCP LoST discovery MUST be used, if available, in preference to configured LoST servers. That is, the endpoint MUST send queries to this LoST server first, using other LoST servers only if these queries fail.
ED-51：DHCP LoSTディスカバリは、構成されたLoSTサーバーよりも、可能であれば使用する必要があります。つまり、エンドポイントは、最初にこのLoSTサーバーにクエリを送信し、これらのクエリが失敗した場合にのみ他のLoSTサーバーを使用する必要があります。
AN-27: Access networks that support DHCP MUST implement the LIS and LoST discovery options in their DHCP servers and return suitable server addresses as appropriate.
AN-27：DHCPをサポートするアクセスネットワークは、DHCPサーバーにLISおよびLoST検出オプションを実装し、必要に応じて適切なサーバーアドレスを返す必要があります。
ED-52: Endpoints that obtain their own location SHOULD perform LoST mapping to the PSAP URI.
ED-52：独自の場所を取得するエンドポイントは、PSAP URIへのLoSTマッピングを実行する必要があります（SHOULD）。
ED-53: Mapping SHOULD be performed at boot time and whenever a location changes beyond the service boundary obtained from a prior LoST mapping operation, or when the time-to-live value of that response has expired. The value MUST be cached for possible later use.
ED-53：マッピングは、ブート時、および場所が以前のLoSTマッピング操作から取得したサービス境界を超えて変更されるとき、またはその応答の存続時間の値が期限切れになったときに実行する必要があります（SHOULD）。後で使用できるように、値をキャッシュする必要があります。
ED-54: The endpoint MUST attempt to update its location at the time of an emergency call. If it cannot obtain a new location quickly (see Section 6), it MUST use the cached value.
ED-54：エンドポイントは、緊急通話時にその場所を更新する必要があります。新しい場所をすばやく取得できない場合（セクション6を参照）、キャッシュされた値を使用する必要があります。
ED-55: The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call. If it cannot obtain a new mapping quickly, it MUST use the cached value. If the device cannot update the LoST mapping and does not have a cached value, it MUST signal an emergency call without a Route header containing a PSAP URI.
ED-55：エンドポイントは、緊急通話時にLoSTマッピングを更新しようとする必要があります（SHOULD）。新しいマッピングをすばやく取得できない場合は、キャッシュされた値を使用する必要があります。デバイスがLoSTマッピングを更新できず、キャッシュされた値がない場合、PSAP URIを含むルートヘッダーなしで緊急コールを通知する必要があります。
SP-25: Networks MUST be designed so that at least one proxy in the outbound path will recognize emergency calls with a Request URI of the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate that the endpoint understood the call was an emergency call. A proxy that processes such a call looks for the presence of a SIP Route header field with a URI of a PSAP. The absence of such a Route header indicates that the endpoint was unable to invoke LoST, and the proxy MUST perform the LoST mapping and insert a Route header field with the URI obtained.
SP-25：アウトバウンドパスの少なくとも1つのプロキシが「sos」ツリー内のサービスURNのリクエストURIを使用して緊急コールを認識するようにネットワークを設計する必要があります。エンドポイントは、サービスURIを要求URIに配置して、エンドポイントが緊急コールであることをエンドポイントが理解したことを示します。このようなコールを処理するプロキシは、PSAPのURIを持つSIPルートヘッダーフィールドの存在を探します。そのようなルートヘッダーがない場合、エンドポイントはLoSTを呼び出せなかったことを示し、プロキシはLoSTマッピングを実行し、取得したURIを使用してルートヘッダーフィールドを挿入する必要があります。
SP-26: To deal with old user agents that predate this specification and with endpoints that do not have access to their own location data, a proxy that recognizes a call as an emergency call that is not marked as such (see Section 5) MUST also perform this mapping, with the best location it has available for the endpoint. The resulting PSAP URI would be placed in a Route header with the service URN in the Request URI.
SP-26：この仕様より前の古いユーザーエージェントと、独自の位置データにアクセスできないエンドポイントを処理するには、そのようにマークされていない緊急コールとしてコールを認識するプロキシ（セクション5を参照）また、エンドポイントで使用できる最適な場所を使用して、このマッピングを実行します。結果のPSAP URIは、リクエストURIのサービスURNとともにルートヘッダーに配置されます。
SP-27: Proxy servers performing mapping SHOULD use location obtained from the access network for the mapping. If no location is available, a default location (see Section 6.11) MUST be supplied.
SP-27：マッピングを実行するプロキシサーバーは、アクセスネットワークから取得した場所をマッピングに使用する必要があります（SHOULD）。使用できる場所がない場合は、デフォルトの場所（6.11を参照）を指定する必要があります。
SP-28: A proxy server that attempts mapping and fails to get a mapping MUST provide a default mapping. A suitable default mapping would be the mapping obtained previously for the default location appropriate for the caller.
SP-28：マッピングを試み、マッピングの取得に失敗したプロキシサーバーは、デフォルトのマッピングを提供する必要があります。適切なデフォルトのマッピングは、呼び出し元に適したデフォルトの場所に対して以前に取得されたマッピングです。
ED-56/SP-29: [RFC3261] and [RFC3263] procedures MUST be used to route an emergency call towards the PSAP's URI.
ED-56 / SP-29：[RFC3261]および[RFC3263]手順を使用して、緊急コールをPSAPのURIにルーティングする必要があります。
ED-57/SP-30: TLS is the primary mechanism used to secure the signaling for emergency calls. IPsec [RFC4301] MAY be used instead of TLS for any hop. Either TLS or IPsec MUST be used when attempting to signal an emergency call.
ED-57 / SP-30：TLSは、緊急コールのシグナリングを保護するために使用される主要なメカニズムです。 IPsec [RFC4301]は、ホップのTLSの代わりに使用できます。緊急コールを発信する場合は、TLSまたはIPsecのいずれかを使用する必要があります。
ED-58/SP-31: If TLS session establishment is not available or fails, the call MUST be retried without TLS.
ED-58 / SP-31：TLSセッションの確立が利用できないか失敗した場合、TLSなしでコールを再試行する必要があります。
ED-59/SP-32: Following the procedures described in [RFC5626] is RECOMMENDED to maintain persistent TLS connections between entities when one of the entities is an endpoint. Persistent TLS connection between proxies is RECOMMENDED using any suitable mechanism.
ED-59 / SP-32：エンティティの1つがエンドポイントである場合、[RFC5626]で説明されている手順に従って、エンティティ間の永続的なTLS接続を維持することをお勧めします。プロキシ間の永続的なTLS接続は、適切なメカニズムを使用することをお勧めします。
ED-60/AN-28: TLS SHOULD be used when attempting to retrieve location (configuration or dereferencing) with HELD. The use of the mechanism described in [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. IPsec MAY be used instead of TLS.
ED-60 / AN-28：HELDを使用して場所（構成または逆参照）を取得する場合は、TLSを使用する必要があります（SHOULD）。 [RFC5077]で説明されているメカニズムの使用は、サーバー側の状態を維持せずにTLSセッションを確立する時間を最小限に抑えるために推奨されています。 TLSの代わりにIPsecを使用できます。
ED-61/AN-29: When TLS session establishment fails, the location retrieval MUST be retried without TLS.
ED-61 / AN-29：TLSセッションの確立が失敗した場合、TLSを使用せずに場所の取得を再試行する必要があります。
ED-62: The initial SIP signaling method is an INVITE request:
ED-62：最初のSIPシグナリング方式はINVITEリクエストです。
1. The Request URI SHOULD be the service URN in the "sos" tree. If the device does not interpret local dial strings, the Request-URI MUST be a dial string URI [RFC4967] with the dialed digits.
1. リクエストURIは、「sos」ツリーのサービスURNである必要があります。デバイスがローカルダイヤル文字列を解釈しない場合、Request-URIは、ダイヤルされた数字を含むダイヤル文字列URI [RFC4967]である必要があります。
2. The To header field SHOULD be a service URN in the "sos" tree. If the device does not interpret local dial strings, the To: MUST be a dial string URI with the dialed digits.
2. Toヘッダーフィールドは、「sos」ツリーのサービスURNである必要があります。デバイスがローカルダイヤル文字列を解釈しない場合、To：はダイヤルされた数字を含むダイヤル文字列URIである必要があります。
3. The From header field SHOULD contain the address of record (AoR) of the caller.
3. Fromヘッダーフィールドには、発信者のレコードのアドレス（AoR）を含める必要があります（SHOULD）。
4. A Route header field SHOULD be present with a PSAP URI obtained from LoST (see Section 8). If the device does not interpret dial plans or was unable to obtain a route from a LoST server, no such Route header field will be present.
4. ルートヘッダーフィールドは、LoSTから取得したPSAP URIとともに存在する必要があります（セクション8を参照）。デバイスがダイヤルプランを解釈しないか、LoSTサーバーからルートを取得できなかった場合、そのようなルートヘッダーフィールドは存在しません。
5. A Contact header field MUST be globally routable, for example, a Globally Routable User Agent URI (GRUU) [RFC5627], and be valid for several minutes following the termination of the call, provided that the User Agent Client (UAC) remains registered with the same registrar, to permit an immediate callback to the specific device that placed the emergency call. It is acceptable if the UAC inserts a locally routable URI and a subsequent back-to-back user agent (B2BUA) maps that to a globally routable URI.
5. 連絡先ヘッダーフィールドは、グローバルにルーティング可能でなければなりません。たとえば、グローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]であり、ユーザーエージェントクライアント（UAC）が登録されたままであれば、通話終了後数分間有効である必要があります。同じレジストラ。緊急電話をかけた特定のデバイスへの即時コールバックを許可します。 UACがローカルにルーティング可能なURIを挿入し、後続のバックツーバックユーザーエージェント（B2BUA）がそれをグローバルにルーティング可能なURIにマップする場合は許容されます。
6. Other header fields MAY be included as per normal SIP behavior.
6. その他のヘッダーフィールドは、通常のSIP動作に従って含まれる場合があります。
7. If a geolocation URI is included in the INVITE, a Supported header field MUST be included with a 'geolocation-sip' or 'geolocation-http" option tag, as appropriate [RFC6442].
7. 地理位置情報URIがINVITEに含まれている場合、サポートされるヘッダーフィールドは、必要に応じて「geolocation-sip」または「geolocation-http」オプションタグに含まれている必要があります[RFC6442]。
8. If a device understands the SIP location conveyance [RFC6442] extension and has its location available, it MUST include location as either location-by-value or location-by-reference, or both, according to the rules within RFC 6442.
8. デバイスがSIPロケーション伝達[RFC6442]拡張機能を理解し、そのロケーションを利用できる場合、RFC 6442内のルールに従って、ロケーションを値によるロケーションまたは参照によるロケーション、あるいはその両方として含める必要があります。
9. An SDP offer SHOULD be included in the INVITE. If voice is supported, the offer SHOULD include the G.711 codec; see Section 14. As PSAPs may support a wide range of media types and codecs, sending an offerless INVITE may result in a lengthy return offer but is permitted. Cautions in [RFC3261] on offerless INVITEs should be considered before such use.
9. SDPオファーはINVITEに含める必要があります。音声がサポートされている場合、オファーにはG.711コーデックを含める必要があります。セクション14を参照してください。PSAPは幅広いメディアタイプとコーデックをサポートしている可能性があるため、オファーのないINVITEを送信すると、長期のリターンオファーが発生する可能性がありますが、許可されます。 [RFC3261]で提供されていないINVITEに関する注意は、そのような使用の前に考慮する必要があります。
10. If the device includes location-by-value, the user agent (UA) MUST support multipart message bodies, since SDP will likely be also in the INVITE.
10. デバイスにlocation-by-valueが含まれている場合、ユーザーエージェント（UA）はマルチパートメッセージ本文をサポートする必要があります。これは、SDPもINVITEに含まれる可能性が高いためです。
SP-33: SIP proxy servers processing emergency calls:
SP-33：緊急通話を処理するSIPプロキシサーバー：
1. If the proxy interprets dial plans on behalf of user agents, the proxy MUST look for the local emergency dial string at the location of the end device and MAY look for the home dial string. If it finds it, the proxy MUST:
1. プロキシがユーザーエージェントに代わってダイヤルプランを解釈する場合、プロキシはエンドデバイスの場所でローカルの緊急ダイヤル文字列を探す必要があり、ホームダイヤル文字列を探す必要があります。見つかった場合、プロキシは次の処理を実行する必要があります。
* Insert a Geolocation header field. Location-by-reference MUST be used because proxies are not allowed to insert bodies.
* Geolocationヘッダーフィールドを挿入します。プロキシはボディの挿入を許可されていないため、location-by-referenceを使用する必要があります。
* Insert the Geolocation-Routing header with appropriate parameters.
* 適切なパラメーターを使用してGeolocation-Routingヘッダーを挿入します。
* Map the location to a PSAP URI using LoST.
* LoSTを使用して場所をPSAP URIにマッピングします。
* Add a Route header with the PSAP URI.
* PSAP URIを使用してルートヘッダーを追加します。
* Replace the Request-URI, which was the dial string, with the service URN appropriate for the emergency dial string.
* ダイヤル文字列であるRequest-URIを、緊急ダイヤル文字列に適したサービスURNに置き換えます。
* Route the call using normal SIP routing mechanisms.
* 通常のSIPルーティングメカニズムを使用してコールをルーティングします。
2. If the proxy recognizes the service URN in the Request URI and does not find a Route header, it MUST query a LoST server immediately. If a location was provided (which should be the case), the proxy uses that location to query LoST. The proxy may have to dereference a location-by-reference to get a value. If a location is not present and the proxy can query a LIS that has the location of the UA, it MUST do so. If no location is present and the proxy does not have access to a LIS that could provide location, the proxy MUST supply a default location (see Section 6.11). The location (in the signaling, obtained from a LIS, or default) MUST be used in a query to LoST with the service URN received with the call. The resulting URI MUST be placed in a Route header added to the call.
2. プロキシがリクエストURIでサービスURNを認識し、ルートヘッダーが見つからない場合は、LoSTサーバーにすぐにクエリを実行する必要があります。ロケーションが提供された場合（そうである必要があります）、プロキシはそのロケーションを使用してLoSTをクエリします。プロキシは、値を取得するために参照による位置を逆参照する必要がある場合があります。場所が存在せず、プロキシがUAの場所を持つLISをクエリできる場合は、それを行う必要があります。場所が存在せず、プロキシが場所を提供できるLISにアクセスできない場合、プロキシはデフォルトの場所を提供する必要があります（セクション6.11を参照）。 （シグナリングで、LISから取得した、またはデフォルトで）ロケーションは、コールで受信したサービスURNを使用したLoSTへのクエリで使用する必要があります。結果のURIは、呼び出しに追加されるルートヘッダーに配置する必要があります。
3. The proxy MAY add a Geolocation header field. Such an additional location SHOULD NOT be used for routing; the location provided by the UA should be used.
3. プロキシはGeolocationヘッダーフィールドを追加してもよい（MAY）。そのような追加の場所はルーティングに使用すべきではありません。 UAが提供する場所を使用する必要があります。
4. Either a P-Asserted-Identity [RFC3325] or an Identity header field [RFC4474], or both, SHOULD be included to identify the sender. For services that must support emergency calls from unauthenticated devices, valid identity may not be available. Proxies encountering a P-Asserted-Identity will need to pass the header to the PSAP, which is in a different domain. [RFC3325] requires a "spec(T)" to determine what happens if either the "id" privacy service or a Privacy header is present and requests privacy. In the absence of another spec(T), such proxies should pass the header unmodified if and only if the connection between the proxy and the PSAP is, as far as the proxy can determine, protected by TLS with mutual authentication using keys reliably known by the parties, encrypted with no less strength than AES, and the local regulations governing the PSAP do not specify otherwise.
4. P-Asserted-Identity [RFC3325]またはIdentityヘッダーフィールド[RFC4474]、あるいはその両方のいずれかを送信者を識別するために含める必要があります（SHOULD）。認証されていないデバイスからの緊急通話をサポートする必要があるサービスの場合、有効なIDを使用できない場合があります。 P-Asserted-Identityに遭遇したプロキシは、別のドメインにあるPSAPにヘッダーを渡す必要があります。 [RFC3325]「id」プライバシーサービスまたはプライバシーヘッダーのいずれかが存在し、プライバシーを要求した場合に何が起こるかを判断するには、「spec（T）」が必要です。別のspec（T）がない場合、プロキシとPSAPの間の接続が、プロキシが判断できる限り、TLSによって保護されている場合にのみ、そのようなプロキシはヘッダーを変更せずに渡す必要があります。 AESと同等以上の強度で暗号化された当事者、およびPSAPを管理する地域の規制は、他に規定していません。
5. Proxies SHOULD NOT return a 424 error. They should process the INVITE as best they can.
5. プロキシは424エラーを返さないでください。できる限りINVITEを処理する必要があります。
6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a missing value if they must query LoST to obtain a route. Emergency calls are always routed by location.
6. プロキシは、ルートを取得するためにLoSTをクエリする必要がある場合、「no」のGeolocation-Routing値または欠損値に従うべきではありません（SHOULD NOT）。緊急通話は常に場所によってルーティングされます。
ED-63/SP-34: Devices SHOULD have a globally routable URI in a Contact header field that remains valid for several minutes past the time the original call containing the URI completes, unless the device registration expires and is not renewed.
ED-63 / SP-34：デバイスは、Contactヘッダーフィールドにグローバルにルーティング可能なURIを持つ必要があります（SHOULD）。これは、デバイスの登録が期限切れで更新されない限り、URIを含む元のコールが完了した後も数分間有効です。
SP-35: Callbacks to the Contact header URI received within 30 minutes of an emergency call must reach the device regardless of call features (e.g., do not disturb) or services (e.g., call forwarding) that would normally cause the call to be routed to some other entity.
SP-35：緊急通話から30分以内に受信した連絡先ヘッダーURIへのコールバックは、通常は通話がルーティングされる原因となる通話機能（着信拒否など）やサービス（通話転送など）に関係なく、デバイスに到達する必要があります他のエンティティに。
SP-36: Devices MUST have a persistent AoR URI either in a P-Asserted-Identity header field or From protected by an Identity header field suitable for returning a call sometime after the original call. Such a callback would not necessarily reach the device that originally placed the call.
SP-36：デバイスは、P-Asserted-Identityヘッダーフィールドまたは元の呼び出しの後でいつか呼び出しを返すのに適したIdentityヘッダーフィールドで保護されたFromのいずれかに、永続的なAoR URIを持つ必要があります。そのようなコールバックは、必ずしも最初にコールを発信したデバイスに到達するとは限りません。
ED-64/SP-37: During the course of an emergency call, PSAPs and responders may need to transfer the call to some other entity. The request for such a transfer is signaled by a REFER request within the dialog with method=INVITE and a Refer-To header field [RFC3515]. Devices MUST react to such a transfer request with the appropriate INVITE.
ED-64 / SP-37：緊急通話中に、PSAPと応答者は他のエンティティに通話を転送する必要がある場合があります。このような転送の要求は、method = INVITEとRefer-Toヘッダーフィールド[RFC3515]を使用して、ダイアログ内のREFER要求によって通知されます。デバイスは、適切なINVITEでこのような転送要求に反応する必要があります。
ED-65: Normal [RFC3261] procedures for termination MUST be used for termination of the call.
ED-65：通話の終了には、通常の[RFC3261]終了手順を使用する必要があります。
ED-66/SP-38: User agents and proxies MUST disable features that will interrupt an ongoing emergency call, such as:
ED-66 / SP-38：ユーザーエージェントとプロキシは、次のような進行中の緊急通話を中断する機能を無効にする必要があります。
o Call waiting
o キャッチホン
o Call transfer
o 通話転送
o Three-way call
o 三者通話
o Hold
o ホールド
o Outbound call blocking
o アウトバウンドコールブロッキング
when an emergency call is established, but see ED-65 with respect to call waiting. Also see ED-73 in Section 14.
緊急コールが確立されているが、キャッチホンについてはED-65を参照してください。セクション14のED-73も参照してください。
ED-67/SP-39: The emergency dial strings SHOULD NOT be permitted in call forward numbers or speed dial lists.
ED-67 / SP-39：緊急ダイヤル文字列は、自動転送番号または短縮ダイヤルリストでは許可されていません。
ED-68/SP-40: The user agent and proxies MUST disable call features that would interfere with the ability of callbacks from the PSAP to be completed, such as:
ED-68 / SP-40：ユーザーエージェントとプロキシは、次のようなPSAPからのコールバックの機能を妨げる呼び出し機能を無効にする必要があります。
o Do not disturb
o 邪魔しないでください
o Call forward (all kinds)
o 転送（すべての種類）
These features SHOULD be disabled for approximately 30 minutes following termination of an emergency call.
これらの機能は、緊急コールの終了後約30分間無効にする必要があります。
ED-69: Callbacks SHOULD be determined by retaining the domain of the PSAP that answers an outgoing emergency call and instantiating a timer that starts when the call is terminated. If a call is received from the same domain and within the timer period, and it is sent to the URI in a Contact header or the AoR used in the emergency call, then it should be assumed to be a callback. The suggested timer period is 5 minutes. The mechanism described in [RFC4916] can be used by the PSAP to inform the endpoint of the PSAP's domain. Recognizing a callback from the domain of the PSAP will not always work, and further standardization will be required to give the endpoint the ability to recognize a callback.
ED-69：緊急コールの発信に応答するPSAPのドメインを保持し、コールが終了したときに開始するタイマーをインスタンス化することにより、コールバックを決定する必要があります（SHOULD）。コールが同じドメインからタイマー期間内に受信され、ContactヘッダーのURIまたは緊急コールで使用されるAoRに送信される場合、コールバックであると見なされます。推奨されるタイマー期間は5分です。 [RFC4916]で説明されているメカニズムは、PSAPがエンドポイントにPSAPのドメインを通知するために使用できます。 PSAPのドメインからのコールバックの認識は常に機能するとは限りません。エンドポイントにコールバックを認識できるようにするには、さらに標準化が必要になります。
ED-70: Endpoints MUST send and receive media streams on RTP [RFC3550].
ED-70：エンドポイントはRTP [RFC3550]でメディアストリームを送受信する必要があります。
ED-71: Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used.
ED-71：通常のSIPオファー/アンサー[RFC3264]ネゴシエーションを使用して、使用するメディアストリームについて合意する必要があります。
ED-72/SP-41: G.711 A-law (and mu-law if they are intended to be used in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711, a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and Adaptive Multi-Rate - WideBand (AMR-WB) in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding.
ED-72 / SP-41：[RFC3551]で説明されているように、G.711 A-law（および北米での使用が意図されている場合はmu-law）でエンコードされた音声をサポートする必要があります。エンドポイントがG.711をサポートできない場合、PSAPで受信したオファーにG.711が含まれるようにトランスコーダーを使用する必要があります。オファーには、G.722やAdaptive Multi-Rate-WideBand（AMR-WB）などのワイドバンドコーデックを含めることが望ましいです。 PSAPは、トランスコーディングを回避するために、そのエリアのエンドポイントで一般的な狭帯域コーデックをサポートする必要があります（SHOULD）。
ED-73: Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call.
ED-73：無音抑止（音声アクティビティ検出メソッド）を緊急通話に使用してはなりません（MUST NOT）。 PSAPコールテイカーは、バックグラウンドで何が起こっているかに関する情報を取得して、コールの処理方法を決定することがあります。
ED-74: Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975].
ED-74：インスタントメッセージング（IM）をサポートするエンドポイントは、[RFC3428]または[RFC4975]のいずれかをサポートする必要があります。
ED-75: Endpoints supporting real-time text MUST comply with [RFC4103]. The expectations for emergency service support for the real-time text medium are described in [RFC5194] Section 7.1.
ED-75：リアルタイムテキストをサポートするエンドポイントは[RFC4103]に準拠する必要があります。リアルタイムテキストメディアの緊急サービスサポートへの期待は、[RFC5194]セクション7.1で説明されています。
ED-76: Endpoints supporting video MUST support H.264 per [RFC6184].
ED-76：ビデオをサポートするエンドポイントは、[RFC6184]に従ってH.264をサポートする必要があります。
ED-77: INVITE requests to a service URN starting with "test." indicate a request for an automated test, for example, "urn:service:test.sos.fire". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (not found) that it was not. A 486 (busy here) MUST be returned if the test service is busy, and a 404 (not found) MUST be returned if the PSAP does not support the test mechanism.
ED-77：「test」で始まるサービスURNへのINVITEリクエスト。 「urn：service：test.sos.fire」のように、自動テストのリクエストを示します。標準のSIPと同様に、200（OK）応答はアドレスが認識されたことを示し、404（見つかりません）は認識されなかったことを示します。テストサービスがビジーの場合は486（ここでビジー）を返す必要があり、PSAPがテストメカニズムをサポートしていない場合は404（見つかりません）を返す必要があります。
ED-78: In its response to the test, the PSAP MAY include a text body (text/plain) indicating the identity of the PSAP, the requested service, and the location reported with the call. For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was location-by-reference. If the location-by-reference was supplied and the dereference requires credentials, the PSAP SHOULD use credentials supplied by the LIS for test purposes. This alerts the LIS that the dereference is not for an actual emergency call, and therefore location-hiding techniques, if they are being used, may be employed for this dereference. Use of SIPS for the request would assure that the response containing the location is kept private.
ED-78：テストへの応答では、PSAPはPSAPのID、要求されたサービス、および呼び出しで報告された場所を示すテキスト本文（text / plain）を含めることができます（MAY）。後者の場合、PSAP SHOULDは、テストで提供された元の場所が参照による場所であっても、値による場所を返す必要があります（SHOULD）。参照による場所が提供され、逆参照が資格情報を必要とする場合、PSAPは、テスト目的でLISによって提供される資格情報を使用する必要があります（SHOULD）。これは、逆参照が実際の緊急通話用ではないことをLISに警告します。したがって、位置非表示手法が使用されている場合は、この逆参照に使用できます。リクエストにSIPSを使用すると、ロケーションを含むレスポンスが確実に非公開になります。
ED-79: A PSAP accepting a test call SHOULD accept a media loopback [RFC6849] test and SHOULD support the "rtp-pkt-loopback" and "rtp-media-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User agents should expect the PSAP to loop back no more than 3 packets of each media type accepted (which limits the duration of the test), after which the PSAP would normally send BYE.
ED-79：テストコールを受け入れるPSAPは、メディアループバック[RFC6849]テストを受け入れる必要があり、「rtp-pkt-loopback」および「rtp-media-loopback」オプションをサポートする必要があります（SHOULD）。ユーザーエージェントは "loopback-source"のループバック属性を指定し、PSAPはミラーです。ユーザーエージェントは、PSAPが（テストの期間を制限する）受け入れられる各メディアタイプの最大3パケットをループバックすることを期待する必要があります。
ED-80: User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address not due to a reboot. After an initial test, a full test SHOULD be repeated approximately every 30 days with a random interval.
ED-80：ユーザーエージェントは、再起動によるものではない切断とその後のIPアドレスの変更後に、メディアループバックを含む完全な通話テストを実行する必要があります（SHOULD）。最初のテストの後、ランダムな間隔で約30日ごとにフルテストを繰り返す必要があります。
ED-81: User agents MUST NOT place a test call immediately after booting. If the IP address changes after booting, the endpoint should wait a random amount of time (in perhaps a 30-minute period, sufficient for any avalanche-restart event to complete) and then test.
ED-81：ユーザーエージェントは、起動直後にテストコールを発信してはなりません。起動後にIPアドレスが変更された場合、エンドポイントはランダムな時間（おそらく30分間で、雪崩の再起動イベントが完了するのに十分な時間）待ってからテストする必要があります。
ED-82: PSAPs MAY refuse repeated requests for test from the same device in a short period of time. Any refusal is signaled with a 486 (busy here) or 488 (not acceptable here) response.
ED-82：PSAPは、同じデバイスからの繰り返しのテスト要求を短時間で拒否する場合があります。拒否は、486（ここでビジー）または488（ここでは受け入れられません）の応答で通知されます。
Security considerations for emergency calling have been documented in [RFC5069] and [RFC6280]. This document suggests that security (TLS or IPsec) be used hop by hop on a SIP call to protect location information, identity, etc. It also suggests that if the attempt to create a security association fails the call be retried without the security. It's 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.
緊急通話のセキュリティに関する考慮事項は、[RFC5069]と[RFC6280]に文書化されています。このドキュメントでは、SIPコールでホップバイホップでセキュリティ（TLSまたはIPsec）を使用して、位置情報やIDなどを保護することを提案しています。また、セキュリティアソシエーションの作成に失敗した場合、セキュリティなしでコールを再試行することも提案しています。データを保護するよりも、緊急電話をかける方が重要です。実際、多くの管轄区域では、緊急電話をかけるときにプライバシーが明示的に免除されます。セキュリティなしで電話をかけると、場所などのユーザー情報が表示される場合があります。代替策-セキュリティが確立できない場合に呼び出しに失敗すること-は許容できないと見なされます。
This document registers service URNs in the Service URN Labels registry per [RFC5031] for testing.
このドキュメントでは、テスト用に[RFC5031]に従ってサービスURNをサービスURNラベルレジストリに登録します。
A new entry in the URN Service Label registry has been added. The new service is "test", the reference is this document, and the description is "self-test".
URNサービスラベルレジストリに新しいエントリが追加されました。新しいサービスは「テスト」、リファレンスはこのドキュメント、説明は「セルフテスト」です。
A new subregistry has been created: 'test' Sub-Services. The registration process is Expert Review per [RFC5226]. The expert review should consider that the entries in this registry nominally track the entries in the 'sos' subregistry, although it is not required that every entry in 'sos' have an entry in 'test', and it is possible that entries in the 'test' subregistry may not necessarily be in the 'sos' subregistry. For example, testing of non-emergency URNs may be allowed. The reference is this document. The initial content of the subregistry is:
新しいサブレジストリが作成されました：「test」サブサービス。登録プロセスは、[RFC5226]によるExpert Reviewです。専門家のレビューでは、このレジストリのエントリが名目上「sos」サブレジストリのエントリを追跡していることを考慮する必要がありますが、「sos」のすべてのエントリが「test」のエントリを持つ必要はなく、 「test」サブレジストリは、必ずしも「sos」サブレジストリにあるとは限りません。たとえば、緊急ではないURNのテストが許可される場合があります。参照はこのドキュメントです。サブレジストリの最初の内容は次のとおりです。
Service Reference Description
------------------------------------------------------------------
test.sos RFC 6881 test for sos
test.sos.ambulance RFC 6881 test for sos.ambulance
test.sos.animal-control RFC 6881 test for sos.animal-control
test.sos.fire RFC 6881 test for sos.fire
test.sos.gas RFC 6881 test for sos.gas
test.sos.marine RFC 6881 test for sos.marine
test.sos.mountain RFC 6881 test for sos.mountain
test.sos.physician RFC 6881 test for sos.physician
test.sos.poison RFC 6881 test for sos.poison
test.sos.police RFC 6881 test for sos.police
Working group members participating in the creation and review of this document include Hannes Tschofenig, Ted Hardie, Marc Linsner, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Barbara Stark, Richard Barnes, and Peter Blatherwick.
このドキュメントの作成とレビューに参加しているワーキンググループのメンバーには、Hannes Tschofenig、Ted Hardie、Marc Linsner、Roger Marshall、Stu Goldman、Shida Schubert、James Winterbottom、Barbara Stark、Richard Barnes、およびPeter Blatherwickが含まれます。
[LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006.
[LLDP-MED] ANSI / TIA、「Link Layer Discovery Protocol-Media Endpoint Discovery」、TIA標準、TIA-1057、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R。およびW. Arbaugh、「Authentication for DHCP Messages」、RFC 3118、2001年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージング用のセッション開始プロトコル（SIP）拡張機能」、RFC 3428、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、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月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、2004年12月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103] Hellstrom、G。、およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、2005年6月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Divamic Host Configuration Protocol（DHCPv4 and DHCPv6）Option for Civic Addresses Configuration Information」、RFC 4776、2006年11月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、J。、「Connected Identity in the Session Initiation Protocol（SIP）」、RFC 4916、2007年6月。
[RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007.
[RFC4967] Rosen、B。、「Session Initiation Protocol Uniform Resource Identifierのダイヤル文字列パラメータ」、RFC 4967、2007年7月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「メッセージセッションリレープロトコル（MSRP）」、RFC 4975、2007年9月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031] Schulzrinne、H.、「緊急およびその他の既知のサービスのためのUniform Resource Name（URN）」、RFC 5031、2008年1月。
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson、M。、およびJ. Winterbottom、「Presence Information Data Format Location Object（PIDF-LO）の改訂されたCivic Location Format」、RFC 5139、2008年2月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「LoST：A Location-to-Service Translation Protocol」、RFC 5222、2008年8月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「Discovering Location-to-Service Translation（LoST）Servers Using the Dynamic Host Configuration Protocol（DHCP）」、RFC 5223、2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Session Traversal Utilities for NAT（STUN）」、RFC 5389、2008年10月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、2009年10月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、2010年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月。
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6184] Wang、Y.、Even、R.、Kristensen、T。、およびR. Jesup、「RTP Payload Format for H.264 Video」、RFC 6184、2011年5月。
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6225] Polk、J.、Linsner、M.、Thomson、M。、およびB. Aboba、「Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information」、RFC 6225、2011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルのロケーション伝達」、RFC 6442、2011年12月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665] Roach、A。、「SIP固有のイベント通知」、RFC 6665、2012年7月。
[RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, February 2013.
[RFC6849] Kaplan、H。、編、Hedayat、K.、Venna、N.、Jones、P。、およびN. Stratton、「Session Description Protocol（SDP）およびReal-time Transport Protocol（RTPの拡張） ）for Media Loopback」、RFC 6849、2013年2月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年11月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069] Taylor、T.、Tschofenig、H.、Schulzrinne、H。、およびM. Shanmugam、「セキュリティの脅威と緊急通話のマーキングとマッピングの要件」、RFC 5069、2008年1月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月。
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)", RFC 5194, June 2008.
[RFC5194] van Wijk、A。およびG. Gybels、「Session Initiation Protocol（SIP）を使用したリアルタイムテキストオーバーIPのフレームワーク」、RFC 5194、2008年6月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011.
[RFC6443]ローゼン、B。、シュルズリン、H。、ポーク、J。、およびA.ニュートン、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、RFC 6443、2011年12月。
Authors' Addresses
著者のアドレス
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 USA
Ｂりあん ろせん ねうＳたｒ ４７０ こんらｄ Ｄｒ。 まｒｓ、 ぱ １６０４６ うさ
Phone: +1 724 382 1051
EMail: br@brianrosen.net
James Polk Cisco Systems 3913 Treemont Circle Colleyville, TX 76034 USA
James Polk Cisco Systems 3913 Treemont Circleコリービル、テキサス州76034米国
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com