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
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で指定され、その後ターゲットSIPヘッダ/パラメータの取り扱いを明確にすることを意図しているのRFC 3325と4244.に延長され、セッション開始プロトコル（SIP）のプライバシーメカニズムを使用するためのガイドラインを提供して情報提供文書でありますそしてプライバシーヘッダ値のそれぞれのセッション記述プロトコル（SDP）パラメータ（PRIV-値）。
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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この文書は、後に[RFC3325]及び[RFC4244]に拡張されたセッション開始プロトコル（SIP）[RFC3261]、[RFC3323]で定義され、のプライバシーメカニズムを明らかにする。このドキュメントは、ガイドラインとして、プライバシー機構の業務の実践的な方法を説明し、既存のプライバシーメカニズムは変更されません。
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-値ごとに覆い隠されるべきターゲット情報に関しては、いくつかの曖昧さが存在します明示的に指定されていません。このような曖昧さは、プライバシーヘッダを設定するエンティティで相互運用性に悪影響を及ぼす可能性がありプライバシーヘッダを処理するエンティティの両方、定義PRIV-値のそれぞれについて処理プライバシーの異なる解釈をもたらし得ます。
Additional priv-values "id" and "history" are defined in RFCs 3325 and 4244, respectively.
追加PRIV-値「ID」と「歴史」は、それぞれのRFC 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では、PRIV-値「歴史」の歴史・情報ヘッダーのプライバシーを要求するために定義され、「履歴」PRIV-値のために覆い隠されるべき対象は、唯一の歴史-情報ヘッダーとして指定されています。そして「セッション」レベルのプライバシーが要求されている - また、RFCは明らかに歴史-情報ヘッダーが時に「ヘッダー」も対象であることを説明しています。
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ヘッダのプライバシーを要求するために使用されているP-Asserted-Identityヘッダおよびpriv値「ID」を、定義され、それがどのように他のPRIV-値を指定しません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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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-値：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.
このセクションでは、のRFC 3323、3325に定義されている各PRIV-値のセマンティクスを提供し、4244.説明は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).
プライバシーサービスは、利用者（連絡先/経由）によって任意に設定することはできません[RFC3323]のヘッダーを変更することヘッダー要求。
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]歴史 - インフォメーションヘッダー（S）のために要求された歴史のプライバシー
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.
注：これらの表の範囲は、SIPヘッダおよびRFCで指定された関連するパラメータです。
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:
「ここ」の列は、ヘッダがプライバシーを維持するために、治療を必要とする要求と応答のタイプを記述する。この列の値は次のとおりです。
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.
注：プライバシーサービスコール-IDを変更RFC 3323でセクション5.3に示されているように、それは前者と修正された値を保持する必要のある時間は、それから、コールIDヘッダおよび他の対応するヘッダとパラメータ（前者値を復元する必要がありますこのような発信ユーザエージェントに変更コールIDを使用して送信されるすべてのメッセージにある返信先に、置き換え、およびターゲット・ダイアログ）として。それはまた、コールIDヘッダおよび他の対応するヘッダ/パラメータ変更（例えば、ターゲット対話などを、パラメータ「置き換え」）発信ユーザエージェントによって送信された任意の追加的な関連メッセージでなければなりません。詳細な動作については、セクション5.1.1（コール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.
アイデンティティ/アイデンティティ情報、パス、置き換え、ルート、サービス・ルート、およびターゲット対話ヘッダは、これらの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-値「クリティカル」はプライバシーヘッダーに存在しない場合であっても、重要であるので、それは指定されたプライバシーのレベルのすべてを実行することができないとき、プライバシーサービスは、500応答コードで要求を失敗しますPrivacyヘッダーインチ
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ヘッダ/パラメータに含まれ、どの情報が実際にプライバシーに敏感である場合、ユーザエージェントで情報またはプライバシーサービスのプライバシーを維持することができるユーザのプライバシーに敏感な情報の種類を記載しています。
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.
このセクションでは、プライバシーの考慮事項を説明し、ユーザーがプライバシーに敏感な情報を明らかにすることができる各SIPヘッダの治療をお勧めします。このセクションでは、各ヘッダはプライバシー、ユーザーエージェントとプライバシーサービスによって値の所望の治療、及びプライバシーを提供するために必要な他の命令/補足事項にどのように影響するかについての詳細に入ります。
This field frequently contains an IP address or hostname of a UAC (User Agent Client) appended to the Call-ID value.
このフィールドは、頻繁にコール-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.
独自のユーザーレベルのプライバシ機能を実行するユーザエージェントは、頻繁にコールID値が適当長いランダムな値（のFromヘッダのため「タグ」として使用される値が付加されたIPアドレスまたはホスト名の代わりSHOULD 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.
コールIDでIPアドレスまたはホスト名（このようなタグ値からなど）適切に長いランダムな値を代入することにより、ユーザそれはのように十分に一意になるように：要求はプライバシーが含まれている場合、プライバシーサービスは、コール-IDヘッダを匿名化してもよい（MAY） 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.
コールIDは、ダイアログのマッチングに不可欠なので、いつでもプライバシーサービスは、このフィールドを変更し、それが元の値を保持し、ダイアログ内の発信ユーザエージェントによって/に送信されたメッセージでのCall-IDヘッダにそれを復元しなければなりませんRFC 3323で第5.3節に示されるように、プライバシーサービスは、例えば、イン返信するには、/はReplaces /ターゲット（他のSIPヘッダーにPSによって設定されたコールIDの値を含むダイアログ外リクエストを受信するように準備されるべき-Dialog）、対話状態は、そのコールID、そのPSによって変更されたダイアログのためにアクティブである少なくともつつ。このような要求を受信すると、上記で示した関連のヘッダに含まれるコール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.
注：これは、プライバシーサービスは、状態を維持し、それがプライバシーを提供するために変更されたすべての情報を保持している場合にのみ可能です。いくつかのPSは、この場合には、PSは、元のコールIDで修飾されたコールID値を相関させることができない等、Viaヘッダに先立って難読化に情報を暗号化することが知られています。さらなる課題は、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（イン返信先）の詳細な議論については、5.3.3（Replacesヘッダー/パラメータ）、および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節で示したように、ユーザ：プライバシーサービスは、1つは、ユーザーのプライバシーはプライバシーを要求されたときに存在する場合に、ヘッダーコール情報を削除する必要があります。 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.
このフィールドは、URIは、[RFC3315]をREFERなど、半ばダイアログ要求のために、おそらく外の対話を要求ユーザエージェントに到達するために使用が含まれています。 Contactヘッダは、ユーザエージェントへのさらなる要求をルーティングするために必須であるので、それは匿名化された場合でも、機能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アドレスや連絡先を取得できなければ、ユーザエージェントは、Contactヘッダを匿名化してはいけません。
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が公開されたので、UAは匿名の特性に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.
この記事の執筆時点で議論されているメカニズムは、グローバルにルーティング可能なユーザ短い寿命と機能連絡先アドレスを提供し、エージェントのURI（GRUU）[SIPGRUU]、プライバシーに敏感な通話に最適です、とトラバーサルがNATの周りにリレーを使用していますリレーのIPアドレスがContactヘッダにおける使用のために得ることができ、それを通して（TURN）[TURN]。
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を持つ既存のContactヘッダーフィールド値置き換えることによって、Contactヘッダを匿名化する必要があります：ヘッダを、RFC 3323でセクション5.1に示されているようにこれは、一般的に交換することによって行われますプライバシーサービスのことで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 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.
セクション4.1に示されているように、匿名の表示名と匿名URIは、このセクション用表示名「匿名」、Fromヘッダのユーザ部分に「匿名」とURI、およびホスト名の値「anonymous.invalid」に記載されました。 RFC 3323で1.3。
The recommended form of the From header for anonymity is:
匿名のヘッダからの推奨形です。
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
投稿者： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 1928301774
The tag value varies from dialog to dialog, but the rest of this header form is recommended as shown.
タグ値は、ダイアログのダイアログに変化するが、示されるように、このヘッダフォームの残りの部分が推奨されます。
History-Info [RFC4244] header URIs to which the request was forwarded or retargeted can reveal general routing information.
履歴情報[RFC4244]のヘッダのURIは、要求が転送または一般的なルーティング情報を明らかにすることができる再標的化しました。
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.
ヘッダ、プライバシー：セッション、またはプライバシー：歴史を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に示すように、このような場合には、プライバシーサービスは、歴史・情報エントリを削除する必要があります。
Refer to [RFC4244] for detailed behavior for dealing with History-Info headers.
歴史・情報ヘッダに対処するための詳細な動作については、[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.
イン返信するヘッダが参照されるダイアログのコールIDを含んでいます。返信ユーザは、In-返信先ヘッダー内のCall-IDによって識別することができます。
Alice > INV(Call-ID:C1) > Bob Bob > INV(In-Reply-To:C1) > Alice
アリス> INV（コールID：C1）>ボブボブ> INV（イン返信先：C1）>アリスを
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.
インのReply-Toヘッダーが削除されない限り、この場合、アリスはアリスのUAは、コールIDがボブに関連していることを知っているので、返信、ユーザーがボブであることに気づくかもしれません。
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で暗黙ように、返信先ヘッダーを追加しないでください。
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に示すように：プライバシーサービスは、ユーザーのプライバシーはプライバシーを要求されたときに、Toヘッダには、返信を-削除する必要があります。
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
イン返信するヘッダは、ダイアログのコールIDが含まれているので、セクション5.1.1に記載のように加えて、それが返信された、特別な注意が必要である、（-IDを呼び出し）にかかわらず、PRIV-値または
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.
プライバシーヘッダの存在。プライバシーサービスコール-ID要求内を変更したら、プライバシーサービスは、元の要求に応答INVITE要求内に存在する場合に限り、プライバシーサービスを維持するように、Toヘッダには、返信に元の値を復元する必要があります対話状態。
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
例：アリス> INV（CALL-IDを：C1、プライバシー：ユーザー）> PS> INV（CALL-ID：C2）>ボブボブ> INVを（イン返信-TO：C2、プライバシー：なし）> PS> INV（イン返信先：C1）>アリス
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.
に示すように、ヘッダ：ユーザーのプライバシーはプライバシーを要求されたときにプライバシーサービスは、組織のヘッダを追加しないでくださいRFC 3323に5.3節で示したように、ユーザー：ユーザーのプライバシーはプライバシーを要求されたときに1が存在する場合、プライバシーサービスは、組織ヘッダーを削除しなければなりません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.
RFC 3325にセクション7に示され、ユーザのプライバシーがプライバシーを要求されたときP-アサート - アイデンティティヘッダを削除しなければならないようID：その前にヘッダプライバシーサービスは、ユーザーのプライバシーがプライバシーを要求されたときP-アサート - アイデンティティヘッダを削除する必要があります信頼されていないエンティティにメッセージを転送します。
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ヘッダを取り除くためにプライバシーサービスのために推奨されます。idまたはプライバシー：ヘッダ信頼できるエンティティに転送する場合でも、メッセージがにルーティングされないことを確信できない限り、別のプライバシーサービスを経由せず、信頼できないエンティティ。
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.
送信者にルーティング性を維持しながら録音-Routeヘッダを隠すために、プライバシーサービスは、「ストリッピング」と呼ばれる練習を実行することができます。プライバシーサービスにおけるその到着に先立って要求に追加されたすべてのRecord-Routeヘッダを除去する手段をストリッピングし、次いで、それ自体を表す単一のRecord-Routeヘッダを追加します。この場合、プライバシーサービスは削除のヘッダーを保持し、それに応じてそれらを復元する必要があります。
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.
あるいは、プライバシーサービスは、レコードルートヘッダを除去し、単Record-Routeヘッダフィールドにそれらを暗号化することができます。この場合には、プライバシーサービスは、ヘッダを復号化し、それに応答して元の値を復元する必要があります。
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に示されているように、ヘッダ：プライバシーサービスは、ユーザーのプライバシーがプライバシーを要求されたとき、それはプライバシーサービスに到達する前にメッセージに追加された任意のRecord-Routeヘッダを削除又は暗号化すべきです。
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.
プライバシーサービスは、レコードルートヘッダを変更する場合、RFC 3323いくつかの実施例では、セクション5.1に示されているようにコールIDの場合のように、保持された値とRouteヘッダを復元することができなければならない場合Routeヘッダの復元必要であり、不必要なは以下の通りです。
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（アリス）は、要求のためのプライバシーを必要とする場合、プライバシーサービスは、後続の要求（例1を参照）にRouteヘッダを復元する必要はありません。
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（ユーザエージェントサーバ）（ボブ）は、応答のためのプライバシーを必要とするとき、プライバシーサービスは、後続の要求（例2を参照）にRouteヘッダを復元する必要があります。
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
実施例1：Routeヘッダの復元が不要であるUACはプライバシーアリスが必要> INV（プライバシー：ヘッダ）> P1> INV（レコードルート：P1、プライバシー：ヘッダ）> PS> INV（レコードルート：PS）> P2> INV（レコードルート：P2、PS）>ボブボブ> 200（レコードルート：P2、PS）> P2> PS> 200（レコードルート：P2、PS、P1）> P1>アリスアリス>再INV （ルート：P2、PS、P1、プライバシー：ヘッダ）> P1>再INV（ルート：P2、PS、プライバシー：ヘッダ）> PS>再INV（ルート：P2）> P2>再INV>ボブ
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：例Routeヘッダの復元が不要です
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
実施例2：> P2> INV（レコードルート：P2、P1）>ボブボブ> 200（レコードルート：UASはプライバシーアリス> INV> P1> INV（P1レコードルート）を必要とするときにRouteヘッダの復元が必要ですP2、P1、プライバシー：ヘッダ）> P2> PS '> 200（レコードルート：PS'、P1）> P1>アリスアリス>再INV（ルート：PS」、P1）> P1>再INV（ルート：PS '）> PS'>再INV（ルート：P2）> P2>ボブ
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：例Routeヘッダの復元が必要です
Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-Route header, and R means Route header.
注：図1および図2に、プライベートプライバシー手段：ヘッダ、RRは、Record-Routeヘッダを意味し、Rは、Routeヘッダを意味します。
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.
いう-Byヘッダーは呼ば-ByヘッダーとREFER要求は、そのプライバシー要求されたプライバシーサービスで処理されるユーザ（リファラ）によって送信された場合、匿名化対象です。
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を使用して呼ばバイヘッダを匿名化する必要があり、独自にユーザレベルのプライバシ機能を実行する要求をREFER構築するユーザエージェント。
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を使用して、REFERリクエストに言及-Byヘッダーを匿名化する必要があります。
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.
それはREFER以外の要求で表示されるとき一方、呼ば-Byヘッダーは、匿名化対象でない（例えば、INVITE）と呼ばバイヘッダにおけるURIは、要求の送信者を表していないからです。
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
例1：リファラ要求プライバシーなしと審判の要求のプライバシーアリス> REF（以下バイ：アリス）>ボブボブ> INV（以下-から：アリス、プライバシー：ユーザー）> PS> INV（以下-から：アリス）>キャロル
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
例2：（：アリス、プライバシー：ユーザー呼ば-別）> PS> REF（以下バイ：X）>ボブボブ> INV（以下-で：X、プライバシー：ユーザーリファラは、プライバシーと審判要求プライバシーアリス> REFを要求します）> PS> INV（以下バイ：X）>キャロル
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に示すように：ユーザーのプライバシーはプライバシーを要求されたときにプライバシーサービスは、Subjectヘッダを削除しなければなりません。
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で暗示として、独自のユーザー・レベルのプライバシー機能を実行するユーザエージェントは、User-Agentヘッダを追加してはいけません。
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節で示したように、ユーザー：ユーザーのプライバシーはプライバシーを要求されたときにプライバシーサービスは、User-Agentヘッダを削除しなければなりません。
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.
ユーザーエージェントによって追加のViaヘッダー一番下には、応答のためのユーザエージェントに到達するために使用されている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.
RFC 3323セクション4.1.1.3に示されているように、それがまだ機能している匿名の特性を有しているIPアドレスを取得できなければ、ユーザエージェントは、Viaヘッダを匿名化してはいけません。これは、サービスプロバイダから又はTURNなどの機能のいずれかを介して、この目的のために特別に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.
プライバシーサービスは、ユーザーのプライバシーがプライバシーを要求されたときにプライバシーサービスに到達する前に追加された任意のViaヘッダを削除又は暗号化すべきである：ヘッダをRFC 3323でセクション5.1に示されているように、セクション5.1.9（レコードルート）を参照してくださいストリッピングと暗号化の詳細。
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.
応答を処理するときに何のViaストリッピングは必要ありません。
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.
独自のユーザーレベルのプライバシ機能を実行するユーザエージェントは、警告ヘッダにその識別情報を表すホスト名を含むべきではありません。
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のアイデンティティを表す場合）ホスト名の部分を削除することによって警告ヘッダを匿名化すべきです。
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アドレスとポートを匿名化してはなりませんこの目的のためにいずれかのサービス・プロバイダから又はTURNなどの機能を介して特異的に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アドレスとポートの存在を交換することによって行われます。
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ラインのユーザ名と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.
アイデンティティ[RFC4474]ヘッダーフィールドは、識別情報を検証するために使用される署名を含みます。アイデンティティ-Infoヘッダーフィールドは、Identityヘッダの署名者の証明書への参照を含みます。アイデンティティ-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.
Identityヘッダー内の署名から、に、コールIDを、CSEQ、日付、およびContactヘッダーの上とメッセージ本体の上に完全性保護を提供します。プライバシーサービスは、ユーザーのプライバシー保護のために、これらのヘッダおよび/またはメッセージ本文を変更する場合は、完全性保護が破られます。
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.
（などとコールIDからなど）、それらの整合性が保護ヘッダが変更されると、アイデンティティ/アイデンティティ-Infoヘッダーフィールドはもはや有効ではありません。このように、個人情報保護のための要求に作用するプライバシーサービス：ユーザー、プライバシー：ヘッダー、またはプライバシー：セッションは、Identity /アイデンティティ-Infoヘッダーフィールドを挿入した上流の認証サービスが提供する完全性保護を無効にすることができます。整合性を保持する必要性を保護する場合は、そのようなプライバシーサービスの使用は避けるべきです。プライバシーサービスは、完全性保護を無効にそうでない場合、それはアイデンティティ/アイデンティティ-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.
以下のためのことが可能になりた、：ヘッダフィールドURIからのドメイン名（例えば、「anonymous@example.com一口」）匿名化されていない場合、下流のプライバシーサービスの認証サービスは、Identity /アイデンティティ-Infoヘッダーフィールドを追加することができUACを認証するサービス。これは、Fromヘッダーまだ匿名認証済み「これは私が認証されている自分のドメイン内の既知のユーザーですが、私は民間のアイデンティティを維持しています」RFC 4474でセクション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.
所望の展開は、プライバシーサービスは、前の位置やアイデンティティサービスと同じ場所に配置しているでしょう。このように、整合性とプライバシーの両方をシームレスに提供することができます。
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.
このフィールドは、管理ドメインおよび/またはユーザエージェントの訪問ドメインに関する情報が含まれていてもよいです。しかし、Pathヘッダは任意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.
コールが訪問ドメインに登録UAに到達するためにPathヘッダ[RFC3327]は唯一のREGISTERリクエスト/レスポンスに表示され、必要不可欠であることを考えると、それはPathヘッダに含まれる情報を保留または非表示にする目的を達成しません。むしろ、それは有害です。
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.
Replaces [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.
Replacesヘッダーと、INVITEの送信者は、通常、発信ユーザエージェントないか、または交換するターゲットダイアログのユーザエージェントを終了します。したがって、Replacesヘッダー内の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-値またはプライバシーヘッダの存在を、一度プライバシーサービス要求にコールIDを変更し、それは、Call-IDを含んでいてもよいヘッダを監視する必要があり受信したReplacesヘッダー内の元のCall-ID値に変更コール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.
これが適切に機能するための主な課題は、プライバシーサービスは、すべてのダイアログの発信元にシグナリングパス上でなければならないことです。これは一般的に不可能であり、REFERリクエストの結果は、すべての回で機能していません。これは、プライバシーが課されたときに予想されるトレードオフです。
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項で述べたプライバシー要件は、いくつかの状況では表示されたダイアログの確立に失敗する値を含むようにReplacesヘッダーと「置き換え」パラメータの原因になります。この機能の損失は許さおよび/または上で例示として意図されている（すなわち、これらの機能が常に動作することを保証するためにプライバシーサービスの責任ではありません）。
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.
匿名Replacesヘッダー/パラメータの機能は、それが使用される状況に依存します。仕事も参照するか、次の三つの基準によっては動作しない場合があります。
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.
コールIDを生成した1。 2.プライバシーサービスは、シグナリングパス上にあります。 「置き換え」パラメータでREFER開始3。
A few examples that explore when the Replaces header/parameter works or fails are given below.
Replacesヘッダー/パラメータが動作または失敗したときに探索いくつかの例を以下に示します。
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)
実施例1：発信者によって開始された転送は、PSは最初INVのために添加し、REFアリス> INV（CALL-IDを：C1、プライバシー：ユーザー）> PS> INV（CALL-ID：C2）>ボブアリス> REF（参照の対：ボブ置き換え= C1、プライバシー：ユーザー）> PS> REF（参照の-た：？ボブ置き換え= C2）>キャロルキャロル> INVは（置換：C2）>ボブ（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)
実施例2：> PS> INV（CALL-IDを：C2）>ボブアリス> REF（参照の-TO：発信者によって開始された転送、PSは、第INVアリス> INV（：C1、プライバシーユーザコールID）にのみ添加しました？ボブ置き換え= C1）>キャロルキャロル> INV（置き換え：C1）を>ボブ（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は（つまり、アリスからのINVITEのCall-IDを変更）も参照のために添加しないプライバシーヘッダ内に存在しない場合でも、C2にC1からパラメータを「置き換え」の値を変更した場合、実施例2は、成功しますREFER。
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)
例3：> INV（コールIDを：C1）>ボブアリス> REF（参照してください-た：？ボブ置き換え= C1、プライバシー：発信元によって開始転送、PSは、REFアリス> INV（C1コール-ID）をするためにのみ追加しました：ユーザー）> PS> REF（参照してください-た：？ボブ置き換え= C1）>キャロルキャロル> INVは、（置き換え：C1、プライバシーを：ユーザー）> PS」> INVは、（置き換え：C1）>ボブ（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)
実施例4：> PS> INV（CALL-IDを：C2）>ボブボブ> REF（参照の-TO：PSはINVアリス> INV（：C1、プライバシーユーザコールID）の両方に加え終端パーティによって開始された転送、 ？アリス= C2）>キャロルキャロル> INVは、（置き換え置き換え：C2）> PS> INVは（置換：C1）>アリス（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).
注：同じPS（つまりアリスからのINVITEのCall-IDを変更）着信要求をチェックし、コールIDの元の値にキャロルからのINVITEにReplacesヘッダー内の値を変更するため、実施例4に成功した（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)
実施例5：> PS> INV（CALL-IDを：C2）>ボブアリス> REF（参照の-TO：ボブ置き換え=ホールド、PSは、第INVアリス> INV（：C1、プライバシーユーザコールID）にのみ添加しましたC1）>音楽・サーバーのミュージック・サーバー> INVは（置き換え：C1）>ボブ（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.
注：同じPSをするために添加される（すなわち、アリスからのINVITEのCall-IDを変更した場合）実施例5は、成功する音楽サーバからINVITE及びC2へC1からReplacesヘッダー内の値を修正します。
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.
上記の例が示すように、いくつかのシナリオでは、情報は、REFERの故障につながるReplacesヘッダー/パラメータで運ば。コール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.
このフィールドは、ユーザエージェントの管理ドメインについての情報を含んでいてもよいが、Routeヘッダは、任意の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.
Routeヘッダには、プロキシのリストされたセットを介してルーティング強制するSIPリクエストにのみ現れます。プライバシーサービスは、Routeヘッダを匿名化した場合、ルーティングは機能しません。 RFC 3261で定義されているプロキシは、要求-URIの値を置換するRouteヘッダから値を除去するため、さらに、終端ユーザエージェントを含む更なるネットワークエンティティにRouteヘッダ内の情報を明らかに危険がなく、 。
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.
レコードルートヘッダを変更するプライバシーサービスは、必要に応じてRouteヘッダの値を復元する必要があるかもしれません。 RFC 3323でセクション5.1で示したようにプライバシーサービスは、録音-Routeヘッダを修正した場合、保持値でRouteヘッダを復元することができなければなりません。さらに詳細と例については、セクション5.1.9（レコード・ルート）を参照してください。
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.
サービス-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.
Replacesヘッダーに見られるように、ターゲット・ダイアログ[RFC4538]ヘッダーは全く同じ問題に直面しています。これは、特定のPRIV-値のための目標とどのようにプライバシーサービスは、まだプライバシーが要求されていない場合でも、評価し、含まれている値を変更する必要がない理由については、セクション5.3.3（Replacesヘッダー/パラメータ）を参照してください。
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.
作者は彼らのレビューとコメントのためにジョンエルウェル、ジョンピーターソン、ジョナサン・ローゼンバーグ、メアリー・バーンズ、ポールKyzivat、およびローランドJesskeに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（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]バーンズ、M.、エド。、 "リクエスト履歴情報のためのセッション開始プロトコル（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.
[TURN]ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、 "トラバーサルNAT（TURN）の周りにリレーを使用する：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]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）の取得と使用" を参照してください。
[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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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]ウィリス、D.とB. Hoeneisen、 "セッション開始プロトコル非隣接コンタクトを登録するための（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]ウィリス、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]マーイ、R.、ビッグス、B.、およびR.ディーン、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[RFC3892]スパークス、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538]、RFC 4538、2006年6月ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）におけるダイアログ識別介して要求承認"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
Authors' Addresses
著者のアドレス
Mayumi Munakata NTT Corporation
まゆみ むなかた んっｔ こｒぽらちおん
Phone: +81 422 36 7502 EMail: munakata.mayumi@lab.ntt.co.jp
電話：+81 422 36 7502 Eメール：munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
市大SバートNTT法人
EMail: shida@ntt-at.com
メールアドレス：shida@ntt-at.com
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
電話：+81 422 59 7748 Eメール：ohba.takumi@lab.ntt.co.jp