Network Working Group J. Peterson
Request for Comments: 3323 Neustar
Category: Standards Track November 2002
A Privacy Mechanism for the Session Initiation Protocol (SIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
この文書では、プライバシーのサポートにセッション開始プロトコル（SIP）のための新しいメカニズムを定義します。具体的には、ガイドラインは、個人識別情報を漏らさないメッセージの作成のために設けられています。仲介のための新しい「プライバシーサービス」論理的な役割は、ユーザーエージェントが自分自身を満たすことができないいくつかのプライバシー要件に答えるように定義されています。最後に、手段は、ユーザがプライバシーサービスから特定の機能を要求できるが提示されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . 4
3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . 5
3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . 6
3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . 7
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
4.1 Constructing Private Messages . . . . . . . . . . . . . . 8
4.1.1 URIs, Display-Names and Privacy . . . . . . . . . . . . . 8
4.1.1.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . 9
4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . 11
4.3 Routing Requests to Privacy Services . . . . . . . . . . . 12
4.4 Routing Responses to Privacy Services . . . . . . . . . . 13
5. Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
5.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . 17
5.3 Applying User-Level Privacy Functions. . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
This document provides privacy requirements and mechanisms for the Session Initiation Protocol (SIP).
この文書では、セッション開始プロトコル（SIP）のためのプライバシー要件とメカニズムを提供します。
Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. As identity is defined in this document, withholding the identity of a user will, among other things, render the other parties in the dialog unable to send new SIP requests to the user outside of the context of the current dialog.
プライバシーは、特にSIPダイアログ通信の交換を、1つのまたは複数の当事者からの人の身元（および関連する個人情報）の源泉として、この文書で定義されています。これらの当事者は、潜在的メッセージおよび/または、これらのメッセージを処理する任意の仲介者の意図した目的地（複数可）を含んでいます。アイデンティティは、この文書で定義されたように、ユーザのアイデンティティを源泉徴収することは、とりわけ、現在のダイアログのコンテキスト外のユーザーに新しいSIPリクエストを送信することができませんでしダイアログ内の他の当事者をレンダリングします。
In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name. A SIP address-of-record has a form similar to an email address with a SIP URI scheme (for example, sip:alice@atlanta.com). A display-name is a string containing a name for the identified user (for example, "Alice"). SIP identities of this form commonly appear in the To and From header fields of SIP requests and responses. A user may have many identities that they use in different contexts.
SIPにおいては、同一性は、最も一般的にSIP URIおよびオプションの表示名の形で実施されます。 SIPアドレス・オブ・レコードは、SIP URIスキーム（：alice@atlanta.com例えば、SIP）を用いて電子メールアドレスに類似した形状を有しています。表示名は、識別されたユーザ（例えば、「アリス」）の名前を含む文字列です。この形式のSIPアイデンティティは、一般的にし、SIPリクエストとレスポンスのヘッダフィールドから表示されます。ユーザーは、異なるコンテキストで使用する多くのアイデンティティを持っていることがあります。
There are numerous other places in SIP messages in which identity-related information can be revealed. For example, the Contact header field contains a SIP URI, one that is commonly as revealing as the address-of-record in the From. In some headers, the originating user agent can conceal identity information as a matter of local policy without affecting the operation of the SIP protocol. However, certain headers are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data.
アイデンティティ関連情報を明らかにすることが可能なSIPメッセージで、他の多くの場所があります。例えば、コンタクトヘッダフィールドは、SIP URI、アドレス・オブ・レコードからのように明らかように、一般的であるものを含んでいます。いくつかのヘッダーでは、元のユーザエージェントは、SIPプロトコルの動作に影響を与えることなく、ローカルポリシーの問題として識別情報を隠すことができます。しかし、特定のヘッダは、ダイアログ内の後続のメッセージのルーティングに使用され、したがって機能的データで埋めなければなりません。
The privacy problem is further complicated by proxy servers (also referred to in this document as "intermediaries" or "the network") that add headers of their own, such as the Record-Route and Via headers. Information in these headers could inadvertently reveal something about the originator of a message; for example, a Via header might reveal the service provider through whom the user sends requests, which might in turn strongly hint at the user's identity to some recipients. For these reasons, the participation of intermediaries is also crucial to providing privacy in SIP.
プライバシーの問題は、このようなレコード・ルートおよびヘッダなどを介して自分自身のヘッダを追加している（また、「仲介」または「ネットワーク」として、この文書で言及）プロキシサーバによってさらに複雑です。これらのヘッダの情報が誤ってメッセージの発信について何かを明らかにできました。例えば、Viaヘッダは、ユーザーが順番に強く、一部の受信者にユーザーのIDをほのめかすかもしれない要求を、送信者を介してサービスプロバイダを明らかにするかもしれません。これらの理由から、仲介者の参加もSIPにプライバシーを提供するために重要です。
Two complimentary principles have guided the design of this privacy mechanism: Users are empowered to hide their identity and related personal information when they issue requests, but intermediaries and designated recipients of requests are entitled to reject requests whose originator cannot be identified.
2つの相補原則は、このプライバシー機構の設計を導いている：ユーザーは、彼らが要求を発行したときに自分のアイデンティティと関連する個人情報を隠すために権限を与えているが、仲介や要求の指定した受信者は、その発信元を特定できない要求を拒否する権利があります。
The privacy properties of only those specific headers enumerated in the core SIP specification ([1]), as opposed to headers defined by any existing or planned extension, are discussed in this document - however, the privacy mechanisms described in this document can be extended to support extensions.
コアSIP仕様で列挙のみ特定ヘッダのプライバシー特性（[1]）、既存のまたは計画された拡張によって定義されたヘッダとは対照的に、この文書に記載されているが - しかし、この文書に記載されプライバシーメカニズムを拡張することができます拡張をサポートします。
There are other aspects of the general privacy problem for SIP that are not addressed by this document. Most significantly, the mechanisms for managing the confidentiality of SIP headers and bodies, as well the security of session traffic, are not reconsidered here. These problems are sufficiently well addressed in the baseline SIP specification and related documents, and that no new mechanisms are required.
本書で扱われていないSIPのための一般的なプライバシーの問題の他の側面があります。最も重要なのは、SIPヘッダとボディの機密性を管理するためのメカニズムは、同様にセッショントラフィックのセキュリティは、ここで再検討されていません。これらの問題は十分にベースラインSIP仕様および関連するドキュメントで対処されており、新たなメカニズムが必要とされていないこと。
This document begins with a section that provides a general framework and architecture for privacy in SIP (Section 3), followed by sections that detail user agent behavior (Section 4) and privacy service behavior (Section 5).
このドキュメントは、セクションに続くSIP（セクション3）におけるプライバシーのための一般的なフレームワークとアーキテクチャを提供セクション、詳細ユーザーエージェントの動作（第4章）およびプライバシーサービスの動作（セクション5）から始まります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[2] BCP 14、RFC 2119に記載されるように解釈されるべきであり、準拠SIP実装の要求レベルを示します。
A user may possess many identities that are used in various contexts; generally, identities are addresses-of-record which are bound to particular registrars (operated by the administrators of a domain) with whom SIP user agents register. The operators of these domains may be employers, service providers, or unaffiliated users themselves.
ユーザーは、さまざまなコンテキストで使用されている多くのアイデンティティを有することができます。一般的に、アイデンティティは、アドレス・オブ・レコードのSIPユーザエージェントは、登録者で（ドメインの管理者が運営）特定の登録機関にバインドされています。これらのドメインの事業者は雇用者、サービスプロバイダ、または非関連ユーザー自身かもしれません。
When a user voluntarily asserts an identity in a request, they are claiming that they can receive requests sent to that identity in that domain. Strictly speaking, privacy entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message. In particular, there are scenarios in which a party desiring anonymity may:
ユーザーが自発的に要求にアイデンティティを主張するとき、彼らはそのドメイン内のそのIDに送信された要求を受信できることを主張しています。厳密に言えば、プライバシーはいくつかの特定の政党や潜在的に、メッセージの受信者です関係者から特定のアイデンティティと関連する個人情報の配信の制限を伴います。具体的には、当事者は匿名の月を希望するシナリオがあります。
send a message and withhold an identity from the final destination(s) while still communicating an identity to one or more intermediaries
メッセージを送信し、更に一つ以上の仲介にアイデンティティを通信しながら、最終的な宛先（複数可）からのアイデンティティを保留
send a message and withhold their identity from some or all intermediaries, but still communicate an identity end-to-end to the final destination(s)
メッセージを送信し、一部またはすべての仲介から自分のアイデンティティを保留、まだ最終的な宛先（複数可）に同一のエンド・ツー・エンドの通信
withhold identity from both intermediaries and final destination(s)
仲介及び最終的な宛先（複数可）の両方からのアイデンティティを保留
The result of withholding an identity is that the parties in question would be unable, for example, to attempt to initiate a new dialog with the anonymous party at a later time. However, the anonymous party still must be capable of receiving responses and new requests during the dialog in which it is participating.
身元を源泉徴収した結果は、問題の当事者が後で匿名党との新しい対話を開始することを試みること、たとえば、できないであろうということです。しかし、匿名党はまだそれが参加しているダイアログの間に応答して、新しい要求を受信することが可能でなければなりません。
It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms.
要求と応答の両方のアイデンティティ情報を制限することが望ましい場合があります。最初は、応答がプライバシーの問題があることを示唆していることも珍しく思えるかもしれない - おそらく、要求の発信元が知っている、彼らが連絡しようとしていたので、回答者の身元はほとんど機密になることはできません。しかしながら、（例えば、回答者が現在登録された連絡先など）応答の一部の個人情報は、プライバシーの懸念を受け、これらのメカニズムによって対処することができます。
Users may wish for identity information to be withheld from a given party for any number of reasons, for example:
ユーザーは、たとえば、任意の数の理由のために与えられた当事者から天引きされる識別情報を望むことがあります。
Users might want to contact a particular party without revealing their identity in order to impart information with which they would not like to be associated
ユーザーは、彼らが関連していることが好きではないと思われるとの情報を付与するために自分の身元を明らかにすることなく、特定の政党に連絡する場合があります
Users might fear that the exposure of their identity or personal information to some networks or destinations will make them a target for unsolicited advertising, legal censure or other undesirable consequences
ユーザーは、いくつかのネットワークまたは宛先への自分のIDや個人情報の暴露は、それらの迷惑な広告のターゲット、法的非難または他の望ましくない結果になりますことを恐れるかもしれません
Users might want to withhold from participants in a session the identity by which they are known to network intermediaries for the purposes of billing and accounting
ユーザーは、セッションの参加者から、彼らが課金および会計の目的のためにネットワークの仲介に知られていることでアイデンティティを保留する場合があります
When a user agent decides to send a request through a proxy server, it may be difficult for the originator to anticipate the final destination of that message. For that reason, users are advised not to base their estimation of their privacy needs on where they expect a message will go. For example, if a user sends a request to telephone number, they may believe that the final destination of the request will be a station in the public switched telephone network (PSTN) that is unable to inspect, say, SIP Contact headers, and therefore assume that it is safe to leave such headers in the clear; however, such a request might very well end up being retargeted by the network to a native SIP endpoint to which Contact headers are quite legible.
ユーザエージェントは、プロキシサーバを介して要求を送信することを決定するときに発信者がそのメッセージの最終的な目的地を予測することが困難であってもよいです。そのため、ユーザーは自分のプライバシーの彼らの推定は、彼らはメッセージが行くことを期待する場所に必要基づかしないことをお勧めします。ユーザが電話番号に対して要求を送信した場合、例えば、それらは、要求の最終宛先が公衆にステーションが言う、検査することができない電話網（PSTN）、SIP連絡先ヘッダを切り替え、そのためであろうと信じていてもよいです明らかに、このようなヘッダを残すために安全であることを前提としています。しかし、そのような要求は非常によく連絡先ヘッダーはかなり読みやすいこれにネイティブのSIPエンドポイントにネットワークでリターゲットされてしまうかもしれません。
This document describes three degrees of privacy - one level of user-provided privacy, and two levels of network-provided privacy (header privacy and session privacy). How much privacy does a user need for any given session? Generally, if a user is seeking privacy, they're going to need as much of it as they can get. However, if a user knows of no privacy service, they must be content with user-provided privacy alone. Similarly, if a user knows of an anonymization service that can provide session privacy, but is unable to secure session traffic to prevent the anonymizer from possibly eavesdropping on the session, they might judge the loss of session privacy to be the lesser evil. The user might also be aware of exceptional conditions about the architecture in which the user agent is deployed that may obviate one or more privacy concerns.
ユーザ提供のプライバシーのレベル、およびネットワークが提供するプライバシー（ヘッダプライバシーおよびセッションプライバシー）2つのレベル - この文書では、プライバシーの3度を記述する。ユーザーが任意のセッションのためにどのくらいのプライバシーを必要とするのか？ユーザーがプライバシーを求めている場合は、一般的に、彼らは、彼らが得ることができるとして、それをできるだけ多く必要になるだろう。ユーザーは、プライバシーなしのサービスを知っている場合は、彼らだけでは、ユーザ提供のプライバシーとの内容でなければなりません。ユーザーはセッションのプライバシーを提供することができます匿名化サービスを知っているが、おそらくセッションで盗聴からアノニマイザーを防ぐために、セッショントラフィックを確保することができない場合は同様に、彼らはより小さな悪であることをセッションのプライバシーの損失を判断することがあります。また、ユーザーは、ユーザー・エージェントは、1つのまたは複数のプライバシーの問題を未然に防ぐことがあり、その展開されているアーキテクチャに関する例外条件を知っている可能性があります。
A user may not always be the best judge of when privacy is required even under ideal circumstances, and thus privacy may in some architectures by applied by intermediaries without the user's explicit per-message request. By sending a request through intermediaries that can provide a privacy role, the user tacitly permits privacy functions to be invoked as needed.
ユーザーは、常にプライバシーがさえ理想的な状況下で必要とされるときの最高裁判官なるため、プライバシー、ユーザーの明示的なメッセージごとの要求なしに仲介によって適用することにより、いくつかのアーキテクチャではないかもしれないことがあります。プライバシーの役割を提供することができ仲介を通じてリクエストを送信することにより、ユーザーは、暗黙のうち、必要に応じて、プライバシー機能が起動することを可能にします。
It is also important that users understand that intermediaries may be unable to provide privacy functions requested by users. Requests for privacy may not be honored due to legal constraints, unimplemented or misconfigured features, or other exceptional conditions.
これにより、ユーザーは仲介は、ユーザーによって要求されたプライバシー機能を提供することができない可能性があることを理解することも重要です。プライバシーのための要求は法律上の制約、実装されていないか、誤って設定機能、またはその他の例外条件に尊重されない場合があります。
Note that just as it is the prerogative of a user to conceal their identity, so it must also be the prerogative of proxy servers and other users to refuse to process requests from users whom they cannot identify. Therefore users should not just automatically withhold their identity for all requests and responses - inability to ascertain the identity of the originator of the request will frequently be grounds for rejection. Privacy should only be requested when the user has a need for it.
自分のアイデンティティを隠すために、ユーザの特権であるのと同様なお、また、彼らは識別できないユーザからの要求を処理することを拒否するためにプロキシサーバや他のユーザーの特権である必要があります。したがって、ユーザーはただ、自動的にすべての要求と応答のために自分のアイデンティティをご遠慮べきではありません - 要求の発信元の身元を確認できないことが頻繁に拒否の理由になります。ユーザーがそれを必要としている時に個人情報保護にのみ要求されなければなりません。
Further to this point, withholding some information in signaling might not be necessary for all user agents to ensure privacy. For example, user agents may acquire their IP addresses and hostnames dynamically, and these dynamic addresses may not reveal any information about the user whatsoever. In these cases, restricting access to hostnames (as described in Section 4.1.1.3) is unnecessary.
すべてのユーザエージェントがプライバシーを確保するためにさらに、この時点まで、シグナリングにいくつかの情報を源泉徴収する必要はないかもしれません。例えば、ユーザエージェントは、動的にIPアドレスとホスト名を取得してもよいし、これらの動的アドレスは全く利用者に関する情報を明らかにしなくてもよいです。これらのケースでは、（セクション4.1.1.3に記載されているように）ホスト名へのアクセスを制限することは不要です。
There is a certain amount of privacy that a user agent can provide itself. For example, the baseline SIP specification permits a user agent to populate the From header field of a request with an anonymous value. Users can take similar steps to avoid revealing any other unnecessarily identity information in related SIP headers (this is discussed further in Section 4.1.1).
ユーザエージェントは、それ自体を提供することができ、プライバシーの一定量があります。例えば、ベースラインSIP仕様は匿名の値を持つリクエストのヘッダフィールドから移入するユーザエージェントを可能にします。ユーザは関連SIPヘッダ（これは、セクション4.1.1でさらに議論される）内の任意の他の不必要な識別情報を明らかに回避するために同様の手順をとることができます。
A user may have different privacy needs for a message if it traverses intermediaries rather than going directly end-to-end. A user may attempt to conceal things from intermediaries which are not concealed from the final destination, and vice versa. For example, using baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to-end in order to prevent intermediaries from inspecting them. If a SIP message will not pass through intermediaries, however, this step might not be necessary (i.e., lower-layer security, without the addition of security for SIP bodies, could be sufficient).
それはむしろ、エンドツーエンドで直接行くよりも、仲介を横断場合、ユーザーは、メッセージごとに異なるプライバシーのニーズを有することができます。ユーザが最終目的地、およびその逆から隠されていない媒体から物事を隠すことを試みることができます。例えば、ベースラインSIPメカニズムを使用して、ユーザエージェントは、SIP本体は、エンドツーエンドそれらを検査から仲介することを防止するために暗号化することができます。 SIPメッセージが仲介を通過しない場合は、しかし、このステップは必要ではないかもしれない（すなわち、下位層セキュリティ、SIP体のためのセキュリティを添加することなく、十分かもしれません）。
Also note that if a dialog goes directly end-to-end between participants, however, it will not be possible to conceal the network addresses of the participants.
また、ダイアログが直接エンドツーエンドの参加者の間になった場合、しかし、参加者のネットワークアドレスを隠すことができなくなりますのでご注意。
If a user is sending a request through intermediaries, a user agent can conceal its identity to only a limited extent without the intermediaries' cooperation. Also, some information can only be concealed from destination endpoints if an intermediary is entrusted to remove it.
ユーザーが仲介を通じてリクエストを送信している場合、ユーザエージェントは、仲介の協力なしに限られた範囲でのみ、その身元を隠すことができます。仲介は、それを削除するために委託された場合にも、いくつかの情報は、宛先エンドポイントから隠蔽することができます。
For these reasons a user must have a way to request privacy from intermediaries, a means that allows users both to signal some indications of the desired privacy services, and to ensure that their call is routed to an intermediary that is capable of providing these services. A user may be aware of a specific third-party anonymizing host, one with which they have a pre-existing relationship, or a user may request that their local administrative domain provide privacy services.
これらの理由から、ユーザが仲介からプライバシーを要求する方法、ユーザーが両方の希望プライバシーサービスのいくつかの兆候を合図することを可能にする手段を持っている必要があり、その呼び出しは、これらのサービスを提供することが可能である仲介者にルーティングされていることを確認します。ユーザーはその一つで、彼らは既存の関係を持って、特定のサードパーティの匿名化ホストを認識しても、またはユーザーが自分のローカル管理ドメインは、プライバシーサービスを提供することを要求することができます。
Intermediaries may also be empowered to apply privacy to a message without any explicit signaling from the originating user, since user agents may not always be cognizant or capable of requesting privacy when it is necessary.
仲介者は、ユーザエージェントが常に認識し、またはそれが必要である場合、プライバシーを要求することができない可能性があるため、元のユーザからの明示的なシグナリングなしメッセージにプライバシーを適用する権限を与えてもよいです。
There are three different ways that a user agent can contribute to the privacy of a request - by populating headers with values that reflect privacy requirements, by requesting further privacy services from the network, and by using cryptographic confidentiality to secure headers and bodies. Note that the last of these is outside the scope of this document.
プライバシー要件を反映した値でヘッダを取り込むことで、ネットワークからさらにプライバシーサービスを要求することによって、ヘッダとボディを保護するために暗号化機密性を使用して - ユーザエージェントは要求のプライバシーに貢献することができる3つの異なる方法があります。これらの最後には、この文書の範囲外であることに注意してください。
The mechanisms provided in this section assume that a user agent is sufficiently configurable that a user can select header values and provision privacy preferences (ideally on a per-call basis). If this isn't the case, it is possible that a user can route their call through a privacy service that is configured to groom signaling from this user agent in order to provide some of the function described below (see Section 5).
このセクションで提供されるメカニズムは、ユーザエージェントは、ユーザが（理想的には、コールごとに）ヘッダの値と提供プライバシー設定を選択することができることは十分に構成可能であると仮定する。そうでない場合、ユーザは、ルート以下に説明する機能の一部を提供するために、このユーザエージェントからのシグナリンググルーミングするように構成されたプライバシーサービスを通じてコール（セクション5を参照）ことが可能です。
Privacy starts with the user agent. The bulk of the steps that are required to conceal private information about the sender of a message are, appropriately enough, the sender's responsibility.
プライバシーはユーザーエージェントから始まります。メッセージの送信者に関する個人情報を隠すために必要な手順の大部分は、適切に十分に、送信者の責任です。
The following SIP headers, when generated by a user agent, can directly or indirectly reveal identity information about the originator of a message: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning. Note that the use of an authentication system (such as the SIP Digest authentication method described in [1]) also usually entails revealing identity to one or more parties; for more information see Section 6.
以下のSIPヘッダー、ユーザエージェントによって生成されたときに、直接または間接的にメッセージの発信についての識別情報を明らかにすることができます、連絡先、からの返信-TOを介して、コール情報、ユーザーエージェント、組織、サーバー、件名、コールIDを、イン返信先と警告。 （例えば、[1]に記載のSIPダイジェスト認証方式として）認証システムの使用はまた、通常、1つのまたは複数の当事者に現出アイデンティティを伴うことに注意してください。詳細については、セクション6を参照してください。
The first and most obvious step is that user agents SHOULD not include any optional headers that might divulge personal information; there's certainly no reason for a user seeking privacy to include a Call-Info. Secondly, the user SHOULD populate URIs throughout the message in accordance with the guidelines given in Section 4.1.1. For example, users SHOULD create an anonymous From header field for the request. Finally, users MAY also need to request certain privacy functions from the network, as described in Section 4.2.
最初の、そして最も明白なステップは、ユーザエージェントは、個人情報を漏らす可能性のあるオプションのヘッダを含むべきではないということです。コール情報を含めるようにプライバシーを求めているユーザーのための理由は確かにありません。第二に、ユーザーは4.1.1節で与えられたガイドラインに従ってメッセージ全体のURIを投入すべきです。たとえば、ユーザーがリクエストのヘッダフィールドから匿名を作成する必要があります。最後に、ユーザーはまた、4.2節で説明したように、ネットワークから特定のプライバシー機能を要求する必要があるかもしれません。
The Call-ID header, which is frequently constructed in a manner that reveals the IP address or hostname of the originating client, requires special mention. User agents 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).
頻繁に元のクライアントのIPアドレスまたはホスト名を明らかにする方法で構築されたのCall-IDヘッダは、特別な言及が必要です。ユーザエージェントはしばしば適切長いランダム値（リクエストのFromヘッダのための「タグ」として使用される値をも再利用されるかもしれない）のCall-ID値に追加されたIPアドレスまたはホスト名の代わりにすべきです。
Note that if the user wants to conceal any of the above headers from intermediaries alone, without withholding them from the final destination of the message, users MAY also place legitimate values for these headers in encapsulated 'message/sip' S/MIME bodies as described in Section 23 of [1].
ユーザーは、メッセージの最終的な目的地からそれらを源泉徴収することなく、単独の仲介から、上記のヘッダのいずれかを隠すために望んでいるならば説明するように、ユーザはまた、カプセル化された「というメッセージ/一口」S / MIMEボディでこれらのヘッダーのための正当な値を置くかもしれないことに注意してくださいセクション23 [1]。
A certain amount of privacy can be afforded by choosing to populate SIP headers with URIs and display-names that do not reveal any identity information. In some of the header fields (for example, the Reply-To and From headers), URIs are not used in further signaling within the current dialog. In others, like the Contact header, an inaccurate URI will result in a failure to route subsequent requests within the dialog.
プライバシーの一定量は、任意のID情報を明らかにしないURIと表示名を持つSIPヘッダを移入するために選択することによって与えられることができます。ヘッダーフィールド（例えば、返信するためのヘッダーから）の一部では、URIは現在のダイアログ内でさらにシグナリングに使用されません。他では、Contactヘッダーのように、不正確なURIは、ダイアログ内のルート後続の要求に失敗します。
It is a relatively common practice in email and other applications to use an assumed name in the display-name component of the From header field. Outside of a business context (especially in applications such as instant messaging or Internet gaming) the use of such aliases is unlikely to provide a cause for distrust.
これは、電子メールやFromヘッダフィールドの表示名コンポーネントで想定名を使用する他のアプリケーションでは比較的一般的です。 （特に、インスタントメッセージングやインターネットゲームなどのアプリケーションで）ビジネス・コンテキストの外では、このようなエイリアスの使用は不信の原因を提供することはほとんどありません。
It is RECOMMENDED that user agents seeking anonymity use a display-name of "Anonymous".
匿名性を求めているユーザエージェントは「匿名」の表示名を使用することをお勧めします。
The structure of a URI itself can reveal or conceal a considerable amount of personal information. Consider the difference between:
URI自体の構造が明らかに個人情報のかなりの量を隠すことができます。違いを考えてみます。
sip:jon.peterson@neustar.biz
SIP：jon.peterson@neustar.biz
and
そして
sip:a0017@anonymous-sip.com
SIP：a0017@anonymous-sip.com
From the former, the full name and employer of the party in question can easily be guessed. From the latter, you learn nothing other than that the party desires anonymity. In some cases, sufficient anonymity can be achieved by selecting an oblique URI. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header.
元からは、問題の当事者のフルネームと雇用者は容易に推測することができます。後者からは、当事者が匿名を希望していること以外には何も学びません。いくつかのケースでは、十分な匿名性は、斜めURIを選択することによって達成することができます。今日では、SIPの仕様では、Fromヘッダのユーザ部分に「匿名」のURIをお勧めします。
In some URIs, such as those that appear in Contact headers, it MAY also make sense to omit the username altogether, and provide only a hostname, like: sip:anonymous-sip.com
SIP：anonymous-sip.comなコンタクトヘッダに表示されているものなど、いくつかのURIでは、それはまた、完全にユーザー名を省略し、同様に、ホスト名のみを提供するために、意味を行うことができます
It is assumed by this document that the user that requests privacy wishes to receive future requests and responses within this dialog, but does not wish to reveal an identity that could be used to send new requests to him outside the scope of this dialog. For that reason, different treatment must be recommended for URIs that are used in the context of routing further requests in the dialog, as opposed to routing new requests outside the context of the dialog.
それは、プライバシーを要求したユーザがこのダイアログの中に今後の要求と応答を受信したいが、このダイアログの範囲外で彼に新しい要求を送信するために使用することができ身元を明らかにしたくない、この文書が想定されます。ダイアログのコンテキスト外で新しい要求をルーティングとは対照的に、そのため、異なる処理は、ダイアログの更なる要求のルーティングのコンテキストで使用されたURIのために推奨されている必要があります。
For headers indicating how the user would like to be contacted for future sessions (such as the From header), it might not immediately be obvious why changing the hostname would be necessary - if the username is 'anonymous', requests will not be routable to the anonymous user.
ホスト名を変更することが必要となる理由を、ユーザが（例えばFromヘッダなど）、将来のセッションのために連絡することを希望かを示すヘッダのために、それはすぐに明らかではないかもしれない - ユーザ名が「匿名」である場合、要求はにルーティング可能ではありません匿名ユーザー。
Sometimes, merely changing the username will not be enough to conceal a user's identity. A user's SIP service provider might decisively reveal a user's identity (if it reflected something like a small company or a personal domain). So in this case, even though the URI in the From header would not dereference to the anonymous user, humans might easily guess the user's identity and know the proper form of their address-of-record.
時には、単にユーザ名を変更すると、ユーザーの身元を隠すために十分ではありません。 （それは小さな会社や個人のドメインのようなものを反映している場合）、ユーザーのSIPサービスプロバイダは、決定的に、ユーザーの身元を明らかにするかもしれません。したがって、この場合には、URIは、Fromヘッダ匿名ユーザーにない間接参照は、人間がユーザーのIDを推測しやすいかもしれないでしょうにもかかわらず、そのアドレスのレコードの適切な形式を知っています。
For these reasons, the hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs (see [3] for more information about the reserved 'invalid' DNS TLD). The full recommended form of the From header for anonymity is (note that this From header, like all others, MUST contain a valid and unique 'tag=' parameter):
これらの理由から、ホスト名の値 'anonymous.invalidは匿名ユーザのURIのために使用されるべきである（予約「無効」のDNS TLDの詳細については、[3]を参照）。匿名性のためのFromヘッダーの完全な推奨形式は、（これは、ヘッダから、他のすべてのように、有効な一意の「タグ=」パラメータを含まなければならないことに注意してください）です。
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
投稿者： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 1928301774
For headers indicating how further requests in the current dialog should be routed (namely the Contact header, Via header, and session information in the SDP), there seems to be little that a user can do to disguise the existing URI, because users MUST provide a value that will allow them to receive further requests. In some cases, disguising or failing to provide the username, as described above, may create some level of privacy, but the hostname provides a more significant obstacle.
現在のダイアログのさらなる要求が（Viaヘッダー、つまりContactヘッダを、そしてSDPのセッション情報）ルーティングされるべきかを示すヘッダについては、ユーザーが提供しなければならないので、ユーザーは既存のURIを偽装するために行うことができることはほとんどがあるように思われます彼らはさらに要求を受信することができます値。いくつかのケースでは、上述したように、偽装またはユーザ名を提供するために失敗し、プライバシーのいくつかのレベルを作成するが、ホスト名は、より重大な障害を与えることができます。
Is there much additional privacy in using an IP address rather than a hostname? It does prevent someone who casually inspects a message from gathering information that they might see otherwise. However, reverse-resolving such addresses is generally trivial, and substituting an IP address for a hostname could introduce some complications, for example due to NAT and firewall traversal concerns. Headers used in routing may also rely on certain DNS practices to provide services that would be lost if an IP address is used in place of a hostname.
ホスト名ではなくIPアドレスを使用して多くの追加のプライバシーはありますか？それは何気なく、彼らがそうでなければ見るかもしれないという情報を収集からのメッセージを検査し、誰かを防ぐありません。しかし、逆分解そのようなアドレスは、一般的には簡単ですし、ホスト名のIPアドレスを置換することにより、NATやファイアウォールトラバーサルの懸念に例えば、いくつかの合併症をもたらす可能性があります。ルーティングに使用されるヘッダは、IPアドレスがホスト名の代わりに使用された場合に失われることになり、サービスを提供するために、特定のDNS慣行に依拠することができます。
This document thus recommends that the host portion of URIs that are used in the routing of subsequent requests, such as URIs appearing in the Contact header, SHOULD NOT be altered by the user agent due to privacy considerations. If these headers require anonymization, the user requests that service from an intermediary, namely a privacy service.
この文書では、このようにして、コンタクトヘッダに出現するURIとして後続の要求のルーティングに使用されるURIのホスト部分は、によりプライバシーの考慮にユーザエージェントによって変更されるべきではないことをお勧めします。これらのヘッダは、匿名を要求した場合、ユーザーは、仲介、つまりプライバシーサービスからそのサービスを要求します。
Note that many of the considerations regarding the Contact header above apply equal well to SIP headers in which a hostname, rather than a URI, is used for some routing purpose (namely the Via header).
上記Contactヘッダに関する考慮事項の多くは、ホスト名にSIPヘッダに等しく良好に適用されることに注意してください、むしろURIより、いくつかのルーティング目的（即ちビアヘッダ）のために使用されます。
There are some headers that a user agent cannot conceal itself, because they are used in routing, that could be concealed by an intermediary that subsequently takes responsibility for directing messages to and from the anonymous user. The user agent must have some way to request such privacy services from the network. For that purpose, this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses.
その後に、匿名ユーザーからのメッセージを導くための責任を取るの仲介によって隠すことができ、彼らがルーティングに使用されているため、ユーザエージェントは、それ自身を隠すことができないいくつかのヘッダーがあります。ユーザエージェントは、ネットワークからそのようなプライバシーサービスを要求するいくつかの方法を持っている必要があります。そのために、このドキュメントでは、要求と応答のために取り扱い、プライバシーを指定するために使用することができ、新たなSIPヘッダ、プライバシーを、定義されています。
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" / token
プライバシーHDR = "プライバシー" HCOLONのPRIV-値*（ ";" PRIV-値）PRIV-値= "ヘッダ" / "セッション" / "ユーザ" / "なし" / "臨界" /トークン
User agents SHOULD include a Privacy header when network-provided privacy (as described in Section 3.3) is required. Note that some intermediaries may also add the Privacy header to messages, including privacy services. However, such intermediaries SHOULD only do so if they are operating at a user's behest, for example if a user has an administrative arrangement with the operator of the intermediary that it will add such a Privacy header. An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified.
ネットワークが提供する（セクション3.3で説明したように）プライバシーが必要な場合、ユーザエージェントは、プライバシーヘッダを含むべきです。いくつかの仲介もプライバシーサービスを含め、メッセージにプライバシーヘッダを追加することがあります。彼らは、ユーザーの強い要請で動作している場合、ユーザーはそのようなプライバシーヘッダを追加する仲介のオペレータと管理者の配置を持っている場合は、そのような仲介者は、たとえば、そうすべきです。 「どれも」PRIV-値がすでに指定されている場合、仲介者はどのような方法で個人情報保護ヘッダーを変更してはいけません。
The values of priv-value today are restricted to the above options, although further options can be defined as appropriate (see Section 7). Each legitimate priv-value can appear zero or one times in a Privacy header. The current values are:
さらにオプションが（セクション7参照）を適宜定義することができるがPRIV-値今日の値は、上記のオプションに制限されています。各正規PRIV-値プライバシーヘッダに0または1回出現することができます。現在の値は次のとおりです。
header: The user requests that a privacy service obscure those headers which cannot be completely expunged of identifying information without the assistance of intermediaries (such as Via and Contact). Also, no unnecessary headers should be added by the service that might reveal personal information about the originator of the request.
ヘッダ：完全（例えばビアおよび接触のような）仲介の支援なしに情報を識別する抹消することができないこれらのヘッダプライバシーサービスが不明瞭ユーザ要求。また、不要なヘッダは、要求の発信元の個人情報を明らかにする可能性があるサービスによって追加されるべきではありません。
session: The user requests that a privacy service provide anonymization for the session(s) (described, for example, in a Session Description Protocol [5] body) initiated by this message. This will mask the IP address from which the session traffic would ordinarily appear to originate. When session privacy is requested, user agents MUST NOT encrypt SDP bodies in messages. Note that requesting session privacy in the absence of any end-to-end session encryption raises some serious security concerns (see Section 5.2).
セッション：プライバシーサービスは、セッション（S）のための匿名化を提供するユーザの要求は、このメッセージによって開始される（セッション記述プロトコル[5]体内に、例えば、記載されています）。これは、セッショントラフィックが通常発生するように見えることになるからIPアドレスをマスクします。セッションプライバシーが要求されると、ユーザエージェントはメッセージにSDPボディを暗号化してはなりません。任意のエンドツーエンドの暗号化セッションのない状態でセッションのプライバシーを要求すると、いくつかの深刻なセキュリティ上の懸念を（5.2節を参照）を発生させていることに注意してください。
user: This privacy level is usually set only by intermediaries, in order to communicate that user level privacy functions (as discussed in Section 5.3) must be provided by the network, presumably because the user agent is unable to provide them. User agents MAY however set this privacy level for REGISTER requests, but SHOULD NOT set 'user' level privacy for other requests.
ユーザー：このプライバシーレベルは通常のみ仲介によって設定される、（セクション5.3で議論するように）そのユーザレベルのプライバシー機能を通信するためにユーザエージェントがそれらを提供することができない、おそらくので、ネットワークによって提供されなければなりません。ユーザーエージェントは、しかし、REGISTER要求のために、このプライバシーレベルを設定できますが、他の要求のための「ユーザー」レベルのプライバシーを設定すべきではありません。
none: The user requests that a privacy service apply no privacy functions to this message, regardless of any pre-provisioned profile for the user or default behavior of the service. User agents can specify this option when they are forced to route a message through a privacy service which will, if no Privacy header is present, apply some privacy functions which the user does not desire for this message. Intermediaries MUST NOT remove or alter a Privacy header whose priv-value is 'none'. User agents MUST NOT populate any other priv-values (including 'critical') in a Privacy header that contains a value of 'none'.
なし：プライバシーサービスは、サービスの利用者やデフォルトの動作のために関係なく、任意の事前プロビジョニングプロファイルの、このメッセージに何のプライバシー機能を適用していないユーザーの要求。彼らは何のプライバシーヘッダが存在しない場合、ユーザは、このメッセージのために望んでいないいくつかのプライバシー機能を適用しますプライバシーサービスを通じてルーティングメッセージに強制された場合、ユーザーエージェントは、このオプションを指定することができます。仲介者は、そのPRIV-値である「なし」のプライバシーヘッダを削除または変更してはなりません。ユーザエージェントは「なし」の値が含まれている個人情報保護ヘッダに（「重要な」を含む）他のPRIV-値を移入してはなりません。
critical: The user asserts that the privacy services requested for this message are critical, and that therefore, if these privacy services cannot be provided by the network, this request should be rejected. Criticality cannot be managed appropriately for responses.
重要：ユーザーは、このメッセージのために要求されたプライバシーサービスが重要であり、これらのプライバシーサービスがネットワークによって提供することができない場合ので、この要求は拒否されるべきであると主張します。重要度は、応答のために適切に管理することができません。
When a Privacy header is constructed, it MUST consist of either the value 'none', or one or more of the values 'user', 'header' and 'session' (each of which MUST appear at most once) which MAY in turn be followed by the 'critical' indicator.
プライバシーヘッダが構成されている場合、それは今度は、値「なし」、または値「ユーザ」の一つ以上のいずれかの（最大で一度現れなければなりませんそれぞれが）「ヘッダ」と「セッション」MAYで構成しなければなりません「緊急」レベルの指標が続きます。
The following table specifies extensions to Table 2 in [1].
次の表は、表2に拡張子を指定する[1]。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o o
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
The most obvious way for a user agent to invoke the privacy function is to direct a request through an intermediary known to act as a privacy service. Doing so traditionally entails the configuration of pre-loaded Route headers that designate the privacy service.
プライバシー機能を呼び出すためのユーザエージェントのための最も明白な方法は、プライバシーサービスとして作用することが知ら介して要求を向けることです。そうすることで、伝統的にプライバシーサービスを指定プリロードされたRouteヘッダの設定を必要とします。
It is RECOMMENDED that service providers couple the privacy service function with a local outbound proxy. Users can thereby send their messages that request privacy through their usual outbound route. Users should not assume, however, that the administrative domain that is the destination of the request would be willing and able to perform the privacy service function on their behalf. If the originating user wishes to keep their local administrative domain a secret, then they must use a third-party anonymization service outside of any of the principal administrative domains associated with the session.
これは、そのサービスプロバイダのカップルローカルアウトバウンドプロキシとプライバシーサービス機能推奨されます。ユーザーは、それによって彼らの通常の発信ルートを通じて、プライバシーを要求し、そのメッセージを送信することができます。ユーザーは、要求の送信先である管理ドメインが自分に代わってプライバシーサービス機能を実行することをいとわないとことができるだろうということ、しかし、仮定するべきではありません。発信ユーザがローカル管理ドメイン秘密にしておくことを希望する場合は、それらがセッションに関連付けられている主な管理ドメインのいずれかの外側で、サードパーティの匿名化サービスを使用する必要があります。
It is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service. Ideally, users SHOULD establish a direct (i.e., single pre-loaded Route header) connection to a privacy service; this will both allow the user to inspect a certificate presented by the privacy service, and it will provide confidentiality for requests that will reduce the chances that the information that the privacy service will obscures is revealed before a message arrives at the privacy service. By establishing a direct connection to a privacy service, the user also eliminates the possibility that intermediaries could remove requests for privacy. If a direct connection is impossible, users SHOULD use a mechanism like SIPS to guarantee the use of lower-layer security all the way to the privacy service.
非常にプライバシーサービスに連絡する際、ユーザエージェントは、TLSなどのネットワークまたはトランスポート層セキュリティを、使用することをお勧めします。理想的には、ユーザはプライバシーサービスへの接続を直接（すなわち、単一プリロードルートヘッダ）を確立すべきです。これは、ユーザーがプライバシーサービスによって提示された証明書を検査することができます両方、それはメッセージがプライバシーサービスに到着する前に、プライバシーサービスが不明瞭になることを情報が明らかにされる可能性を削減する要求のための機密性を提供します。プライバシーサービスへの直接接続を確立することにより、ユーザーは、仲介者がプライバシーの要求を削除することができる可能性を排除します。直接接続が不可能な場合、ユーザーはすべての方法プライバシーサービスに下位層のセキュリティの使用を保証するためにSIPSのようなメカニズムを使用すべきです。
If a user agent believes that it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing a new option-tag, 'privacy', especially when the 'critical' priv-value is present in the Privacy header. That way, in the unlikely event that the user agent sends a request to an intermediary that does not support the extensions described in this document, the request will fail. Note that because of special privacy service
ユーザエージェントは、それがプライバシーサービスに直接リクエストを送信していることを信じているならば、それは、「緊急」レベルPRIV-値はプライバシーに存在し、特に「プライバシー」を、新しいオプションタグを含むProxy-Requireヘッダーを含むべきですヘッダ。こうすることで、ユーザエージェントは、この文書で説明する機能拡張をサポートしていないの仲介にリクエストを送信し万一に、要求は失敗します。なおので、特別なプライバシーサービスの
behavior (described in Section 5), no subsequent intermediaries in the signaling path of the request will also need to the support the 'privacy' option-tag - once the privacy service has fulfilled all the required privacy functions, the 'privacy' option-tag is removed from the Proxy-Require header.
（第5節で説明する）行動、リクエストのシグナリングパスには、その後の仲介もサポートする「プライバシー」オプションタグを必要としないだろう - プライバシーサービスは、すべての必要なプライバシー機能、「プライバシー」を満たした後option-タグは、Proxy-Requireヘッダーから除去されます。
Making sure that responses will go through a privacy service is a little bit trickier. The path traversed by SIP responses is the same as the path over which the request traveled. Thus, the responding user agent, for example, cannot force a privacy service to be injected in the response path after it has received a request.
応答がプライバシーサービスを経ると確信して作ることは少しトリッキーです。 SIP応答によってトラバースされる経路は、要求が移動その上のパスと同じです。したがって、応答ユーザエージェントは、例えば、それは要求を受信した後に応答経路に注入するプライバシーサービスを強制することはできません。
What a responding user agent can do, however, is ensure that the path by which requests reach them traverses their privacy service. In some architectures, the privacy service function will be fulfilled by the same server to which requests for the local administrative domain are sent, and hence it will automatically be in the path of incoming requests. However, if this is not the case, the user will have to ensure that requests are directed through a third-party privacy service.
応答ユーザエージェントは何ができるか、しかし、パスがそれによって彼らのプライバシーサービスを横断達する要求していることを確認しています。いくつかのアーキテクチャでは、プライバシーサービス機能は、ローカルの管理ドメインのために要求すると、同じサーバによって成就される送信され、ひいてはそれが自動的に着信要求のパスになります。しかし、そうでない場合には、ユーザーが要求は、サードパーティのプライバシーサービスを通じて向けられていることを確認する必要があります。
One way to accomplish this is to procure an 'anonymous callback' URI from the third-party service and to distribute this as an address-of-record. A privacy service provider might offer these anonymous callback URIs to users in the same way that an ordinary SIP service provider grants addresses-of-record. The user would then register their normal address-of-record as a contact address with the third-party service.
これを実現するための一つの方法は、サードパーティのサービスから「匿名のコールバック」URIを調達するとアドレスのレコードとしてこれを配布することです。プライバシーサービスプロバイダは、通常のSIPサービスプロバイダは、アドレス・オブ・レコードを付与するのと同じようにユーザーにこれらの匿名のコールバックURIを提供するかもしれません。その後、ユーザは、サードパーティのサービスとの連絡先として、それらの通常のアドレスのレコードを登録します。
Alternatively, a user agent could send REGISTER requests through a privacy service with a request for 'user' level privacy. This will allow the privacy service to insert anonymous Contact header URIs. Requests sent to the user's conventional address-of-record would then reach the user's devices without revealing any usable contact addresses.
また、ユーザエージェントは、「ユーザー」レベルのプライバシーのための要求にプライバシーサービスを通じてREGISTERリクエストを送信することができます。これは、プライバシーサービスは、匿名のContactヘッダーのURIを挿入することができます。ユーザーの従来のアドレス・オブ・レコードに送られた要求は、任意の使用可能な連絡先を明らかにすることなく、ユーザーのデバイスに達します。
Finally, a user might generate a CPL ([7]) script that will direct requests to an anonymization service.
最後に、ユーザは、CPL（[7]）匿名化サービスへの要求を指示するスクリプトを生成することがあります。
Users are also advised to use transport or network layer security in the response path. This may involve registering a SIPS URI and/or maintaining persistent TLS connections over which their user agent receives requests.
ユーザーはまた、応答パスでの輸送やネットワークレイヤセキュリティを使用することをお勧めします。これは、SIPS URIを登録および/またはそのユーザエージェントが要求を受信する上で永続的なTLS接続を維持することを含むことができます。
Privacy services MAY in turn route requests through other privacy services. This may be necessary if a privacy service does not support a particular privacy function, but it knows of a peer that does. Privacy services may also cluster themselves into networks that exchange session traffic between one another in order to further disguise the participants in a session, although no specific architecture or method for doing so is described in this document.
プライバシーサービスができる他のプライバシサービスを通じてターンルートを要求しました。プライバシーサービスは、特定のプライバシー機能をサポートしていない場合、これが必要かもしれないが、それはありませんピアを知っています。そうするための特定のアーキテクチャやメソッドは、この文書に記載されていないが、プライバシーサービスも、さらにセッションの参加者を偽装するために、互いの間のセッショントラフィックを交換ネットワークに自分自身をクラスタ化します。
This document defines a new SIP logical role called a "privacy service". The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves.
この文書では、「プライバシーサービス」と呼ばれる新しいSIP論理的な役割を定義します。プライバシーサービスの役割は頻繁にSIPプロキシサーバとして動作できるエンティティにより、ネットワーク中継によってインスタンス化されます。プライバシーサービスの機能は、ユーザエージェント自身によって提供することができないSIPメッセージのプライバシー機能を提供することです。
When a message arrives at a server that can act as a privacy service, the service SHOULD evaluate the level of privacy requested in a Privacy header. Usually, only the services explicitly requested should be applied. However, privacy services MAY have some means outside SIP of ascertaining the preferences of the user (such as a pre-arranged user profile) and therefore they MAY perform such other privacy functions without an explicit Privacy header. Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support the Privacy header, or a user agent that does not allow the user to configure the values of headers that could reveal personal information. However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header.
メッセージは、プライバシーサービスとして機能することができ、サーバに到着すると、サービスはプライバシーヘッダーで要求されたプライバシーのレベルを評価する必要があります。通常、明示的に要求のみのサービスが適用されるべきです。しかし、プライバシーサービスは、（例えば、予め配置されたユーザプロファイルとして）ユーザの嗜好を把握するSIP外部手段を有することができ、従って、それらは、明示的なプライバシーヘッダことなく、このような他のプライバシーの機能を実行することができます。プライバシーサービスでも、ユーザレベルのプライバシー機能を実行すると、例えば、有用である可能性、ユーザが値を設定することはできませんPrivacyヘッダー、またはユーザーエージェントをサポートし、レガシークライアントからメッセージを送信しているとき個人情報を開示する可能性があり、ヘッダーの。 「どれも」のプライバシーヘッダーの値をメッセージに指定されている場合は、プライバシーサービスは、任意のプライバシー機能を実行してはならないとプライバシーヘッダを削除または変更してはいけません。
Privacy services MUST implement support for the 'none' and 'critical' privacy tokens, and MAY implement any of other privacy levels described in Section 4.2 as well as any extensions that are not detailed in this document. In some cases, the privacy service will not be capable of fulfilling the requested level of privacy. If the 'critical' privacy level is present in the Privacy header of a request, then if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then it MUST fail the request with a 500 (Server Error) response code. The reason phrase of the status line of the response SHOULD contain appropriate text indicating that there has been a privacy failure as well as an enumeration of the priv-value(s) which were not supported by the privacy service (the reason phrase SHOULD also respect any Accept-Language header in the request if possible).
プライバシーサービスは、「なし」と「重要なのプライバシートークンのサポートを実装しなければならない、と4.2節と同様に、本書で詳述されていない任意の拡張子に記載された他のプライバシーレベルのいずれかを実施することができます。いくつかのケースでは、プライバシーサービスは、プライバシーの要求水準を満たすことができるではありません。 「重要なのプライバシーレベルが要求のプライバシーヘッダに存在する場合、プライバシーサービスはプライバシーヘッダーで指定されたプライバシーのレベルのすべてを実行することができない場合、それは500（サーバーエラー）で要求に失敗しなければなりません応答コード。応答のステータス行の理由フレーズは、プライバシー障害ならびにプライバシーサービス（語句も尊重しなければならない理由でサポートされていなかったPRIV-値（S）の列挙があったことを示す適切なテキストを含むべきです可能であれば要求内の任意のAccept-Languageヘッダー）。
When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable. When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from a message.
そうでない場合は、このメッセージをルーティングに関与する他のプライバシーサービスが不必要に同じ機能を適用するかもしれない - プライバシーサービスプライバシーヘッダに記載されているプライバシーレベルに対応する機能のいずれかを実行するとき、それはプライバシーヘッダから対応PRIV-値を削除する必要があります、多くの場合、望ましくないであろう。最後PRIV-値（「クリティカル」数えない）プライバシーヘッダから除去された場合、全体のプライバシーヘッダがメッセージから除去されなければなりません。
When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request.
プライバシーサービスは、全体のプライバシーヘッダを削除したときに、メッセージが要求である場合、プライバシーサービスはまた、要求のプロキシ要求ヘッダフィールドから任意の「プライバシー」オプションタグを削除する必要があります。
If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help to obscure headers that might otherwise reveal information about the originator of the request. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent back-to-back user agent (B2BUA).
[ヘッダー]のプライバシーレベルが要求された場合は、元のユーザーは、そうでない場合は、要求の発信元の情報を明らかにするかもしれないヘッダをあいまいに支援するためにプライバシーサービスを求めています。ダイアログの更なるメッセージが発信ユーザエージェントにルーティングする必要がある場合ただし、その隠された値は、回復可能でなければなりません。プライバシーサービスが頻繁に透明バックツーバックユーザエージェント（B2BUA）として動作する必要があり、これらの機能を提供するために。
Firstly, a request for header privacy entails that the server SHOULD NOT add any headers to the message that reveal any identity or personal information, including the following: Call-Info, Server, and Organization. All of these provide optional information that could reveal facts about the user that has request anonymity.
コール情報、サーバー、および組織：まず、ヘッダプライバシーのための要求は、サーバーが以下を含む任意の身元や個人情報を、明らかにしたメッセージに任意のヘッダを追加しないことを伴います。これらのすべてが匿名を要求しているユーザーについての事実を明らかにすることができ、オプションの情報を提供します。
Privacy services operating on requests SHOULD remove all Via headers that have been added to the request prior to its arrival at the privacy service (a practice referred to as "Via stripping") and then SHOULD add a single Via header representing themselves. Note that the bottommost such Via header field value in a request contains an IP address or hostname that designates the originating client, and subsequent Via header field values may indicate hosts in the same administrative domain as the client. No Via stripping is required when handling responses.
リクエスト上で動作プライバシーサービスは、以前のプライバシーサービスでその到着を要求に追加されたすべてのViaヘッダを削除する必要があります（実際には「ビアストリッピング」と呼ばれる）、その後、自分自身を表す単一のViaヘッダを追加する必要があります。要求に一番下ようなViaヘッダーフィールド値は元のクライアントを指定するIPアドレスまたはホスト名が含まれていることに注意してください、そしてその後のViaヘッダフィールド値は、クライアントと同じ管理ドメイン内のホストを示すことができます。応答を処理するときに何のViaストリッピングは必要ありません。
Contact headers are added by user agents to both requests and responses. A privacy service SHOULD replace the value of the Contact header in a message with a URI that does not dereference to the originator of the message (such as the anonymous URI described in Section 4.1.1.3). The URI that replaces the existing Contact header field value MUST dereference to the privacy service.
連絡先のヘッダーには、要求と応答の両方にユーザエージェントによって追加されます。プライバシーサービスは、メッセージの発信者に間接参照（例えば匿名URIとしては、セクション4.1.1.3を参照）ないURIとメッセージのContactヘッダの値を交換してください。プライバシーサービスへの既存のContactヘッダーフィールド値MUSTの間接参照を置き換えるURI。
In a manner similar to Via stripping, a privacy service SHOULD also strip any Record-Route headers that have been added to a request before it reaches the privacy service - though note that no such headers will be present if there is only one hop between the originating user agent and the privacy service, as is recommended above. Such Record-Route headers might also divulge information about the administrative domain of the client.
間に一つだけのホップがある場合、そのようなヘッダが存在しないことに注意してくださいしかし - 経由でストリッピングと同様に、プライバシーサービスはまた、プライバシーサービスに到達する前に、要求に追加されたレコードの-Routeヘッダを削除すべきです上記の推奨されるよう、ユーザーエージェントおよびプライバシーサービスを発信します。そのようなレコード-Routeヘッダには、クライアントの管理ドメインの情報を漏らす可能性があります。
For the purposes of this document, it is assumed that the privacy service has locally persisted the values of any of the above headers that are so removed, which requires the privacy service to keep a pretty significant amount of state on a per-dialog basis. When further requests or responses associated with the dialog reach the privacy service, it MUST restore values for the Via, Record-
このドキュメントの目的のために、プライバシーサービスは、ローカルに当たり、ダイアログベースで状態の、かなり重要な量を維持するためにプライバシーサービスを必要とするので、削除されている上記のヘッダのいずれかの値を持続しているものとします。ダイアログに関連するさらなる要求または応答がプライバシーサービスに達すると、それは経由、記録的に値を復元する必要があります
Route/Route or Contact headers that it has previously removed in the interests of privacy. There may be alternative ways (outside the scope of this document) to perform this function that do not require keeping state in the privacy service (usually means that involve encrypting and persisting the values in the signaling somehow).
それは以前にプライバシーの利益のために取り外したルート/ルートや連絡先のヘッダー。 （何とかシグナリングに値を暗号化し、持続伴う通常の手段）プライバシーサービスの状態を維持する必要はありません。この機能を実行するには（このドキュメントの範囲外）別の方法があるかもしれません。
The following procedures are RECOMMENDED for handling the Record-Route header field of requests and responses, which provides specialchallenges to a privacy service:
以下の手順は、プライバシーサービスにspecialchallengesを提供し、要求と応答のRecord-Routeヘッダーフィールドを、処理するために推奨されます。
When a privacy service is processing (on behalf of the originator) a request that contains one or more Record-Route header field values, the privacy service must strip these values from the request and remember both the dialog identifiers and the ordered Record-Route header field values. As described above, it must also replace the Contact header field with a URI indicating itself. When a response with the same dialog identifiers arrives at the privacy service, the privacy service must reapply any Record-Route header field values to the response in the same order, and it must then add a URI representing itself to the Record-Route header field of the response. If the response contains Record-Route header field values of its own, these must also be included (in order) in the Record-Route header field after the URI representing the privacy service.
プライバシーサービスは、1つまたは複数のRecord-Routeヘッダーフィールド値を含む要求（発信者に代わって）処理している場合は、プライバシーサービスはリクエストからこれらの値を削除し、ダイアログ識別子と注文したRecord-Routeヘッダの両方を覚えておく必要がありますフィールドの値。上述したように、それはまた、それ自体を示すURIとContactヘッダーフィールドを交換しなければなりません。同じダイアログ識別子を持つ応答がプライバシーサービスに到着すると、プライバシーサービスは、同じ順序で応答する任意のRecord-Routeヘッダフィールド値を再適用する必要があり、それは、次いで、Record-Routeヘッダフィールドに自分自身を表すURIを追加する必要があります応答の。応答は、独自のRecord-Routeヘッダフィールド値を含む場合、これらはまた、URIは、プライバシーサービスを表す後Record-Routeヘッダフィールドに（順番に）含まれていなければなりません。
Note that when a privacy service is handling a request and providing privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated. This document recommends no way of statefully restoring those headers if they are stripped.
プライバシーサービスは要求を処理し、要求の宛先に代わってプライバシーを提供している際に、プライバシーサービスの下流録音-Routeヘッダのプライバシーを提供することがはるかに複雑であることに注意してください。この文書では、それらが取り除かれた場合にステートフルこれらのヘッダを復元する手立てを推奨しません。
If a privacy level of 'session' is requested, then the user has requested that the privacy service anonymize the session traffic (e.g., for SIP telephony calls, the audio media) associated with this dialog.
「セッション」のプライバシーレベルが要求された場合、ユーザーは、プライバシーサービスは、このダイアログに関連付けられている（SIPテレフォニー通話、オーディオメディアのために、例えば）セッショントラフィックを匿名化することを要求しています。
The SIP specification dictates that intermediaries such as proxy servers cannot inspect and modify message bodies. The privacy service logical role MUST therefore act as a back-to-back user agent in order to provide media privacy, effectively terminating and re-originating the messages that initiate a session (although in support of session privacy the privacy service does not need to alter headers characterizing the originator or destination when the request is re-originated). In order to introduce an anonymizer for session traffic, the privacy service needs to control a middlebox [8] that can provide an apparent source and sink for session traffic. The details of the implementation of an anonymizer, and the modifications that must be made to the Session Description Protocol (SDP [5]) bodies in the messages that initiate a session are outside the scope of this document.
SIPの仕様では、このようなプロキシサーバとしての仲介を検査し、メッセージ本文を修正することができないことを指示します。セッションのプライバシーのサポートにプライバシーサービスをする必要はありませんが、プライバシーサービスの論理的な役割は、したがって、（効果的にセッションを開始するメッセージを終端し、再発信さ、メディアのプライバシーを提供するために、バックツーバックユーザエージェントとして機能しなければなりません発信者又は要求が再発信され宛先）を特徴付けるのヘッダを変更します。セッショントラフィックのアノニマイザを導入するために、プライバシーサービスは、ミドルボックスを制御する必要がある[8]見かけの源を提供し、セッショントラフィックに沈むことができます。アノニマイザの実装の詳細、およびセッション開始メッセージのセッション記述プロトコル（SDP [5]）体に対してなされなければならない変更は、本文書の範囲外です。
The risk, of course, of using such an anonymizer is that the anonymizer itself is party to your communications. For that reason, requesting session-level privacy without resort to some sort of end-to-end security for the session traffic (with RTP [6] media, for example, SRTP [4]) is NOT RECOMMENDED.
もちろん、このようアノニマイザーを使用してのリスクは、アノニマイザー自体があなたのコミュニケーションの当事者であるということです。 、そのためセッショントラフィックのためのエンドツーエンドのセキュリティのいくつかの並べ替えに頼らずにセッションレベルのプライバシーを要求する（RTPと[6]メディアは、例えば、SRTP [4]）は推奨されません。
If a privacy level of 'user' is requested, then the originating user has requested that privacy services perform the user-level privacy functions described in Section 4.1.
「ユーザー」のプライバシーレベルが要求された場合は、元のユーザーは、プライバシーサービスは、4.1節で説明したユーザレベルのプライバシー機能を実行することを要求しています。
Note that the privacy service MUST remove any non-essential informational headers that have been added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To.
プライバシーサービスは、件名を含む、ユーザエージェントによって追加されたすべての非必須情報のヘッダを削除し、コール情報、組織、ユーザーエージェント、返信先をとでは、返信先なければならないことに注意してください。
Significantly, user-level privacy could entail the modification of the From header, changing it from its original value to an anonymous value. Prior to the current issue of the SIP specification, the modification of the values of the To and From headers by intermediaries was not permitted, and would result in improper dialog matching by the endpoints. Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response.
重要なことは、ユーザーレベルのプライバシー、匿名の値を元の値からの変化から、ヘッダの変更を伴う可能性があります。 SIP仕様の現在の問題の前に、仲介によって値の修正とヘッダからは許されていなかった、と端点による不適切なダイアログマッチングにつながります。現在、ダイアログのマッチングは、にやヘッダ、全体ではなく、ヘッダフィールドからタグのみを使用しています。したがって、新しい下にURI値をルールとヘッダから身を仲介することによって変更することができます。要求と応答の間で変更からヘッダー内のURIの値ただし、一部のレガシークライアントは、エラー条件を検討してください。
Also, performing user-level privacy functions MAY entail the modification of the Call-ID header, since the Call-ID commonly contains a hostname or IP address corresponding to the originating client. This field is essential to dialog matching, and it cannot be altered by intermediaries.
コールIDは、一般的に元のクライアントに対応するホスト名またはIPアドレスが含まれているのでまた、ユーザレベルのプライバシー機能を実行することは、コール-IDヘッダーの変更を伴ってもよいです。このフィールドは、ダイアログのマッチングに不可欠であり、それは仲介によって変更することはできません。
Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent.
そのため、プライバシーサービスは、プライバシー上の理由から任意のダイアログ・マッチングのヘッダーを変更する必要があるすべての時間は、それは透明バックツーバックユーザエージェントとして行動しなければならない、そしてそれは、ダイアログ・マッチングのヘッダーの元の値を保持しなければなりません。これらの値は、発信ユーザエージェントに送信されたメッセージに復元する必要があります。
Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the very personal information that the user has asked the privacy service to obscure.
プライバシーを要求するメッセージは、機密性と整合性を必要とします。整合性がなければ、要求されたプライバシー機能は、潜在的に識別情報を暴露する、ダウングレードまたは排除することができます。機密性がなければ、ネットワーク（またはユーザーとプライバシーサービスとの間のいずれかの仲介）上の盗聴者は、ユーザーが不明瞭にプライバシーサービスを求めていることを非常に個人的な情報を見ることができました。
All of the network-provided privacy functions in this document entail a good deal of trust for the privacy service. Users should only trust privacy services that are somehow accountable to them.
この文書に記載されているネットワークが提供するプライバシー機能のすべては、プライバシーサービスの信頼の良い取引を伴います。ユーザーは、何らかの形で彼らに責任がある、プライバシーサービスを信頼する必要があります。
Operators of privacy services should be aware that in the eyes of downstream entities, a privacy service will be the only source to which anonymous messages can be traced.
プライバシーサービスのオペレータは、下流のエンティティの目には、プライバシーサービスが匿名のメッセージがトレース可能な唯一の源になることに注意してください。
Note that authentication mechanisms, including the Digest authentication method described in the SIP specification, are outside the scope of the privacy considerations in this document. Revealing identity through authentication is highly selective, and may not result in the compromise of any private information. Obviously, users that do not wish to reveal their identity to servers that issue authentication challenges MAY elect not to respond to such challenges.
SIP仕様で説明ダイジェスト認証方法を含む、その認証メカニズムに注意し、この文書に記載されているプライバシーの考慮の範囲外です。認証を通じて身元を明らかにすることは非常に選択され、そして任意の個人情報の妥協が得られないことがあります。明らかに、認証チャレンジを発行するサーバーへの彼らの身元を明らかにしたくないユーザーは、このような課題に対応しないことを選択するかもしれません。
This document defines a new SIP header field called "Privacy" that allows a user agent to request a certain degree of privacy for a message. This behavior associated with this header is specified in Section 4.2. This header has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
この文書では、ユーザエージェントがメッセージのプライバシーをある程度要求することを可能にする「プライバシー」と呼ばれる新しいSIPヘッダフィールドを定義します。このヘッダに関連付けられているこの現象は、セクション4.2で指定されています。このヘッダはhttp://www.iana.org/assignments/sip-parameters下ヘッダーサブレジストリに追加されました。
Header name: Privacy Compact form: none defined
ヘッダー名：プライバシーコンパクトなフォーム：何も定義されていません
This document also creates an IANA registry for values that populate the Privacy header. This registry should be indexed by priv-value tokens and should contain a short semantic description of the new value. The current values of the "Privacy" header are as follows:
この文書はまた、プライバシーヘッダーを移入値のためのIANAレジストリを作成します。このレジストリは、PRIV-値トークンによってインデックス付けされなければならないと、新たな価値の短い意味記述が含まれている必要があります。次のように「プライバシー」ヘッダの現在の値は次のとおりです。
o user: Request that privacy services provide a user-level privacy function
Oユーザ：プライバシーサービスは、ユーザーレベルのプライバシー機能を提供することを要求します
o header: Request that privacy services modify headers that cannot be set arbitrarily by the user (Contact/Via).
ヘッダO：プライバシーサービスは、ユーザー（連絡先/経由）によって任意に設定することができないヘッダを変更することを要求します。
o session: Request that privacy services provide privacy for session media
Oセッション：プライバシーサービスは、セッションメディアのプライバシーを提供することを要求します
o none: Privacy services must not perform any privacy function
Oなし：プライバシーサービスは、任意のプライバシー機能を実行してはなりません
o critical: Privacy service must perform the specified services or fail the request
O重要：プライバシー・サービスは、指定されたサービスを実行したり、要求を失敗しなければなりません
New values for the "Privacy" header can only be defined by IETF Consensus including RFC publication (RFC 2434). IANA registration for the "Privacy" header field values is required along with the RFC publication.
「プライバシー」ヘッダの新しい値は、RFC公報（RFC 2434）を含むIETF合意によって定義することができます。 「プライバシー」ヘッダフィールド値のIANA登録はRFC公開と共に必要とされます。
Authors of extensions to the SIP protocol that expose personal information about the participants in sessions are advised against extending the "Privacy" header - rather, it is preferable to create new identity mechanisms whose privacy can be managed by the user agent without the agency of intermediaries.
セッションの参加者の個人情報を公開するSIPプロトコルの拡張機能の作者は、「プライバシー」ヘッダを拡張に対してお勧めします - むしろ、そのプライバシー仲介の代理店なしでユーザエージェントによって管理することができ、新たなアイデンティティメカニズムを作成することが好ましいです。 。
This document also defines a new SIP option-tag, 'privacy', that represents support for the extension defined in this document.
この文書はまた、この文書で定義された拡張機能のサポートを表す新しいSIPオプションタグ「プライバシー」を、定義されています。
Normative References
引用規格
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999.
[3]イーストレイク、D.とA. Panitz、 "予約トップレベルDNS名"、RFC 2606、1999年6月。
Informative References
参考文献
[4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E., Naslund, M. and K. Normann, "The Secure Real Time Transport Protocol", Work in Progress.
[4] Baugher、M.、マグリュー、D.、オラン、D.、ブロム、R.、カララ、E.、Naslund、M.及びK.ノーマン、 "セキュアリアルタイムトランスポートプロトコル"、ProgressのWork。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress
[7]レノックス、J.、およびH. Schulzrinneと、「CPL：インターネット電話サービスのユーザーコントロールの言語」、進行中で働い
[8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[8] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.及びA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
Author's Address
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
Acknowledgments
謝辞
The author would like to thank Allison Mankin, Rohan Mahy, Eric Rescorla, Mark Watson, Cullen Jennings, Robert Sparks, Jonathan Rosenberg, Ben Campbell, Tom Gray and John Elwell for their comments.
作者は彼らのコメントのためのアリソンマンキン、ロハンマーイ、エリックレスコラ、マーク・ワトソン、カレン・ジェニングス、ロバート・スパークス、ジョナサン・ローゼンバーグ、ベン・キャンベル、トム・グレイ、ジョンエルウェルに感謝したいと思います。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。