[要約] RFC 5379は、SIPのプライバシーメカニズムの使用に関するガイドラインです。その目的は、SIP通信のプライバシーを保護するための指針を提供することです。
Independent Submission M. Munakata
Request for Comments: 5379 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
February 2010
Guidelines for Using the Privacy Mechanism for SIP
SIPにプライバシーメカニズムを使用するためのガイドライン
Abstract
概要
This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values).
これは、RFC 3323で指定され、その後RFCS 3325および4244で拡張されたセッション開始プロトコル（SIP）にプライバシーメカニズムを使用するためのガイドラインを提供する情報ドキュメントです。ターゲットSIPヘッダー/パラメーターの処理を明確にすることを目的としています。および各プライバシーヘッダー値（PRIV値）のセッション説明プロトコル（SDP）パラメーター。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5379.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5379で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Semantics of Existing priv-values ...............................4
4. Target for Each priv-value ......................................5
4.1. Target SIP Headers for Each priv-value .....................5
4.2. Target SDP Parameters for Each priv-value ..................6
4.3. Treatment of priv-value Not Supported by the
Privacy Service ............................................7
5. Recommended Treatment of User-Privacy-Sensitive Information .....7
5.1. Target SIP Headers .........................................7
5.1.1. Call-ID .............................................7
5.1.2. Call-Info ...........................................8
5.1.3. Contact .............................................8
5.1.4. From ................................................9
5.1.5. History-Info .......................................10
5.1.6. In-Reply-To ........................................10
5.1.7. Organization .......................................11
5.1.8. P-Asserted-Identity ................................11
5.1.9. Record-Route .......................................12
5.1.10. Referred-By .......................................13
5.1.11. Reply-To ..........................................14
5.1.12. Server ............................................14
5.1.13. Subject ...........................................15
5.1.14. User-Agent ........................................15
5.1.15. Via ...............................................15
5.1.16. Warning ...........................................16
5.2. Target SDP Parameters .....................................16
5.2.1. c/m Lines ..........................................16
5.2.2. o Line .............................................17
5.2.3. i/u/e/p Lines ......................................17
5.3. Considerations for Non-Target SIP Headers/Parameters ......17
5.3.1. Identity/Identity-Info .............................17
5.3.2. Path ...............................................18
5.3.3. Replaces Header/Parameter ..........................18
5.3.4. Route ..............................................21
5.3.5. Service-Route ......................................21
5.3.6. Target-Dialog ......................................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
This document clarifies the privacy mechanism for the Session Initiation Protocol (SIP) [RFC3261] defined in [RFC3323], which was later extended in [RFC3325] and [RFC4244]. This document describes the practical manner of operations of the privacy mechanism as a guideline and does not change the existing privacy mechanism.
この文書は、[RFC3323]で定義されたセッション開始プロトコル（SIP）[RFC3261]のプライバシーメカニズムを明確にします。このドキュメントは、プライバシーメカニズムの実用的な操作方法をガイドラインとして説明し、既存のプライバシーメカニズムを変更しません。
In RFC 3323, the semantics of the basic set of priv-values (header, session, user, none, and critical) is defined, but there are some ambiguities in regards to the target information to be obscured per priv-value, which are not explicitly specified. An ambiguity such as this could result in different interpretations of privacy handling for each of the priv-values defined, both at an entity setting a Privacy header and at an entity processing a Privacy header, which could have an adverse impact on interoperability.
RFC 3323では、PRIV値の基本セット（ヘッダー、セッション、ユーザー、なし、およびクリティカル）のセマンティクスが定義されていますが、PRIV値ごとに曖昧になるターゲット情報に関するあいまいさがあります。明示的に指定されていません。このようなあいまいさは、プライバシーヘッダーを設定するエンティティとエンティティでプライバシーヘッダーを処理するエンティティの両方で、定義された各価値のプライバシー処理の異なる解釈をもたらす可能性があります。
Additional priv-values "id" and "history" are defined in RFCs 3325 and 4244, respectively.
追加のPRIV値「ID」と「履歴」は、それぞれRFCS 3325および4244で定義されています。
In RFC 4244, the priv-value "history" is defined in order to request privacy for History-Info headers, and the target to be obscured for "history" priv-value is specified as only the History-Info headers. In addition, the RFC clearly describes that History-Info headers are also the target when "header"- and "session"-level privacy are requested.
RFC 4244では、履歴INFOヘッダーのプライバシーを要求するためにPRIV値の「履歴」が定義され、「履歴」PRIV値のターゲットが履歴INFOヘッダーのみとして指定されます。さらに、RFCは、「ヘッダー」と「セッション」レベルのプライバシーが要求されたときに、履歴INFOヘッダーもターゲットであることを明確に説明しています。
On the other hand, RFC 3325 defines the P-Asserted-Identity header and a priv-value "id", which is used to request privacy for only the P-Asserted-Identity header, but it does not specify how other priv-values may impact the privacy handling of the P-Asserted-Identity header. Because of this lack of specification, it has been observed that some implementations are suffering from the inability to achieve the intended privacy due to discrepancies in interpretations.
一方、RFC 3325は、P asserted-IdentityヘッダーとPRIV値「ID」を定義します。P-Asserted-Identityヘッダーのプライバシー処理に影響を与える可能性があります。この仕様がないため、一部の実装は、解釈の矛盾のために意図したプライバシーを達成できないことに苦しんでいることが観察されています。
This document tries to clarify the SIP headers and SDP parameters to be obscured for each of the priv-values to alleviate the potential interoperability issues already seen due to a lack of explicit text.
このドキュメントは、SIPヘッダーとSDPパラメーターを明確にしようとし、それぞれのPRIV値について不明瞭になり、明示的なテキストがないためにすでに見られる潜在的な相互運用性の問題を軽減します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Note: This document is informational; therefore, it does not specify any new normative behaviors of privacy mechanism. All the RFC 2119 language in this document is derived from the normative text in the existing RFCs, such as RFC 3323.
注：このドキュメントは情報提供です。したがって、プライバシーメカニズムの新しい規範的行動は指定されていません。このドキュメントのすべてのRFC 2119言語は、RFC 3323などの既存のRFCの規範的なテキストから派生しています。
priv-value: Values registered with IANA to be used in the Privacy header. Registered priv-values are "header", "session", "user", "none", and "critical" defined in [RFC3323]; "id" defined in [RFC3325]; and "history" defined in [RFC4244].
priv-value：プライバシーヘッダーで使用されるIANAに登録された値。登録されたPRIV値は、[RFC3323]で定義されている「ヘッダー」、「セッション」、「ユーザー」、「なし」、「クリティカル」です。[RFC3325]で定義された「ID」;[RFC4244]で定義されている「歴史」。
privacy service: A network entity that executes privacy functions before forwarding messages to the next hop. It is sometimes abbreviated to PS in this document.
プライバシーサービス：次のホップにメッセージを転送する前にプライバシー機能を実行するネットワークエンティティ。このドキュメントでは、PSと略されることがあります。
user-level privacy: Privacy for user-inserted information that can be anonymized by the user agent itself.
ユーザーレベルのプライバシー：ユーザーエージェント自体が匿名化できるユーザー挿入情報のプライバシー。
This section provides the semantics of each priv-value defined in RFCs 3323, 3325, and 4244. The descriptions are taken from the IANA registration.
このセクションでは、RFCS 3323、3325、および4244で定義されている各PRIV値のセマンティクスを説明します。説明はIANA登録から取得されます。
Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function
header Request that privacy services modify [RFC3323] headers that cannot be set arbitrarily by the user (Contact/Via).
ヘッダーは、プライバシーサービスがユーザーがarbitrarily意的に設定できないヘッダーを変更することを要求します（連絡先/via）。
session Request that privacy services provide [RFC3323] privacy for session media
セッションリクエストプライバシーサービスは、セッションメディアに[RFC3323]プライバシーを提供する
none Privacy services must not perform any [RFC3323] privacy function
プライバシーサービスはありません[RFC3323]プライバシー機能を実行してはなりません
critical Privacy service must perform the [RFC3323] specified services or fail the request
重要なプライバシーサービスは[RFC3323]指定されたサービスを実行するか、リクエストに失敗する必要があります
id Privacy requested for Third-Party [RFC3325] Asserted Identity
サードパーティに要求されたIDプライバシー[RFC3325]がアイデンティティを主張する
history Privacy requested for [RFC4244] History-Info header(s)
[rfc4244]歴史的インフォヘッダーにリクエストされた履歴プライバシー
Tables in this section show the recommended treatment of SIP headers and SDP parameters per priv-value. SIP headers and SDP parameters not shown in the tables are regarded as non-targets of these priv-values. Some non-target SIP headers/SDP parameters may carry privacy-sensitive information that may need privacy treatment regardless of the privacy level requested. This is further described in 5.3.
このセクションの表は、SIPヘッダーの推奨処理とPRIV値ごとのSDPパラメーターを示しています。テーブルには示されていないSIPヘッダーとSDPパラメーターは、これらのPRIV値の非ターゲットと見なされます。一部の非ターゲットSIPヘッダー/SDPパラメーターには、要求されたプライバシーレベルに関係なく、プライバシー扱いが必要になる場合があるプライバシーに敏感な情報が含まれる場合があります。これは5.3でさらに説明されています。
The way in which SIP headers and SDP parameters listed here are obscured may depend on the implementation and network policy. This document does not prevent different variations that may exist based on local policy but tries to provide recommendations for how a privacy service treats SIP headers and SDP parameters.
ここにリストされているSIPヘッダーとSDPパラメーターが不明瞭になる方法は、実装とネットワークポリシーに依存する可能性があります。このドキュメントは、ローカルポリシーに基づいて存在する可能性のあるさまざまなバリエーションを防ぐのではなく、プライバシーサービスがSIPヘッダーとSDPパラメーターをどのように扱うかについての推奨事項を提供しようとします。
Note: The scope of these tables is SIP headers and related parameters specified in RFCs.
注：これらのテーブルの範囲は、RFCSで指定されたSIPヘッダーと関連パラメーターです。
Table 1 below shows a recommended treatment of each SIP header for each priv-value. Detailed descriptions of the recommended treatment per SIP header are covered in Section 5.
以下の表1は、各priv値に対して各SIPヘッダーの推奨処理を示しています。SIPヘッダーごとの推奨治療の詳細な説明は、セクション5で説明されています。
The "where" column describes the request and response types in which the header needs the treatment to maintain privacy. Values in this column are:
「Where」列は、プライバシーを維持するためにヘッダーが治療を必要とするリクエストと応答の種類を説明します。この列の値は次のとおりです。
R: The header needs the treatment when it appears in a request.
R：ヘッダーは、リクエストに表示されるときに治療が必要です。
r: The header needs the treatment when it appears in a response.
R：ヘッダーは、応答に表示されるときに治療が必要です。
The next five columns show the recommended treatment for each priv-value:
次の5つの列は、各priv値の推奨治療を示しています。
delete: The header is recommended to be deleted at a privacy service.
削除：ヘッダーは、プライバシーサービスで削除することをお勧めします。
not add: The header is recommended not to be added at a privacy service.
追加しないでください：ヘッダーはプライバシーサービスに追加されないことをお勧めします。
anonymize: The header is recommended to be anonymized at a privacy service. How to anonymize the header depends on the header. Details are given in Section 5.
匿名化：ヘッダーは、プライバシーサービスで匿名化することをお勧めします。ヘッダーを匿名化する方法は、ヘッダーによって異なります。詳細については、セクション5に記載されています。
anonymize*: An asterisk indicates that the involvement of a privacy service and treatment of the relevant header depend on the circumstance. Details are given in Section 5.
匿名*：アスタリスクは、プライバシーサービスの関与と関連するヘッダーの扱いが状況に依存することを示します。詳細については、セクション5に記載されています。
Target headers where user header session id history
--------------------------------------------------------------------
Call-ID (Note) R anonymize - - - -
Call-Info Rr delete not add - - -
Contact R - anonymize - - -
From R anonymize - - - -
History-Info Rr - delete delete - delete
In-Reply-To R delete - - - -
Organization Rr delete not add - - -
P-Asserted-Identity Rr - delete - delete -
Record-Route Rr - anonymize - - -
Referred-By R anonymize* - - - -
Reply-To Rr delete - - - -
Server r delete not add - - -
Subject R delete - - - -
User-Agent R delete - - - -
Via R - anonymize - - -
Warning r anonymize - - - -
Table 1: Recommended PS behavior for each SIP header
表1：各SIPヘッダーに推奨されるPS動作
Note: Any time a privacy service modifies a Call-ID, it MUST retain the former and modified values as indicated in Section 5.3 in RFC 3323. It MUST then restore the former value in a Call-ID header and other corresponding headers and parameters (such as In-Reply-To, Replaces, and Target-Dialog) in any messages that are sent using the modified Call-ID to the originating user agent. It should also modify a Call-ID header and other corresponding headers/parameters (such as Target-Dialog and "replaces" parameter) in any further relevant messages that are sent by the originating user agent. Refer to Section 5.1.1 (Call-ID) for the detailed behavior.
注：プライバシーサービスがCall-IDを変更するときは、RFC 3323のセクション5.3に示されているように、前者と変更された値を保持する必要があります。その後、コールIDヘッダーおよびその他の対応するヘッダーとパラメーターの前の値を復元する必要があります。修正されたcall-idを使用して送信されたメッセージで、In-Reply-to、and、and、Target-dialogなど）。また、発信元のユーザーエージェントによって送信されるさらに関連するメッセージで、Call-IDヘッダーとその他の対応するヘッダー/パラメーター（ターゲットダイアログや「置換」パラメーターなど）を変更する必要があります。詳細な動作については、セクション5.1.1（call-id）を参照してください。
Identity/Identity-Info, Path, Replaces, Route, Service-Route, and Target-Dialog headers are not targets of these priv-values (and should not be anonymized or modified by a privacy service based on a priv-value in a Privacy header). Refer to Section 5.3 for details.
アイデンティティ/アイデンティティINFO、パス、交換、ルート、サービスルート、およびターゲットダイアログヘッダーは、これらのPRIV値のターゲットではありません（プライバシーのPRIV値に基づくプライバシーサービスによって匿名化または変更されるべきではありませんヘッダ）。詳細については、セクション5.3を参照してください。
The recommended PS behaviors for each SDP parameters are simple. The c, m, o, i, u, e, and p lines in SIP request/response are recommended to be anonymized when user privacy is requested with Privacy:session.
各SDPパラメーターの推奨されるPS動作は簡単です。SIPリクエスト/応答のC、M、O、I、U、E、およびP行は、ユーザープライバシーがプライバシー：セッションで要求される場合に匿名化することをお勧めします。
As specified in RFC 3323, if the priv-value of "critical" is present in the Privacy header of a request, and if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header, it MUST fail the request with a 500 (Server Error) response code as indicated in Section 5 in RFC 3323.
RFC 3323で指定されているように、「クリティカル」のPRIV値がリクエストのプライバシーヘッダーに存在する場合、およびプライバシーサービスがプライバシーヘッダーで指定されたプライバシーのすべてのレベルを実行できない場合、失敗する必要があります。RFC 3323のセクション5に示されているように、500（サーバーエラー）応答コードを要求します。
Since the protection of privacy is important, even if the priv-value "critical" is not present in the Privacy header, the privacy service should fail the request with a 500 response code when it is incapable of performing all of the levels of privacy specified in the Privacy header.
プライバシーの保護は重要であるため、プライバシーヘッダーにpriv-valueの「クリティカル」が存在しない場合でも、プライバシーサービスは、指定されたプライバシーのすべてのレベルを実行できない場合、500応答コードでリクエストに失敗するはずです。プライバシーヘッダー。
The following SIP headers and related parameters may concern privacy. This section describes what kind of user-privacy-sensitive information may be included in each SIP header/parameter, and how to maintain privacy for such information at a user agent or a privacy service when the information is indeed privacy-sensitive.
次のSIPヘッダーと関連するパラメーターは、プライバシーに関するものかもしれません。このセクションでは、各SIPヘッダー/パラメーターにどのような種類のユーザー-Privacyに敏感な情報が含まれているか、および情報が実際にプライバシーに敏感である場合、ユーザーエージェントまたはプライバシーサービスでそのような情報のプライバシーを維持する方法について説明します。
This section describes privacy considerations and recommended treatment for each SIP header that may reveal user-privacy-sensitive information. This section goes into details about how each header affects privacy, the desired treatment of the value by the user agent and privacy service, and other instructions/additional notes necessary to provide privacy.
このセクションでは、ユーザー-Privacyに敏感な情報を明らかにする可能性のある各SIPヘッダーのプライバシーに関する考慮事項と推奨治療について説明します。このセクションは、各ヘッダーがプライバシーにどのように影響するか、ユーザーエージェントとプライバシーサービスによる価値の望ましい扱い、およびプライバシーを提供するために必要なその他の指示/追加メモの詳細について詳しく説明します。
This field frequently contains an IP address or hostname of a UAC (User Agent Client) appended to the Call-ID value.
このフィールドには、call-id値に追加されたUAC（ユーザーエージェントクライアント）のIPアドレスまたはホスト名が頻繁に含まれています。
A user agent executing a user-level privacy function on its own SHOULD substitute for the IP address or hostname that is frequently appended to the Call-ID value a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused) as indicated in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー関数を独自に実行するユーザーエージェントは、call-id値に頻繁に追加されるIPアドレスまたはホスト名に置き換える必要があります。RFC 3323のセクション4.1に示されているように、リクエストは再利用されるかもしれません）。
A privacy service MAY anonymize the Call-ID header when the request contains Privacy:user by substituting for the IP address or hostname in the Call-ID a suitably long random value (such as a From tag value) so that it is sufficiently unique as indicated in Section 5.3 in RFC 3323.
プライバシーサービスは、リクエストにプライバシーを含む場合、コールアイドヘッダーを匿名化できます：ユーザーは、Call-IDのIPアドレスまたはホスト名を適切に長いランダム値（タグ値から）に置き換えて、それが十分に一意であるようにRFC 3323のセクション5.3に示されています。
Call-ID is essential to dialog matching, so any time a privacy service modifies this field, it MUST retain the former value and restore it in a Call-ID header in any messages that are sent to/by the originating user agent inside the dialog as indicated in Section 5.3 in RFC 3323. A privacy service should be prepared to receive a request outside the dialog containing the value of the Call-ID set by the PS in other SIP headers (e.g., In-Reply-To/Replaces/ Target-Dialog), at least while the dialog state is active for the dialog whose Call-ID was modified by that PS. When such a request is received, the Call-ID value contained in the relevant headers indicated above should be replaced by the retained value.
Call-IDはダイアログマッチングに不可欠であるため、プライバシーサービスがこのフィールドを変更するときはいつでも、ダイアログ内の出身のユーザーエージェントに送信されるメッセージのコールIDヘッダーでそれを復元する必要がありますRFC3323のセクション5.3に示されているように。プライバシーサービスは、他のSIPヘッダーにPSが設定したコールIDの値を含むダイアログの外部でリクエストを受信するために準備する必要があります（例：In-Reply-to/ factes/ターゲット/ターゲット-dialog）、少なくともダイアログ状態がアクティブであり、そのpsによってCall-idが変更されたダイアログの場合。そのような要求が受信された場合、上記の関連するヘッダーに含まれるコールID値は、保持値に置き換える必要があります。
Note: This is possible only if the privacy service maintains the state and retains all the information it modified to provide privacy. Some PSs are known to encrypt information prior to obfuscation in the Via header, etc. In this case, the PS cannot correlate the modified Call-ID value with the original Call-ID. Further challenges are imposed when the PS needs to stay on a signaling path to ensure that it receives all the messages targeted towards the caller for which a PS provides privacy, especially when the request is out-of-dialog.
注：これは、プライバシーサービスが州を維持し、プライバシーを提供するために変更したすべての情報を保持している場合にのみ可能です。一部のPSSは、Viaヘッダーなどで難読化する前に情報を暗号化することが知られています。この場合、PSは修正されたCall-ID値を元のCall-IDと相関させることはできません。PSが信号経路にとどまる必要がある場合、特にリクエストが外れている場合、PSがプライバシーを提供する発信者を対象とするすべてのメッセージを受信する必要がある場合、さらなる課題が課されます。
Refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3 (Replaces Header/Parameter), and 5.3.6 (Target-Dialog), for detailed discussion.
詳細な説明については、対応するセクション5.1.6（in-reply-to）、5.3.3（Header/parameterを置き換える）、および5.3.6（ターゲットダイアログ）を参照してください。
This field contains additional information about the user.
このフィールドには、ユーザーに関する追加情報が含まれています。
A user agent executing a user-level privacy function on its own SHOULD NOT add a Call-Info header as indicated in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1に示されているように、コールINFOヘッダーを追加しないでください。
A privacy service MUST delete a Call-Info header if one exists when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add a Call-Info header when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
プライバシーサービスは、ユーザープライバシーがプライバシーでリクエストされたときに存在する場合にコールINFOヘッダーを削除する必要があります：RFC 3323のセクション5.3に示されているユーザー。プライバシーサービスは、プライバシーでユーザープライバシーがリクエストされている場合、コールINFOヘッダーを追加してはなりません。RFC 3323のセクション5.1に示されているヘッダー。
This field contains a URI used to reach the user agent for mid-dialog requests and possibly out-of-dialog requests, such as REFER [RFC3315]. Since the Contact header is essential for routing further requests to the user agent, it must include a functional URI even when it is anonymized.
このフィールドには、[RFC3315]を参照するなど、ダイアログの中間要求と場合によってはダイアログ外のリクエストのためにユーザーエージェントに到達するために使用されるURIが含まれています。連絡先ヘッダーはユーザーエージェントにさらにリクエストをルーティングするために不可欠であるため、匿名化された場合でも機能性URIを含める必要があります。
A user agent MUST NOT anonymize a Contact header, unless it can obtain an IP address or contact address that is functional yet has a characteristic of anonymity as indicated in Section 4.1.1.3 in RFC 3323.
ユーザーエージェントは、RFC 3323のセクション4.1.1.3に示されているように、機能的であるが匿名性の特徴を持つIPアドレスまたは連絡先アドレスを取得できない限り、連絡先ヘッダーを匿名化してはなりません。
Since RFC 3323 was published, there have been proposals that allow UAs to obtain an IP address or contact address with a characteristic of anonymity.
RFC 3323が公開されて以来、UASが匿名性の特性を持つIPアドレスまたは連絡先アドレスを取得できるようにする提案がありました。
The mechanisms that are discussed at the time of this writing are Globally Routable User Agent URIs (GRUU) [SIPGRUU], which provides a functional Contact address with a short life span, making it ideal for privacy sensitive calls, and Traversal Using Relays around NAT (TURN) [TURN], through which an IP address of a relay can be obtained for use in a Contact header.
この執筆時点で議論されているメカニズムは、グローバルにルーティング可能なユーザーエージェントURIS（Gruu）[Sipgruu]であり、短い寿命のある機能的な連絡先アドレスを提供し、プライバシーに敏感な通話に最適であり、NATの周りのリレーを使用したトラバーサル（ターン）[ターン]、リレーのIPアドレスをコンタクトヘッダーで使用するために取得できます。
A privacy service SHOULD anonymize a Contact header by replacing the existing Contact header field value with the URI that dereferences to the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323. This is generally done by replacing the IP address or hostname with that of the privacy service.
プライバシーサービスは、既存の連絡先ヘッダーフィールド値をURIに置き換えて、RFC 3323のセクション5.1に示すように、ユーザープライバシーがプライバシー：ヘッダーで要求された場合にプライバシーサービスに逆行することをURIに置き換えることにより、連絡先ヘッダーを匿名化する必要があります。プライバシーサービスのIPアドレスまたはホスト名。
This field contains the identity of the user, such as display-name and URI.
このフィールドには、表示名やURIなどのユーザーのIDが含まれています。
A user agent executing a user-level privacy function on its own SHOULD anonymize a From header using an anonymous display-name and an anonymous URI as indicated in Section 4.1 in RFC 3323.
RFC 3323のセクション4.1に示されているように、匿名のディスプレイ名と匿名のURIを使用して、ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、ヘッダーからAを匿名化する必要があります。
A privacy service should anonymize a From header when user privacy is requested with Privacy:user.
プライバシーサービスは、プライバシー：ユーザーでユーザープライバシーが要求されたときにヘッダーから匿名を匿名化する必要があります。
Note: This does not prevent a privacy service from anonymizing the From header based on local policy.
注：これは、プライバシーサービスがローカルポリシーに基づいてヘッダーから匿名化することを妨げません。
The anonymous display-name and anonymous URI mentioned in this section use display-name "Anonymous", a URI with "anonymous" in the user portion of the From header, and the hostname value "anonymous.invalid" as indicated in Section 4.1.1.3 in RFC 3323.
このセクションで言及されている匿名のディスプレイ名と匿名のURIは、ディスプレイ名「匿名」、From Headerのユーザー部分に「匿名」を持つURI、およびセクション4.1で示されているホスト名「Anonymous.Invalid」を使用します。RFC 3323で1.3。
The recommended form of the From header for anonymity is:
匿名性のヘッダーから推奨される形式は次のとおりです。
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774 The tag value varies from dialog to dialog, but the rest of this header form is recommended as shown.
from： "anonymous" <sip：anonymous@anonymous.invalid>; tag = 1928301774タグ値はダイアログごとに異なりますが、このヘッダーフォームの残りは示されているように推奨されます。
History-Info [RFC4244] header URIs to which the request was forwarded or retargeted can reveal general routing information.
History-INFO [RFC4244]ヘッダーは、リクエストが転送された、またはリターゲティングされているヘッダーURISが一般的なルーティング情報を明らかにすることができます。
A user agent executing a user-level privacy function on its own SHOULD NOT add a History-Info header as indicated in Section 3.3 in RFC 4244.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 4244のセクション3.3に示されているように、履歴INFOヘッダーを追加しないでください。
A privacy service SHOULD delete the History-Info headers when user privacy is requested with Privacy:header, Privacy:session, or Privacy:history as indicated in Section 3.3 in RFC 4244.
プライバシーサービスは、ユーザープライバシーがプライバシーで要求されたときに履歴INFOヘッダーを削除する必要があります：ヘッダー、プライバシー：セッション、またはプライバシー：RFC 4244のセクション3.3に示されているように。
The privacy could be also expressed for a specific History-Info entry by inserting "privacy=history" in the History-Info header. In such a case, a privacy service SHOULD delete the History-Info entry as indicated in Section 4.3.3.1.1 in RFC 4244.
プライバシーは、歴史INFOヘッダーに「プライバシー=履歴」を挿入することにより、特定の履歴INFOエントリでも表明できます。そのような場合、RFC 4244のセクション4.3.3.1.1に示されているように、プライバシーサービスは履歴INFOエントリを削除する必要があります。
Refer to [RFC4244] for detailed behavior for dealing with History-Info headers.
履歴INFOヘッダーを扱うための詳細な動作については、[RFC4244]を参照してください。
The In-Reply-To header contains a Call-ID of the referenced dialog. The replying user may be identified by the Call-ID in an In-Reply-To header.
In Reply-to Headerには、参照されたダイアログのCall-IDが含まれています。返信ユーザーは、call-idによって繰り返されるヘッダーで識別される場合があります。
Alice > INV(Call-ID:C1) > Bob
Bob > INV(In-Reply-To:C1) > Alice
In this case, unless the In-Reply-To header is deleted, Alice might notice that the replying user is Bob because Alice's UA knows that the Call-ID relates to Bob.
この場合、繰り返しヘッダーが削除されない限り、アリスのUAがコールアイドがボブに関連していることを知っているため、アリスは返信ユーザーがボブであることに気付くかもしれません。
A user agent executing a user-level privacy function on its own should not add an In-Reply-To header as implied in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー関数を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1で暗示されているように、In Reply-to Headerを追加しないでください。
A privacy service MUST delete the In-Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.3に示されているように、プライバシー：ユーザーでユーザープライバシーが要求された場合、In-Reply-to Headerを削除する必要があります。
In addition, since an In-Reply-To header contains the Call-ID of the dialog to which it is replying, special attention is required, as described in Section 5.1.1 (Call-ID), regardless of the priv-value or presence of a Privacy header. Once a privacy service modifies a Call-ID in the request, a privacy service should restore the former value in an In-Reply-To header, if present in the INVITE request replying to the original request, as long as the privacy service maintains the dialog state.
さらに、In-Reply-to Headerには、返信しているダイアログのCall-IDが含まれているため、Priv-Valueまたはに関係なく、セクション5.1.1（Call-ID）で説明されているように、特別な注意が必要です。プライバシーヘッダーの存在。プライバシーサービスがリクエストでCall-IDを変更すると、プライバシーサービスが元のリクエストに返信する招待リクエストに存在する場合、プライバシーサービスがプライバシーサービスが維持されている限り、プライバシーサービスは前者の価値を復元する必要があります。ダイアログ状態。
Example:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(In-Reply-To:C1) > Alice
Note: This is possible only if the privacy service maintains the state and retains all the information that it modified to provide privacy even after the dialog has been terminated, which is unlikely. Call-back is difficult to achieve when a privacy service is involved in forming the dialog to be referenced.
注：これは、プライバシーサービスが状態を維持し、ダイアログが終了した後でもプライバシーを提供するように変更したすべての情報を保持している場合にのみ可能です。コールバックは、参照するダイアログの形成にプライバシーサービスが関与している場合に達成することが困難です。
This field contains additional information about the user.
このフィールドには、ユーザーに関する追加情報が含まれています。
A user agent executing a user-level privacy function on its own should not add an Organization header as implied in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1で暗示されているように組織ヘッダーを追加しないでください。
A privacy service MUST delete the Organization header if one exists when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add an Organization header when user privacy is requested with Privacy: header as indicated in Section 5.1 in RFC 3323.
プライバシーサービスは、ユーザープライバシーがプライバシーで要求されたときに存在する場合に組織ヘッダーを削除する必要があります：RFC3323のセクション5.3に示されているユーザーは、プライバシーサービスがプライバシーでリクエストされた場合に組織ヘッダーを追加すべきではありません：RFC 3323のセクション5.1。
This header contains a network-verified and network-asserted identity of the user sending a SIP message.
このヘッダーには、SIPメッセージを送信するユーザーのネットワーク検証およびネットワークアサートされたアイデンティティが含まれています。
A privacy service MUST delete the P-Asserted-Identity headers when user privacy is requested with Privacy:id as indicated in Section 7 in RFC 3325 and should delete the P-Asserted-Identity headers when user privacy is requested with Privacy:header before it forwards the message to an entity that is not trusted.
プライバシーサービスは、ユーザープライバシーがプライバシーでリクエストされているときにP-Asserted-Identityヘッダーを削除する必要があります：RFC 3325のセクション7に示されているIDは、ユーザープライバシーがプライバシーでリクエストされている場合にP-Asserted-IDENDITITYヘッダーを削除する必要があります：その前にヘッダーメッセージを信頼されていないエンティティに転送します。
It is recommended for a privacy service to remove the P-Asserted-Identity header if user privacy is requested with Privacy:id or Privacy:header even when forwarding to a trusted entity, unless it can be confident that the message will not be routed to an untrusted entity without going through another privacy service.
ユーザープライバシーがプライバシーで要求されている場合は、プライバシーサービスがP-Asserted-Identityヘッダーを削除することをお勧めします。別のプライバシーサービスを通過することなく、信頼されていないエンティティ。
This field may reveal information about the administrative domain of the user.
このフィールドは、ユーザーの管理ドメインに関する情報を明らかにする場合があります。
In order to hide Record-Route headers while keeping routability to the sender, privacy services can execute a practice referred to as "stripping". Stripping means removing all the Record-Route headers that have been added to the request prior to its arrival at the privacy service and then adding a single Record-Route header representing itself. In this case, the privacy service needs to retain the removed headers and restore them in a response.
送信者へのルーティング可能性を維持しながらレコードルートヘッダーを隠すために、プライバシーサービスは「ストリッピング」と呼ばれるプラクティスを実行できます。ストリッピングとは、プライバシーサービスに到着する前にリクエストに追加されたすべてのレコードルートヘッダーを削除し、それ自体を表す単一のレコードルートヘッダーを追加することを意味します。この場合、プライバシーサービスは削除されたヘッダーを保持し、それらを応答して復元する必要があります。
Alternatively, privacy services can remove the Record-Route headers and encrypt them into a single Record-Route header field. In this case, the privacy service needs to decrypt the header and restore the former values in a response.
あるいは、プライバシーサービスはレコードルートヘッダーを削除し、それらを単一のレコードルートヘッダーフィールドに暗号化できます。この場合、プライバシーサービスはヘッダーを復号化し、応答で前の値を復元する必要があります。
A privacy service SHOULD strip or encrypt any Record-Route headers that have been added to a message before it reaches the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.1に示されているプライバシー：ヘッダーでユーザープライバシーが要求されたときに、プライバシーサービスに到達する前にメッセージに追加されたレコードルートヘッダーを削除または暗号化する必要があります。
As in the case of a Call-ID, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values as indicated in Section 5.1 in RFC 3323. Some examples where the restoration of the Route headers is necessary and unnecessary are given below.
コールIDの場合と同様に、プライバシーサービスがレコードルートヘッダーを変更する場合、RFC 3323のセクション5.1に示されているように、保持値でルートヘッダーを復元できる必要があります。必要であり、不要を以下に示します。
When a UAC (Alice) requires privacy for a request, a privacy service does not have to restore the Route headers in the subsequent request (see Example 1).
UAC（Alice）がリクエストにプライバシーを必要とする場合、プライバシーサービスは後続のリクエストでルートヘッダーを復元する必要はありません（例1を参照）。
On the other hand, when a UAS (User Agent Server) (Bob) requires privacy for a response, a privacy service has to restore the Route headers in the subsequent request (see Example 2).
一方、UAS（ユーザーエージェントサーバー）（BOB）が応答にプライバシーを必要とする場合、プライバシーサービスは後続の要求でルートヘッダーを復元する必要があります（例2を参照）。
Example 1:
Restoration of Route header is UNNECESSARY when UAC requires privacy
Alice > INV(Privacy:header) > P1 >
INV(Record-Route:P1, Privacy:header) > PS >
INV(Record-Route:PS) > P2 >
INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 > PS >
200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
re-INV(Route:P2,PS, Privacy:header) > PS >
re-INV(Route:P2) > P2 > re-INV > Bob
Alice P1 PS P2 Bob
| | | | |
| INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
| 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS |
|<----------------|<----------------|<----------------|<--------------|
| | | | |
| INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
Figure 1: Example when restoration of Route header is UNNECESSARY
図1：ルートヘッダーの復元が不要な場合
Example 2:
Restoration of Route header is NECESSARY when UAS requires privacy
Alice > INV > P1 > INV(Record-Route:P1) > P2 >
INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
re-INV(Route:P2) > P2 > Bob
Alice P1 PS' P2 Bob
| | | | |
| INV |INV RR:P1 | | INV RR:P2,P1 |
|-------------->|---------------------------------->|---------------->|
| | | | |
| 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
|<--------------|<----------------|<----------------|<----------------|
| | | | |
| INV R:PS',P1 | INV R:PS' | INV R:P2 | INV |
|-------------->|---------------->|---------------->|---------------->|
| | | (Restored) | |
Figure 2: Example when restoration of Route header is NECESSARY
図2：例ルートヘッダーの復元が必要な場合
Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-Route header, and R means Route header.
注：図1および2では、PRIVはプライバシーを意味します：ヘッダー、RRはレコードルートヘッダーを意味し、Rはルートヘッダーを意味します。
The Referred-By [RFC3892] header carries a SIP URI representing the identity of the referrer.
紹介された[RFC3892]ヘッダーには、リファラーのアイデンティティを表すSIP URIが搭載されています。
The Referred-By header is an anonymization target when the REFER request with the Referred-By header is sent by the user (referrer) whose privacy is requested to be processed in the privacy service.
紹介されたヘッダーは、紹介されたヘッダーを含む参照要求がユーザー（リファラー）によって送信された場合、プライバシーがプライバシーサービスで処理されるように要求される場合の匿名化ターゲットです。
A user agent that constructs REFER requests executing a user-level privacy function on its own should anonymize a Referred-By header by using an anonymous URI.
紹介を構築するユーザーエージェントは、匿名のURIを使用して紹介されたヘッダーを匿名化する必要があります。
A privacy service should anonymize a Referred-By header in a REFER request by using an anonymous URI when user privacy is requested with Privacy:user.
プライバシーサービスは、ユーザープライバシーがリクエストされている場合に匿名のURIを使用して、紹介リクエストで紹介されたヘッダーを匿名化する必要があります：ユーザー。
On the other hand, the Referred-By header is not an anonymization target when it appears in a request other than REFER (e.g., INVITE) because the URI in the Referred-By header does not represent the sender of the request.
一方、紹介されたヘッダー以外のリクエストに表示される場合（招待）以外のリクエストに表示される場合、紹介されたヘッダーは匿名化ターゲットではありません。
Example 1:
Referrer requests no privacy and referee requests privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:user) > PS >
INV(Referred-By:Alice) > Carol
Example 2:
Referrer requests privacy and referee requests privacy
Alice > REF(Referred-By:Alice, Privacy:user) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:user) > PS >
INV(Referred-By:X) > Carol
This field contains a URI that can be used to reach the user on subsequent call-backs.
このフィールドには、後続のコールバックでユーザーにリーチするために使用できるURIが含まれています。
A user agent executing a user-level privacy function on its own should not add a Reply-To header in the message as implied in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1で暗示されているように、メッセージにヘッダーに返信することを追加しないでください。
A privacy service MUST delete a Reply-To header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.3に示されているプライバシー：ユーザーでユーザープライバシーが要求された場合、返信者を削除する必要があります。
This field contains information about the software used by the UAS to handle the request.
このフィールドには、リクエストを処理するためにUASが使用するソフトウェアに関する情報が含まれています。
A user agent executing a user-level privacy function on its own should not add a Server header in the response as implied in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1で暗示されているように、応答にサーバーヘッダーを追加しないでください。
A privacy service must delete a Server header in a response when user privacy is requested with Privacy:user. A privacy service SHOULD NOT add a Server header in a response when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323.
プライバシーサービスは、プライバシー：ユーザーでユーザープライバシーが要求された場合、応答でサーバーヘッダーを削除する必要があります。プライバシーサービスは、RFC 3323のセクション5.1に示されているプライバシー：ヘッダーでユーザープライバシーが要求された場合、応答にサーバーヘッダーを追加しないでください。
This field contains free-form text about the subject of the call. It may include text describing something about the user.
このフィールドには、コールの主題に関する自由形式のテキストが含まれています。ユーザーに関する何かを説明するテキストが含まれる場合があります。
A user agent executing a user-level privacy function on its own should not include any information identifying the caller in a Subject header.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントには、件名ヘッダーに発信者を識別する情報を含めるべきではありません。
A privacy service MUST delete a Subject header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.3に示されているプライバシー：ユーザーのプライバシーを要求する場合、サブジェクトヘッダーを削除する必要があります。
This field contains the UAC's information.
このフィールドには、UACの情報が含まれています。
A user agent executing a user-level privacy function on its own should not add a User-Agent header as implied in Section 4.1 in RFC 3323.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、RFC 3323のセクション4.1で暗示されているように、ユーザーエージェントヘッダーを追加しないでください。
A privacy service MUST delete a User-Agent header when user privacy is requested with Privacy:user as indicated in Section 5.3 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.3に示されているように、プライバシー：ユーザーのプライバシーでユーザープライバシーが要求された場合、ユーザーエージェントヘッダーを削除する必要があります。
The bottommost Via header added by a user agent contains the IP address and port or hostname that are used to reach the user agent for responses. Via headers added by proxies may reveal information about the administrative domain of the user.
ユーザーエージェントによって追加されたヘッダーを介したBottommostには、応答のためにユーザーエージェントにリーチするために使用されるIPアドレスとポートまたはホスト名が含まれています。プロキシによって追加されたヘッダーを介して、ユーザーの管理ドメインに関する情報が明らかになる場合があります。
A user agent MUST NOT anonymize a Via header as indicated in Section 4.1.1.3 in RFC 3323, unless it can obtain an IP address that is functional yet has a characteristic of anonymity. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN.
ユーザーエージェントは、機能的でありながら匿名性の特徴を持つIPアドレスを取得できない限り、RFC 3323のセクション4.1.1.3に示されているように、ヘッダーを匿名化してはなりません。これは、サービスプロバイダーから、またはターンなどの機能を通じて、この目的のために特にIPアドレスを取得することで可能です。
A privacy service SHOULD strip or encrypt any Via headers that have been added prior to reaching the privacy service when user privacy is requested with Privacy:header as indicated in Section 5.1 in RFC 3323. Refer to Section 5.1.9 (Record-Route) for details of stripping and encryption.
プライバシーサービスは、プライバシーを要求したときにプライバシーサービスに到達する前に追加されたヘッダーを除去または暗号化する必要があります。RFC3323のセクション5.1に示されているヘッダー。ストリッピングと暗号化の詳細。
A privacy service MUST restore the original values of Via headers when handling a response in order to route the response to the originator as indicated in Section 5.1 in RFC 3323.
プライバシーサービスは、RFC 3323のセクション5.1に示されているように、応答者への応答をルーティングするために、応答を処理するときにヘッダーの元の値を復元する必要があります。
No Via stripping is required when handling responses.
応答を処理するときは、ストリッピングを介して必要ありません。
This field may contain the hostname of the UAS.
このフィールドには、UASのホスト名が含まれている場合があります。
A user agent executing a user-level privacy function on its own should not include the hostname representing its identity in a Warning header.
ユーザーレベルのプライバシー機能を単独で実行するユーザーエージェントは、警告ヘッダーにそのIDを表すホスト名を含めるべきではありません。
A privacy service should anonymize a Warning header by deleting the hostname portion (if it represents a UAS's identity) from the header when user privacy is requested with Privacy:user.
プライバシーサービスは、プライバシー：ユーザーでユーザープライバシーが要求されたときに、ヘッダーからホスト名部分（UASのIDを表す場合）を削除して、警告ヘッダーを匿名化する必要があります。
This section describes privacy considerations for each SDP [RFC4566] parameter that may reveal information about the user.
このセクションでは、ユーザーに関する情報を明らかにする可能性のある各SDP [RFC4566]パラメーターのプライバシーに関する考慮事項について説明します。
When privacy functions for user-inserted information are requested to be executed at a privacy service, user agents MUST NOT encrypt SDP bodies in messages as indicated in Section 4.2 in RFC 3323.
ユーザーが挿入された情報のプライバシー機能がプライバシーサービスで実行されるように要求される場合、ユーザーエージェントは、RFC 3323のセクション4.2に示されているように、メッセージでSDPボディを暗号化してはなりません。
The c and m lines in the SDP body convey the IP address and port for receiving media.
SDPボディのCおよびMラインは、メディアを受け取るためにIPアドレスとポートを伝えます。
A user agent must not anonymize the IP address and port in the c and m lines, unless it can obtain an IP address that is functional yet has a characteristic of anonymity as implied in Section 4.1.1.3 in RFC 3323. This may be possible by obtaining an IP address specifically for this purpose either from the service provider or through features such as TURN.
ユーザーエージェントは、機能的であるが、RFC 3323のセクション4.1.1.3で暗示されているように匿名性の特性を持つIPアドレスを取得できない限り、C行およびM行のIPアドレスとポートを匿名化してはいけません。この目的のために、サービスプロバイダーまたはターンなどの機能を通じて、特にこの目的のためにIPアドレスを取得します。
A privacy service must anonymize the IP address and port in c and m lines using a functional anonymous IP address and port when user privacy is requested with Privacy:session. This is generally done by replacing the IP address and port present in the SDP with that of a relay server.
プライバシーサービスは、ユーザープライバシーがプライバシー：セッションで要求された場合、機能的な匿名IPアドレスとポートを使用して、CおよびMラインのIPアドレスとポートを匿名化する必要があります。これは通常、SDPに存在するIPアドレスとポートをリレーサーバーのIPアドレスとポートに置き換えることによって行われます。
The username and IP address in this parameter may reveal information about the user.
このパラメーターのユーザー名とIPアドレスは、ユーザーに関する情報を明らかにする場合があります。
A user agent may anonymize the username in an o line by setting username to "-" and anonymize the IP address in the o line by replacing it with a value so that it is sufficiently unique.
ユーザーエージェントは、ユーザー名を " - "に設定してo行でユーザー名を匿名化し、o行のIPアドレスを値に置き換えて匿名化して、十分に一意にすることができます。
A privacy service must anonymize the username and IP address in the o line by setting the username to "-" and replacing the IP address with a value so that it is sufficiently unique when user privacy is requested with Privacy:session.
プライバシーサービスは、ユーザー名を " - "に設定し、IPアドレスを値に置き換えて、ユーザープライバシーがプライバシーでリクエストされたときに十分に一意であるように値に置き換えることにより、O Lineのユーザー名とIPアドレスを匿名化する必要があります：セッション。
These lines may contain information about the user.
これらの行には、ユーザーに関する情報が含まれている場合があります。
A user agent executing a session-level privacy function on its own should not include user's information in the i, u, e, and p lines.
セッションレベルのプライバシー関数を単独で実行するユーザーエージェントは、i、u、e、およびp行にユーザーの情報を含めるべきではありません。
A privacy service should modify the i, u, e, and p lines to delete the user's identity information when user privacy is requested with Privacy:session.
プライバシーサービスは、ユーザーのプライバシーがプライバシー：セッションで要求されたときに、ユーザーのID情報を削除するためにi、u、e、およびp行を変更する必要があります。
The Identity [RFC4474] header field contains a signature used for validating the identity. The Identity-Info header field contains a reference to the certificate of the signer of Identity headers. An Identity-Info header may reveal information about the administrative domain of the user.
ID [RFC4474]ヘッダーフィールドには、IDの検証に使用される署名が含まれています。ID-INFOヘッダーフィールドには、アイデンティティヘッダーの署名者の証明書への参照が含まれています。ID-INFOヘッダーは、ユーザーの管理ドメインに関する情報を明らかにする場合があります。
The signature in an Identity header provides integrity protection over the From, To, Call-ID, Cseq, Date, and Contact headers and over the message body. The integrity protection is violated if a privacy service modifies these headers and/or the message body for the purpose of user privacy protection.
アイデンティティヘッダーの署名は、call-id、cseq、日付、および連絡先ヘッダーから、およびメッセージ本文からの整合性保護を提供します。プライバシーサービスがユーザープライバシー保護を目的としてこれらのヘッダーおよび/またはメッセージ本文を変更すると、整合性保護に違反します。
Once those integrity-protected headers (such as From and Call-ID) are modified, the Identity/Identity-Info header fields are not valid any more. Thus, a privacy service acting on a request for Privacy:user, Privacy:header, or Privacy:session can invalidate integrity protection provided by an upstream authentication service that has inserted Identity/Identity-Info header fields. The use of such a privacy service should be avoided if integrity protect needs to be retained. Otherwise, if the privacy service invalidates the integrity protection, it should remove the Identity/Identity-Info header fields.
これらの整合性保護されたヘッダー（FromやCall-IDなど）が変更されると、ID/ID-INFOヘッダーフィールドはもはや有効ではありません。したがって、プライバシーのリクエストに基づいて行動するプライバシーサービス：ユーザー、プライバシー：ヘッダー、またはプライバシー：セッションは、ID/ID-INFOヘッダーフィールドを挿入したアップストリーム認証サービスによって提供される整合性保護を無効にすることができます。整合性保護を保持する必要がある場合、このようなプライバシーサービスの使用は避けるべきです。それ以外の場合、プライバシーサービスが整合性保護を無効にした場合、ID/ID-INFOヘッダーフィールドを削除する必要があります。
An authentication service downstream of the privacy service may add Identity/Identity-Info header fields if the domain name of the From header field URI has not been anonymized (e.g., 'sip:anonymous@example.com'), which makes it possible for the service to authenticate the UAC. This authenticated yet anonymous From header means "this is a known user in my domain that I have authenticated, but I am keeping its identity private" as indicated in Section 12 in RFC 4474.
プライバシーサービスの下流の認証サービスは、ヘッダーフィールドのドメイン名が匿名化されていない場合（ 'sip：anonyous@example.com'）、それが可能になる場合、ID/ID-INFOヘッダーフィールドを追加する場合があります。UACを認証するサービス。ヘッダーからのこの認証されているが匿名は、「これは私が認証した私のドメインの既知のユーザーであるが、私はそのアイデンティティをプライベートに保っている」ということを意味します。RFC4474のセクション12に示されています。
The desired deployment will have a privacy service located before or co-located with the identity service; thus, integrity and privacy can both be provided seamlessly.
目的の展開には、IDサービスと共同住宅が配置されるか、プライバシーサービスがあります。したがって、整合性とプライバシーは両方ともシームレスに提供できます。
This field may contain information about the administrative domain and/or the visited domain of the user agent. However, the Path header is not the target of any priv-values.
このフィールドには、管理ドメインおよび/またはユーザーエージェントの訪問ドメインに関する情報が含まれている場合があります。ただし、パスヘッダーは、PRIV値のターゲットではありません。
Given that the Path header [RFC3327] only appears in REGISTER requests/responses and is essential for a call to reach the registered UA in the visited domain, it serves no purpose to withhold or hide the information contained in the Path header; rather, it is harmful.
パスヘッダー[RFC3327]は、レジスタリクエスト/応答にのみ表示され、訪問ドメインの登録UAに到達するための呼び出しに不可欠であることを考えると、パスヘッダーに含まれる情報を差し控えたり隠したりする目的はありません。むしろ、それは有害です。
The only reason privacy may be considered desirable is if the visited domain wants to withhold its topology from the home domain of the user. In doing so, the domain withholding the topology needs to ensure that it provides sufficient information so that the home domain can route the call to the visited domain, thus reaching the UA.
プライバシーが望ましいと見なされる唯一の理由は、訪問されたドメインがユーザーのホームドメインからトポロジを差し控えたい場合です。そうすることで、トポロジーを差し控えるドメインは、ホームドメインが訪問ドメインに通話をルーティングしてUAに到達できるように、十分な情報を提供することを確認する必要があります。
However, anonymization of network-privacy-sensitive information is out of scope.
ただし、ネットワークに敏感な情報の匿名化は範囲外です。
The Replaces [RFC3891] header and the "replaces" parameter contain identifiers of a dialog to be replaced, which are composed of Call-ID, local tag, and remote tag.
[RFC3891]の交換ヘッダーと「交換」パラメーターには、Call-ID、ローカルタグ、およびリモートタグで構成されるダイアログの識別子が含まれています。
The sender of the INVITE with a Replaces header is usually not the originating user agent or terminating user agent of the target dialog to be replaced. Therefore, the Call-ID within the Replaces header is unlikely to be generated by the sender, and thus this header is outside the anonymization target per priv-value.
交換ヘッダーを備えた招待者の送信者は、通常、置き換えるターゲットダイアログの発信元のユーザーエージェントまたは終了ユーザーエージェントではありません。したがって、交換ヘッダー内のCall-IDが送信者によって生成される可能性は低いため、このヘッダーはPRIV値ごとに匿名化ターゲットの外側にあります。
The "replaces" parameter, which appears in a Refer-To header in a REFER request, is not the target of any particular priv-values either. As described in Section 5.1.1 (Call-ID), regardless of the priv-value or the presence of a Privacy header, once a privacy service modifies a Call-ID in the request, it should monitor headers that may contain Call-ID and restore the portion of the value representing the modified Call-ID to the original Call-ID value in a Replaces header received.
参照要求の紹介ヘッダーに表示される「交換」パラメーターは、特定のPRIV値のターゲットでもありません。セクション5.1.1（call-id）で説明されているように、プライバシーヘッダーのpriv値や存在に関係なく、プライバシーサービスがリクエストでcall-idを変更すると、call-idを含む可能性のあるヘッダーを監視する必要があります。修正されたCall-IDを表す値の部分を、受け取った交換ヘッダーの元のCall-ID値に復元します。
The main challenge for this to function properly is that a privacy service has to be on a signaling path to the originator for every dialog. This is generally not possible and results in REFER requests not functioning at all times. This is a trade-off that is anticipated when privacy is imposed.
これが適切に機能するための主な課題は、プライバシーサービスがすべてのダイアログのオリジネーターへのシグナリングパスにある必要があることです。これは通常不可能であり、紹介要求が常に機能していません。これは、プライバシーが課されるときに予想されるトレードオフです。
The privacy requirements mentioned in Section 5.1.1 will cause the Replaces header and "replaces" parameter to contain values that will fail the resulting dialog establishment in some situations. This loss of functionality is allowed and/or intended as illustrated above (i.e., it is not the responsibility of a privacy service to ensure that these features always work).
セクション5.1.1に記載されているプライバシー要件は、ヘッダーを交換し、パラメーターを「交換」すると、結果のダイアログ確立が失敗する値を含むようにします。この機能の損失は、上記のように許可されており、および/または意図されています（つまり、これらの機能が常に機能することを保証するのはプライバシーサービスの責任ではありません）。
The functionality of the Replaces header/parameter when anonymized depends on the circumstances in which it is used. REFER may work or may not work depending on the following three criteria.
匿名化された場合の交換ヘッダー/パラメーターの機能は、使用される状況に依存します。参照は、次の3つの基準に応じて機能する場合と機能しない場合があります。
1. Who generated the Call-ID. 2. Where the privacy service is on the signaling path. 3. Who initiates the REFER with the "replaces" parameter.
1. Call-IDを生成した人。2.プライバシーサービスがシグナリングパスにある場所。3.「交換」パラメーターで参照を開始する人。
A few examples that explore when the Replaces header/parameter works or fails are given below.
交換ヘッダー/パラメーターの動作または障害があるときに調査するいくつかの例を以下に示します。
Example 1:
Transfer initiated by the originator, PS added for first INV and REF
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob (SUCCEED)
Example 2:
Transfer initiated by the originator, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)
Note: Example 2 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is also added for REFER and modifies the value in the "replaces" parameter from C1 to C2 even if there is no Privacy header in the REFER.
注：同じPS（アリスからの招待のコールアイドを変更する）が参照用に追加され、プライバシーヘッダーがない場合でも「C1からC2に「置き換える」パラメーターの値も変更すると、例2が成功します。参照。
Example 3:
Transfer initiated by the originator, PS added only for REF
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:user) > PS' >
INV(Replaces:C1) > Bob (SUCCEED)
Example 4:
Transfer initiated by the terminating party, PS added for both INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)
Note: Example 4 succeeds because the same PS (that modifies the Call-ID in the INVITE from Alice) checks the incoming requests and modifies the value in a Replaces header in the INVITE from Carol to the former value of Call-ID (C1).
注：例4は、同じPS（アリスからの招待のコールアイドを変更する）が着信要求をチェックし、キャロルからCall-IDの以前の価値に招待されたヘッダーの交換ヘッダー（C1）を変更するため、成功します。。
Example 5:
Hold, PS added only for first INV
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)
Note: Example 5 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is added for the INVITE from the Music-Server and modifies the value in a Replaces header from C1 to C2.
注：例5は、同じPS（アリスからの招待のコールアイドを変更する）が音楽サーバーから招待のために追加され、Aの代替ヘッダーの値をC1からC2に変更すると成功します。
As the above examples show, in some scenarios, information carried in the Replaces header/parameter would result in failure of the REFER. This will not happen if the Call-ID is not modified at a privacy service.
上記の例が示すように、いくつかのシナリオでは、交換ヘッダー/パラメーターに掲載された情報が紹介の障害になります。これは、Call-IDがプライバシーサービスで変更されていない場合には発生しません。
This field may contain information about the administrative domain of the user agent, but the Route header is not the target of any priv-values.
このフィールドには、ユーザーエージェントの管理ドメインに関する情報が含まれている場合がありますが、ルートヘッダーはPRIV値のターゲットではありません。
Route headers appear only in SIP requests to force routing through the listed set of proxies. If a privacy service anonymizes the Route header, the routing does not function. Furthermore, there is no risk in revealing the information in the Route headers to further network entities, including the terminating user agent, because a proxy removes the value from the Route header when it replaces the value in the Request-URI as defined in RFC 3261.
ルートヘッダーは、リストされているプロキシセットを介してルーティングを強制するために、SIPリクエストにのみ表示されます。プライバシーサービスがルートヘッダーを匿名化する場合、ルーティングは機能しません。さらに、RFC 3261で定義されているようにリクエスト-URIの値を置き換えるとプロキシがルートヘッダーから値を削除するため、ロートヘッダー内の情報をさらにネットワークエンティティを含むさらなるネットワークエンティティへの情報を公開するリスクはありません。。
A privacy service that modifies Record-Route headers may need to restore the values in Route headers as necessary. As indicated in Section 5.1 in RFC 3323, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values. Please refer to Section 5.1.9 (Record-Route) for further detail and examples.
レコードルートヘッダーを変更するプライバシーサービスは、必要に応じてルートヘッダーの値を復元する必要がある場合があります。RFC 3323のセクション5.1に示されているように、プライバシーサービスがレコードルートヘッダーを変更する場合、保持値でルートヘッダーを復元できる必要があります。詳細と例については、セクション5.1.9（Record-Route）を参照してください。
Service-Route headers [RFC3608] appear only in 200 OK responses to REGISTER requests and contain information about the registrar. The purpose of the privacy mechanism defined in RFC 3323 is to secure the user's privacy, so the case where a registrar sets a Privacy header is not considered here. Therefore, the Service-Route header is not the target of any priv-values.
Service-Routeヘッダー[RFC3608]は、登録リクエストに対する200のOK応答のみで表示され、レジストラに関する情報を含んでいます。RFC 3323で定義されているプライバシーメカニズムの目的は、ユーザーのプライバシーを保護することです。そのため、レジストラがプライバシーヘッダーを設定する場合はここでは考慮されません。したがって、サービスルートヘッダーは、PRIV値のターゲットではありません。
The Target-Dialog [RFC4538] header faces exactly the same issues as seen for the Replaces header. Please refer to Section 5.3.3 (Replaces Header/Parameter) for why this is not a target for any particular priv-values and how a privacy service still needs to evaluate and modify the value contained, even if no privacy is requested.
ターゲットダイアログ[RFC4538]ヘッダーは、交換ヘッダーで見られるのとまったく同じ問題に直面しています。プライバシーが要求されていなくても、これが特定のPRIV値のターゲットではない理由、およびプライバシーサービスが含まれる値を評価および変更する必要がある理由については、セクション5.3.3（ヘッダー/パラメーターを置き換えます）を参照してください。
This guideline document adds no new security considerations to those discussed in [RFC3323], [RFC3325], and [RFC4244].
このガイドライン文書は、[RFC3323]、[RFC3325]、および[RFC4244]で説明したものに新しいセキュリティ上の考慮事項を追加しません。
The authors would like to thank John Elwell, Jon Peterson, Jonathan Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their reviews and comments.
著者は、ジョン・エルウェル、ジョン・ピーターソン、ジョナサン・ローゼンバーグ、メアリー・バーンズ、ポール・キジバット、ローランド・ジェスケのレビューとコメントに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244] Barnes、M.、ed。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008.
[ターン] Rosenberg、J.、Mahy、R。、およびP. Matthews、「NATの周りのリレーを使用したトラバーサル（ターン）：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、2008年7月の作業。
[SIPGRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[Sipgruu] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）の取得と使用」、RFC 5627、2009年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327] Willis、D。およびB. Hoeneisen、「Addjacentコンタクトを登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、2002年12月。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3608] Willis、D。およびB. Hoeneisen、「登録中のサービスルート発見のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3608、2003年10月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」は「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[RFC3892] Sparks、R。、「セッション開始プロトコル（SIP）メカニズムを参照」、RFC 3892、2004年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による認可を要求する」、RFC 4538、2006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
Authors' Addresses
著者のアドレス
Mayumi Munakata NTT Corporation
Mayumi Munakata ntt Corporation
Phone: +81 422 36 7502
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
Shida Schubert NTT Corporation
EMail: shida@ntt-at.com
Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
Takumi Ohba NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585 Japan
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp