[要約] RFC 8876は、非対話型の緊急通報に関する標準を定めたもので、緊急通報システムの改善を目的としています。このRFCは、緊急通報の信頼性と効率性を向上させるためのガイドラインを提供しています。
Internet Engineering Task Force (IETF) B. Rosen
Request for Comments: 8876
Category: Standards Track H. Schulzrinne
ISSN: 2070-1721 Columbia U.
H. Tschofenig
R. Gellens Core Technology Consulting September 2020
R. Gellens Core Technology Consulting 2020年9月
Non-interactive Emergency Calls
非対話型緊急電話
Abstract
概要
Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.
緊急呼び出しのためのインターネットの使用は、RFC 6443、「インターネットマルチメディアを使用した緊急呼び出しのためのフレームワーク」に記載されています。場合によっては、アプリケーションデータの送信が必要なのはすべて必要とされておらず、対話型メディアチャネルは確立されていません。音声やビデオやテキストなどのインタラクティブメディア。この文書では、共通の警告プロトコル（CAP）に基づくデータのコンテナを含むSIPメッセージトランザクションの使用方法について説明します。そのタイプの緊急要求はセッションを確立し、それをSIP INVITEと区別しています。対話型メディアチャネルなしで緊急サービスの要求を開始する必要があるデバイスは、このドキュメントのメカニズムを使用します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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 Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8876.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/frfc8876で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Architectural Overview
4. Protocol Specification
4.1. CAP Transport
4.2. Profiling of the CAP Document Content
4.3. Sending a Non-interactive Emergency Call
5. Error Handling
5.1. 425 (Bad Alert Message) Response Code
5.2. The AlertMsg-Error Header Field
6. Call Backs
7. Handling Large Amounts of Data
8. Example
9. Security Considerations
10. IANA Considerations
10.1. 'application/EmergencyCallData.cap+xml' Media Type
10.2. 'cap' Additional Data Block
10.3. 425 Response Code
10.4. AlertMsg-Error Header Field
10.5. SIP AlertMsg-Error Codes
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
[RFC6443] describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session.
[RFC6443]インターネットを使用して緊急電話をかける方法と、公共の安全留守ポイント（PSAP）はインターネットマルチメディア緊急呼び出しをネイティブに処理する方法を説明しています。緊急サービスのためのマルチメディアトラフィックの交換は、そのセッションのさまざまなパラメータをネゴシエートするSIP INVITEで始まるSIPセッション確立を含みます。
In some cases, however, there is only application data to be conveyed from the end devices to a PSAP or an intermediary. Examples of such environments include sensors issuing alerts, and certain types of medical monitors. These messages may be alerts to emergency authorities and do not require establishment of a session. These types of interactions are called 'non-interactive emergency calls'. In this document, we use the term "call" so that similarities between non-interactive alerts and sessions with interactive media are more obvious.
しかしながら、場合によっては、エンドデバイスからPSAPまたは仲介者に伝達されるアプリケーションデータのみがある。そのような環境の例には、警告を発行するセンサ、および特定の種類の医療用モニタが含まれる。これらのメッセージは緊急時に警告することができ、セッションの確立を必要としません。これらの種類の相互作用は「対話式緊急呼び出し」と呼ばれます。このドキュメントでは、対話型メディアを持つ非対話型アラートとセッションの類似点がより明白になるように、「呼び出し」という用語を使用します。
Non-interactive emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality, and location. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Transport Protocol [RFC3550] packets, such as voice, video, or real-time text.
非対話型緊急呼び出しは、緊急表示、緊急呼び出しルーティング機能、および場所が必要なという意味で定期的な緊急呼び出しに似ています。しかしながら、通信相互作用は、対話型メディア、すなわち、音声、ビデオ、またはリアルタイムテキストなどのリアルタイムトランスポートプロトコル[RFC3550]パケットの交換につながりません。
The Common Alerting Protocol (CAP) [CAP] is a format for exchanging emergency alerts and public warnings. CAP is mainly used for conveying alerts and warnings between authorities and from authorities to the public. The scope of this document is conveying CAP alerts from private devices to emergency service authorities, as a call without any interactive media.
一般的な警告プロトコル（CAP）[CAP]は、緊急警告と公の警告を交換するための形式です。キャップは主に当局間および当局から一般に警告と警告を搬送するために使用されます。この文書の範囲は、インタラクティブなメディアのない呼び出しとして、プライベートデバイスから緊急サービス当局にキャップアラートを運ぶことです。
This document describes a method of including a CAP alert in a SIP transaction by defining it as a block of "additional data" as defined in [RFC7852]. The CAP alert is included either by value (the CAP alert is in the body of the message, using a CID) or by reference (the message includes a URI that, when dereferenced, returns the CAP alert). The additional data mechanism is also used to send alert-specific data beyond that available in the CAP alert. This document also describes how a SIP MESSAGE [RFC3428] transaction can be used to send a non-interactive call.
この文書では、[RFC7852]で定義されているように「追加データ」のブロックとして定義することで、SIPトランザクションにキャップアラートを含める方法について説明します。CAPアラートは値ごとに含まれています（CAPアラートはメッセージの本文にある、CIDを使用して）、または参照によって含まれます（メッセージには、参照されるときはCAPアラートを返します）。追加のデータメカニズムは、キャップアラートで使用可能なそれを超えて警告固有のデータを送信するためにも使用されます。この文書では、SIPメッセージ[RFC3428]トランザクションを使用して非対話式通話を送信する方法についても説明します。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきです。
Non-interactive emergency call: An emergency call where there is no two-way interactive media
非対話型緊急電話：双方向の対話型メディアがない緊急呼び出し
SIP: Session Initiation Protocol [RFC3261]
SIP：セッション開始プロトコル[RFC3261]
PIDF-LO: Presence Information Data Format Location Object, a data structure for carrying location [RFC4119]
PIDF-LO：プレゼンス情報データフォーマットロケーションオブジェクト、場所を伝送するためのデータ構造[RFC4119]
LoST: Location To Service Translation protocol [RFC5222]
LOST：サービス翻訳プロトコルへのロケーション[RFC5222]
CID: Content-ID [RFC2392]
cid：content-id [RFC2392]
CAP: Common Alerting Protocol [CAP]
CAP：一般的な警告プロトコル[CAP]
PSAP: Public Safety Answering Point, the call center for emergency calls
PSAP：公安留守番電話、緊急電話のコールセンター
ESRP: Emergency Services Routing Proxy, a type of SIP Proxy Server used in some emergency services networks
ESRP：緊急サービスルーティングプロキシ、一部の緊急サービスネットワークで使用されるSIPプロキシサーバーの種類
This section illustrates two envisioned usage modes: targeted and location-based emergency alert routing.
このセクションでは、ターゲットと位置ベースの緊急警告ルーティングの2つの想定されている使用モードを示します。
1. Emergency alerts containing only data are targeted to an intermediary recipient responsible for evaluating the next steps. These steps could include:
1. データのみを含む緊急アラートは、次のステップを評価する責任を負う仲介者受信者を対象としています。これらのステップは次のとおりです。
a. Sending a non-interactive call containing only data towards a Public Safety Answering Point (PSAP);
a. パブリック安全回答ポイント（PSAP）に向かってデータのみを含む非対話式通話を送信する。
b. Establishing a third-party-initiated emergency call towards a PSAP that could include audio, video, and data.
b. オーディオ、ビデオ、およびデータを含めることができるPSAPに向かってサードパーティ開始緊急呼び出しを確立する。
2. Emergency alerts may be targeted to a service URN [RFC5031] used for IP-based emergency calls where the recipient is not known to the originator. In this scenario, the alert may contain only data (e.g., a SIP MESSAGE with CAP content, a Geolocation header field, and one or more Call-Info header fields containing additional data [RFC7852]).
2. 緊急警告は、受信者が発信者に知られていないIPベースの緊急呼び出しに使用されるサービスURN [RFC5031]を対象としている場合があります。このシナリオでは、アラートにはデータ（例えば、CAPコンテンツを含むSIPメッセージ、Geolocationヘッダフィールド、および追加データ[RFC7852]を含む1つまたは複数のコール情報ヘッダフィールド）のみを含めることができる。
Figure 1 shows a deployment variant where a sensor is pre-configured (using techniques outside the scope of this document) to issue an alert to an aggregator that processes these messages and performs whatever steps are necessary to appropriately react to the alert. For example, a security firm may use different sensor inputs to dispatch their security staff to a building they protect or to initiate a third-party emergency call.
図1は、これらのメッセージを処理するアグリゲータにアラートを発行し、アラートに適切に反応するために必要なステップを実行するために、センサーが事前設定されている展開バリアント（この文書の範囲外の技術を使用して）を示しています。たとえば、セキュリティ会社は異なるセンサー入力を使用して、セキュリティスタッフを保護したり、サードパーティの緊急呼び出しを開始したりするための建物に派遣することができます。
+------------+ +------------+
| Sensor | | Aggregator |
| | | |
+---+--------+ +------+-----+
| |
Sensors |
trigger |
emergency |
alert |
| SIP MESSAGE with CAP |
|----------------------------->|
| |
| Aggregator
| processes
| emergency
| alert
| SIP 200 (OK) |
|<-----------------------------|
| |
| |
Figure 1: Targeted Emergency Alert Routing
図1：緊急緊急警告ルーティング
In Figure 2, a scenario is shown where the alert is routed using location information and a service URN. An emergency services routing proxy (ESRP) may use LoST (a protocol defined by [RFC5222], which translates a location to a URI used to route an emergency call) to determine the next-hop proxy to route the alert message to. A possible receiver is a PSAP, and the recipient of the alert may be a call taker. In the generic case, there is very likely no prior relationship between the originator and the receiver, e.g., a PSAP. For example, a PSAP is likely to receive and accept alerts from entities it has no previous relationship with. This scenario is similar to a classic voice emergency services call, and the description in [RFC6881] is applicable. In this use case, the only difference between an emergency call and an emergency non-interactive call is that the former uses INVITE, creates a session, and negotiates one or more media streams, while the latter uses MESSAGE, does not create a session, and does not have interactive media.
図2では、警告が位置情報とサービスURNを使用してルーティングされているシナリオが示されています。緊急サービスルーティングプロキシ（ESRP）は、紛失（RFC5222で定義されているプロトコルが定義されています。これにより、緊急呼び出しをルーティングするために使用されるURIへの位置が変換されます）を使用して、警告メッセージをルーティングするためのネクストホッププロキシを決定します。可能な受信機はPSAPであり、警告の受信者はコールテイカーである可能性があります。一般的な場合には、発信者と受信機との間には事前の関係、例えばPSAPの間には非常に可能性が高い。たとえば、PSAPは、以前の関係がないエンティティからのアラートを受信して受け入れる可能性があります。このシナリオは古典的な音声緊急サービスの呼び出しと似ていますが、[RFC6881]の説明が適用されます。このユースケースでは、緊急呼び出しと緊急ノンインタラクティブコールとの間の唯一の違いは、前者がINVITEを使用し、セッションを作成し、1つまたは複数のメディアストリームをネゴシエートし、後者はセッションを作成しません。対話型メディアを持っていません。
+----------+ +----------+ +-----------+
|Sensor or | | ESRP | | PSAP |
|Aggregator| | | | |
+----+-----+ +---+------+ +----+------+
| | |
Sensors | |
trigger | |
emergency | |
alert | |
| | |
| | |
| SIP MESSAGE w/CAP | |
| (including service URN, |
| such as urn:service:sos) |
|------------------>| |
| | |
| ESRP performs |
| emergency alert |
| routing |
| | MESSAGE with CAP |
| | (including identity info) |
| |----------------------------->|
| | |
| | PSAP
| | processes
| | emergency
| | alert
| | SIP 200 (OK) |
| |<-----------------------------|
| | |
| SIP 200 (OK) | |
|<------------------| |
| | |
| | |
Figure 2: Location-Based Emergency Alert Routing
図2：位置ベースの緊急警告ルーティング
This document addresses sending a CAP alert in a SIP MESSAGE transaction for a non-interactive emergency call. Behavior with other transactions is not defined.
このドキュメントは、非対話型の緊急呼び出しのためにSIPメッセージトランザクションでCAPアラートを送信します。他のトランザクションとの動作は定義されていません。
The CAP alert is included in a SIP message as an additional data block [RFC7852]. Accordingly, it is conveyed in the SIP message with a Call-Info header field with a purpose of "EmergencyCallData.cap". The header field may contain a URI that is used by the recipient (or in some cases, an intermediary) to obtain the CAP alert. Alternatively, the Call-Info header field may contain a Content-ID URL [RFC2392] and the CAP alert included in the body of the message. In the latter case, the CAP alert is located in a MIME block of the type 'application/emergencyCallData.cap+xml'.
CAPアラートは、追加データブロックとしてSIPメッセージに含まれています[RFC7852]。したがって、「EmermarityCallData.Cap」の目的でCall-Infoヘッダーフィールドを使用してSIPメッセージで伝達されます。ヘッダフィールドは、キャップアラートを取得するために受信者（または場合によっては仲介者）によって使用されるURIを含み得る。あるいは、Call-Infoヘッダーフィールドには、Content-ID URL [RFC2392]とメッセージの本文に含まれるキャップアラートを含めることができます。後者の場合、CAPアラートは「Application / EmermanitalCallData.cap XML」型のMIMEブロックにあります。
If the SIP server does not support the functionality required to fulfill the request, then a 501 Not Implemented will be returned as specified in [RFC3261]. This is the appropriate response when a User Agent Server (UAS) does not recognize the request method and is not capable of supporting it for any user.
SIPサーバーが要求を満たすために必要な機能をサポートしていない場合は、[RFC3261]で指定されているとおりに実装されていない501が返されます。これは、ユーザーエージェントサーバー（UAS）が要求メソッドを認識しない場合の適切な応答です。これは、どのユーザーに対してもサポートできません。
The 415 Unsupported Media Type error will be returned as specified in [RFC3261] if the SIP server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header fields, depending on the specific problem with the content.
リクエストのメッセージ本文は、要求されたメソッドのサーバーによってサポートされていない形式であるため、SIPサーバーが要求を処理することを拒否している場合、415サポートされていないメディアタイプのエラーが[RFC3261]で指定されます。サーバーは、コンテンツの特定の問題に応じて、Accept、Accept-Encoding、またはAccept-Languageヘッダーフィールドを使用して許容可能なフォーマットのリストを返す必要があります。
The usage of CAP MUST conform to the specification provided with [CAP]. For usage with SIP, the following additional requirements are imposed (where "sender" and "author" are as defined in CAP and "originator" is the entity sending the CAP alert, which may be different from the entity sending the SIP MESSAGE):
キャップの使用法は、[CAP]に付属の仕様に準拠している必要があります。SIPを使用した使用のために、次の追加要件が課されます（ "Sender"と "Author"はCAPで定義されているとおり、 "Originator"はCAPアラートを送信するエンティティです。これは、SIPメッセージを送信するエンティティとは異なる可能性があります。
sender: The following restrictions and conditions apply to setting the value of the <sender> element:
送信者：<sender>要素の値を設定するには、以下の制限と条件が適用されます。
* Originator is a SIP entity, Author indication irrelevant: When the alert was created by a SIP-based originator and it is not useful to be explicit about the author of the alert, then the <sender> element MUST be populated with the SIP URI of the user agent.
* オリジネータはSIPエンティティ、著者表示は無関係です。アラートがSIPベースの発信者によって作成され、アラートの作成者について明示的になるのは有用ではない場合は、<sender>要素にのSIP URIを入力する必要があります。ユーザーエージェント。
* Originator is a non-SIP entity, Author indication irrelevant: When the alert was created by a non-SIP-based entity and the identity of this original sender is to be preserved, then this identity MUST be placed into the <sender> element. In this situation, it is not useful to be explicit about the author of the alert. The specific type of identity being used will depend on the technology used by the originator.
* オリジネータは非SIP以外のエンティティです。この状況では、アラートの作成者について明示的なものではありません。使用されている特定の種類のアイデンティティは、発信者が使用する技術に依存します。
* Author indication relevant: When the author is different from the originator of the message and this distinction should be preserved, then the <sender> element MUST NOT contain the SIP URI of the user agent.
* 著者表示関連：著者がメッセージの発信者と異なる場合、この区別を保存する必要がある場合は、<sender>要素にユーザーエージェントのSIP URIを含めることはできません。
incidents: The <incidents> element MUST be present. This incident identifier MUST be chosen in such a way that it is unique for a given <sender, expires, incidents> combination. Note that the <expires> element is OPTIONAL and might not be present.
インシデント：<Incidents>要素が存在している必要があります。このインシデント識別子は、特定の<Sender、Expires、Incidents> Combulineに対して固有の方法で選択する必要があります。<expires>要素はオプションであり、存在しない可能性があることに注意してください。
scope: The value of the <scope> element MAY be set to "Private" if the alert is not meant for public consumption. The <addresses> element is, however, not used by this specification since the message routing is performed by SIP and the respective address information is already available in other SIP header fields. Populating information twice into different parts of the message may lead to inconsistency.
スコープ：<scope>要素の値は、アラートが公衆消費のためのものではない場合は「プライベート」に設定されている可能性があります。ただし、メッセージルーティングはSIPによって実行され、それぞれのアドレス情報がすでに他のSIPヘッダーフィールドで既に利用可能であるため、<addresses>要素は使用されません。情報をメッセージのさまざまな部分に2回占めると、矛盾が発生する可能性があります。
parameter: The <parameter> element MAY contain additional information specific to the sender, conforming to the CAP alert syntax.
パラメータ：<parameter>要素には、CAP ALERT構文に準拠して、送信者に固有の追加情報が含まれている可能性があります。
area: It is RECOMMENDED to omit this element when constructing a message. If the CAP alert is given to the SIP entity to transport and it already contains an <area> element, then the specified location information SHOULD be copied into a PIDF-LO structure (the data format for location used by emergency calls on the Internet) referenced by the SIP 'Geolocation' header field. If the CAP alert is being created by the SIP entity using a PIDF-LO structure referenced by 'geolocation' to construct <area>, implementers must be aware that <area> is limited to a circle or polygon, and conversion of other shapes will be required. Points SHOULD be converted to a circle with a radius equal to the uncertainty of the point. Arc-bands and ellipses SHOULD be converted to polygons with similar coverage, and 3D locations SHOULD be converted to 2D forms with similar coverage.
エリア：メッセージを構築するときにこの要素を省略することをお勧めします。キャップアラートが転送するSIPエンティティに与えられ、既に<area>要素が含まれている場合、指定された位置情報はPIDF-LO構造にコピーする必要があります（インターネット上の緊急呼び出しで使用される場所のデータ形式）。SIP 'Geolocation'ヘッダーフィールドによって参照されます。「Geolocation」によって参照されているPIDF-LO構造を使用してCAPアラートがSIPエンティティによって作成されている場合、実装者は<area>がサークルまたはポリゴンに限定されていることを認識しておく必要があります。必要とされます。ポイントは、点の不確実性に等しい半径を持つ円に変換されるべきです。アークバンドと楕円は、同様のカバレッジを持つポリゴンに変換されるべきであり、3D位置は同様のカバレッジで2Dフォームに変換されるべきです。
A non-interactive emergency call is sent using a SIP MESSAGE transaction with a CAP URI or body part as described above in a manner similar to how an emergency call with interactive media is sent, as described in [RFC6881]. The MESSAGE transaction does not create a session nor establish interactive media streams, but otherwise, the header content of the transaction, routing, and processing of non-interactive calls are the same as those of other emergency calls.
非対話型緊急呼は、[RFC6881]で説明されているように、双方向メディアを持つ緊急呼び出しがどのように送信されるかと同様に、上述のように、上述のようにSIPメッセージ取引を使用して送信される。メッセージトランザクションはセッションを作成したり、インタラクティブ・メディア・ストリームを確立したりしたりしませんが、その他の方法では、非対話型通話のヘッダーコンテンツは他の緊急呼び出しと同じです。
This section defines a new error response code and a header field for additional information.
このセクションでは、追加情報の新しいエラー応答コードとヘッダーフィールドを定義します。
This SIP extension creates a new response code defined as follows:
このSIP拡張機能は、次のように定義された新しい応答コードを作成します。
425 (Bad Alert Message)
425（悪い警告メッセージ）
The 425 response code is a rejection of the request, indicating that it was malformed enough that no reasonable emergency response to the alert can be determined.
425応答コードは要求の拒絶であり、警告に対する合理的な緊急対応が判断されないほど十分に不正行為されたことを示す。
A SIP intermediary can also use this code to reject an alert it receives from a User Agent (UA) when it detects that the provided alert is malformed.
SIP仲介機関はまた、提供された警告が不正なことを検出したときにそれがユーザエージェント（UA）から受信するアラートを拒否することができる。
Section 5.2 describes an AlertMsg-Error header field with more details about what was wrong with the alert message in the request. This header field MUST be included in the 425 response.
セクション5.2では、リクエスト内の警告メッセージの何が問題になっていたのかについて詳しくは、alertmsg-errorヘッダーフィールドについて説明します。このヘッダーフィールドは425応答に含める必要があります。
It is usually the case that emergency calls are not rejected if there is any useful information that can be acted upon. It is only appropriate to generate a 425 response when the responding entity has no other information in the request that is usable by the responder.
通常行動することができる有用な情報がある場合、緊急通話が拒否されない場合です。応答エンティティに応答者によって使用可能な要求に他の情報がない場合には、425の応答を生成することが適切です。
A 425 response code MUST NOT be sent in response to a request that lacks an alert message (i.e., CAP data), as the user agent in that case may not support this extension.
425の応答コードは、その場合のユーザエージェントがこの拡張をサポートしていない可能性があるので、警告メッセージ（すなわち、キャップデータ）を欠く要求に応答して送信してはならない。
A 425 response is a final response within a transaction and MUST NOT terminate an existing dialog.
425応答はトランザクション内の最後の応答であり、既存のダイアログを終了してはいけません。
The AlertMsg-Error header field provides additional information about what was wrong with the original request. In some cases, the provided information will be used for debugging purposes.
ALERTMSG-ERRORヘッダーフィールドは、元のリクエストの間違っていたものに関する追加情報を提供します。場合によっては、提供された情報がデバッグ目的で使用されます。
The AlertMsg-Error header field has the following ABNF [RFC5234]:
alertmsg-errorヘッダーフィールドには、次のABNF [RFC5234]があります。
message-header =/ AlertMsg-Error
; (message-header from RFC 3261)
AlertMsg-Error = "AlertMsg-Error" HCOLON
ErrorValue
ErrorValue = error-code
*(SEMI error-params)
error-code = 3DIGIT
error-params = error-code-text
/ generic-param ; from RFC 3261
error-code-text = "message" EQUAL quoted-string ; from RFC 3261
HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].
HCOLON、SEMI、等は[RFC3261]で定義されています。DICITは[RFC5234]で定義されています。
The AlertMsg-Error header field MUST contain only one ErrorValue to indicate what was wrong with the alert payload the recipient determined was bad.
alertmsg-errorヘッダーフィールドには、受信者が決定した受信者が決定されたことを示すアラートペイロードの何が問題になっていたのかを示すための1つのerrorValueを含める必要があります。
The ErrorValue contains a 3-digit error code indicating what was wrong with the alert in the request. This error code has a corresponding quoted error text string that is human readable. The text string is OPTIONAL, but RECOMMENDED for human readability, similar to the string phrase used for SIP response codes. The strings in this document are recommendations and are not standardized -- meaning an operator can change the strings but MUST NOT change the meaning of the error code. The code space for ErrorValue is separate from SIP Status Codes.
ErrorValueには、要求内のアラートの何が問題になっていたかを示す3桁のエラーコードが含まれています。このエラーコードには、人間が読める対応するエラーテキスト文字列があります。テキスト文字列はオプションですが、SIPレスポンスコードに使用される文字列句と同様に、人間の読みやすさに推奨されます。この文書の文字列は推奨事項であり、標準化されていません - オペレータは文字列を変更できますが、エラーコードの意味を変更してはなりません。ErrorValueのコードスペースはSIPステータスコードとは別のものです。
The AlertMsg-Error header field MAY be included in any response if an alert message was in the request part of the same transaction. For example, suppose a UA includes an alert in a MESSAGE to a PSAP. The PSAP can accept this MESSAGE, even though its UA determined that the alert message contained in the MESSAGE was bad. The PSAP merely includes an AlertMsg-Error header field value in the 200 OK to the MESSAGE, thus informing the UA that the MESSAGE was accepted but the alert provided was bad.
警告メッセージが同じトランザクションの要求部分にあった場合、alertmsg-errorヘッダーフィールドは任意の応答に含まれている可能性があります。たとえば、UAがPSAPへのメッセージ内のアラートを含むと仮定する。そのUAがメッセージに含まれている警告メッセージが不良であると判断したとしても、PSAPはこのメッセージを受け入れることができます。PSAPには、メッセージに200 OKにあるALERTMSGエラーヘッダーフィールド値が含まれているだけで、メッセージが受け入れられたが、提供されたアラートが悪かったことをUAに通知する。
If, on the other hand, the PSAP cannot accept the transaction without a suitable alert message, a 425 response is sent.
一方、PSAPが適切な警告メッセージなしでトランザクションを受け入れることができない場合、425の応答が送信されます。
A SIP intermediary that requires the UA's alert message in order to properly process the transaction may also send a 425 response with an AlertMsg-Error code.
トランザクションを正しく処理するためにUAの警告メッセージを必要とするSIP仲介者は、ALERTMSGエラーコードで425の応答を送信することもできます。
This document defines an initial list of AlertMsg-Error values for any SIP response, including provisional responses (other than 100 Trying) and the new 425 response. There MUST NOT be more than one AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in provisional responses MUST be sent using the mechanism defined in [RFC3262]; or, if that mechanism is not negotiated, they MUST be repeated in the final response to the transaction.
このドキュメントでは、暫定的な応答（100以外の試行）と新しい425の応答を含む、任意のSIP応答に対するalertmsgエラー値の初期リストを定義します。SIPレスポンスに複数のALERTMSGエラーコードが必要です。暫定応答で送信されたALERTMSG-ERROR値[RFC3262]で定義されているメカニズムを使用して送信する必要があります。あるいは、そのメカニズムがネゴシエートされていない場合、それらはトランザクションに対する最終的な応答で繰り返されなければなりません。
AlertMsg-Error: 100 ; message="Cannot process the alert payload"
AlertMsg-Error: 101 ; message="Alert payload was not present or could not be found"
ALERTMSG-ERROR：101;message = "アラートペイロードが存在しませんでした、または見つかりませんでした"
AlertMsg-Error: 102 ; message="Not enough information to determine the purpose of the alert"
alertmsg-error：102;メッセージ=「アラートの目的を判断するのに十分な情報がない」
AlertMsg-Error: 103 ; message="Alert payload was corrupted"
Additionally, if an entity cannot or chooses not to process the alert message from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field.
さらに、EntityがSIP要求からアラートメッセージを処理できない場合や選択できない場合は、設定可能な再試行後のヘッダーフィールドの有無にかかわらず、500（サーバー内部エラー）を使用する必要があります。
This document does not describe any method for the recipient to call back the sender of a non-interactive call. Usually, these alerts are sent by automata, which do not have a mechanism to receive calls of any kind. The identifier in the 'From' header field may be useful to obtain more information, but any such mechanism is not defined in this document. The CAP alert may contain related contact information for the sender.
この文書は、受信者が非対話式通話の送信者を呼び戻すためのメソッドを説明していません。通常、これらのアラートはオートマトンによって送信されます。これは、任意の種類の通話を受信するためのメカニズムを持っていません。'from' headerフィールドの識別子は、より多くの情報を取得するのに役立ちますが、この文書ではそのようなメカニズムは定義されていません。キャップアラートには、送信者の関連連絡先情報が含まれている場合があります。
Sensors may have large quantities of data that they may wish to send. Including large amounts of data (tens of kilobytes) in a MESSAGE is not advisable because SIP entities are usually not equipped to handle very large messages. In such cases, the sender SHOULD make use of the by-reference mechanisms defined in [RFC7852], which involves making the data available via HTTPS [RFC2818] (either at the originator or at another entity), placing a URI to the data in the 'Call-Info' header field, and the recipient uses HTTPS to retrieve the data. The CAP alert itself can be sent by reference using this mechanism, as can any or all of the additional data blocks that may contain sensor-specific data.
センサーは、それらが送信したいと思うかもしれない大量のデータを持つかもしれません。メッセージ内の大量のデータ（数十キロバイト）を含めることは、SIPエンティティが通常非常に大きなメッセージを処理するために装備されていないため、お勧めできません。そのような場合、送信者は[RFC7852]で定義されている副参照メカニズムを使用しています。これは、HTTPS [RFC2818]（発信者または別のエンティティのいずれかで）使用可能なデータをデータに配置する必要があります。'Call-Info'ヘッダフィールドと受信者はHTTPSを使用してデータを取得します。CAPアラート自体は、センサ固有のデータを含むことができる追加のデータブロックのいずれかまたはすべての場合、このメカニズムを使用して参照によって送信できます。
There are no rate-limiting mechanisms for any SIP transactions that are standardized, although implementations often include such functions. Non-interactive emergency calls are typically handled the same as any emergency call, which means a human call-taker is involved. Implementations should take note of this limitation, especially when calls are placed automatically without human initiation.
標準化されているSIPトランザクションに対してレート制限メカニズムはありませんが、実装はしばしばそのような機能を含みます。非対話型緊急通話は通常、緊急通報と同じ緊急呼び出しと同じ扱いにされています。実装は、特に電話が自動的に人間の開始なしで自動的に配置されている場合には、この制限に注意してください。
The following example shows a CAP document indicating a BURGLARY alert issued by a sensor called 'sensor1@example.com'. The location of the sensor can be obtained from the attached location information provided via the 'Geolocation' header field contained in the SIP MESSAGE structure. Additionally, the sensor provided some data along with the alert message, using proprietary information elements intended only to be processed by the receiver, a SIP entity acting as an aggregator.
次の例は、 'sensor1@example.com'というセンサーによって発行された強盗警告を示すキャップ文書を示しています。センサの位置は、SIPメッセージ構造に含まれる「GeoLocation」ヘッダフィールドを介して提供された添付位置情報から取得することができる。さらに、センサは、受信機によって処理されることが意図される独自の情報要素を使用して、アグリゲータとして機能する独自の情報要素を使用して、警告メッセージと共にいくつかのデータを提供する。
MESSAGE sip:aggregator@example.com SIP/2.0 Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:sensor1@example.com;tag=49583 To: sip:aggregator@example.com Call-ID: asd88asd77a@2001:db8::ff Geolocation: <cid:abcdef@example.com> ;routing-allowed=yes Supported: geolocation CSeq: 1 MESSAGE Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
メッセージSIP：aggregator@example.com SIP / 2.0 Via：SIP / 2.0 / TCP Sensor1.example.com; Branch = Z9HG4BK776SGDKSE MAX-FORWORDS：70から：SIP：Sensor1@example.com; TAG = 49583対：SIP：Aggregator@ example.com call-id：ASD88ASD77A @ 2001：DB8 :: FF GeoLocation：<cid：abcdef@example.com>; routing-ablection =はいサポート：Geolocation CSEQ：1 message call-info：cid：abcdef2 @例。com;目的= emergermalcalldata.cap content-type：マルチパート/ミックス。境界= BUNDARY1コンテンツ長：...
--boundary1
Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@example.com>
Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier>
<sender>sip:sensor1@example.com</sender>
<sent>2020-01-04T20:57:35Z</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Private</scope>
<incidents>abc1234</incidents>
<info>
<category>Security</category>
<event>BURGLARY</event>
<urgency>Expected</urgency>
<certainty>Likely</certainty>
<severity>Moderate</severity>
<senderName>SENSOR 1</senderName>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE1</valueName>
<value>123</value>
</parameter>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value>
</parameter>
</info>
</alert>
--boundary1
Content-Type: application/pidf+xml
Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="sensor">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>44.85249659 -93.238665712</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2020-02-04T20:57:29Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:timestamp>2020-01-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
Figure 3: Example Message Conveying an Alert to an Aggregator
図3：アグリゲータへのアラートを伝えるメッセージの例
The following shows the same CAP document sent as a non-interactive emergency call towards a PSAP.
以下は、PSAPへの対話型の緊急呼び出しとして送信されたのと同じCAP文書を示しています。
MESSAGE urn:service:sos SIP/2.0 Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa Max-Forwards: 70 From: sip:aggregator@example.com;tag=32336 To: 112 Call-ID: asdf33443a@example.com Route: sip:psap1.example.gov Geolocation: <cid:abcdef@example.com> ;routing-allowed=yes Supported: geolocation Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap CSeq: 1 MESSAGE Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ...
メッセージURN：サービス：SOS SIP / 2.0から：SIP / 2.0 / TCP SIP：AGGREG.1.EXAMPLE.com; Branch = Z9HG4BK776ABSSA MAX-FORWORDS：70：SIP：AGGREGATER@EXAMPLE.COM; tag = 32336から：112call-id：asdf33443a@example.comルート：SIP：PSAP1.example.gox geoolocation：<cid：abcdef@example.com>; routing-ablection =はいサポートされています：geoolocation call-info：cid：abcdef2@example.com;目的= emermargyCallData.cap CSEQ：1メッセージcontent-type：マルチパート/ミックス。境界= BUNDARY1コンテンツ長：...
--boundary1
- voundary1
Content-Type: application/EmergencyCallData.cap+xml
Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier>
<sender>sip:sensor1@example.com</sender>
<sent>2020-01-04T20:57:35Z</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Private</scope>
<incidents>abc1234</incidents>
<info>
<category>Security</category>
<event>BURGLARY</event>
<urgency>Expected</urgency>
<certainty>Likely</certainty>
<severity>Moderate</severity>
<senderName>SENSOR 1</senderName>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE1</valueName>
<value>123</value>
</parameter>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value>
</parameter>
</info>
</alert>
--boundary1
- voundary1
Content-Type: application/pidf+xml
Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="sensor">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>44.85249659 -93.2386657124</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2020-02-04T20:57:25Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:timestamp>2020-01-04T20:57:25Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
Figure 4: Example Message Conveying an Alert to a PSAP
図4：PSAPへのアラートを伝えるメッセージの例
This section discusses security considerations when SIP user agents issue emergency alerts utilizing MESSAGE and CAP. Location-specific threats are not unique to this document and are discussed in [RFC7378] and [RFC6442].
SIPユーザエージェントがメッセージとCAPを利用して緊急警告を発行するときのセキュリティ上の考慮事項について説明します。場所固有の脅威はこの文書に固有のものではなく、[RFC7378]と[RFC6442]で説明されています。
The Emergency Context Resolution with Internet Technologies (ECRIT) emergency services architecture [RFC6443] considers classic individual-to-authority emergency calling where the identity of the emergency caller does not play a role at the time of the call establishment itself, i.e., a response to the emergency call does not depend on the identity of the caller. In the case of emergency alerts generated by devices such as sensors, the processing may be different in order to reduce the number of falsely generated emergency alerts. Alerts could get triggered based on certain sensor input that might have been caused by factors other than the actual occurrence of an alert-relevant event. For example, a sensor may simply be malfunctioning. For this reason, not all alert messages are directly sent to a PSAP, but rather, may be pre-processed by a separate entity, potentially under supervision by a human, to filter alerts and potentially correlate received alerts with others to obtain a larger picture of the ongoing situation.
インターネットテクノロジ（ECRIT）緊急サービスアーキテクチャ[RFC6443]の緊急コンテキスト解決[RFC6443]は、緊急発信者の身元が呼確立自体の時点で役割を果たしていない古典的な個人間緊急呼び出し、すなわち応答を考慮します。緊急呼び出しには発信者の身元には依存しません。センサなどの装置によって生成された緊急警告の場合、誤って生成された緊急警報の数を減らすために処理は異なる場合がある。アラートは、実際のアラート関連イベントの発生以外の要因によって引き起こされた可能性がある特定のセンサー入力に基づいてトリガーされる可能性があります。例えば、センサは単に故障している可能性がある。このため、すべての警告メッセージがPSAPに直接送信されるわけではなく、むしろ、人間による監督下で潜在的に潜在的に事前処理され、警告をフィルタリングし、他の人との潜在的に受信したアラートを相関させることができます。進行中の状況の
In any case, for alerts initiated by sensors, the identity could play an important role in deciding whether to accept or ignore an incoming alert message. With the scenario shown in Figure 1, it is very likely that only authenticated sensor input will be processed. For this reason, it needs to be possible to refuse to accept alert messages from unknown origins. Two types of information elements can be used for this purpose:
いずれにせよ、警告のために、センサーによって開始されたアラートの場合、IDは、受信警告メッセージを受け入れるか無視するかを決定するのに重要な役割を果たすことができます。図1に示すシナリオでは、認証されたセンサー入力のみが処理される可能性が非常に高いです。このため、不明な起源から警告メッセージを受け入れることを拒否することが可能である必要があります。この目的のために2種類の情報要素を使用することができます。
1. SIP itself provides security mechanisms that allow the verification of the originator's identity, such as P-Asserted-Identity [RFC3325] or SIP Identity [RFC8224]. The latter provides a cryptographic assurance while the former relies on a chain-of-trust model. These mechanisms can be reused.
1. SIP自体は、Pアサートアイデンティティ[RFC3325]またはSIP ID [RFC8224]など、発信者の身元の検証を可能にするセキュリティメカニズムを提供します。後者は、前者が信頼型モデルに依存している間に暗号化保証を提供します。これらのメカニズムは再利用できます。
2. CAP provides additional security mechanisms and the ability to carry further information about the sender's identity. Section 3.3.4.1 of [CAP] specifies the signing algorithms of CAP documents.
2. キャップは追加のセキュリティメカニズムと送信者の身元に関するさらなる情報を運ぶ能力を提供します。[CAP]のセクション3.3.4.1は、CAP文書の署名アルゴリズムを指定します。
The specific policy and mechanisms used in a given deployment are out of scope for this document.
特定の展開で使用されている特定のポリシーとメカニズムはこの文書に対して範囲外です。
There is no rate limiting mechanisms in SIP, and all kinds of emergency calls, including those defined in this document, could be used by malicious actors or misbehaving devices to effect a denial-of-service attack on the emergency services. The mechanism defined in this document does not introduce any new considerations, although it may be more likely that devices that place non-interactive emergency calls without a human initiating them may be more likely than those that require a user to initiate them.
SIPには料金制限メカニズムがありません。この文書で定義されているものを含むあらゆる種類の緊急呼び出しは、緊急サービスに対するサービス拒否攻撃に影響を与えるために悪意のある俳優や誤動作のデバイスによって使用される可能性があります。この文書で定義されているメカニズムは新しい考慮事項を導入していませんが、人間が開始する人間のない非対話型緊急呼び出しを配置するデバイスは、ユーザーがそれらを開始することを要求するものよりも高い可能性があります。
Implementors should note that automated emergency calls may be prohibited or regulated in some jurisdictions, and there may be penalties for "false positive" calls.
実装者は、自動化された緊急呼び出しがいくつかの管轄区域で禁止または規制される可能性があることに注意してください。
This document describes potential retrieval of information by
dereferencing URIs found in a Call Info header of a SIP MESSAGE.
These may include a CAP alert as well as other additional data
[RFC7852] blocks. The domain of the device sending the SIP MESSAGE;
the domain of the server holding the CAP alert, if sent by reference;
and the domain of other additional data blocks, if sent by reference,
may all be different. No assumptions can be made that there are
trust relationships between these entities. Recipients MUST take
precautions in retrieving any additional data blocks passed by
reference, including the CAP alert, because the URI may point to a
malicious actor or entity not expecting to be referred to for this
purpose. The considerations in handling URIs in [RFC3986] apply.
Use of timestamps to prevent replay is subject to the availability of accurate time at all participants. Because emergency event notification via this mechanism is relatively low frequency and generally involves human interaction, implementations may wish to consider messages with times within a small number of seconds of each other to be effectively simultaneous for the purposes of detecting replay. Implementations may also wish to consider that most deployed time distribution protocols likely to be used by these systems are not presently secure.
再生を防ぐためのタイムスタンプの使用は、すべての参加者での正確な時間の可用性の対象となります。このメカニズムを介した緊急事態通知は比較的低い周波数であり、一般的に人間の相互作用を含み、実装は、再生を検出する目的で、互いの少数の秒数秒以内の時間とのメッセージを検討したいと思うかもしれません。実装は、これらのシステムによって使用される可能性が高いほとんどの展開された時間配信プロトコルが現在安全ではないと考えることもできます。
In addition to the desire to perform identity-based access control, the classic communication security threats need to be considered, including integrity protection to prevent forgery or replay of alert messages in transit. To deal with replay of alerts, a CAP document contains the mandatory <identifier>, <sender>, and <sent> elements and an optional <expire> element. Together, these elements make the CAP document unique for a specific sender and provide time restrictions. An entity that has already received a CAP alert within the indicated timeframe is able to detect a replayed message and, if the content of that message is unchanged, then no additional security vulnerability is created. Additionally, it is RECOMMENDED to make use of SIP security mechanisms, such as the SIP Identity PASSporT [RFC8225], to tie the CAP alert to the SIP message. To provide protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is RECOMMENDED. [RFC6443] discusses the issues of using TLS with emergency calls, which are equally applicable to non-interactive emergency calls.
アイデンティティベースのアクセス制御を実行したいという要望に加えて、輸送中の警告メッセージの偽造または再生を防ぐための完全性保護を含む、クラシックなコミュニケーションセキュリティの脅威を考慮する必要があります。アラートの再生に対処するために、CAP文書には、必須の<識別子>、<Sender>、および<SENT>要素とオプションの<expire>要素が含まれています。これらの要素は、CAP文書を特定の送信者に対して固有にし、時間制限を提供します。示された時間枠内にCAPアラートを既に受信したエンティティは、再生メッセージを検出することができ、そのメッセージの内容が変更されていない場合は、追加のセキュリティの脆弱性が作成されません。さらに、SIP ID Passport [RFC8225]などのSIPセキュリティメカニズムを使用して、CAPアラートをSIPメッセージに接続することをお勧めします。隣接するSIPエンティティ間のSIPメッセージ交換全体を保護するために、TLSの使用法をお勧めします。 [RFC6443] TLSを緊急呼び出しで使用する問題について説明します。これは、非対話式緊急呼び出しに等しく適用されます。
Note that none of the security mechanisms in this document protect against a compromised sensor sending crafted alerts. Confidentiality provided for any emergency calls, including non-interactive messages, is subject to local regulations. Privacy issues are discussed in [RFC7852] and are applicable here.
この文書内のセキュリティメカニズムのどれも、妥協された警告を送信する妥協されたセンサーに対して保護されていないことに注意してください。非対話型メッセージを含む緊急電話に提供される機密性は、現地規制の対象となります。プライバシーの問題は[RFC7852]で説明され、ここに適用されます。
Type name: application
タイプ名：アプリケーション
Subtype name: EmergencyCallData.cap+xml
サブタイプ名：EmermarityCallData.cap XML.
Required parameters: N/A
必要なパラメータ：N / A.
Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [RFC3629].
オプションのパラメータ：文字セット。囲まれたXMLの文字エンコードを示します。デフォルトはUTF-8 [RFC3629]です。
Encoding considerations: 7bit, 8bit, or binary. See Section 3.2 of [RFC7303].
エンコードに関する考慮事項7ビット、8ビット、またはバイナリ。[RFC7303]のセクション3.2を参照してください。
Security considerations: This content type is designed to carry payloads of the Common Alerting Protocol (CAP). RFC 8876 discusses security considerations for this.
セキュリティ上の考慮事項：このコンテンツタイプは、共通の警告プロトコル（CAP）のペイロードを携帯するように設計されています。RFC 8876はこれに関するセキュリティ上の考慮事項について説明します。
Interoperability considerations: This content type provides a way to convey CAP payloads.
相互運用性の考慮事項：このコンテンツタイプは、キャップペイロードを伝える方法を提供します。
Published specification: RFC 8876
公開仕様：RFC 8876
Applications that use this media type: Applications that convey alerts and warnings according to the CAP standard.
このメディアタイプを使用するアプリケーションCAP規格に従ってアラートと警告を伝えるアプリケーション。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information: OASIS has published the Common Alerting
Protocol at <https://docs.oasis-open.org/emergency/cap/v1.2/CAP-
v1.2-os.pdf>
Person and email address to contact for further information:
Hannes Tschofenig <hannes.tschofenig@gmx.net>
Intended usage: Limited use
意図された用途：限られた使用
Author/Change controller: The IESG
作者/変更コントローラー：IESG
Other information: This media type is a specialization of 'application/xml' [RFC7303], and many of the considerations described there also apply to application/ EmergencyCallData.cap+xml.
その他の情報：このメディアタイプは 'application / XML' [RFC7303]の特殊化であり、そこで説明されている考慮事項の多くはアプリケーション/ emergermalcalldata.cap XMLにも適用されます。
Per this document, IANA has registered a new block type in the "Emergency Call Data Types" subregistry of the "Emergency Call Additional Data" registry defined in [RFC7852]. The token is "cap", the Data About is "The Call", and the reference is this document.
この文書によると、IANAは[RFC7852]で定義されている「緊急呼び別データ」レジストリの「緊急呼データタイプ」サブレクシストに新しいブロックタイプを登録しました。トークンは "cap"で、データに関するデータは "Call"で、参照はこの文書です。
In the SIP "Response Codes" registry, the following has been added under Request Failure 4xx.
SIPの「応答コード」レジストリでは、次のことが要求失敗4xxの下に追加されました。
+===============+===================+===========+
| Response Code | Description | Reference |
+===============+===================+===========+
| 425 | Bad Alert Message | RFC 8876 |
+---------------+-------------------+-----------+
Table 1: Response Codes Registry Addition
表1：応答コードレジストリ追加
This SIP Response code is defined in Section 5.
このSIP応答コードはセクション5で定義されています。
The SIP AlertMsg-Error header field is created by this document, with its definition and rules in Section 5. The IANA "Session Initiation Protocol (SIP) Parameters" registry has been updated as follows.
SIP ALERTMSG-ERRORヘッダーフィールドは、このドキュメントによってセクション5の定義と規則によって作成されます.IANA "Session Initiation Protocol（SIP）パラメータ）レジストリは次のように更新されました。
1. In the "Header Fields" subregistry, the following has been added:
1. 「ヘッダーフィールド」サブレイストでは、次のものが追加されました。
+================+=========+===========+
| Head Name | compact | Reference |
+================+=========+===========+
| AlertMsg-Error | | RFC 8876 |
+----------------+---------+-----------+
Table 2: Header Fields Registry Addition
表2：ヘッダーフィールドレジストリ追加
2. In the "Header Field Parameters and Parameter Values" subregistry, the following has been added:
2. 「ヘッダフィールドパラメータとパラメータ値」サブレイストでは、以下が追加されました。
+================+================+============+===========+
| Header Field | Parameter Name | Predefined | Reference |
| | | Values | |
+================+================+============+===========+
| AlertMsg-Error | code | no | RFC 8876 |
+----------------+----------------+------------+-----------+
Table 3: Header Field Parameters and Parameter Values Registry Addition
表3：ヘッダーフィールドパラメータとパラメータ値レジストリ追加
This document creates a new registry called "SIP AlertMsg-Error Codes". AlertMsg-Error codes provide reasons for an error discovered by a recipient, categorized by the action to be taken by the error recipient. The initial values for this registry are shown below. The registration procedure is Specification Required [RFC8126].
このドキュメントでは、 "SIP AlertMsg-Error Codes"という新しいレジストリが作成されます。ALERTMSG-ERRORコードは、エラー受信者によって取得されるアクションによって分類された受信者によって発見されたエラーの理由を提供します。このレジストリの初期値を以下に示します。登録手順は必要です[RFC8126]。
+======+=====================================+===========+
| Code | Default Reason Phrase | Reference |
+======+=====================================+===========+
| 100 | "Cannot process the alert payload" | RFC 8876 |
+------+-------------------------------------+-----------+
| 101 | "Alert payload was not present or | RFC 8876 |
| | could not be found" | |
+------+-------------------------------------+-----------+
| 102 | "Not enough information to | RFC 8876 |
| | determine the purpose of the alert" | |
+------+-------------------------------------+-----------+
| 103 | "Alert payload was corrupted" | RFC 8876 |
+------+-------------------------------------+-----------+
Table 4: SIP AlertMsg-Error Codes Registry Creation
表4：SIP ALERTMSG - エラーコードレジストリ作成
Details of these error codes are in Section 5.
これらのエラーコードの詳細はセクション5にあります。
[CAP] Jones, E. and A. Botterell, "Common Alerting Protocol Version 1.2", OASIS Standard CAP-V1.2, July 2010, <https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf>.
[キャップ]ジョーンズ、E.およびA.Botterell、「共通警戒プロトコルバージョン1.2」、OASIS規格CAP-V1.2、<https：//docs.oasis-open.org/emergency/cap/v1。2 / cap-v1.2-os.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.
[RFC2392] Levinson、E.、「Content-IDおよびメッセージIDユニフォーム・ロケーター」、RFC 2392、DOI 10.17487 / RFC2392、1998年8月、<https：//www.rfc-editor.org/info/rfc2392>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, <https://www.rfc-editor.org/info/rfc3262>.
[RFC3262] Rosenberg、J.およびH.Schulzrinne、「セッション開始プロトコル（SIP）」、RFC 3262、DOI 10.17487 / RFC3262、2002年6月、<https：//ww.rfc-editor.org/情報/ RFC3262>。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, <https://www.rfc-editor.org/info/rfc3428>.
[RFC3428]キャンベル、B.、ED。、Rosenberg、J.、Schulzrinne、H.、Hiuitema、C.、およびD. Gurle、「インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子」、RFC 3428、DOI 10.17487 /RFC3428、2002年12月、<https：//www.rfc-editor.org/info/rfc3428>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, <https://www.rfc-editor.org/info/rfc4119>.
[RFC4119] Peterson、J.、「プレゼンスベースのGeoPrivロケーションオブジェクトフォーマット」、RFC 4119、DOI 10.17487 / RFC4119、2005年12月、<https：//www.rfc-editor.org/info/rfc4119>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H.およびC.Lilley、「XMLメディアタイプ」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<https：//www.rfc-editor.org/info/rfc7303>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>.
[RFC6442] Polk、J.、Rosen、B.およびJ.Peterson、「セッション開始プロトコルのためのロケーション運搬」、RFC 6442、DOI 10.17487 / RFC6442、2011年12月、<https：//www.rfc-編集者。org / info / rfc6442>。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <https://www.rfc-editor.org/info/rfc6881>.
[RFC6881]ローゼン、B.およびJ.Polk、「緊急通報をサポートしているコミュニケーションサービスのための最高の現在の実践」、BCP 181、RFC 6881、DOI 10.17487 / RFC6881、2013年3月、<https：//www.rfc-編集者.org / info / rfc6881>。
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>.
[RFC7852] Gellens、R.、Rosen、B.、Tschofenig、H.、Marshall、R.、およびJ.WinterBottom、「緊急コールに関する追加データ」、RFC 7852、DOI 10.17487 / RFC7852、2016年7月、<https://www.rfc-editor.org/info/rfc7852>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225] Wendt、C.およびJ.Peterson、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<https：//www.rfc-editor.org/info/rfc8225>。
[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, December 2014, <https://www.rfc-editor.org/info/rfc7378>.
[RFC7378] Tschofenig、H.、Schulzrinne、H.、およびB. Aboba、Ed。、「信頼できる場所」、RFC 7378、DOI 10.17487 / RFC7378、2014年12月、<https：//www.rfc-editor.org/情報/ RFC7378>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.
[RFC8224] Peterson、J.、Jennings、C、Rescorla、E.、およびC.Wendt、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<HTTPS）//www.rfc-editor.org/info/rfc8224>。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, DOI 10.17487/RFC5031, January 2008, <https://www.rfc-editor.org/info/rfc5031>.
[RFC5031] Schulzrinne、H。、「緊急事態およびその他の有名なサービスのためのユニフォームリソース名（URN）、RFC 5031、DOI 10.17487 / RFC5031、2008年1月、<https：//www.rfc-editor.org/情報/ RFC5031>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325] Jennings、C、Peterson、J.、M. Watson、「信頼できるネットワーク内のセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<HTTPS//www.rfc-editor.org/info/rfc3325>。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, <https://www.rfc-editor.org/info/rfc5222>.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H.、およびH.Tschofenig、 "Lost：Service to-Service Translation Protocol"、RFC 5222、DOI 10.17487 / RFC5222、2008年8月、<https：//www.rfc-editor.org/info/rfc5222>。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2011, <https://www.rfc-editor.org/info/rfc6443>.
[RFC6443]ローゼン、B.、Schulzrinne、H.、Polk、J.、およびA.ニュートン、「インターネットマルチメディアを使用した緊急呼び出しのためのフレームワーク」、RFC 6443、DOI 10.17487 / RFC6443、2011年12月、<HTTPS：// WWW.rfc-editor.org / info / rfc6443>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
Acknowledgments
謝辞
The authors would like to thank the participants of the Early Warning ad hoc meeting at IETF 69 for their feedback. Additionally, we would like to thank the members of the NENA Long Term Direction Working Group for their feedback.
著者らは、彼らのフィードバックのためにIETF 69で早期警告アドホック会議の参加者に感謝したいと思います。さらに、私たちは彼らのフィードバックのためにNENAの長期方向ワーキンググループのメンバーに感謝します。
Additionally, we would like to thank Martin Thomson, James Winterbottom, Shida Schubert, Bernard Aboba, Marc Linsner, Christer Holmberg, and Ivo Sedlacek for their review comments.
さらに、Martin Thomson、James Winterbottom、Shida Schubert、Bernard Aboba、Marc Linsner、Christer Holmberg、およびIvo Sedlacekのレビューのコメントに感謝します。
Authors' Addresses
著者の住所
Brian Rosen 470 Conrad Dr Mars, PA 16046 United States of America
Brian Rosen 470 Conrad Dr Mars、PA 16046アメリカ合衆国
Email: br@brianrosen.net
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 United States of America
Schulzrinne Columbia University Computer Science専門科大学450 Computer Science Building New York、NY 10027アメリカ合衆国
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: https://www.cs.columbia.edu
Hannes Tschofenig Austria
Hannes Tschofenigオーストリア
Email: Hannes.Tschofenig@gmx.net
URI: https://www.tschofenig.priv.at
Randall Gellens Core Technology Consulting
Randall Gellens Core Technology Consulting
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com