[要約] RFC 8688は、拒否された通話に対するSIP（Session Initiation Protocol）の応答コードを定義しています。その目的は、通話が拒否された場合に明確なエラーコードを提供し、通信の品質と信頼性を向上させることです。
Internet Engineering Task Force (IETF) E.W. Burger
Request for Comments: 8688 Georgetown University
Category: Standards Track B. Nagda
ISSN: 2070-1721 Massachusetts Institute of Technology
December 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls
拒否された通話のセッション開始プロトコル（SIP）応答コード
Abstract
概要
This document defines the 608 (Rejected) Session Initiation Protocol (SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked.
このドキュメントでは、608（拒否）セッション開始プロトコル（SIP）応答コードを定義しています。この応答コードにより、呼び出し側は、仲介者が呼び出しの試行を拒否したことを知ることができます。誰も呼び出しを提供せず、したがって応答しません。 6xxコードとして、発信者は同じユーザーエージェントサーバーに接続しようとすると、失敗する可能性が高いことを認識します。 608応答コードが必要になる最初のユースケースは、仲介者が分析エンジンである場合です。この場合、拒否はマシンまたは他のプロセスによるものです。これは、ターゲットユーザーエージェントサーバーの人間がユーザーが通話を望まなかったことを示す607（不要な）SIP応答コードとは対照的です。一部の管轄区域では、この区別が重要です。このドキュメントでは、608応答でCall-Infoヘッダーフィールドを使用して、拒否された発信者が誤って通話をブロックしたエンティティに連絡できるようにすることも定義しています。これは、通話がブロックされていることに気付いた法的な発信者に修復メカニズムを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8688.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8688で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Protocol Operation
3.1. Intermediary Operation
3.2. JWS Construction
3.2.1. JOSE Header
3.2.2. JWT Payload
3.2.3. JWS Signature
3.3. UAC Operation
3.4. Legacy Interoperation
3.5. Announcement Requirements
4. Examples
4.1. Full Exchange
4.2. Web Site jCard
4.3. Multi-modal jCard
4.4. Legacy Interoperability
5. IANA Considerations
5.1. SIP Response Code
5.2. SIP Feature-Capability Indicator
5.3. JSON Web Token Claim
5.4. Call-Info Purpose
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The IETF has been addressing numerous issues surrounding how to handle unwanted and, depending on the jurisdiction, illegal calls [RFC5039]. Secure Telephone Identity Revisited (STIR) [RFC7340] and Signature-based Handling of Asserted information using toKENs (SHAKEN) [SHAKEN] address the cryptographic signing and attestation, respectively, of signaling to ensure the integrity and authenticity of the asserted caller identity.
IETFは、管轄区域によっては、不必要な、そして違法な呼び出し[RFC5039]を処理する方法を取り巻く数多くの問題に取り組んできました。 Secure Telephone Identity Revisited（STIR）[RFC7340]および署名ベースのアサートされた情報のtoKENs（SHAKEN）を使用した処理（SHAKEN）は、シグナリングの暗号化署名と証明をそれぞれ処理して、アサートされた発信者IDの整合性と信頼性を保証します。
This document describes a new Session Initiation Protocol (SIP) [RFC3261] response code, 608, which allows calling parties to learn that an intermediary rejected their call. As described below, we need a distinct indicator to differentiate between a user rejection and an intermediary's rejection of a call. In some jurisdictions, service providers may not be permitted to block calls, even if unwanted by the user, unless there is an explicit user request. Moreover, users may misidentify the nature of a caller.
このドキュメントでは、新しいセッション開始プロトコル（SIP）[RFC3261]応答コード608について説明します。これにより、発信者は、仲介者が通話を拒否したことを知ることができます。以下で説明するように、ユーザーの拒否と仲介者の呼び出しの拒否を区別するための明確なインジケータが必要です。管轄区域によっては、明示的なユーザー要求がない限り、ユーザーが望まない場合でも、サービスプロバイダーは呼び出しをブロックすることが許可されない場合があります。さらに、ユーザーは発信者の性質を誤認する可能性があります。
For example, a legitimate caller may call a user who finds the call to be unwanted. However, instead of marking the call as unwanted, the user may mark the call as illegal. With that information, an analytics engine may determine to block all calls from that source. However, in some jurisdictions, blocking calls from that source for other users may not be legal. Likewise, one can envision jurisdictions that allow an operator to block such calls, but only if there is a remediation mechanism in place to address false positives.
たとえば、正当な発信者は、その通話が不要であると判断したユーザーに電話をかけることがあります。ただし、通話を不要としてマークする代わりに、ユーザーは通話を不正としてマークすることができます。その情報を使用して、分析エンジンはそのソースからのすべての呼び出しをブロックすることを決定できます。ただし、管轄区域によっては、そのソースからの他のユーザーへの通話をブロックすることが合法でない場合があります。同様に、オペレーターがそのような呼び出しをブロックできる管轄区域を想定できますが、それは誤検知に対処するための修復メカニズムが設置されている場合に限られます。
Some call-blocking services may return responses such as 604 (Does Not Exist Anywhere). This might be a strategy to try to get a destination's address removed from a calling database. However, other network elements might also interpret this to mean the user truly does not exist, which might result in the user not being able to receive calls from anyone, even if they wanted to receive the calls. In many jurisdictions, providing such false signaling is also illegal.
一部のコールブロッキングサービスは、604（どこにも存在しない）などの応答を返す場合があります。これは、呼び出し元のデータベースから宛先のアドレスを削除しようとする戦略かもしれません。ただし、他のネットワーク要素もこれを解釈して、ユーザーが実際には存在しないことを意味する場合があります。その結果、ユーザーが呼び出しを受信したい場合でも、ユーザーは誰からも呼び出しを受信できなくなる可能性があります。多くの管轄区域では、そのような誤ったシグナリングを提供することも違法です。
The 608 response code addresses this need of remediating falsely blocked calls. Specifically, this code informs the SIP User Agent Client (UAC) that an intermediary blocked the call and provides a redress mechanism that allows callers to contact the operator of the intermediary.
608応答コードは、誤ってブロックされた通話を修復するこの必要性に対処します。具体的には、このコードは、仲介者が通話をブロックしたことをSIPユーザーエージェントクライアント（UAC）に通知し、発信者が仲介者のオペレーターに連絡できるようにする修復メカニズムを提供します。
In the current call handling ecosystem, users can explicitly reject a call or later mark a call as being unwanted by issuing a 607 SIP response code (Unwanted) [RFC8197]. Figures 1 and 2 show the operation of the 607 SIP response code. The User Agent Server (UAS) indicates the call was unwanted. As [RFC8197] explains, not only does the called party desire to reject that call, they can let their proxy know that they consider future calls from that source unwanted. Upon receipt of the 607 response from the UAS, the proxy may send unwanted call indicators, such as the value of the From header field and other information elements, to a call analytics engine. For various reasons described in [RFC8197], if a network operator receives multiple reports of unwanted calls, that may indicate that the entity placing the calls is likely to be a source of unwanted calls for many people. As such, other customers of the service provider may want the service provider to automatically reject calls on their behalf.
現在の通話処理エコシステムでは、ユーザーは607 SIP応答コード（不要）[RFC8197]を発行することにより、通話を明示的に拒否するか、後で通話を不要としてマークできます。図1および2は、607 SIP応答コードの動作を示しています。ユーザーエージェントサーバー（UAS）は、通話が不要であったことを示します。 [RFC8197]が説明しているように、着信側はそのコールを拒否したいだけでなく、その発信元からの今後のコールは望ましくないと見なしていることをプロキシに通知できます。 UASから607応答を受信すると、プロキシは、Fromヘッダーフィールドやその他の情報要素の値などの不要な呼び出しインジケーターを呼び出し分析エンジンに送信します。 [RFC8197]で説明されているさまざまな理由により、ネットワークオペレーターが不要な通話の複数のレポートを受け取った場合、通話を発信しているエンティティが多くの人にとって不要な通話の発信元である可能性が高いことを示している可能性があります。そのため、サービスプロバイダーの他の顧客は、サービスプロバイダーに代わってコールを自動的に拒否することを望む場合があります。
There is another value of the 607 rejection code. Presuming the proxy forwards the response code to the UAC, the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender.
607拒否コードには別の値があります。プロキシが応答コードをUACに転送すると想定すると、呼び出し側のUACまたは介在するプロキシは、ユーザーがその送信者からの呼び出しの受信に関心がないことも学習します。
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 607 | Called | 607 +-----+
| UAC | <--------- | Party | <-------- | UAS |
+-----+ | Proxy | +-----+
+-----------+
Figure 1: Unwanted (607) Call Flow
図1：不要な（607）コールフロー
For calls rejected with a 607 from a legitimate caller, receiving a 607 response code can inform the caller to stop attempting to call the user. Moreover, if a legitimate caller believes the user is rejecting their calls in error, they can use other channels to contact the user. For example, if a pharmacy calls a user to let them know their prescription is available for pickup and the user mistakenly thinks the call is unwanted and issues a 607 response code, the pharmacy, having an existing relationship with the customer, can send the user an email or push a note to the pharmacist to ask the customer to consider not rejecting their calls in the future.
正当な発信者からの607で拒否された通話の場合、607応答コードを受信すると、発信者にユーザーの呼び出しを停止するよう通知できます。さらに、正当な発信者がユーザーが誤って通話を拒否していると確信した場合、他のチャネルを使用してユーザーに連絡することができます。たとえば、薬局が処方箋が集荷に利用できることを知らせるためにユーザーに電話をかけ、ユーザーが誤って電話が不要であると考えて607応答コードを発行した場合、顧客との既存の関係を持つ薬局はユーザーを送信できます。メールまたは薬剤師にメモをプッシュして、今後電話を拒否しないことを検討するようにお客様に依頼します。
Many systems that allow the user to mark the call unwanted (e.g., with the 607 response code) also allow the user to change their mind and unmark such calls. This mechanism is relatively easy to implement as the user usually has a direct relationship with the service provider that is blocking calls.
ユーザーが（607応答コードなどを使用して）通話に不要のマークを付けることができる多くのシステムでは、ユーザーが気が変わってそのような通話のマークを外すこともできます。ユーザーは通常、呼び出しをブロックしているサービスプロバイダーと直接的な関係があるため、このメカニズムは比較的簡単に実装できます。
However, things become more complicated if an intermediary, such as a third-party provider of call management services that classifies calls based on the relative likelihood that the call is unwanted, misidentifies the call as unwanted. Figure 3 shows this case. Note that the UAS typically does not receive an INVITE since the called party proxy rejects the call on behalf of the user. In this situation, it would be beneficial for the caller to learn who rejected the call so they can correct the misidentification.
ただし、通話が不要であるという相対的な可能性に基づいて通話を分類する通話管理サービスのサードパーティプロバイダーなどの仲介者が通話を不要であると誤認すると、事態はさらに複雑になります。図3はこのケースを示しています。着信側プロキシはユーザーに代わって呼び出しを拒否するため、UASは通常INVITEを受信しないことに注意してください。この状況では、誤認を修正できるように、発信者が誰が通話を拒否したかを知ることが有益です。
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
Figure 2: Unwanted (607) Ladder Diagram
図2：不要な（607）ラダー図
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 608 | Called | +-----+
| UAC | <--------- | Party | | UAS |
+-----+ | Proxy | +-----+
+-----------+
Figure 3: Rejected (608) Call Flow
図3：拒否された（608）コールフロー
In this situation, one might consider having the intermediary use the 607 response code. 607 indicates to the caller that the subscriber does not want the call. However, [RFC8197] specifies that one of the uses of 607 is to inform analytics engines that a user (human) has rejected a call. The problem here is that network elements downstream from the intermediary might interpret the 607 as coming from a user (human) who has marked the call as unwanted, as opposed to coming from an algorithm using statistics or machine learning to reject the call. An algorithm can be vulnerable to the base-rate fallacy [BaseRate] rejecting the call. In other words, those downstream entities should not rely on another entity "deciding" the call is unwanted. By distinguishing between a (human) user rejection and an intermediary engine's statistical rejection, a downstream network element that sees a 607 response code can weigh it as a human rejection in its call analytics, versus deciding whether to consider a 608 at all, and if so, weighing it appropriately.
この状況では、仲介者に607応答コードを使用させることを検討できます。 ６０７は、加入者が呼を望まないことを発呼者に示す。ただし、[RFC8197]は、607の使用の1つが分析エンジンにユーザー（人間）が通話を拒否したことを通知することであると規定しています。ここでの問題は、統計または機械学習を使用して呼び出しを拒否するアルゴリズムからではなく、中間の下流のネットワーク要素が607を、呼び出しを不要としてマークしたユーザー（人間）からのものとして解釈する可能性があることです。アルゴリズムは、コールを拒否する基本レートの誤り[BaseRate]に対して脆弱である可能性があります。言い換えると、それらのダウンストリームエンティティは、コールが不要であると「決定」する別のエンティティに依存すべきではありません。 （人間の）ユーザー拒否と中間エンジンの統計的拒否を区別することにより、607応答コードを確認するダウンストリームネットワーク要素は、コール分析で人間の拒否と比較して、608を検討するかどうかを決定するかどうか、およびしたがって、適切に計量します。
It is useful for blocked callers to have a redress mechanism. One can imagine that some jurisdictions will require it. However, we must be mindful that most of the calls that intermediaries block will, in fact, be illegal and eligible for blocking. Thus, providing alternate contact information for a user would be counterproductive to protecting that user from illegal communications. This is another reason we do not propose to simply allow alternate contact information in a 607 response message.
ブロックされた発信者が救済メカニズムを備えていると便利です。一部の法域ではそれが必要になると想像できます。ただし、仲介者がブロックするほとんどの呼び出しは、実際には違法であり、ブロックの対象となることに注意する必要があります。したがって、ユーザーに代替の連絡先情報を提供することは、そのユーザーを違法な通信から保護する逆効果となります。これは、607応答メッセージで代替連絡先情報を単に許可することを提案しないもう1つの理由です。
Why do we not use the same mechanism an analytics service provider offers their customers? Specifically, why not have the analytics service provider allow the called party to correct a call blocked in error? The reason is that while there is an existing relationship between the customer (called party) and the analytics service provider, it is unlikely there is a relationship between the caller and the analytics service provider. Moreover, there are numerous call blocking providers in the ecosystem. Therefore, we need a mechanism for indicating an intermediary rejected a call that also provides contact information for the operator of that intermediary without exposing the target user's contact information.
分析サービスプロバイダーが顧客に提供するのと同じメカニズムを使用しないのはなぜですか？具体的には、分析サービスプロバイダーに、被呼者が誤ってブロックされた通話を修正することを許可しないようにしてください。その理由は、顧客（着信側）と分析サービスプロバイダーの間に既存の関係はありますが、呼び出し元と分析サービスプロバイダーの間に関係がある可能性は低いからです。さらに、エコシステムには多数のコールブロッキングプロバイダーがあります。したがって、対象ユーザーの連絡先情報を公開せずに、仲介者のオペレーターに連絡先情報も提供する、仲介者が通話を拒否したことを示すメカニズムが必要です。
The protocol described in this document uses existing SIP protocol mechanisms for specifying the redress mechanism. In the Call-Info header field passed back to the UAC, we send additional information specifying a redress address. We choose to encode the redress address using jCard [RFC7095]. As we will see later in this document, this information needs to have its own application-layer integrity protection. Thus, we use jCard rather than vCard [RFC6350], as we have a marshaling mechanism for creating a JavaScript Object Notation (JSON) [RFC8259] object, such as a jCard, and a standard integrity format for such an object, namely, JSON Web Signature (JWS) [RFC7515]. The SIP community is familiar with this concept as it is the mechanism used by STIR [RFC8224].
このドキュメントで説明するプロトコルは、既存のSIPプロトコルメカニズムを使用して、救済メカニズムを指定します。 UACに返されるCall-Infoヘッダーフィールドで、アドレスを指定する追加情報を送信します。 jCard [RFC7095]を使用して、アドレスをエンコードすることを選択します。このドキュメントの後半で説明するように、この情報には独自のアプリケーション層の整合性保護が必要です。したがって、jCardなどのJavaScript Object Notation（JSON）[RFC8259]オブジェクトを作成するためのマーシャリングメカニズムと、そのようなオブジェクトの標準整合性形式であるJSONがあるため、vCard [RFC6350]ではなくjCardを使用します。 Web署名（JWS）[RFC7515]。 SIPコミュニティはSTIR [RFC8224]で使用されるメカニズムであるため、この概念に精通しています。
Integrity protecting the jCard with a cryptographic signature might seem unnecessary at first, but it is essential to preventing potential network attacks. Section 6 describes the attack and why we sign the jCard in more detail.
暗号署名でjCardを完全に保護することは、最初は不必要に思えるかもしれませんが、潜在的なネットワーク攻撃を防ぐために不可欠です。セクション6では、攻撃と、jCardに署名する理由について詳しく説明します。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section uses the term "intermediary" to mean the entity that acts as a SIP UAS on behalf of the user in the network as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy.
このセクションでは、「仲介者」という用語を使用して、ユーザーのUAS（通常は、必ずしもそうではないが、電話）ではなく、ネットワーク内のユーザーに代わってSIP UASとして機能するエンティティを意味します。仲介者は、連続したユーザーエージェント（B2BUA）またはSIPプロキシである可能性があります。
Figure 4 shows an overview of the call flow for a rejected call.
図4は、拒否されたコールのコールフローの概要を示しています。
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
Figure 4: Rejected (608) Ladder Diagram
図4：拒否された（608）ラダー図
An intermediary MAY issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP [RFC3261] request to indicate that an intermediary rejected the offered communication as unwanted by the user. An intermediary MAY issue the 608 as the value of the "cause" parameter of a SIP reason-value in a Reason header field [RFC3326].
仲介者は、INVITE、MESSAGE、SUBSCRIBE、またはその他のダイアログ外SIP [RFC3261]要求の失敗応答で608応答コードを発行して、仲介者が提供された通信をユーザーが望まないものとして拒否したことを示してもよい（MAY）。仲介者は、理由ヘッダーフィールド[RFC3326]のSIP理由値の「原因」パラメータの値として608を発行してもよい（MAY）。
If an intermediary issues a 608 code and there are no indicators the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), the intermediary MUST include a Call-Info header field in the response.
仲介者が608コードを発行し、発呼者がCall-Infoヘッダーフィールドの内容を悪意のある目的で使用するインジケーターがない場合（セクション6を参照）、仲介者は応答にCall-Infoヘッダーフィールドを含める必要があります。
If there is a Call-Info header field, it MUST have the "purpose" parameter of "jwscard". The value of the Call-Info header field MUST refer to a valid JSON Web Signature (JWS) [RFC7515] encoding of a jCard [RFC7095] object. The following section describes the construction of the JWS.
Call-Infoヘッダーフィールドがある場合は、「jwscard」の「purpose」パラメーターが必要です。 Call-Infoヘッダーフィールドの値は、jCard [RFC7095]オブジェクトの有効なJSON Web Signature（JWS）[RFC7515]エンコーディングを参照する必要があります。次のセクションでは、JWSの構造について説明します。
Proxies need to be mindful that a downstream intermediary may reject the attempt with a 608 while other paths may still be in progress. In this situation, the requirements stated in Section 16.7 of [RFC3261] apply. Specifically, the proxy should cancel pending transactions and must not create any new branches. Note this is not a new requirement but simply pointing out the existing 6xx protocol mechanism in SIP.
プロキシは、ダウンストリームの仲介者が608での試行を拒否する一方で、他のパスがまだ進行中である可能性があることに注意する必要があります。この状況では、[RFC3261]のセクション16.7に記載されている要件が適用されます。具体的には、プロキシは保留中のトランザクションをキャンセルし、新しいブランチを作成してはなりません。これは新しい要件ではなく、SIPの既存の6xxプロトコルメカニズムを指摘するだけであることに注意してください。
The intermediary constructs the JWS of the jCard as follows.
仲介者は、jCardのJWSを次のように構築します。
The Javascript Object Signing and Encryption (JOSE) header MUST include the typ, alg, and x5u parameters from JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". Implementations MUST support ES256 as JSON Web Algorithms (JWA) [RFC7518] defines it and MAY support other registered signature algorithms. Finally, the x5u parameter MUST be a URI that resolves to the public key certificate corresponding to the key used to digitally sign the JWS.
JavaScript Object Signing and Encryption（JOSE）ヘッダーには、JWS [RFC7515]のtyp、alg、およびx5uパラメータを含める必要があります。 typパラメータの値は「vcard + json」でなければなりません。 JSON Web Algorithms（JWA）[RFC7518]はそれを定義し、他の登録済み署名アルゴリズムをサポートしてもよい（MAY）ので、実装はES256をサポートする必要があります。最後に、x5uパラメータは、JWSのデジタル署名に使用されるキーに対応する公開キー証明書に解決されるURIである必要があります。
The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST be present is the "iat" (issued at) claim [RFC7519]. The "iat" MUST be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks.
ペイロードには2つのJSON値が含まれています。存在しなければならない最初のJSON Web Token（JWT）クレームは、「iat」（発行場所）クレーム[RFC7519]です。 「iat」は、608応答の発行日時に設定する必要があります。この必須コンポーネントは、応答をリプレイ攻撃から保護します。
The second JWT claim that MUST be present is the "jcard" claim. The value of the jcard [RFC7095] claim is a JSON array conforming to the JSON jCard data format defined in [RFC7095]. Section 5.3 describes the registration. In the construction of the jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this specification MUST be prepared to receive a full jCard. Call originators (at the UAC) can use the information returned by the jCard to contact the intermediary that rejected the call to appeal the intermediary's blocking of the call attempt. What the intermediary does if the blocked caller contacts the intermediary is outside the scope of this document.
存在しなければならない2番目のJWTクレームは、「jcard」クレームです。 jcard [RFC7095]クレームの値は、[RFC7095]で定義されているJSON jCardデータ形式に準拠したJSON配列です。セクション5.3では、登録について説明します。 jcardクレームの構成では、「jcard」にURL、EMAIL、TEL、またはADRプロパティの少なくとも1つを含める必要があります。この仕様をサポートするUACは、完全なjCardを受け取る準備ができている必要があります。 （UACの）通話の発信者は、jCardから返された情報を使用して、通話を拒否した仲介者に連絡し、仲介者による通話の試みのブロックをアピールできます。ブロックされた発信者が仲介者に連絡した場合の仲介者の処理は、このドキュメントの範囲外です。
JWS [RFC7515] specifies the procedure for calculating the signature over the jCard JWT. Section 4 of this document has a detailed example on constructing the JWS, including the signature.
JWS [RFC7515]は、jCard JWTで署名を計算する手順を指定します。このドキュメントのセクション4には、署名を含む、JWSの構築に関する詳細な例があります。
A UAC conforming to this specification MUST include the sip.608 feature-capability indicator in the Feature-Caps header field of the INVITE request.
この仕様に準拠するUACは、INVITE要求のFeature-Capsヘッダーフィールドにsip.608機能能力インジケーターを含める必要があります。
Upon receiving a 608 response, UACs perform normal SIP processing for 6xx responses.
UACは608応答を受信すると、6xx応答に対して通常のSIP処理を実行します。
As for the disposition of the jCard itself, the UAC MUST check the "iat" claim in the JWT. As noted in Section 3.2.2, we are concerned about replay attacks. Therefore, the UAC MUST reject jCards that come with an expired "iat". The definition of "expired" is a matter of local policy. A reasonable value would be on the order of a minute due to clock drift and the possibility of the playing of an audio announcement before the delivery of the 608 response.
jCard自体の処理については、UACはJWTの「iat」クレームをチェックする必要があります。セクション3.2.2で述べたように、私たちはリプレイ攻撃を懸念しています。したがって、UACは「iat」が期限切れのjCardを拒否する必要があります。 「期限切れ」の定義は、ローカルポリシーの問題です。クロックドリフトと608応答の配信前に音声アナウンスが再生される可能性があるため、妥当な値は1分程度です。
If the UAC indicates support for 608 and the intermediary issues a 608, life is good, as the UAC will receive all the information it needs to remediate an erroneous block by an intermediary. However, what if the UAC does not understand 608? For example, how can we support callers from a legacy, non-SIP, public-switched network connecting to the SIP network via a media gateway?
UACが608のサポートを示し、仲介者が608を発行する場合、UACは仲介者が誤ったブロックを修正するために必要なすべての情報を受け取るため、良好です。ただし、UACが608を理解しない場合はどうなりますか？たとえば、メディアゲートウェイを介してSIPネットワークに接続している、レガシーの非SIPパブリックスイッチドネットワークからの発信者をどのようにサポートできますか？
We address this situation by having the first network element that conforms with this specification play an announcement. See Section 3.5 for requirements on the announcement. The simple rule is a network element that inserts the sip.608 feature capability MUST be able to convey at a minimum how to contact the operator of the intermediary that rejected the call attempt.
この状況に対処するには、この仕様に準拠する最初のネットワーク要素でアナウンスを再生します。発表の要件については、セクション3.5を参照してください。単純なルールは、sip.608機能を挿入するネットワーク要素です。機能は、コールの試行を拒否した仲介者のオペレーターに連絡する方法を最低限伝達できる必要があります。
The degenerate case is the intermediary is the only element that understands the semantics of the 608 response code. Obviously, any SIP device will understand that a 608 response code is a 6xx error. However, there are no other elements in the call path that understand the meaning of the value of the Call-Info header field. The intermediary knows this is the case as the INVITE request will not have the sip.608 feature capability. In this case, one can consider the intermediary to be the element "inserting" a virtual sip.608 feature capability. If the caveats described in Sections 3.5 and 6 do not hold, the intermediary MUST play the announcement.
縮退した場合は、中間が608応答コードのセマンティクスを理解する唯一の要素です。明らかに、どのSIPデバイスも608応答コードが6xxエラーであることを理解します。ただし、Call-Infoヘッダーフィールドの値の意味を理解する呼び出しパス内の他の要素はありません。 INVITEリクエストにはsip.608機能がないため、仲介者はこれを知っています。この場合、仲介者は仮想sip.608機能の機能を「挿入」する要素であると考えることができます。セクション3.5とセクション6で説明されている警告が満たされない場合、仲介者はアナウンスを再生する必要があります。
Now we take the case where a network element that understands the 608 response code receives an INVITE for further processing. A network element conforming with this specification MUST insert the sip.608 feature capability per the behaviors described in Section 4.2 of [RFC6809].
次に、608応答コードを理解するネットワーク要素が、さらなる処理のためにINVITEを受信した場合を取り上げます。この仕様に準拠するネットワーク要素は、[RFC6809]のセクション4.2で説明されている動作ごとにsip.608機能を挿入する必要があります。
Do note that even if a network element plays an announcement describing the contents of the 608 response message, the network element MUST forward the 608 response code message as the final response to the INVITE.
ネットワーク要素が608応答メッセージの内容を説明するアナウンスを再生する場合でも、ネットワーク要素は608応答コードメッセージをINVITEへの最終応答として転送する必要があることに注意してください。
One aspect of using a feature capability is that only the network elements that will either consume (UAC) or play an announcement (media gateway, session border controller (SBC) [RFC7092], or proxy) need to understand the sip.608 feature capability. If the other network elements conform to Section 16.6 of [RFC3261], they will pass header fields such as "Feature-Caps: *;+sip.608" unmodified and without need for upgrade.
機能を使用する1つの側面は、アナウンスを消費する（UAC）または再生する（メディアゲートウェイ、セッションボーダーコントローラー（SBC）[RFC7092]、またはプロキシ）ネットワーク要素のみがsip.608機能を理解する必要があることです。 。他のネットワーク要素は、[RFC3261]のセクション16.6に準拠している場合、「Feature-Caps：*; + sip.608」などのヘッダーフィールドを変更せずに、アップグレードの必要なしに渡します。
Because the ultimate disposition of the call attempt will be a 600-class response, the network element conveying the announcement in the legacy direction MUST use the 183 Session Progress response to establish the media session. Because of the small chance the UAC is an extremely old legacy device and is using UDP, the UAC MUST include support for 100rel [RFC3262] in its INVITE, the network element conveying the announcement MUST Require 100rel in the 183, and the UAC MUST issue a Provisional Response ACKnowledgement (PRACK) to which the network element MUST respond 200 OK PRACK.
コール試行の最終的な処理は600クラスの応答になるため、レガシー方向でアナウンスを伝達するネットワーク要素は、183セッションプログレス応答を使用してメディアセッションを確立する必要があります。 UACが非常に古いレガシーデバイスであり、UDPを使用している可能性が低いため、UACはそのINVITEに100rel [RFC3262]のサポートを含める必要があり、アナウンスを伝達するネットワーク要素は183で100relを要求する必要があり、UACは発行する必要がありますネットワーク要素が200 OK PRACKに応答する必要がある暫定応答確認（PRACK）。
There are a few requirements on the element that handles the announcement for legacy interoperation.
レガシー相互運用のアナウンスを処理する要素にはいくつかの要件があります。
As noted above, the element that inserts the sip.608 feature capability is responsible for conveying the information referenced by the Call-Info header field in the 608 response message. However, this specification does not mandate how to convey that information.
上記のように、sip.608機能機能を挿入する要素は、608応答メッセージのCall-Infoヘッダーフィールドによって参照される情報を伝達する責任があります。ただし、この仕様はその情報を伝える方法を義務付けていません。
Let us take the case where a telecommunications service provider controls the element inserting the sip.608 feature capability. It would be reasonable to expect the service provider would play an announcement in the media path towards the UAC (caller). It is important to note the network element should be mindful of the media type requested by the UAC as it formulates the announcement. For example, it would make sense for an INVITE that only indicated audio codecs in the Session Description Protocol (SDP) [RFC4566] to result in an audio announcement. Likewise, if the INVITE only indicated real-time text [RFC4103] and the network element can render the information in the requested media format, the network element should send the information in a text format.
電気通信サービスプロバイダーがsip.608機能を挿入する要素を制御する場合を考えてみましょう。サービスプロバイダーがUAC（発信者）へのメディアパスでアナウンスを再生することを期待することは合理的です。ネットワーク要素は、UACがアナウンスを作成するときに要求するメディアタイプに注意する必要があることに注意することが重要です。たとえば、セッション記述プロトコル（SDP）[RFC4566]でオーディオコーデックのみを示した結果、オーディオアナウンスが発生することは、INVITEにとって意味があります。同様に、INVITEがリアルタイムテキスト[RFC4103]のみを示し、ネットワーク要素が要求されたメディア形式で情報をレンダリングできる場合、ネットワーク要素は情報をテキスト形式で送信する必要があります。
It is also possible for the network element inserting the sip.608 feature capability to be under the control of the same entity that controls the UAC. For example, a large call center might have legacy UACs, but have a modern outbound calling proxy that understands the full semantics of the 608 response code. In this case, it is enough for the outbound calling proxy to digest the Call-Info information and handle the information digitally rather than "transcoding" the Call-Info information for presentation to the caller.
sip.608機能を挿入するネットワーク要素が、UACを制御する同じエンティティの制御下にあることも可能です。たとえば、大規模なコールセンターにはレガシーUACがありますが、608応答コードの完全なセマンティクスを理解する最新のアウトバウンドコーリングプロキシがあります。この場合、発信呼び出しプロキシがCall-Info情報をダイジェストし、発信者に提示するためにCall-Info情報を「トランスコード」するのではなく、デジタルで処理するだけで十分です。
These examples are not normative, do not include all protocol elements, and may have errors. Review the protocol documents for actual syntax and semantics of the protocol elements.
これらの例は規範的ではなく、すべてのプロトコル要素が含まれているわけではなく、エラーがある可能性があります。プロトコル要素の実際の構文とセマンティクスについては、プロトコルのドキュメントを確認してください。
Given an INVITE, shamelessly taken from [SHAKEN], with the line breaks in the Identity header field for display purposes only:
[SHAKEN]から恥ずかしげなく取り上げられたINVITEが、表示のみを目的としてIdentityヘッダーフィールドで改行されているとします。
INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69
Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3>
To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155550112>
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153
v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv
An intermediary could reply:
仲介者は返信できます：
SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
The location https://block.example.net/complaint-jws resolves to a JWS. One would construct the JWS as follows.
ロケーションhttps://block.example.net/complaint-jwsはJWSに解決されます。 JWSは次のように構築します。
The JWS header of this example jCard could be:
このサンプルjCardのJWSヘッダーは次のようになります。
{ "alg":"ES256",
"typ":"vcard+json",
"x5u":"https://certs.example.net/reject_key.cer"
}
Now, let us construct a minimal jCard. For this example, the jCard refers the caller to an email address, remediation@blocker.example.net:
次に、最小限のjCardを作成します。この例では、jCardは発信者にメールアドレスremediation@blocker.example.netを参照します。
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, "text",
"remediation@blocker.example.net"]
]
]
With this jCard, we can now construct the JWT:
このjCardを使用して、JWTを作成できます。
{
"iat":1546008698,
"jcard":["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"},
"text", "remediation@blocker.example.net"]
]
]
}
To calculate the signature, we need to encode the JSON Object Signing and Encryption (JOSE) header and JWT into base64url. As an implementation note, one can trim whitespace in the JSON objects to save a few bytes. UACs MUST be prepared to receive pretty-printed, compact, or bizarrely formatted JSON. For the purposes of this example, we leave the objects with pretty whitespace. Speaking of pretty vs. machine formatting, these examples have line breaks in the base64url encodings for ease of publication in the RFC format. The specification of base64url allows for these line breaks, and the decoded text works just fine. However, those extra line-break octets would affect the calculation of the signature. Implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info header field.
署名を計算するには、JSON Object Signing and Encryption（JOSE）ヘッダーとJWTをbase64urlにエンコードする必要があります。実装上の注意として、JSONオブジェクトの空白を削除して数バイトを節約できます。 UACは、きれいに印刷された、コンパクトな、または奇妙な形式のJSONを受信できるように準備する必要があります。この例では、オブジェクトにかなりの空白を残しています。きれいなフォーマットとマシンのフォーマットについて言えば、これらの例では、RFCフォーマットでの公開を容易にするために、base64urlエンコーディングに改行を入れています。 base64urlの指定により、これらの改行が可能になり、デコードされたテキストは問題なく機能します。ただし、これらの余分な改行オクテットは、署名の計算に影響します。実装は、JOSEヘッダーまたはJWTのbase64urlエンコーディングに改行を挿入してはなりません（MUST NOT）。これは、UACがCall-Infoヘッダーフィールドによって参照されるURIから任意の長いオクテットストリームを受信する準備ができている必要があることも意味します。
base64url of JOSE header:
JOSEヘッダーのbase64url：
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0 =
base64url of JWT:
JWTのbase64url：
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
In this case, the object to sign (remembering this is just a single long line; the line breaks are for ease of review but do not appear in the actual object) is as follows:
この場合、署名するオブジェクト（これは単一の長い行であることを思い出してください。改行は見やすくするためですが、実際のオブジェクトには表示されません）は次のとおりです。
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
We use the following X.509 PKCS #8-encoded Elliptic Curve Digital Signature Algorithm (ECDSA) key, also shamelessly taken from [SHAKEN], as an example key for signing the hash of the above text. Do NOT use this key in real life! It is for example purposes only. At the very least, we would strongly recommend encrypting the key at rest.
上記のテキストのハッシュに署名するためのキーの例として、次のX.509 PKCS＃8でエンコードされた楕円曲線デジタル署名アルゴリズム（ECDSA）キーを使用します。このキーは実際には使用しないでください。これは単なる例です。少なくとも、保存されているキーを暗号化することを強くお勧めします。
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----
The resulting JWS, using the above key on the above object, renders the following ECDSA P-256 SHA-256 digital signature.
結果のJWSは、上記のオブジェクトの上記のキーを使用して、次のECDSA P-256 SHA-256デジタル署名をレンダリングします。
7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
Thus, the JWS stored at https://blocker.example.net/complaints-jws would contain:
したがって、https：//blocker.example.net/complaints-jwsに格納されているJWSには以下が含まれます。
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6 g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6 g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
For an intermediary that provides a Web site for adjudication, the jCard could contain the following. Note that we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard.
裁決のためのWebサイトを提供する仲介者の場合、jCardには以下を含めることができます。 JWSの計算は示していないことに注意してください。 Call-InfoヘッダーフィールドのURI参照は、署名されたjCardのJWSになります。
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"]
]
]
For an intermediary that provides a telephone number and a postal address, the jCard could contain the following. Note that we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard.
電話番号と住所を提供する仲介者の場合、jCardには次のものが含まれます。 JWSの計算は示していないことに注意してください。 Call-InfoヘッダーフィールドのURI参照は、署名されたjCardのJWSになります。
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["adr", {"type":"work"}, "text",
["Argument Clinic",
"12 Main St","Anytown","AP","000000","Somecountry"]
]
["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"]
]
]
Note that it is up to the UAC to decide which jCard contact modality, if any, it will use.
どのjCard連絡先モダリティを使用するかは、UACが決定することに注意してください。
Figure 5 depicts a call flow illustrating legacy interoperability. In this non-normative example, we see a UAC that does not support the full semantics for 608. However, there is an SBC that does support 608. Per [RFC6809], the SBC can insert "*;+sip.608" into the Feature-Caps header field for the INVITE. When the intermediary, labeled "Called Party Proxy" in the figure, rejects the call, it knows it can simply perform the processing described in this document. Since the intermediary saw the sip.608 feature capability, it knows it does not need to send any media describing whom to contact in the event of an erroneous rejection. For illustrative purposes, the figure shows generic SIP Proxies in the flow. Their presence or absence or the number of proxies is not relevant to the operation of the protocol. They are in the figure to show that proxies that do not understand the sip.608 feature capability can still participate in a network offering 608 services.
図5は、従来の相互運用性を示すコールフローを示しています。この非規範的な例では、608の完全なセマンティクスをサポートしないUACが表示されます。ただし、608をサポートするSBCがあります。[RFC6809]に従って、SBCは「*; + sip.608」をINVITEのFeature-Capsヘッダーフィールド。仲介者は、図で「Called Party Proxy」と表示されている場合、コールを拒否すると、このドキュメントで説明されている処理を簡単に実行できることがわかります。仲介者はsip.608機能を確認したため、誤った拒否があった場合に連絡先を説明するメディアを送信する必要がないことがわかります。説明のために、この図はフロー内の一般的なSIPプロキシを示しています。それらの有無、またはプロキシの数は、プロトコルの操作には関係ありません。これらは図にあり、sip.608機能を理解しないプロキシでも、608サービスを提供するネットワークに参加できることを示しています。
+---------+
| Call |
|Analytics|
| Engine |
+--+--+---+
^ |
| |
| v
+-+--+-+
+---+ +-----+ +---+ +-----+ +-----+ |Called|
|UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party |
+---+ +-----+ +---+ +-----+ +-----+ |Proxy |
| | +------+
| INVITE | |
|------------------>| |
| | INVITE |
| |------------------------------>|
| | Feature-Caps: *;+sip.608 |
| | |
| | 608 Rejected |
| |<------------------------------|
| 183 | Call-Info: <...> |
|<------------------| [path for Call-Info elided |
| SDP for media | for illustration purposes]|
| | |
| PRACK | |
|------------------>| |
| | |
| 200 OK PRACK | |
|<------------------| |
| | |
|<== Announcement ==| |
| | |
| 608 Rejected | |
|<------------------| |
| Call-Info: <...> | |
| | |
Figure 5: Legacy Operation
図5：従来の操作
When the SBC receives the 608 response code, it correlates that with the original INVITE from the UAC. The SBC remembers that it inserted the sip.608 feature capability, which means it is responsible for somehow alerting the UAC the call failed and disclosing whom to contact. At this point, the SBC can play a prompt, either natively or through a mechanism such as NETANN [RFC4240], that sends the relevant information in the appropriate media to the UAC. Since this is a potentially long transaction and there is a chance the UAC is using an unreliable transport protocol, the UAC will have indicated support for provisional responses, the SBC will indicate it requires a PRACK from the UAC in the 183 response, the UAC will provide the PRACK, and the SBC will acknowledge receipt of the PRACK before playing the announcement.
SBCが608応答コードを受信すると、UACからの元のINVITEと相関します。 SBCは、sip.608機能を挿入したことを記憶しています。つまり、UACにコールが失敗したことを警告し、連絡先を開示する責任があります。この時点で、SBCは、ネイティブまたはNETANN [RFC4240]などのメカニズムを介して、適切なメディアの関連情報をUACに送信するプロンプトを再生できます。これは潜在的に長いトランザクションであり、UACが信頼できないトランスポートプロトコルを使用している可能性があるため、UACは暫定応答のサポートを示し、SBCは183応答でUACからのPRACKが必要であることを示し、UACはPRACKを提供すると、SBCはアナウンスを再生する前にPRACKの受信を確認します。
As an example, the SBC could extract the FN and TEL jCard fields and play something like a special information tone (see Section 6.21.2.1 of Telcordia [SR-2275] or Section 7 of ITU-T E.180 [ITU.E.180.1998]), followed by "Your call has been rejected by...", followed by a text-to-speech translation of the FN text, followed by "You can reach them on...", followed by a text-to-speech translation of the telephone number in the TEL field.
例として、SBCはFNおよびTEL jCardフィールドを抽出し、特別な情報トーンのようなものを再生できます（Telcordiaのセクション6.21.2.1 [SR-2275]またはITU-T E.180のセクション7を参照してください[ITU.E. 180.1998]）、続いて「あなたの通話は...によって拒否されました」、FNテキストの音声合成、続いて「それらに到達できます...」、その後にテキストTELフィールドの電話番号の音声変換。
Note that the SBC also still sends the full 608 response code, including the Call-Info header field, towards the UAC.
SBCは、Call-Infoヘッダーフィールドを含む完全な608応答コードもUACに送信することに注意してください。
This document defines a new SIP response code, 608, in the "Response Codes" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry defined in [RFC3261].
このドキュメントでは、[RFC3261]で定義されている「Session Initiation Protocol（SIP）Parameters」レジストリの「Response Codes」サブレジストリで、新しいSIP応答コード608を定義しています。
Response code: 608 Description: Rejected Reference: RFC 8688
応答コード：608説明：拒否された参照：RFC 8688
This document defines the feature capability, sip.608, in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809].
このドキュメントでは、[RFC6809]で定義されている「SIP Feature-Capability Indicator Registration Tree」レジストリで機能機能sip.608を定義しています。
Name: sip.608 Description: This feature-capability indicator, when included in a Feature-Caps header field of an INVITE request, indicates that the entity associated with the indicator will be responsible for indicating to the caller any information contained in the 608 SIP response code, specifically, the value referenced by the Call-Info header field. Reference: RFC 8688
名前：sip.608説明：この機能機能インジケーターは、INVITEリクエストのFeature-Capsヘッダーフィールドに含まれている場合、インジケーターに関連付けられたエンティティが608 SIPに含まれる情報を発信者に示す責任があることを示します。応答コード、具体的には、Call-Infoヘッダーフィールドによって参照される値。リファレンス：RFC 8688
This document defines the new JSON Web Token claim in the "JSON Web Token Claims" subregistry created by [RFC7519]. Section 3.2.2 defines the syntax. The required information is:
このドキュメントは、[RFC7519]によって作成された「JSON Web Token Claims」サブレジストリで新しいJSON Web Tokenクレームを定義します。セクション3.2.2は構文を定義します。必要な情報は次のとおりです。
Claim Name: jcard Claim Description: jCard data Change Controller: IESG Reference: RFC 8688, [RFC7095]
クレーム名：jcardクレーム説明：jCardデータ変更コントローラー：IESGリファレンス：RFC 8688、[RFC7095]
This document defines the new predefined value "jwscard" for the "purpose" header field parameter of the Call-Info header field. This modifies the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry by adding this RFC as a reference to the line for the header field "Call-Info" and parameter name "purpose":
このドキュメントでは、Call-Infoヘッダーフィールドの「purpose」ヘッダーフィールドパラメータの新しい事前定義値「jwscard」を定義しています。これにより、ヘッダーフィールド「Call-Info」およびパラメーター名「purpose」の行への参照としてこのRFCを追加することにより、「Session Initiation Protocol（SIP）Parameters」レジストリの「Header Field Parameters and Parameter Values」サブレジストリが変更されます。
Header Field: Call-Info Parameter Name: purpose Predefined Values: Yes Reference: RFC 8688
ヘッダーフィールド：Call-Infoパラメーター名：目的定義済みの値：はい参照：RFC 8688
Intermediary operators need to be mindful to whom they are sending the 608 response. The intermediary could be rejecting a truly malicious caller. This raises two issues. The first is the caller, now alerted that an intermediary is automatically rejecting their call attempts, may change their call behavior to defeat call-blocking systems. The second, and more significant risk, is that by providing a contact in the Call-Info header field, the intermediary may be giving the malicious caller a vector for attack. In other words, the intermediary will be publishing an address that a malicious actor may use to launch an attack on the intermediary. Because of this, intermediary operators may wish to configure their response to only include a Call-Info header field for INVITE, or other signed initiating methods, that pass validation by STIR [RFC8224].
仲介業者は、608応答を送信する相手に注意する必要があります。仲介者が本当に悪意のある発信者を拒否している可能性があります。これには2つの問題があります。 1つ目は発信者です。仲介者が自動的に通話を拒否しているため、通話の動作が変更されて通話ブロックシステムが無効になる可能性があることが警告されています。 2番目の、より重大なリスクは、Call-Infoヘッダーフィールドに連絡先を提供することにより、仲介者が悪意のある発信者に攻撃のベクトルを提供する可能性があることです。つまり、仲介者は、悪意のある俳優が仲介者への攻撃を開始するために使用する可能性があるアドレスを公開します。このため、中間オペレーターは、STIR [RFC8224]による検証に合格するINVITEまたはその他の署名された開始メソッドのCall-Infoヘッダーフィールドのみを含めるように応答を構成する場合があります。
Another risk is as follows. Consider an attacker that floods a proxy that supports the sip.608 feature. However, the SDP in the INVITE request refers to a victim device. Moreover, the attacker somehow knows there is a 608-aware gateway connecting to the victim who is on a segment that lacks the sip.608 feature capability. Because the mechanism described here can result in sending an audio file to the target of the SDP, an attacker could use the mechanism described by this document as an amplification attack, given a SIP INVITE can be under 1 kilobyte and an audio file can be hundreds of kilobytes. One remediation for this is for devices that insert a sip.608 feature capability to only transmit media to what is highly likely to be the actual source of the call attempt. A method for this is to only play media in response to a STIR-signed INVITE that passes validation. Beyond requiring a valid STIR signature on the INVITE, the intermediary can also use remediation procedures such as doing the connectivity checks specified by Interactive Connectivity Establishment [RFC8445]. If the target did not request the media, the check will fail.
別のリスクは次のとおりです。 sip.608機能をサポートするプロキシをフラッディングする攻撃者を考えます。ただし、INVITE要求のSDPは、被害者のデバイスを指します。さらに、攻撃者は、sip.608機能を持たないセグメント上にいる被害者に接続する608対応ゲートウェイがあることをどういうわけか知っています。ここで説明するメカニズムはオーディオファイルをSDPのターゲットに送信する可能性があるため、SIP INVITEが1キロバイト未満で、オーディオファイルが数百になる可能性がある場合、攻撃者はこのドキュメントで説明されているメカニズムを増幅攻撃として使用する可能性があります。キロバイトの。このための1つの修正は、コール試行の実際のソースである可能性が非常に高いメディアにのみメディアを送信するsip.608機能を挿入するデバイス用です。このための方法は、検証に合格したSTIR署名付きINVITEに応答してのみメディアを再生することです。 INVITEで有効なSTIR署名を要求するだけでなく、仲介者は、Interactive Connectivity Establishment [RFC8445]で指定されている接続チェックを行うなどの修復手順を使用することもできます。ターゲットがメディアを要求しなかった場合、チェックは失敗します。
Yet another risk is a malicious intermediary that generates a malicious 608 response with a jCard referring to a malicious agent. For example, the recipient of a 608 may receive a TEL URI in the vCard. When the recipient calls that address, the malicious agent could ask for personally identifying information. However, instead of using that information to verify the recipient's identity, they are phishing the information for nefarious ends. A similar scenario can unfold if the malicious agent inserts a URI that points to a phishing or other site. As such, we strongly recommend the recipient validates to whom they are communicating with if asking to adjudicate an erroneously rejected call attempt. Since we may also be concerned about intermediate nodes modifying contact information, we can address both issues with a single solution. The remediation is to require the intermediary to sign the jCard. Signing the jCard provides integrity protection. In addition, one can imagine mechanisms such as used by [SHAKEN].
さらに別のリスクは、悪意のあるエージェントを参照するjCardで悪意のある608応答を生成する悪意のある仲介者です。たとえば、608の受信者は、vCardでTEL URIを受信できます。受信者がそのアドレスを呼び出すと、悪意のあるエージェントが個人を特定する情報を要求する可能性があります。ただし、その情報を使用して受信者の身元を確認する代わりに、悪意のある目的で情報をフィッシングしています。悪意のあるエージェントがフィッシングやその他のサイトを指すURIを挿入した場合にも、同様のシナリオが発生する可能性があります。そのため、誤って拒否された通話の試みについて裁定を求める場合は、受信者が通信相手を確認することを強くお勧めします。中間ノードが連絡先情報を変更することについても懸念があるため、1つのソリューションで両方の問題に対処できます。是正策は、仲介者がjCardに署名することを要求することです。 jCardに署名すると、整合性が保護されます。また、[SHAKEN]で使われているようなメカニズムも想像できます。
Similarly, one can imagine an adverse agent that maliciously spoofs a 608 response with a victim's contact address to many active callers who may then all send redress requests to the specified address (the basis for a denial-of-service attack). The process would occur as follows: (1) a malicious agent senses INVITE requests from a variety of UACs and (2) spoofs 608 responses with an unsigned redress address before the intended receivers can respond, causing (3) the UACs to all contact the redress address at once. The jCard encoding allows the UAC to verify the blocking intermediary's identity before contacting the redress address. Specifically, because the sender signs the jCard, we can cryptographically trace the sender of the jCard. Given the protocol machinery of having a signature, one can apply local policy to decide whether to believe that the sender of the jCard represents the owner of the contact information found in the jCard. This guards against a malicious agent spoofing 608 responses.
同様に、悪意のあるエージェントが被害者の連絡先アドレスを含む608応答を悪意を持って多くのアクティブな発信者にスプーフィングして、すべてが指定のアドレス（サービス拒否攻撃の基礎）に救済要求を送信することを想像できます。プロセスは次のように発生します：（1）悪意のあるエージェントがさまざまなUACからのINVITEリクエストを検知し、（2）意図した受信者が応答する前に、署名されていないアドレスで608応答をスプーフし、（3）UACがすべてのすぐにアドレスを救済します。 jCardエンコーディングを使用すると、UACは、アドレスをリセットする前に、ブロックする仲介者のIDを確認できます。具体的には、送信者がjCardに署名するため、jCardの送信者を暗号で追跡できます。署名を持つプロトコル機構を前提として、ローカルポリシーを適用して、jCardの送信者がjCardにある連絡先情報の所有者であると信じるかどうかを決定できます。これは、608応答をスプーフィングする悪意のあるエージェントから保護します。
Specifically, one could use policies around signing certificate issuance as a mechanism for traceback to the entity issuing the jCard. One check could be verifying that the identity of the subject of the certificate relates to the To header field of the initial SIP request, similar to validating that the intermediary was vouching for the From header field of a SIP request with that identity. Note that we are only protecting against a malicious intermediary and not a hidden intermediary attack (formerly known as a "man-in-the-middle attack"). Thus, we only need to ensure the signature is fresh, which is why we include "iat". For most implementations, we assume that the intermediary has a single set of contact points and will generate the jCard on demand. As such, there is no need to directly correlate HTTPS fetches to specific calls. However, since the intermediary is in control of the jCard and Call-Info response, an intermediary may choose to encode per-call information in the URI returned in a given 608 response. However, if the intermediary does go that route, the intermediary MUST use a non-deterministic URI reference mechanism and be prepared to return dummy responses to URI requests referencing calls that do not exist so that attackers attempting to glean call metadata by guessing URIs (and thus calls) will not get any actionable information from the HTTPS GET.
具体的には、jCardを発行するエンティティへのトレースバックのメカニズムとして、証明書発行の署名に関するポリシーを使用できます。 1つのチェックでは、証明書のサブジェクトのIDが最初のSIP要求のToヘッダーフィールドに関連していることを確認できます。これは、仲介者がそのIDを持つSIP要求のFromヘッダーフィールドを保証していることを検証するのと同様です。悪意のある仲介者に対してのみ保護しており、隠れた仲介者の攻撃（以前は「中間者攻撃」と呼ばれていました）ではないことに注意してください。したがって、署名が新鮮であることを確認する必要があるだけなので、「iat」を含めます。ほとんどの実装では、仲介者が1組の接点を持ち、オンデマンドでjCardを生成すると想定しています。そのため、HTTPSフェッチを特定の呼び出しに直接関連付ける必要はありません。ただし、仲介者はjCardとCall-Info応答を制御しているため、仲介者は所定の608応答で返されたURIに呼び出しごとの情報をエンコードすることを選択できます。ただし、仲介者がそのルートをたどる場合、仲介者は非決定的なURI参照メカニズムを使用し、存在しない呼び出しを参照するURIリクエストにダミーの応答を返す準備ができているため、攻撃者はURIを推測して呼び出しメタデータを収集することができます（したがって、呼び出し）は、HTTPS GETから実用的な情報を取得しません。
Since the decision of whether to include Call-Info in the 608 response is a matter of policy, one thing to consider is whether a legitimate caller can ascertain whom to contact without including such information in the 608. For example, in some jurisdictions, if only the terminating service provider can be the intermediary, the caller can look up who the terminating service provider is based on the routing information for the dialed number. Thus, the Call-Info jCard could be redundant information. However, the factors going into a particular service provider's or jurisdiction's choice of whether to include Call-Info is outside the scope of this document.
Call-Infoを608応答に含めるかどうかの決定はポリシーの問題であるため、考慮すべき1つのことは、そのような情報を608に含めずに連絡先を確認できるかどうかです。たとえば、一部の管轄区域では、終端サービスプロバイダーのみが仲介者になることができます。発信者は、着信番号のルーティング情報に基づいて、終端サービスプロバイダーが誰であるかを検索できます。したがって、Call-Info jCardは冗長な情報になる可能性があります。ただし、Call-Infoを含めるかどうかの特定のサービスプロバイダーまたは管轄区域の選択に入る要素は、このドキュメントの範囲外です。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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：Session Initiation Protocol」 、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://www.rfc-editor.org/ info / rfc3262>。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <https://www.rfc-editor.org/info/rfc3326>.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487 / RFC3326、2002年12月、<https：// www .rfc-editor.org / info / rfc3326>。
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, <https://www.rfc-editor.org/info/rfc6809>.
[RFC6809] Holmberg、C.、Sedlacek、I。、およびH. Kaplan、「Session Initiation Protocol（SIP）の機能と機能のサポートを示すメカニズム」、RFC 6809、DOI 10.17487 / RFC6809、2012年11月、<https ：//www.rfc-editor.org/info/rfc6809>。
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>.
[RFC7095] Kewisch、P。、「jCard：The JSON Format for vCard」、RFC 7095、DOI 10.17487 / RFC7095、2014年1月、<https://www.rfc-editor.org/info/rfc7095>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518] Jones、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<https://www.rfc-editor.org/info/rfc7518>。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。
[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>。
[BaseRate] Bar-Hillel, M., "The Base-Rate Fallacy in Probability Judgements", April 1977, <https://apps.dtic.mil/docs/citations/ADA045772>.
[BaseRate] Bar-Hillel、M。、「Probability JudgementsのBase-Rate Fallacy」、1977年4月、<https://apps.dtic.mil/docs/citations/ADA045772>。
[ITU.E.180.1998] ITU-T, "Technical characteristics of tones for the telephone service", ITU-T Recommendation E.180/Q.35, March 1998.
[ITU.E.180.1998] ITU-T、「電話サービスのトーンの技術的特性」、ITU-T勧告E.180 / Q.35、1998年3月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, DOI 10.17487/RFC4240, December 2005, <https://www.rfc-editor.org/info/rfc4240>.
[RFC4240] Burger、E.、Ed。、Van Dyke、J。、およびA. Spitzer、「SIPを使用した基本的なネットワークメディアサービス」、RFC 4240、DOI 10.17487 / RFC4240、2005年12月、<https：//www.rfc -editor.org/info/rfc4240>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, January 2008, <https://www.rfc-editor.org/info/rfc5039>.
[RFC5039] Rosenberg、J。およびC. Jennings、「The Session Initiation Protocol（SIP）and Spam」、RFC 5039、DOI 10.17487 / RFC5039、2008年1月、<https://www.rfc-editor.org/info/ rfc5039>。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>.
[RFC6350] Perreault、S。、「vCard Format Specification」、RFC 6350、DOI 10.17487 / RFC6350、2011年8月、<https://www.rfc-editor.org/info/rfc6350>。
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <https://www.rfc-editor.org/info/rfc7092>.
[RFC7092] Kaplan、H。およびV. Pascual、「A Sessiononomy of Session Initiation Protocol（SIP）Back-to-Back User Agents」、RFC 7092、DOI 10.17487 / RFC7092、2013年12月、<https：//www.rfc -editor.org/info/rfc7092>。
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7340] Peterson、J.、Schulzrinne、H。、およびH. Tschofenig、「Secure Telephone Identity Problem Statement and Requirements」、RFC 7340、DOI 10.17487 / RFC7340、2014年9月、<https：//www.rfc-editor。 org / info / rfc7340>。
[RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", RFC 8197, DOI 10.17487/RFC8197, July 2017, <https://www.rfc-editor.org/info/rfc8197>.
[RFC8197] Schulzrinne、H。、「不要なコールのSIP応答コード」、RFC 8197、DOI 10.17487 / RFC8197、2017年7月、<https://www.rfc-editor.org/info/rfc8197>。
[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、「Session Initiation Protocol（SIP）での認証済みID管理」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<https ：//www.rfc-editor.org/info/rfc8224>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、< https://www.rfc-editor.org/info/rfc8445>。
[SHAKEN] ATIS/SIP Forum IP-INNI Task Group, "Signature-based Handling of Asserted information using toKENs (SHAKEN)", ATIS 1000074, January 2017, <https://www.sipforum.org/download/sip-forum-twg-10- signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813>.
[SHAKEN] ATIS / SIPフォーラムIP-INNIタスクグループ、「toKENを使用したアサートされた情報の署名ベースの処理（SHAKEN）」、ATIS 1000074、2017年1月、<https://www.sipforum.org/download/sip-forum -twg-10-アサートされた情報を使用した署名ベースの処理-tokens-shaken-pdf /？wpdmdl = 2813>。
[SR-2275] Telcordia, "Telcordia Notes on the Networks", Telcordia SR-2275, October 2000.
[SR-2275] Telcordia、「Telcordia Notes on the Networks」、Telcordia SR-2275、2000年10月。
Acknowledgements
謝辞
This document liberally lifts from [RFC8197] in its text and structure. However, the mechanism and purpose of 608 is quite different than 607. Any errors are the current editor's and not the editor of RFC 8197. Thanks also go to Ken Carlberg of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on improving the document. Tolga's suggestion to provide a mechanism for legacy interoperability served to expand the document by 50%. In addition, Tolga came up with the jCard attack. Finally, Christer Holmberg, as always, provided a close reading and fixed a SIP feature-capability bug found by Yehoshua Gev.
この文書は、そのテキストと構造において、[RFC8197]から自由に出てきます。ただし、608のメカニズムと目的は607とはかなり異なります。エラーは現在の編集者のものであり、RFC 8197の編集者ではありません。提案については、FCCのケンカールバーグ、ラスハウズリー、ポールキジバット、およびトルガアスヴェレンにも感謝します。ドキュメントの改善について。従来の相互運用性のメカニズムを提供するというTolgaの提案は、ドキュメントを50％拡大するのに役立ちました。さらに、TolgaはjCard攻撃を思いつきました。最後に、Christer Holmbergは、いつものように、詳細な資料を提供し、Yehoshua Gevによって発見されたSIP機能機能のバグを修正しました。
Of course, we appreciated the close read and five pages of comments from our estimable Area Director, Adam Roach. In addition, we received valuable comments during IETF Last Call and JWT review from Ines Robles, Mike Jones, and Brian Campbell, and IESG review from Alissa Cooper, Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most glee, Warren Kumari.
もちろん、エリアディレクターであるAdam Roachからの5頁のコメントと密接な読解に感謝しました。さらに、IEESのラストコールとJWTのレビュー中に、イネスロブレス、マイクジョーンズ、ブライアンキャンベルからIESGのレビュー中に貴重なコメントを受け取り、アリッサクーパー、エリックヴィンケ、アレクセイメルニコフ、ベンジャミンカドゥック、バリーレイバ、そして大喜びでWarrenからIESGレビューを受け取りました。クマリ。
Finally, Bhavik Nagda provided clarifying edits as well and, more especially, wrote and tested an implementation of the 608 response code in Kamailio. Code is available at https://github.com/ nagdab/608_Implementation. Grace Chuan from MIT regenerated and verified the JWT while working at the FCC.
最後に、Bhavik Nagdaは明確な編集も提供し、特に、Kamailioで608応答コードの実装を作成してテストしました。コードはhttps://github.com/ nagdab / 608_Implementationで入手できます。 MITのGrace Chuanは、FCCでの作業中にJWTを再生成および検証しました。
Authors' Addresses
著者のアドレス
Eric W. Burger Georgetown University 37th & O St, NW Washington, DC 20057 United States of America
エリックW.バーガージョージタウン大学37th＆O St、NWワシントンDC 20057アメリカ合衆国
Email: eburger@standardstrack.com
Bhavik Nagda Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 United States of America
Bhavik Nagdaマサチューセッツ工科大学77 Massachusetts Avenue Cambridge、MA 02139アメリカ合衆国
Email: nagdab@gmail.com