RFC 8197 - A SIP Response Code for Unwanted Calls 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8197
タイトル : RFC 8197 - 不要な通話のSIP応答コード
翻訳編集 : 自動生成

[要約] RFC 8197は、迷惑な電話に対するSIP応答コードを定義しています。その目的は、迷惑な電話を特定し、適切な応答を提供することです。

Internet Engineering Task Force (IETF)                    H. Schulzrinne
Request for Comments: 8197                                           FCC
Category: Standards Track                                      July 2017
ISSN: 2070-1721

A SIP Response Code for Unwanted Calls

不要な通話のSIP応答コード

Abstract

概要

This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

このドキュメントは607（Unwanted）SIP応答コードを定義し、着信側が通話またはメッセージが不要であることを示すことができます。 SIPエンティティは、この情報を使用して、この発呼者からの今後のコールが着信者に対して、またはより広く処理される方法を調整できます。

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 http://www.rfc-editor.org/info/rfc8197.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8197で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Normative Language  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Behavior of SIP Entities  . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  SIP Response Code . . . . . . . . . . . . . . . . . . . .   5
     5.2.  SIP Global Feature-Capability Indicator . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

In many countries, an increasing number of calls are unwanted [RFC5039]: they might be fraudulent or illegal telemarketing or maybe the receiving party does not want to be disturbed by, say, surveys or solicitation by charities. Carriers and other service providers may want to help their subscribers avoid receiving such calls, using a variety of global or user-specific filtering algorithms. One input into such algorithms is user feedback. User feedback may be offered through smartphone apps, APIs or within the context of a SIP-initiated call. This document addresses feedback within the SIP call. Here, the called party either rejects the SIP [RFC3261] request as unwanted or terminates the session with a BYE request after answering the call. INVITE and MESSAGE requests are most likely to trigger such a response.

多くの国では、電話の増加が望まれない[RFC5039]：詐欺的または違法なテレマーケティングであるか、受信者が、たとえば調査や慈善団体による勧誘に邪魔されることを望まない場合があります。通信事業者やその他のサービスプロバイダーは、さまざまなグローバルまたはユーザー固有のフィルタリングアルゴリズムを使用して、加入者がこのようなコールを受け取らないようにすることができます。このようなアルゴリズムへの1つの入力は、ユーザーフィードバックです。ユーザーのフィードバックは、スマートフォンアプリ、API、またはSIPで開始された通話のコンテキスト内で提供されます。このドキュメントでは、SIPコール内のフィードバックについて説明します。ここでは、着信側はSIP [RFC3261]要求を不要として拒否するか、呼び出しに応答した後、BYE要求でセッションを終了します。 INVITEおよびMESSAGEリクエストは、このような応答をトリガーする可能性が最も高いです。

To allow the called party to express that the call was unwanted, this document defines the 607 (Unwanted) response code. The user agent (UA) of the called party, based on input from the called party or some UA-internal logic, uses this to indicate that this call is unwanted and that future attempts are likely to be similarly rejected. While factors such as identity spoofing and call forwarding may make authoritative identification of the calling party difficult or impossible, the network can use such a rejection -- possibly combined with a pattern of rejections by other callees and/ or other information -- as input to a heuristic algorithm for determining future call treatment. The heuristic processing and possible treatment of persistently unwanted calls are outside the scope of this document.

着信側がコールが不要であることを表明できるように、このドキュメントでは607（Unwanted）応答コードを定義しています。着信側からの入力または一部のUA内部ロジックに基づいて、着信側のユーザーエージェント（UA）はこれを使用して、この呼び出しが不要であり、今後の試行が同様に拒否される可能性が高いことを示します。 IDのなりすましや自動転送などの要因により、発呼者の信頼できる識別が困難または不可能になる可能性がありますが、ネットワークでは、このような拒否を、他の受信者による拒否のパターンやその他の情報と組み合わせて、将来の通話処理を決定するための発見的アルゴリズム。永続的に不要な呼び出しのヒューリスティック処理と可能な処理は、このドキュメントの範囲外です。

When this document refers to "caller identity", it uses "identity" in the same sense as [SIP-IDENTITY], i.e., to mean either a canonical address-of-record (AOR) SIP URI employed to reach a user (such as 'sip:alice@atlanta.example.com'), or a telephone number, which commonly appears in either a tel URI [RFC3966] or as the user portion of a SIP URI.

