[要約] RFC 3892は、SIPのReferred-Byメカニズムに関する仕様です。このRFCの目的は、SIPセッションの転送と関連する問題を解決するために、Referred-Byヘッダーの使用方法を定義することです。
Network Working Group R. Sparks
Request for Comments: 3892 Xten
Category: Standards Track September 2004
The Session Initiation Protocol (SIP) Referred-By Mechanism
セッション開始プロトコル（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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
セッション開始プロトコル（SIP）参照メソッドは、1つの当事者（リファラー）が第2の当事者（審判）に任意のURIを参照するための任意のURIを提供するメカニズムを提供します。そのURIがSIP URIの場合、審判はSIPリクエスト、多くの場合、そのURI（紹介ターゲット）に招待状を送信します。このドキュメントは紹介方法を拡張し、リファラーが審判を仲介者として使用して紹介ターゲットへの紹介要求に関する情報を提供できるようにします。この情報には、紹介者と紹介者が紹介したURIの身元が含まれます。このメカニズムは、S/MIMEを利用して、悪意のある仲介者からこの情報を保護するのに役立ちます。この保護はオプションですが、受信者は存在しない限り、リクエストを受け入れることを拒否する場合があります。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 3
2.1. Referrer Behavior . . . . . . . . . . . . . . . . . . . 4
2.2. Referee Behavior . . . . . . . . . . . . . . . . . . . . 4
2.3. Refer Target Behavior . . . . . . . . . . . . . . . . . 5
3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6
4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7
4.1. Refer Target Inspection of a Referred-By Token . . . . . 8
5. The 429 Provide Referrer Identity Error Response . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Identifying the Referee in the Referred-by Token . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Basic REFER . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
7.3. Requiring Referrer Identity . . . . . . . . . . . . . . 14
7.4. Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
The SIP REFER method [2] provides a mechanism where one party (the referrer) provides a second party (the referee) with an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). Nothing provided in [2] distinguishes this referenced request from any other request the referee might have sent to the refer target.
SIP紹介方法[2]は、1つの当事者（リファラー）が任意のURIを参照する任意のURIを備えた第2の当事者（審判）を提供するメカニズムを提供します。そのURIがSIP URIの場合、審判はSIPリクエスト、多くの場合、そのURI（紹介ターゲット）に招待状を送信します。[2]で提供されているものは、審判が紹介ターゲットに送信した可能性のある他のリクエストとこの参照要求を区別するものではありません。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
|----------------->| INVITE target |
| |------------------->|
There are applications of REFER, such as call transfer [8], where it is desirable to provide the refer target with particular information about the referrer and the REFER request itself. This information may include, but is not limited to, the referrer's identity, the referred to URI, and the time of the referral. The refer target can use this information when deciding whether to admit the referenced request. This document defines one set of mechanisms to provide that information.
コール転送[8]など、紹介のアプリケーションがあります。この場合、紹介ターゲットにリファラーと紹介要求自体に関する特定の情報を提供することが望ましいです。この情報には、リファラーの身元、紹介されたURI、および紹介の時間が含まれる場合がありますが、これらに限定されません。参照ターゲットは、参照されるリクエストを認めるかどうかを決定するときにこの情報を使用できます。このドキュメントでは、その情報を提供するメカニズムのセットを定義します。
All of the mechanisms in this document involve placing information in the REFER request that the referee copies into the referenced request. This necessarily establishes the referee as an eavesdropper and places the referee in a position to launch man-in-the-middle attacks on that information.
このドキュメントのすべてのメカニズムには、審判が参照されるリクエストにコピーする紹介要求に情報を配置することが含まれます。これにより、必然的に審判が盗聴者として確立され、審判がその情報に対する中間の攻撃を開始する立場に置きます。
At the simplest level, this document defines a mechanism for carrying the referrer's identity, expressed as a SIP URI in a new header: Referred-By. The refer target can use that information, even if it has not been protected from the referee, at the perils and with the limitations documented here. The document proceeds to define an S/MIME based mechanism for expressing the identity of the referrer and capturing other information about the REFER request, allowing the refer target to detect tampering (and other undesirable behaviors) by the referee.
最も単純なレベルでは、このドキュメントは、新しいヘッダーのSIP URIとして表されるリファラーのアイデンティティを運ぶためのメカニズムを定義します：refered-by。参照ターゲットは、審判から保護されていなくても、危険にさらされていても、ここに文書化された制限を使用しても、その情報を使用できます。このドキュメントは、紹介者の身元を表現し、紹介要求に関する他の情報をキャプチャするためのS/MIMEベースのメカニズムを定義し、紹介ターゲットが審判による改ざん（およびその他の望ましくない行動）を検出できるようにします。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
The following figure summarizes how Referred-By information is carried to the Refer Target. The Referrer provides a Referred-By header with its SIP address-of-record, optionally associating an S/MIME protected token reflecting the identity of the referrer and the details of the REFER request. The Referee copies this header and the token, if provided, into the triggered request (shown here as an INVITE).
次の図は、紹介された情報が参照ターゲットにどのように伝達されるかをまとめたものです。リファラーは、リファラーのIDと紹介リクエストの詳細を反映したS/MIME保護されたトークンをオプションで関連付けて、recordのSIPアドレスを紹介する紹介ヘッダーを提供します。審判はこのヘッダーとトークンを、提供された場合、トリガーされたリクエストにコピーします（ここでは招待状として表示）。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
| Referred-By: referrer;cid=X | |
| | |
| (one of the body parts is) | |
| Content-ID: X | |
| <Referred-By Token> | |
|----------------------------->| |
| | INVITE target |
| | Referred-By: referrer;cid=X |
| | |
| | (one of the body parts is) |
| | Content-ID: X |
| | <Referred-By token> |
| |---------------------------->|
A UA sending a REFER request (a referrer) MAY provide a Referred-By header field value in the request. A REFER request MUST NOT contain more than one Referred-By header field value.
紹介要求（リファラー）を送信するUAは、リクエストに紹介されたヘッダーフィールド値を提供する場合があります。紹介要求には、ヘッダーのフィールド値を複数紹介してはなりません。
A referrer MAY include a Referred-By token in a REFER request. A REFER request containing a Referred-By token MUST contain a Referred-By header field value with a cid parameter value equal to the Content-ID of the body part containing the token.
リファラーには、紹介リクエストに紹介されたトークンを含めることができます。紹介されたトークンを含む参照要求には、トークンを含むボディパーツのコンテンツIDに等しいCIDパラメーター値を持つ参照ヘッダーフィールド値を含める必要があります。
The referrer will receive a NOTIFY with a message/sipfrag [4] body indicating a final response of 429 "Provide Referrer Identity" to the referenced request if the refer target requires a valid Referred-By token to accept the request. This can occur when either no token is provided or a provided token is invalid.
リファラーは、参照ターゲットがリクエストを受け入れるために有効な紹介されたトークンを必要とする場合、参照要求に429の最終応答を示すメッセージ/SIPFRAG [4]ボディを含む通知を受け取ります。これは、トークンが提供されないか、提供されたトークンが無効である場合に発生する可能性があります。
The referrer will receive a 429 "Provide Referrer Identity" response to the REFER if the referee requires a Referred-By token to be present in order to accept the REFER.
リファラーは、審判が紹介を受け入れるために紹介されたトークンを存在させることを要求する場合、紹介に対する429の「リファラーIDの提供」応答を受け取ります。
If a referrer wishes to re-attempt to refer a referee after receiving a 429 response or a NOTIFY containing a 429, it MAY submit a new REFER request containing a Referred-By token.
リファラーが429の応答を受け取った後に審判を紹介するために再触媒を希望する場合、429を含む通知を受け取る場合は、紹介されたトークンを含む新しい紹介要求を送信することができます。
A UA accepting a REFER request (a referee) to a SIP URI (using either the sip: or sips: scheme) MUST copy any Referred-By header field value and token into the referenced request without modification.
uaは、requer request（referee）をSIP URIに受け入れます（SIP：またはSIPS：スキームのいずれかを使用）は、紹介されたヘッダーフィールド値をコピーし、修正なしで参照されるリクエストにトークンをコピーする必要があります。
A referee MAY reject a REFER request that does not contain a Referred-By token with a 429 "Provide Referrer Identity" response. A referee SHOULD NOT reject a request that contains a Referred-By token encrypted to a key it does not possess simply because it cannot decrypt the token. (One scenario where such rejection would be appropriate is when the referee is attempting to remain anonymous (see Section 6.1).) Note that per [3], the referee should still be able to verify the signature of such an encrypted token.
審判は、429の「リファラーIDの提供」応答を持つ紹介されたトークンを含まない紹介要求を拒否する場合があります。審判は、トークンを復号化できないという理由だけで、それが持っていないキーに暗号化された紹介されたトークンを含むリクエストを拒否すべきではありません。（そのような拒絶が適切であるシナリオの1つは、審判が匿名のままでいることを試みている場合（セクション6.1を参照）。）[3]に従って、審判はそのような暗号化されたトークンの署名を検証できるはずであることに注意してください。
A referee SHOULD present the same identity to the referrer and the refer target.
審判は、同じアイデンティティをリファラーと紹介ターゲットに提示する必要があります。
A UA receiving a non-REFER SIP request MAY inspect the request for a Referred-By header field and token.
非参照SIPリクエストを受信するUAは、紹介されたヘッダーフィールドとトークンのリクエストを検査する場合があります。
If a Referred-By header field value is not present, this UA cannot distinguish this request from any other the UA acting as the referee might have sent. Thus, the UA would apply exactly the admissions policies and processing described in [5] to the request.
紹介されたヘッダーフィールド値が存在しない場合、このUAは、このリクエストを、審判が送信した可能性のあるUAが他のどのUAと区別することはできません。したがって、UAは[5]で説明されている入学ポリシーと処理をリクエストに正確に適用します。
If a Referred-By header field value is present, the receiving UA can consider itself a refer target and MAY apply additional admission policies based on the contents of the Referred-By header field and token.
参照されたヘッダーフィールド値が存在する場合、受信UAはそれ自体が紹介ターゲットと見なされ、参照されたヘッダーフィールドとトークンの内容に基づいて追加の入場ポリシーを適用することができます。
The referee is in a position to modify the contents of the Referred-By header field value, or falsely provide one even if no REFER actually exists. If such behavior could affect admission policy (including influencing the agent's user by rendering misleading content), the refer target SHOULD require that a valid Referred-By token be present.
審判は、紹介されたヘッダーフィールド値の内容を変更する立場にあるか、紹介が実際に存在しなくても誤って提供します。そのような動作が入場ポリシーに影響を与える可能性がある場合（誤解を招くコンテンツを提供することでエージェントのユーザーに影響を与えることを含む）、紹介ターゲットは、有効な紹介されたトークンが存在することを要求する必要があります。
The refer target MAY reject a request if no Referred-By token is present or if the token is stale using the 429 "Provide Referrer Identity" error response defined in Section 5. The 428 error response from [7] is not appropriate for this purpose - it is needed for the refer target to request an authentication token from the referee.
参照ターゲットは、紹介されたトークンが存在しない場合、または429の「リファラーIDを提供する」エラー応答を使用してトークンが古くなっている場合、[7]からの428エラー応答がこの目的に適していない場合、リクエストを拒否できます。 - 紹介ターゲットが審判に認証トークンを要求するために必要です。
If no Referred-By token is present, the refer target MAY proceed with processing the request. If the agent provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information is suspect.
紹介されたトークンが存在しない場合、参照ターゲットはリクエストの処理を進めることができます。エージェントがリクエストの処理の一環として紹介されたヘッダーからユーザーに情報を提供する場合、情報が疑わしいことをユーザーに通知する必要があります。
The refer target MUST reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response.
参照ターゲットは、429のエラー応答を使用して、無効なトークン（セクション4を参照）を使用して、他の方法では整理されたリクエストを拒否する必要があります。
Referred-By is a request header field as defined by [5]. It can appear in any request. It carries a SIP URI representing the identity of the referrer and, optionally, the Content-ID of a body part (the Referred-By token) that provides a more secure statement of that identity.
[5]で定義されているリクエストヘッダーフィールドです。任意のリクエストで表示できます。リファラーのアイデンティティを表すSIP URI、およびオプションでは、そのアイデンティティのより安全な声明を提供する身体部分（紹介されたトークン）のコンテンツIDを運びます。
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri
*( SEMI (referredby-id-param / generic-param) )
referrer-uri = ( name-addr / addr-spec )
referredby-id-param = "cid" EQUAL sip-clean-msg-id
referedby-id-param = "cid" equalsip-clean-msg-id
sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
dot-atom = atom *( "." atom )
dot-atom = atom *（ "。"原子）
atom = 1*( alphanum / "-" / "!" / "%" / "*" /
"_" / "+" / "'" / "`" / "~" )
Since the Content-ID appears as a SIP header parameter value which must conform to the expansion of the gen-value defined in [5], this grammar produces values in the intersection of the expansions of gen-value and msg-id from [9]. The double-quotes surrounding the sip-clean-msg-id MUST be replaced with left and right angle brackets to derive the Content-ID used in the message's MIME body. For example,
Content-IDは[5]で定義されているGen-Valueの拡張に準拠する必要があるSIPヘッダーパラメーター値として表示されるため、この文法は[9からのGen-ValueとMSG-IDの拡張の交差点で値を生成します。]。SIPクリーンMSG-IDを囲む二重引用符は、メッセージのMimeボディで使用されるコンテンツIDを導出するために、左および直角ブラケットに置き換える必要があります。例えば、
Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example"
indicates the token is in the body part containing
Content-ID: <2UWQFN309shb3@ref.example>
If the referrer-uri contains a comma, question mark, or semicolon, (for example, if it contains URI parameters) the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
リファラー-URIにコンマ、疑問符、またはセミコロンが含まれている場合（たとえば、URIパラメーターが含まれている場合）、URIは角度ブラケット（<and>）に囲まれている必要があります。URIパラメーターはこれらのブラケットに含まれています。URIが角度ブラケットに囲まれていない場合、セミコロンが区別されるパラメーターは、URIパラメーターではなく、ヘッダーパラメーターです。
The Referred-By header field MAY appear in any SIP request, but is meaningless for ACK and CANCEL. Proxies do not need to be able to read Referred-By header field values and MUST NOT remove or modify them.
紹介されたヘッダーフィールドは、任意のSIPリクエストに表示される場合がありますが、ACKとキャンセルでは無意味です。プロキシは、紹介されたヘッダーのフィールド値を読み取ることができず、それらを削除または変更してはなりません。
The following row should be interpreted as if it appeared in Table 3 of RFC 3261.
次の行は、RFC 3261の表3に表示されるかのように解釈する必要があります。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Referred-By R - o - o o o
The Referred-By token is an Authenticated Identity Body as defined by [3]. This body part MUST be identified with a MIME [6] Content-ID: field.
紹介されたトークンは、[3]で定義されている認証されたアイデンティティ本体です。この体の部分は、mime [6] content-id：fieldで識別する必要があります。
The sipfrag inside a Referred-By token MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request.
紹介されたトークン内のSIPFRAGには、参照要求から紹介、紹介、日付ヘッダーフィールドのコピーを含める必要があります。
The token SHOULD NOT contain the Call-ID header field from the REFER request as that information is not useful to the refer target and may even be an information leak. The token SHOULD NOT contain the From header field from the REFER request since the identity being claimed is represented in the Referred-By header field.
トークンは、参照ターゲットには役に立たず、情報リークである可能性があるため、参照要求からのcall-idヘッダーフィールドを含めるべきではありません。トークンは、請求されているアイデンティティが紹介されたヘッダーフィールドに表されているため、参照要求からのヘッダーフィールドを含めるべきではありません。
The token MAY contain the To header field from the REFER request, but it SHOULD NOT be included unless the referrer has cryptographically identified the referee. Some ways this authentication can be achieved include inspecting the certificates used in a TLS association between the referrer and the referee or encrypting the Refer-To header in the REFER request using the S/MIME encryption techniques detailed in [5].
トークンには、参照要求からヘッダーへのフィールドが含まれる場合がありますが、リファラーが暗号化された審判を識別していない限り、含めるべきではありません。この認証を達成できるいくつかの方法には、[5]に詳述されているS/MIME暗号化技術を使用して、紹介者と審判の間のTLS関連の関連付けを検査するか、紹介要求の紹介ヘッダーを暗号化することが含まれます。
When inspecting the certificates used to establish TLS associations, the identity asserted in the token's To header field URI is compared to the subjectAltNames from the referee's certificate. The sip and sips URI schemes MUST be treated as equivalent for this comparison. If the URI is an exact match, confidence in the authentication is high and the To header field MAY be added to the token. If the certificate subjects contain only a hostname matching the hostname portion of the URI, an application level warning SHOULD be issued to the referrer agent's user seeking that user's consent before including the To header field in the token.
TLS協会を確立するために使用される証明書を検査する場合、トークンのヘッダーフィールドURIに主張された身元は、審判の証明書の対象者と比較されます。SIPおよびSIPS URIスキームは、この比較に相当するものとして扱わなければなりません。URIが正確な一致である場合、認証に対する信頼性が高く、トークンにヘッダーフィールドが追加される場合があります。証明書の被験者がURIのホスト名部分に一致するホスト名のみを含む場合、トークンにヘッダーフィールドを含める前に、ユーザーの同意を求めるリファラーエージェントのユーザーにアプリケーションレベルの警告を発行する必要があります。
Including the To header field in the token significantly strengthens the claim being asserted by the token, but may have privacy implications as discussed in Section 6.1.
トークンのヘッダーフィールドを含めると、トークンによって主張されているクレームが大幅に強化されますが、セクション6.1で説明したようにプライバシーへの影響がある場合があります。
Additional header fields and body parts MAY be included in the token.
トークンには、追加のヘッダーフィールドと体の部分が含まれる場合があります。
As described in [3], a Referred-By token MAY be encrypted as well as signed. The subjectAltName of the certificate used for these operations SHOULD exactly match the identity claimed in the referrer-uri in the Referred-By header field in the token.
[3]で説明されているように、紹介されたトークンは暗号化され、署名されている場合があります。これらの操作に使用される証明書の件名は、トークンの紹介されたヘッダーフィールドのリファラーURIで主張されているIDと正確に一致する必要があります。
A refer target MUST treat a Referred-By token with an invalid signature as an invalid token. A target SHOULD treat a token with an aged Date header field value as invalid.
参照ターゲットは、無効なトークンとして無効な署名を使用して、紹介されたトークンを扱う必要があります。ターゲットは、高齢の日付ヘッダーフィールド値でトークンを無効として扱う必要があります。
A target SHOULD verify that the request it receives matches the reference in the Refer-To header field in the token. This verification SHOULD include at least the request method and any indicated end-to-end header field values. Note that the URI in the Refer-To header field may not match the request URI in the received request due to request re-targeting between the referee and the refer target.
ターゲットは、受信するリクエストがトークンの参照ヘッダーフィールドの参照と一致することを確認する必要があります。この検証には、少なくともリクエスト方法と、指定されたエンドツーエンドヘッダーフィールド値が含まれている必要があります。参照ヘッダーフィールドのURIは、審判と紹介ターゲット間のリクエストリクエストのために、受信リクエストのリクエストURIと一致しない場合があることに注意してください。
The target SHOULD verify that the identity in the Referred-By header field in the token exactly matches the SubjectAltName from the signing certificate, reporting discrepancies to its user as described in [3].
ターゲットは、[3]で説明されているように、ユーザーに不一致を報告する署名証明書の件名と正確に一致しているトークンの参照ヘッダーフィールドのアイデンティティが署名証明書から正確に一致することを確認する必要があります。
If the token contains a To header field, the target SHOULD verify that the identity it expresses matches the referrer. One way of verifying this is to exactly match the identity in the token's To header field with the subjectAltName of the certificate used by the referee to sign the aib protecting the request itself. The 428 response defined in [7] can be used to request such an aib if one is not already present.
トークンにヘッダーからヘッダーのフィールドが含まれている場合、ターゲットが表現するアイデンティティがリファラーと一致することを確認する必要があります。これを検証する1つの方法は、トークンのアイデンティティをヘッダーフィールドに正確に一致させることです。審判が使用する証明書の件名を使用して、リクエスト自体を保護するAIBに署名することです。[7]で定義されている428の応答は、まだ存在していない場合はそのようなAIBを要求するために使用できます。
The 429 client error response code is used by a refer target to indicate that the referee must provide a valid Referred-By token. As discussed in the behavior section, the referee will forward this error response to the referrer in a NOTIFY as the result of the REFER. The suggested text phrase for the 429 error response is "Provide Referrer Identity".
429クライアントエラー応答コードは、参照ターゲットによって使用され、審判が有効な紹介ごとのトークンを提供する必要があることを示します。動作セクションで説明したように、審判は紹介の結果として通知でこのエラー応答を紹介者に転送します。429エラー応答の推奨されるテキストフレーズは、「リファラーのアイデンティティを提供する」です。
The mechanism defined in this specification relies on an intermediary (the referee) to forward information from the referrer to the refer target. This necessarily establishes the referee as an eavesdropper of that information and positions him perfectly to launch man-in-the-middle attacks using the mechanism.
この仕様で定義されているメカニズムは、紹介者から紹介ターゲットに情報を転送するための仲介者（審判）に依存しています。これにより、必然的に審判がその情報の盗聴者として確立され、メカニズムを使用して中間の攻撃を開始するために完全に彼を配置します。
A SIP proxy is similarly positioned. Protecting SIP messaging from malicious proxy implementations is discussed in [5]. In contrast to a proxy, the referee's agent is an endpoint. Proxies will typically be managed and monitored by service providers. Malicious behavior by a proxy is more likely to be noticed and result in negative repercussions for the provider than malicious behavior by an endpoint would be. The behavior of an endpoint can be entirely under the control of a single user. Thus, it is more feasible for an endpoint acting as referee to behave maliciously than it is for a proxy being operated by a service provider.
SIPプロキシも同様に配置されています。悪意のあるプロキシの実装からSIPメッセージングを保護することは、[5]で説明されています。プロキシとは対照的に、審判のエージェントはエンドポイントです。プロキシは通常、サービスプロバイダーによって管理および監視されます。プロキシによる悪意のある行動は、エンドポイントによる悪意のある行動よりも、プロバイダーに否定的な影響を与える可能性が高くなります。エンドポイントの動作は、1人のユーザーの制御下にあることがあります。したがって、レフェリーとして行動するエンドポイントが、サービスプロバイダーによって操作されるプロキシよりも悪意のある行動をとることが可能です。
This specification uses an S/MIME based mechanism to enable the refer target to detect manipulation of the Referred-By information by the referee. Use of this protection is optional! The community has asserted that there are systems where trust in the validity of this information is either not important or can be established through other means. Any implementation choosing not to use this optional mechanism needs to provide its own defense to the following risks:
この仕様では、S/MIMEベースのメカニズムを使用して、参照ターゲットが審判による紹介情報の操作を検出できるようにします。この保護の使用はオプションです！コミュニティは、この情報の有効性に対する信頼が重要ではないか、他の手段を通じて確立できるシステムがあると主張しています。このオプションのメカニズムを使用しないことを選択する実装は、次のリスクに独自の防御を提供する必要があります。
o The Referred-By information is highly likely to influence request admission policy. For instance, it may be displayed to the user of the agent with a "This call was transferred to you by X. Accept?" prompt. A malicious referee can unduly influence that policy decision by providing falsified referred-by information. This includes falsely claiming to have been referred in the first place. (The S/MIME mechanism protects the information with a signature, hampering the referee's ability to inject or modify information without knowing the key used for that signature.)
o 紹介された情報は、リクエスト入学ポリシーに影響を与える可能性が非常に高いです。たとえば、「この呼び出しはX. Accept？」で「この呼び出しがあなたに転送された」というエージェントのユーザーに表示される場合があります。プロンプト。悪意のある審判は、偽造された照会された情報を提供することにより、その政策決定に不当に影響を与えることができます。これには、そもそも参照されたと誤って主張することが含まれます。（S/MIMEメカニズムは、署名で情報を保護し、その署名に使用されるキーを知らずに情報を注入または変更する審判の能力を妨げます。）
o A referee is by definition an eavesdropper of the referred-by information. Parts of that information may be sensitive. (The S/MIME mechanism allows encryption.)
o 審判は、定義上、紹介された情報の盗聴者です。その情報の一部は敏感になる場合があります。（S/MIMEメカニズムにより、暗号化が可能になります。）
o The referee may store any referred-by information it sees and paste it into future unrelated requests. (The S/MIME mechanism allows detection of stale assertions by covering a timestamp with the signature and allows detection of use in unrelated requests by covering the Refer-To header field with the signature.)
o 審判は、紹介された情報を紹介する情報を保存し、将来の無関係なリクエストに貼り付けることができます。（S/MIMEメカニズムにより、タイムスタンプを署名でカバーすることにより、古いアサーションの検出が可能になり、参照ヘッダーフィールドを署名でカバーすることにより、無関係な要求で使用を検出できます。）
The mechanisms in this specification do NOT prevent the referee from deleting ALL referred-by information from the referenced request. A refer target can not detect such deletion. This introduces no new problems since removing all referred-by information from a referenced request transforms it into an ordinary SIP request as described in [5]. Thus the referee gains no new influence over processing logic at the refer target by removing the referred-by information.
この仕様のメカニズムは、参照される要求から参照されたすべての情報を審判が削除することを妨げません。参照ターゲットは、そのような削除を検出できません。これは、参照された要求から参照されたすべての情報を削除することで、[5]で説明されているように通常のSIP要求に変換されるため、新しい問題は発生しません。したがって、審判は、紹介された情報を削除することにより、ターゲットでのロジックの処理に対する新しい影響を獲得しません。
Refer targets can protect themselves from the possibility of a malicious referee removing a token (leaving an unsecured identity in the Referred-By header field) by using the 429 error response.
紹介ターゲットは、429エラー応答を使用して、悪意のある審判がトークンを削除する可能性から自分自身を保護できます（紹介されたヘッダーフィールドに無担保アイデンティティを残す）。
Applications using the mechanisms in this document may be able to take advantage of pre-existing relationships between the participants to mitigate the risks of its use. In some transfer scenarios, A has the choice of referring B to C or referring C to B. If A and B have a pre-existing trust relationship, leading A to have greater confidence that B will not behave maliciously (B is A's administrative assistant for example), referring B to C may make more sense.
このドキュメントでメカニズムを使用したアプリケーションは、参加者間の既存の関係を活用して、その使用のリスクを軽減できる場合があります。いくつかの転送シナリオでは、AはBをCに参照するか、BをBに参照するかを選択します。AとBが既存の信頼関係を持っている場合、AはBが悪意を持って振る舞わないというより大きな自信を持っています（BはAの管理アシスタントです。たとえば）、BをCに参照すると、より理にかなっている場合があります。
This mechanism involves two SIP requests between three endpoints, the REFER and the referenced request. The content of those messages (including the referred-by information) is subject to the security considerations and protection mechanisms documented in [5].
このメカニズムには、3つのエンドポイントの間の2つのSIP要求、参照要求と参照要求が含まれます。これらのメッセージの内容（紹介された情報を含む）は、[5]に文書化されたセキュリティ上の考慮事項と保護メカニズムの対象となります。
Proxies between the participants may collect referred-by information and re-insert it in future requests or make it available to hostile endpoints. The end-to-end confidentiality capabilities discussed in [5] can help reduce the risk of exposing sensitive referred-by information to these proxies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referee and the refer target are identical to the abuse by the referee, and the considerations discussed for a malicious referee applies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referrer and the referee are similar to those discussed for the presentation of Authenticated Identity Bodies in [7].
参加者間のプロキシは、紹介された情報を収集し、将来のリクエストで再挿入するか、敵対的なエンドポイントで利用できるようにすることができます。[5]で議論されているエンドツーエンドの機密性能力は、これらのプロキシに敏感な情報を公開するリスクを減らすのに役立ちます。審判と紹介ターゲットの間のプロキシ（またはそれらが情報を漏らす可能性のあるエンドポイント）によるその後の要求における虐待の可能性は、審判による虐待と同一であり、悪意のある審判について議論された考慮事項が適用されます。紹介者と審判の間のプロキシ（またはそれらが情報を漏らす可能性のあるエンドポイント）によるその後の要求における虐待の可能性は、[7]で認証されたアイデンティティ体の提示について議論されたものと同様です。
To a refer target, a Referred-By token minimally asserts "The identity expressed by this Referred-By header field asked at the time indicated in this Date header field that the request indicated by this Refer-To header field be sent". This assertion makes no claims at all about who is being asked to send the request. This is sufficient to enable policies such as "Accept any requests referred by Alice", but not "Only accept requests from Bob if he can prove that Alice referred him to us". Thus, there is an opportunity for a cut-and-paste attack. If Mallory sees Alice refer Carol to us using a minimal token, he can copy that token into his own request (as long as it matches what is indicated in the embedded Refer-To header), and it will appear to us that Alice referred Mallory to us. This risk is best mitigated by protecting the REFER Alice sends to Carol from eavesdropping, using TLS or the S/MIME mechanisms detailed in [5].
紹介するターゲットに、紹介されたトークンは、「この紹介されたヘッダーフィールドに尋ねられたこの参照ヘッダーフィールドで表明されたアイデンティティは、このヘッダーに示されたリクエストが送信されることを尋ねられました」と主張します。このアサーションは、誰がリクエストを送信するように求められているかについて、まったく主張しません。これは、「アリスが紹介するリクエストを受け入れる」などのポリシーを有効にするのに十分ですが、「アリスが彼を私たちに紹介したことを証明できればボブからのリクエストを受け入れる」ことはありません。したがって、カットアンドペースト攻撃の機会があります。マロリーがアリスが最小限のトークンを使用してキャロルを紹介するのを見た場合、彼はそのトークンを自分の要求にコピーすることができます（埋め込まれた紹介ヘッダーに示されているものと一致する限り）、アリスはマロリーを紹介したように見えます私たちに。このリスクは、[5]で詳述されているTLSまたはS/MIMEメカニズムを使用して、アリスが盗聴からキャロルに送る紹介を保護することにより、最もよく緩和されます。
Including the To header field from the REFER request in the Referred-by token enables the "Only accept requests from Bob if he can prove that Alice referred him to us". Alice is constrained to add this header to the token only if she is sure she is sending the REFER request to Bob. We, in turn, ensure it was Bob that sent the referenced request to us, in addition to validating Alice's signature of the token. Mallory's earlier attack is not effective with this token.
紹介されたトークンの紹介要求からのヘッダーフィールドを含めることで、「アリスが彼を私たちに紹介したことを証明できる場合にのみ、ボブからのリクエストを受け入れる」ことができます。アリスは、ボブに紹介リクエストを送信していると確信している場合にのみ、このヘッダーをトークンに追加するように制約されています。次に、トークンのアリスの署名を検証することに加えて、参照された要求を私たちに送ったのはボブであることを確認します。マロリーの以前の攻撃は、このトークンでは効果的ではありません。
Including the To header field in the Referred-By token has privacy implications, however. Carol, above, might wish to contact us anonymously. That wish would be defeated if Carol's identity appeared in the token Alice created. If Alice encrypted the token to us, Carol will not even be aware of the information leak. To protect herself when she wishes anonymity, Carol will have to reject any REFER requests containing a Referred-By token she can not inspect.
ただし、トークンごとにヘッダーフィールドを含めるには、プライバシーの影響があります。上記のキャロルは、匿名で私たちに連絡したいと思うかもしれません。キャロルの身元がトークンアリスが作成した場合、その願いは敗北するでしょう。アリスがトークンを私たちに暗号化した場合、キャロルは情報漏れさえ認識しません。彼女が匿名性を望んでいるときに自分自身を守るために、キャロルは、彼女が検査できない紹介されたトークンを含む紹介要求を拒否する必要があります。
This example shows the secured Referred-By mechanism applied to a REFER to an SIP INVITE URI.
この例は、SIP招待状の参照に適用される照会されたメカニズムを示しています。
Details are shown only for those messages involved in exercising the mechanism defined in this document.
詳細は、このドキュメントで定義されているメカニズムの行使に関与するメッセージについてのみ表示されます。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: sip:referee@referee.example
From: sip:referrer@referrer.example;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（適切な署名はここにあります）
--dragons39-- --unique-boundary-1--
-dragons39--- Unique-Boundary-1--
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O =審判2890844526 2890844526 IN IP4 referee.example s = session sdp c = in ip4 referee.example t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20398823.2UWQFN309shb3@referrer.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（適切な署名はここにあります）
--dragons39-- --my-boundary-9--
-dragons39----my-boundary-9--
The flow for this example is the same as that of Section 7.1. Here, the referrer has opted to not include a Referred-By token, and the refer target is willing to accept the referenced request without one.
この例のフローは、セクション7.1のフローと同じです。ここで、リファラーは紹介されたトークンを含めないことを選択し、紹介ターゲットは参照された要求なしで受け入れようとします。
F1 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239930 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
Content-Length: 0
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O =審判2890844526 2890844526 IN IP4 referee.example s = session sdp c = in ip4 referee.example t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000
In contrast to the example in Section 7.2, the refer target requires a Referred-By token to accept the referenced request. The referrer chooses to provide an encrypted token (note that the block surrounded by asterisks represents encrypted content). F1 and F2 are identical to the messages detailed in Section 7.2.
セクション7.2の例とは対照的に、参照ターゲットは参照されるリクエストを受け入れるために参照されたトークンを必要とします。リファラーは、暗号化されたトークンを提供することを選択します（アスタリスクに囲まれたブロックは暗号化されたコンテンツを表していることに注意してください）。F1とF2は、セクション7.2で詳述されているメッセージと同一です。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| F3 429 Provide Referrer Identity
| |<---------------------------|
| | ACK |
| F4 NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| F5 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F6 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F3 SIP/2.0 429 Provide Referrer Identity
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>;tag=392093422302334
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Content-Length: 0
F4 NOTIFY sip:referrer@referrer.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390
To: <sip:referrer@referrer.example>;tag=39092342
From: <sip:referee@referee.example>;tag=199949923
Call-ID: 2203900ef0299349d9209f023a
CSeq: 3920390 NOTIFY
Event: refer;id=1239930
Subscription-State: terminated
Content-Type: message/sipfrag
Content-Length: (appropriate value)
SIP/2.0 429 Provide Referrer Identity
SIP/2.0 429リファラーのアイデンティティを提供します
F5 REFER sip:referee@referee.example SIP/2.0
Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423
To: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239931 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature)
（適切な署名）
--boundary42--
-boundary42---
F6 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=1342093482342
Call-ID: 23499234-9239842993@referee.example
CSeq: 19309423 INVITE
Max-Forwards: 70
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Contact: <sip:referee@referee.example>
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: (appropriate value)
--my-boundary-9
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O =審判2890844526 2890844526 IN IP4 referee.example s = session sdp c = in ip4 referee.example t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Refer-To: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;cid="20342EFXEI.390sdefn2@referrer.example" *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature)
（適切な署名）
--boundary42-- --my-boundary-9--
-boundary42----my-boundary-9--
The Refer-To URI may be a SIP URI indicating the REFER method. Consider The following URI which A uses to refer B to send a REFER request to C which refers C to send an INVITE to D.
紹介URIは、参照方法を示すSIP URIである場合があります。bを参照するために使用する次のuriを考えてみましょう。cにcに参照要求を送信します。これは、cをDに送信するcを参照します。
Note that A provides a Referred-By token which gets passed through B and C to D. In particular, B does not provide its own Referred-By token to C. Also note that A is notified of the outcome of the request it triggered at B (the REFER), not at C (the INVITE).
aは、bとcを介してDに渡される紹介されたトークンを提供していることに注意してください。特に、bはCに照会されたトークンを提供しないことに注意してください。B（参照）、C（招待）ではなく。
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
This reference would result in the following flow:
この参照は、次のフローになります。
A B C D
| F1 REFER | | |
|------------------>| | |
| 202 Accepted | | |
|<------------------| | |
| NOTIFY | | |
|<------------------| F2 REFER | |
| 200 OK |------------------>| |
|------------------>| 202 Accepted | |
| F3 NOTIFY |<------------------| |
|<------------------| NOTIFY | |
| 200 OK |<------------------| F4 INVITE |
|------------------>| 200 OK |------------------>|
| |------------------>| 200 OK |
| | NOTIFY |<------------------|
| |<------------------| ACK |
| | 200 OK |------------------>|
| |------------------>| |
| | | |
F1 REFER sip:B SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:B.example>
From: <sip:A.example>;tag=23490234
Call-ID: 2304098023@A.example
CSeq: 2342093 REFER
Max-Forwards: 70
Contact: <sip:A.example>
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（適切な署名はここにあります）
--dragons39-- --unique-boundary-1--
-dragons39--- Unique-Boundary-1--
F2 REFER sip:C.example SIP/2.0
Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842
To: <sip:C.example>
From: <sip:B.example>;tag=2934u23
Call-ID: 203942834@B.example
CSeq: 8321039 REFER
Max-Forwards: 70
Contact: <sip:B.example>
Refer-To: <sip:D.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;cid="23094202342.1012309123@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（適切な署名はここにあります）
--dragons39-- --unique-boundary-1--
-dragons39--- Unique-Boundary-1--
F3 NOTIFY sip:A.example SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:A.example>;tag=23490234
From: <sip:B.example>;tag=5923020
Call-ID: 2304098023@A.example
CSeq: 29420342 NOTIFY
Event: refer;id=2342093
Subscription-State: terminated
Max-Forwards: 70
Contact: <sip:B.example>
Content-Type: message/sipfrag
Content-Length: (appropriate value)
SIP/2.0 202 Accepted
SIP/2.0 202が受け入れました
F4 INVITE sip:D.example SIP/2.0
Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234
To: <sip:D.example>
From: <sip:C.example>;tag=023942334
Call-ID: 23489020352@C.example
CSeq: 1230934 INVITE
Max-Forwards: 70
Contact: <sip:C.example>
Referred-By: <sip:A.example>;
cid="23094202342.10123091233@A.example"
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: (appropriate value)
--unique-boundary-1
Content-Type: application/sdp
Content-Length: (appropriate value)
v=0
o=C 2890844526 2890844526 IN IP4 C.example
s=Session SDP
c=IN IP4 C.example
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
cid="23094202342.1012309123@A.example"
--dragons39
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
(appropriate signature goes here)
（適切な署名はここにあります）
--dragons39-- --unique-boundary-1--
-dragons39--- Unique-Boundary-1--
This document defines a new SIP header field name with a compact form (Referred-By and b respectively). It also defines a new SIP client error response code (429).
このドキュメントでは、コンパクトなフォーム（それぞれ参照とB）を持つ新しいSIPヘッダーフィールド名を定義します。また、新しいSIPクライアントエラー応答コード（429）も定義します。
The following changes are reflected at:
次の変更が反映されています。
http:///www.iana.org/assignments/sip-parameters
http：///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section (replacing any existing row for Referred-By).
次の行がヘッダーフィールドセクションに追加されました（紹介するために既存の行を置き換えます）。
Header Name Compact Form Reference
Referred-By b [RFC3892]
The following row has been added to the response code section under the Request Failure 4xx heading.
次の行は、リクエスト障害4xx見出しの下で応答コードセクションに追加されました。
429 Provide Referrer Identity [RFC3892]
429リファラーのアイデンティティを提供[RFC3892]
Rohan Mahy distilled RFC2822's msg-id into this document's definition of sip-clean-msg-id.
Rohan Mahyは、RFC2822のMSG-IDをこのドキュメントのSIP-Clean-MSG-IDの定義に蒸留しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[2] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[3] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[3] Peterson、J。、「セッション開始プロトコル（SIP）認証IDボディ（AIB）形式」、RFC 3893、2004年9月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4] Sparks、R。、「インターネットメディアタイプメッセージ/Sipfrag」、RFC 3420、2002年11月。
[5] 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.
[5] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[7] Peterson、J。、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、2003年3月、進行中の作業。
[8] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003.
[8] Sparks、R。and A. Johnston、「セッション開始プロトコルコールコントロール - 転送」、2003年2月の作業。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
Robert J. Sparks Xten 5100 Tennyson Parkway Suite 1000 Plano, TX 75024
ロバートJ.スパークスXten 5100テニスンパークウェイスイート1000プラノ、テキサス75024
EMail: RjS@xten.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。