このドキュメントが「発信者ID」に言及する場合、[SIP-IDENTITY]と同じ意味で「ID」を使用します。つまり、ユーザーに到達するために使用される正規のレコードのアドレス（AOR）SIP URI（「sip：alice@atlanta.example.com」など）または電話番号。通常、tel URI [RFC3966]またはSIP URIのユーザー部分として表示されます。

2. Normative Language

2. 規範的な言語

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]で説明されているように解釈されます。

3. Motivation

3. 動機

None of the existing 4xx, 5xx, or 6xx response codes signify that this SIP request is unwanted by the called party. For example, 603 (Decline) might be used if the called party is currently at dinner or in a meeting, but does not want to indicate any specific reason. As described in Section 21.6.2 [RFC3261], a 603 response may include a Retry-After header field to indicate a better time to attempt the call. Thus, the call is rejected due to the called party's (temporary) status. As described in Section 4, the called party invokes the "unwanted call" user interface and 607 (Unwanted) response indicating that it is instead the caller's identity that is causing the call to be rejected.

既存の4xx、5xx、または6xx応答コードのいずれも、このSIP要求が着信側に不要であることを示していません。たとえば、着信側が現在夕食中または会議中であるが、特定の理由を示したくない場合は、603（拒否）を使用できます。セクション21.6.2 [RFC3261]で説明されているように、603応答にはRetry-Afterヘッダーフィールドが含まれている可能性があり、呼び出しを試行するのに適切な時間を示します。したがって、着信側の（一時的な）ステータスにより、コールは拒否されます。セクション4で説明したように、着信側は「不要なコール」ユーザーインターフェイスと607（Unwanted）応答を呼び出し、代わりに発信者のIDがコールを拒否していることを示します。

4. Behavior of SIP Entities

4. SIPエンティティの動作

The response code 607 MAY be used in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP request to indicate that the offered communication is unwanted. The response code MAY also be used as the value of the "cause" parameter of a SIP reason-value in a Reason header field [RFC3326], typically when the called party user agent issues a BYE request terminating an incoming call or a forking proxy issues a CANCEL request after receiving a 607 response from one of the branches. (Including a Reason header field with the 607 status code allows the called party user agent that receives a CANCEL request to make an informed choice whether and how to include such calls in their missed-call list or whether to show an appropriate indication to the user.) The SIP entities receiving this response code are not obligated to take any particular action beyond those appropriate for 6xx responses. Following the default handling for 6xx responses in [RFC5057], the 607 response destroys the transaction. The service provider delivering calls or messages to the user issuing the response MAY take a range of actions, for example, add the calling party to a personal blacklist specific to the called party, use the information as input when computing the likelihood that the calling party is placing unwanted calls ("crowd sourcing"), initiate a traceback request, or report the calling party's identity to consumer complaint databases. As discussed in Section 6, reversing the 'unwanted' labeling is beyond the scope of this mechanism, as it will likely require a mechanism other than call signaling.

応答コード607は、提供された通信が望ましくないことを示すために、INVITE、MESSAGE、SUBSCRIBE、またはその他のダイアログ外SIP要求の失敗応答で使用される場合があります。応答コードは、Reasonヘッダーフィールド[RFC3326]のSIP reason-valueの「原因」パラメータの値としても使用される場合があります。これは、通常、着呼側のユーザーエージェントがBYEリクエストを発行して、着信コールまたは分岐プロキシを終了する場合に使用されます。ブランチの1つから607応答を受信した後、CANCEL要求を発行します。（Reasonヘッダーフィールドに607ステータスコードを含めると、CANCEL要求を受信した着呼側ユーザーエージェントは、不在着信リストにそのような通話を含めるかどうか、およびその方法をユーザーに通知するかどうか、またはユーザーに適切な指示を表示するかどうかを通知する選択を行うことができます。）この応答コードを受け取ったSIPエンティティは、6xx応答に適切なアクションを超える特定のアクションを実行する義務はありません。 [RFC5057]の6xx応答のデフォルトの処理に従って、607応答はトランザクションを破棄します。応答を発行するユーザーに通話またはメッセージを配信するサービスプロバイダーは、さまざまなアクションを実行できます。たとえば、発信者を着信者固有の個人ブラックリストに追加し、発信者がその可能性を計算するときに入力として情報を使用しますは、不要な呼び出し（「クラウドソーシング」）を行ったり、トレースバック要求を開始したり、発信者のIDを消費者の苦情データベースに報告したりしています。セクション6で説明したように、「不要な」ラベル付けを元に戻すことは、コールシグナリング以外のメカニズムが必要になる可能性が高いため、このメカニズムの範囲を超えています。

The user experience is envisioned to be somewhat similar to email spam buttons where the detailed actions of the email provider remain opaque to the user.

ユーザーエクスペリエンスは、電子メールプロバイダーの詳細なアクションがユーザーに不透明なままである電子メールスパムボタンにいくぶん似ていると想定されています。

The mechanism described here is only one of many inputs likely to be used by call-filtering algorithms operated by service providers, using data on calls from a particular identifier such as a telephone number to establish handling for future calls from the same identifier. Call handling for unwanted calls is likely to involve a combination of heuristics, analytics, and machine learning. These may use call characteristics such as call duration and call volumes for a particular caller, including changes in those metrics over time, as well as user feedback via non-SIP approaches and the mechanism described here. Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls.

ここで説明するメカニズムは、電話番号などの特定の識別子からの呼び出しに関するデータを使用して、同じ識別子からの将来の呼び出しの処理を確立する、サービスプロバイダーが操作する呼び出しフィルタリングアルゴリズムで使用される可能性が高い多くの入力の1つにすぎません。不要な通話の通話処理には、ヒューリスティック、分析、機械学習の組み合わせが含まれる可能性があります。これらは、特定の発信者の通話時間や通話量などの通話特性を使用できます。これには、時間の経過に伴うメトリックの変化や、SIP以外のアプローチおよびここで説明するメカニズムによるユーザーフィードバックが含まれます。実装では、発信者に誤って不要なラベルを付けることと、不要な呼び出しを配信することとの間で適切なトレードオフを行う必要があります。

Systems receiving 607 responses could decide to treat pre-call and mid-call responses differently, given that the called party has had access to call content for mid-call rejections.

607応答を受信するシステムは、着信側が通話中の拒否のために通話コンテンツにアクセスできる場合、通話前と通話中の応答を異なる方法で処理することを決定できます。

Depending on the implementation, the response code does not necessarily automatically block all calls from that caller identity. The same user interface action might also trigger addition of the caller identity to a local, on-device blacklist or graylist, e.g., causing such calls to be flagged or alerted with a different ring tone.

実装によっては、応答コードは必ずしもその呼び出し元IDからのすべての呼び出しを自動的にブロックするわけではありません。同じユーザーインターフェースアクションによって、発信者のIDがローカルのデバイス上のブラックリストまたはグレーリストに追加されることもあります。たとえば、そのような通話にフラグが付けられたり、別の呼び出し音で警告されたりします。

The actions described here do not depend on the nature of the SIP URI, e.g., whether or not it describes a telephone number; however, the same anonymous SIP URI [RFC3323] may be used by multiple callers; thus, such URIs are unlikely to be appropriate for URI-specific call treatment. SIP entities tallying responses for particular callers may need to consider canonicalzing SIP URIs, including telephone numbers, as described in [SIP-IDENTITY]. The calling party may be identified in different locations in the SIP header, e.g., the From header field, P-Asserted-Identity or History-Info, and may also be affected by diverting services.

ここで説明するアクションは、SIP URIの性質、たとえば電話番号を記述するかどうかに依存しません。ただし、同じ匿名SIP URI [RFC3323]が複数の呼び出し元によって使用される場合があります。したがって、そのようなURIがURI固有の呼び出し処理に適切であるとは考えられません。特定の発信者の応答を集計するSIPエンティティは、[SIP-IDENTITY]で説明されているように、電話番号を含むSIP URIの正規化を検討する必要がある場合があります。発呼者は、SIPヘッダーのさまざまな場所（Fromヘッダーフィールド、P-Asserted-Identity、History-Infoなど）で識別され、転送サービスの影響を受ける場合もあります。

This document defines a SIP feature-capability [RFC6809], sip.607, that allows the registrar to indicate that the corresponding proxy supports this particular response code. This allows the UA, for example, to provide a suitable user-interface element, such as a "spam" button, only if its service provider actually supports the feature. The presence of the feature capability does not imply that the provider will take any particular action, such as blocking future calls. A UA may still decide to render a "spam" button even without such a capability if, for example, it maintains a device-local blacklist or reports unwanted calls to a third party.

このドキュメントでは、対応するプロキシがこの特定の応答コードをサポートしていることをレジストラが示すことを可能にするSIP機能機能[RFC6809]、sip.607を定義しています。これにより、たとえば、サービスプロバイダーが実際に機能をサポートしている場合にのみ、UAが「スパム」ボタンなどの適切なユーザーインターフェイス要素を提供できるようになります。この機能の存在は、プロバイダーが将来の呼び出しをブロックするなどの特定のアクションを実行することを意味するものではありません。 UAは、たとえば、デバイスローカルのブラックリストを維持したり、不要な呼び出しをサードパーティに報告したりする場合、そのような機能がなくても「スパム」ボタンを表示することを決定する場合があります。

5. IANA Considerations

5. IANAに関する考慮事項

5.1. SIP Response Code

5.1. SIP応答コード

This document registers a new SIP response code. This response code is defined by the following information, which has been added to the "Response Codes" subregistry under the "Session Initiation Protocol (SIP) Parameters" registry <http://www.iana.org/assignments/sip-parameters>.

このドキュメントでは、新しいSIP応答コードを登録します。この応答コードは、「Session Initiation Protocol（SIP）Parameters」レジストリの「Response Codes」サブレジストリに追加された次の情報によって定義されます<http://www.iana.org/assignments/sip-parameters> 。

Response Code: 607

応答コード：607

Description: Unwanted

説明：不要

Reference: [RFC8197]

参照：[RFC8197]

5.2. SIP Global Feature-Capability Indicator

5.2. SIPグローバル機能能力インジケーター

This document defines the feature capability sip.607 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809].

このドキュメントでは、[RFC6809]で定義されている「SIP Feature-Capability Indicator Registration Tree」レジストリで機能ケーパビリティsip.607を定義しています。

Name: sip.607

名前：sip.607

Description: This feature-capability indicator, when included in a Feature-Caps header field of a REGISTER response, indicates that the server supports, and will process, the 607 (Unwanted) response code.

説明：この機能機能インジケーターは、REGISTER応答のFeature-Capsヘッダーフィールドに含まれている場合、サーバーが607（不要な）応答コードをサポートし、処理することを示します。

Reference: [RFC8197]

参照：[RFC8197]

6. Security Considerations

6. セキュリティに関する考慮事項

If the calling party address is spoofed, users may report the caller identity as placing unwanted calls, possibly leading to the blocking of calls from the legitimate user of the caller identity in addition to the unwanted caller, i.e., creating a form of denial-of-service attack. Thus, the response code SHOULD NOT be used for creating global call filters unless the calling party identity has been authenticated using [SIP-IDENTITY] as being assigned to the caller placing the unwanted call. (The creation of call filters local to a user agent is beyond the scope of this document.)

発呼者のアドレスがスプーフィングされている場合、ユーザーは不要な通話を発信したとして発信者IDを報告し、不要な発信者に加えて発信者IDの正当なユーザーからの通話をブロックする可能性があります。 -サービス攻撃。したがって、[SIP-IDENTITY]を使用して発呼者IDが不要なコールを発信する発信者に割り当てられていると認証されていない限り、応答コードはグローバルコールフィルタの作成に使用しないでください。（ユーザーエージェントに対してローカルな呼び出しフィルターの作成は、このドキュメントの範囲外です。）

Even if the identity is not spoofed, a call or message recipient might flag legitimate caller identities, e.g., to exact vengeance on a person or business, or simply by mistake. To correct errors, any additions to a personal list of blocked caller identities should be observable and reversible by the party being protected by the blacklist. For example, the list may be shown on a web page or the subscriber may be notified by periodic email reminders. Any additions to a global or carrier-wide list of unwanted callers needs to consider that any user-initiated mechanism will suffer from an unavoidable rate of false positives and tailor their algorithms accordingly, e.g., by comparing the fraction of delivered calls for a particular caller that are flagged as unwanted rather than just the absolute number and considering time-weighted filters that give more credence to recent feedback.

IDが偽装されていなくても、通話またはメッセージの受信者は、正当な発信者IDにフラグを立てる可能性があります。エラーを修正するために、ブロックされた発信者IDの個人リストへの追加は、ブラックリストによって保護されている当事者によって監視および復元可能である必要があります。たとえば、リストをWebページに表示したり、定期的な電子メールリマインダーで加入者に通知したりできます。不要な発信者のグローバルまたはキャリア全体のリストへの追加は、ユーザーが開始したメカニズムが誤検知の不可避な割合に悩まされ、それに応じてアルゴリズムを調整することを考慮する必要があります。たとえば、特定の発信者に配信された通話の割合を比較する絶対数だけでなく、不要としてフラグが付けられ、最近のフィードバックに信頼性を与える時間加重フィルターを検討します。

If an attacker on an unsecured network can spoof SIP responses for a significant number of call recipients, it may be able to convince the call-filtering algorithm to block legitimate calls. Use of TLS to protect signaling mitigates against this risk.

セキュリティで保護されていないネットワーク上の攻撃者が多数の通話受信者に対するSIP応答を偽装できる場合、正当な通話をブロックするように通話フィルタリングアルゴリズムを説得できる可能性があります。 TLSを使用してシグナリングを保護すると、このリスクを軽減できます。

Since caller identities are routinely reassigned to new subscribers, algorithms are advised to consider whether the caller identity has been reassigned to a new subscriber and possibly reset any related rating. (In some countries, there are services that track which telephone numbers have been disconnected before they are reassigned to a new subscriber.)

発信者IDは定期的に新しいサブスクライバーに再割り当てされるため、発信者IDが新しいサブスクライバーに再割り当てされているかどうかを検討し、関連する評価をリセットする可能性があるアルゴリズムを推奨します。（一部の国では、新しい加入者に再割り当てされる前に切断された電話番号を追跡するサービスがあります。）

Some call services, such as 3PCC [RFC3725] and call transfer [RFC5359], increase the complexity of identifying who (if anyone) should be impacted by the receipt of 607 within BYE. Such services might cause the wrong party to be flagged or prevent flagging the desired party.

3PCC [RFC3725]やコール転送[RFC5359]などの一部のコールサービスは、BYE内での607の受信によって影響を受ける人（存在する場合）を特定する複雑さを増します。このようなサービスにより、間違ったパーティーにフラグが立てられるか、目的のパーティーにフラグが立てられなくなる可能性があります。

For both individually authenticated and unauthenticated calls, recipients of response code 607 may want to distinguish responses sent before and after the call has been answered, ascertaining whether either response timing suffers from a lower false-positive rate.

個別に認証された呼び出しと認証されていない呼び出しの両方で、応答コード607の受信者は、呼び出しの応答の前後に送信された応答を区別して、どちらかの応答タイミングの誤検知率が低下しているかどうかを確認できます。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <http://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月、<http://www.rfc-editor.org/info/rfc3261>。

[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, <http://www.rfc-editor.org/info/rfc3326>.

[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487 / RFC3326、2002年12月、<http：// 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, <http://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月、<http ：//www.rfc-editor.org/info/rfc6809>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。

7.2. Informative References

7.2. 参考引用

[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <http://www.rfc-editor.org/info/rfc3323>.

[RFC3323] Peterson、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<http://www.rfc-editor.org/info/rfc3323> 。

[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <http://www.rfc-editor.org/info/rfc3725>.

[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）におけるサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、DOI 10.17487 / RFC3725、2004年4月、<http://www.rfc-editor.org/info/rfc3725>。

[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.

[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。

[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, January 2008, <http://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月、<http://www.rfc-editor.org/info/ rfc5039>。

[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, <http://www.rfc-editor.org/info/rfc5057>.

[RFC5057] Sparks、R。、「セッション開始プロトコルでの複数ダイアログの使用」、RFC 5057、DOI 10.17487 / RFC5057、2007年11月、<http://www.rfc-editor.org/info/rfc5057>。

[RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>.

[RFC5359] Johnston、A.、Ed。、Sparks、R.、Cunningham、C.、Donovan、S.、and K. Summers、 "Session Initiation Protocol Service Examples"、BCP 144、RFC 5359、DOI 10.17487 / RFC5359、 2008年10月、<http://www.rfc-editor.org/info/rfc5359>。

[SIP-IDENTITY] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-16, February 2017.

[SIP-IDENTITY] Peterson、J.、Jennings、C.、Rescorla、E。、およびC. Wendt、「Session Initiation Protocol（SIP）における認証されたID管理」、作業中、draft-ietf-stir-rfc4474bis -16、2017年2月。

Acknowledgements

謝辞

Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale Worley, and Peter Yee (Gen-ART reviewer) provided helpful comments.

Tolga Asveren、Ben Campbell、Peter Dawes、Spencer Dawkins、Martin Dolly、Keith Drage、Vijay Gurbani、Christer Holmberg、Olle Johansson、Paul Kyzivat、Jean Mahoney、Marianne Mohali、Adam Montville、Al Morton、Denis Ovsienko、Brian Rosen、Brett Tate 、Chris Wendt、Dale Worley、およびPeter Yee（Gen-ARTレビューア）が役立つコメントを提供しました。

Author's Address

著者のアドレス

Henning Schulzrinne FCC 445 12th Street SW Washington, DC 20554 United States of America

ヘニングシュルズリンネFCC 445 12th Street SWワシントンDC 20554アメリカ合衆国

   Email: henning.schulzrinne@fcc.gov