[要約] RFC 3515は、SIPのReferメソッドに関する仕様を定義しており、SIPセッションの転送や転送先の制御を可能にする。目的は、SIPプロトコルの拡張として、セッションの転送機能を提供すること。
Network Working Group R. Sparks
Request for Comments: 3515 dynamicsoft
Category: Standards Track April 2003
The Session Initiation Protocol (SIP) Refer Method
セッション開始プロトコル（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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.
このドキュメントは、参照メソッドを定義します。このセッション開始プロトコル（SIP）拡張機能は、受信者がリクエストで提供されるリソースを参照することを要求します。これは、参照要求の結果を紹介に通知するように送信する当事者を可能にするメカニズムを提供します。これを使用して、コール転送など、多くのアプリケーションを有効にすることができます。
In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.
紹介方法に加えて、このドキュメントでは、参照イベントパッケージと参照リクエストヘッダーを定義します。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3
2.1 The Refer-To Header Field . . . . . . . . . . . . . . . 3
2.2 Header Field Support for the REFER Method . . . . . . . 4
2.3 Message Body Inclusion. . . . . . . . . . . . . . . . . 5
2.4 Behavior of SIP User Agents . . . . . . . . . . . . . . 6
2.4.1 Forming a REFER request . . . . . . . . . . . . . 6
2.4.2 Processing a REFER request. . . . . . . . . . . . 6
2.4.3 Accessing the Referred-to Resource. . . . . . . . 6
2.4.4 Using SIP Events to Report the Results
of the Reference. . . . . . . . . . . . . . . . . 7
2.4.5 The Body of the NOTIFY. . . . . . . . . . . . . . 8
2.4.6 Multiple REFER Requests in a Dialog . . . . . . . 9
2.4.7 Using the Subscription-State Header
Field with Event Refer. . . . . . . . . . . . . . 9
2.5 Behavior of SIP Registrars/Redirect Servers . . . . . . 9
2.6 Behavior of SIP Proxies . . . . . . . . . . . . . . . . 10
3. Package Details: Event refer . . . . . . . . . . . . . . . . 10
3.1 Event Package Name. . . . . . . . . . . . . . . . . . . 10
3.2 Event Package Parameters. . . . . . . . . . . . . . . . 10
3.3 SUBSCRIBE Bodies. . . . . . . . . . . . . . . . . . . . 10
3.4 Subscription Duration . . . . . . . . . . . . . . . . . 10
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.6 Notifier processing of SUBSCRIBE requests . . . . . . . 11
3.7 Notifier Generation of NOTIFY Requests. . . . . . . . . 11
3.8 Subscriber Processing of NOTIFY Requests. . . . . . . . 11
3.9 Handling of Forked Requests . . . . . . . . . . . . . . 11
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 11
3.11 State Agents. . . . . . . . . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Prototypical REFER callflow . . . . . . . . . . . . . . 12
4.2 Multiple REFERs in a dialog . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . 16
5.1 Constructing a Refer-To URI . . . . . . . . . . . . . . 16
5.2 Authorization Considerations for REFER. . . . . . . . . 17
5.3 Considerations for the use of message/sipfrag . . . . . 18
5.3.1 Circumventing Privacy . . . . . . . . . . . . . . 18
5.3.2 Circumventing Confidentiality . . . . . . . . . . 19
5.3.3 Limiting the Breach . . . . . . . . . . . . . . . 19
5.3.4 Cut, Paste and Replay Considerations. . . . . . . 19
6. Historic Material . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Normative References. . . . . . . . . . . . . . . . . . 21
9.2 Informative References. . . . . . . . . . . . . . . . . 21
10. Intellectual Property Statement. . . . . . . . . . . . . . . 21
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
This document defines the REFER method. This SIP [1] extension requests that the recipient REFER to a resource provided in the request.
このドキュメントは、参照メソッドを定義します。このSIP [1]拡張機能は、受信者がリクエストで提供されるリソースを参照することを要求します。
This can be used to enable many applications, including Call Transfer. For instance, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP user agent (UA) to send a SIP REFER request to Bob's UA providing Carol's SIP Contact information. Assuming Bob has given it permission, Bob's UA will attempt to call Carol using that contact. Bob's UA will then report whether it succeeded in reaching the contact to Alice's UA.
これを使用して、コール転送など、多くのアプリケーションを有効にすることができます。たとえば、アリスがボブと電話をかけていて、ボブがキャロルと話す必要があると判断した場合、アリスはSIPユーザーエージェント（UA）に、キャロルのSIP連絡先情報を提供するボブのUAにSIP紹介リクエストを送信するよう指示することができます。ボブが許可を与えたと仮定すると、ボブのUAはその連絡先を使用してキャロルに電話しようとします。その後、ボブのUAは、アリスのUAへの接触に到達することに成功したかどうかを報告します。
REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request.
参照は、RFC 3261 [1]で定義されているSIPメソッドです。紹介方法は、レシピエント（リクエスト-URIによって識別）が、リクエストに記載されている連絡先情報を使用して第三者に連絡する必要があることを示しています。
Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1].
特に明記しない限り、紹介要求を放出および応答するためのプロトコルは、[1]のバイ要求のプロトコルと同じです。紹介（またはその他の未知の）メソッドを実装していないSIPエンティティの動作は、[1]で明示的に定義されています。
A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2].
紹介リクエストは、参照イベントのサブスクリプションを暗黙的に確立します。イベントサブスクリプションは[2]で定義されています。
A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog.
参照要求は、招待状で作成されたダイアログの範囲外に配置することができます。参照してくださいダイアログを作成すると、記録的なルーティングされる場合があるため、単一の連絡先ヘッダーフィールド値を含める必要があります。既存のダイアログ内で発生することは、そのダイアログのルート/レコードルートロジックに従う必要があります。
Refer-To is a request header field (request-header) as defined by [1]. It only appears in a REFER request. It provides a URL to reference.
参照は、[1]で定義されているリクエストヘッダーフィールド（リクエストヘッダー）です。参照要求にのみ表示されます。参照するURLを提供します。
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
(SEMI generic-param)
The following 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
___________________________________________________________________
Refer-To R - - - - - -
The Refer-To header field MAY be encrypted as part of end-to-end encryption.
参照ヘッダーフィールドは、エンドツーエンド暗号化の一部として暗号化される場合があります。
The Contact header field is an important part of the Route/Record-Route mechanism and is not available to be used to indicate the target of the reference.
コンタクトヘッダーフィールドは、ルート/レコードルートメカニズムの重要な部分であり、参照のターゲットを示すために使用できません。
Examples
例
Refer-To: sip:alice@atlanta.example.com
Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
Refer-To: http://www.ietf.org
参照：http：//www.ietf.org
Long headers field values are line-wrapped here for clarity only.
長いヘッダーフィールド値は、明確になるためだけにここでラインで包まれています。
This table adds a column to tables 2 and 3 in [1], describing header field presence in a REFER method. See [1] for a key for the symbols used. A row for the Refer-To request-header should be inferred, mandatory for REFER. Refer-To is not applicable for any other methods. The proxy column in [1] applies to the REFER method unmodified.
この表は、[1]の表2および3に列を追加し、参照法のヘッダーフィールドの存在を説明しています。使用されるシンボルのキーについては[1]を参照してください。紹介するリクエストヘッダーの行は推測され、紹介に必須です。参照は、他の方法には適用されません。[1]のプロキシ列は、変更されていない参照メソッドに適用されます。
Header Where REFER
Accept R o
Accept 2xx -
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx -
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx -
Accept-Language 415 c
Alert-Info -
Allow Rr o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info -
Contact R m
Contact 1xx -
Contact 2xx m
Contact 3-6xx o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length o
Content-Type *
CSeq c m
Date o
Error-Info 3-6xx o
Expires R o
From c m
In-Reply-To -
Max-Forwards R m
Min-Expires -
MIME-Version o
Organization o
Priority R -
Proxy-Authenticate 401 o
Proxy-Authenticate 407 m
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 o
Retry-After 500,503 o
Retry-After 600,603 o
Route R c
Server r o
Subject R -
Supported R,2xx o
Timestamp o
To c(1) m
Unsupported 420 o
User-Agent o
Via c(2) m
Warning r o
WWW-Authenticate 401 m
WWW-Authenticate 407 o
Table 1: Header Field Support
表1：ヘッダーフィールドサポート
A REFER method MAY contain a body. This specification assigns no meaning to such a body. A receiving agent may choose to process the body according to its Content-Type.
参照方法にはボディが含まれている場合があります。この仕様は、そのような体に意味を割り当てません。受信エージェントは、コンテンツタイプに応じて身体を処理することを選択できます。
REFER is a SIP request and is constructed as defined in [1]. A REFER request MUST contain exactly one Refer-To header field value.
参照はSIPリクエストであり、[1]で定義されているように構築されています。参照要求には、正確に1つの紹介ヘッダーフィールド値が含まれている必要があります。
A UA accepting a well-formed REFER request SHOULD request approval from the user to proceed (this request could be satisfied with an interactive query or through accessing configured policy). If approval is granted, the UA MUST contact the resource identified by the URI in the Refer-To header field value as discussed in Section 2.4.3.
適切に形成された紹介要求を受け入れるUAは、ユーザーから続行するように承認を要求する必要があります（このリクエストは、インタラクティブなクエリに満たすことができます。承認が認められた場合、UAは、セクション2.4.3で説明したように、紹介ヘッダーフィールド値のURIによって識別されたリソースに連絡する必要があります。
If the approval sought above for a well-formed REFER request is immediately denied, the UA MAY decline the request.
上記の承認が上記の承認がすぐに拒否された場合、UAはリクエストを拒否する可能性があります。
An agent responding to a REFER method MUST return a 400 (Bad Request) if the request contained zero or more than one Refer-To header field values.
リクエストにゼロまたは複数の参照ヘッダーフィールド値が含まれている場合、紹介方法に応答するエージェントは400（悪い要求）を返す必要があります。
An agent (including proxies generating local responses) MAY return a 100 (Trying) or any appropriate 4xx-6xx class response as prescribed by [1].
エージェント（ローカル応答を生成するプロキシを含む）は、[1]で規定されている100（試行）または適切な4xx-6xxクラスの応答を返すことができます。
Care should be taken when implementing the logic that determines whether or not to accept the REFER request. A UA not capable of accessing non-SIP URIs SHOULD NOT accept REFER requests to them.
参照要求を受け入れるかどうかを決定するロジックを実装する場合は、注意が必要です。SIP以外のURIにアクセスできないUAは、それらへの参照要求を受け入れないでください。
If no final response has been generated according to the rules above, the UA MUST return a 202 Accepted response before the REFER transaction expires.
上記のルールに従って最終的な応答が生成されていない場合、UAは紹介トランザクションの有効期限が切れる前に202の受け入れられた応答を返す必要があります。
If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4.
参照要求が受け入れられた場合（つまり、2xxクラスの応答が返されます）、受信者はサブスクリプションを作成し、セクション2.4.4で説明されている参照のステータスの通知を送信する必要があります。
The resource identified by the Refer-To URI is contacted using the normal mechanisms for that URI type. For example, if the URI is a SIP URI indicating INVITE (using a method=INVITE URI parameter for example), the UA would issue a new INVITE using all of the normal rules for sending an INVITE defined in [1].
URIへの紹介によって識別されるリソースは、そのURIタイプの通常のメカニズムを使用して連絡されます。たとえば、URIが招待状を示すSIP URIである場合（たとえば、Method = Invite URIパラメーターを使用）、UAは[1]で定義された招待を送信するためにすべての通常のルールを使用して新しい招待状を発行します。
The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference. The dialog identifiers (To, From, and Call-ID) of each NOTIFY must match those of the REFER as they would if the REFER had been a SUBSCRIBE request.
[2]で定義されている通知メカニズムは、参照のステータスの紹介を送信するエージェントに通知するために使用する必要があります。各notifyのダイアログ識別子（to、from、およびcall-id）は、紹介がサブスクライブリクエストであった場合と同じように紹介の識別子と一致する必要があります。
Each NOTIFY MUST contain an Event header field with a value of refer and possibly an id parameter (see Section 2.4.6).
各notifyには、参照値と場合によってはIDパラメーターのイベントヘッダーフィールドが含まれている必要があります（セクション2.4.6を参照）。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3].
それぞれの通知には、「メッセージ/SIPFRAG」タイプの本文を含める必要があります[3]。
The creation of a subscription as defined by [2] always results in an immediate NOTIFY. Analogous to the case for SUBSCRIBE described in that document, the agent that issued the REFER MUST be prepared to receive a NOTIFY before the REFER transaction completes.
[2]で定義されているサブスクリプションの作成は、常に即時の通知をもたらします。そのドキュメントで説明されている購読の場合と同様に、紹介を発行したエージェントは、紹介トランザクションが完了する前に通知を受け取る準備をしなければなりません。
The implicit subscription created by a REFER is the same as a subscription created with a SUBSCRIBE request. The agent issuing the REFER can terminate this subscription prematurely by unsubscribing using the mechanisms described in [2]. Terminating a subscription, either by explicitly unsubscribing or rejecting NOTIFY, is not an indication that the referenced request should be withdrawn or abandoned. In particular, an agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests because the agent sending the REFER terminated its subscription to the refer event before the referenced request completes.
紹介によって作成された暗黙のサブスクリプションは、サブスクライブリクエストで作成されたサブスクリプションと同じです。紹介を発行するエージェントは、[2]に記載されているメカニズムを使用して登録解除することにより、このサブスクリプションを時期尚早に終了できます。サブスクリプションの終了は、通知を明示的に登録または拒否することにより、参照されるリクエストを撤回または放棄する必要があることを示すものではありません。特に、参照リクエストを送信するエージェントが参照されるリクエストが完了する前に紹介イベントにサブスクリプションを終了したため、参照要求に基づいて参照されるSIPリクエストにキャンセルを発行しないでください。
The agent issuing the REFER may extend its subscription using the subscription refresh mechanisms described in [2].
紹介を発行するエージェントは、[2]で説明されているサブスクリプション更新メカニズムを使用してサブスクリプションを拡張できます。
REFER is the only mechanism that can create a subscription to event refer. If a SUBSCRIBE request for event refer is received for a subscription that does not already exist, it MUST be rejected with a 403.
参照は、イベント参照のサブスクリプションを作成できる唯一のメカニズムです。まだ存在しないサブスクリプションに対して、イベント紹介の購読リクエストが受信された場合、403で拒否する必要があります。
Notice that unlike SUBSCRIBE, the REFER transaction does not contain a duration for the subscription in either the request or the response. The lifetime of the state being subscribed to is determined by the progress of the referenced request. The duration of the subscription is chosen by the agent accepting the REFER and is communicated to the agent sending the REFER in the subscription's initial NOTIFY (using the Subscription-State expires header parameter). Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY.
サブスクライブとは異なり、参照トランザクションには、リクエストまたは応答のいずれかのサブスクリプションの期間が含まれていないことに注意してください。サブスクライブされている国家の寿命は、参照される要求の進捗によって決定されます。サブスクリプションの期間は、エージェントが紹介を受け入れることによって選択され、サブスクリプションの最初の通知で紹介を送信するエージェントに通信されます（サブスクリプション状態の有効期限がヘッダーパラメーターを使用します）。紹介を受け入れ、サブスクリプション状態を保持したくないエージェントは、この最初の通知でサブスクリプションを終了できることに注意してください。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3]. The body of a NOTIFY MUST begin with a SIP Response Status-Line as defined in [1]. The response class in this status line indicates the status of the referred action. The body MAY contain other SIP header fields to provide information about the outcome of the referenced action. This body provides a complete statement of the status of the referred action. The refer event package does not support state deltas.
それぞれの通知には、「メッセージ/SIPFRAG」タイプの本文を含める必要があります[3]。通知の本体は、[1]で定義されているSIP応答ステータスラインから開始する必要があります。このステータス行の応答クラスは、紹介されたアクションのステータスを示します。ボディには、参照されるアクションの結果に関する情報を提供するために、他のSIPヘッダーフィールドが含まれている場合があります。このボディは、紹介されたアクションの状態の完全な声明を提供します。参照イベントパッケージは、State Deltasをサポートしていません。
If a NOTIFY is generated when the subscription state is pending, its body should consist only of a status line containing a response code of 100.
サブスクリプション状態が保留中のときに通知が生成される場合、その本体は100の応答コードを含むステータスラインでのみ構成する必要があります。
A minimal, but complete, implementation can respond with a single NOTIFY containing either the body:
最小限であるが完全な実装は、どちらのボディを含む単一のnotifyで応答できます。
SIP/2.0 100 Trying
SIP/2.0 100試行
if the subscription is pending, the body:
サブスクリプションが保留中の場合、ボディ：
SIP/2.0 200 OK
SIP/2.0 200 OK
if the reference was successful, the body:
参照が成功した場合、ボディ：
SIP/2.0 503 Service Unavailable
SIP/2.0 503サービスは利用できません
if the reference failed, or the body:
参照が故障した場合、またはボディ：
SIP/2.0 603 Declined
SIP/2.0 603が拒否されました
if the REFER request was accepted before approval to follow the reference could be obtained and that approval was subsequently denied (see Section 2.4.7).
参照に従うための承認の前に紹介要求が受け入れられた場合、その承認はその後拒否されました（セクション2.4.7を参照）。
An implementation MAY include more of a SIP message in that body to convey more information. Warning header field values received in responses to the referred action are good candidates. In fact, if the reference was to a SIP URI, the entire response to the referenced action could be returned (perhaps to assist with debugging). However, doing so could have grave security repercussions (see Section 5). Implementers must carefully consider what they choose to include.
実装には、より多くの情報を伝えるために、その本体にもっと多くのSIPメッセージが含まれる場合があります。紹介されたアクションへの回答で受信された警告ヘッダーフィールド値は、良い候補です。実際、参照がSIP URIへの参照である場合、参照されるアクションへの全応答が返される可能性があります（おそらくデバッグを支援するため）。ただし、そうすることで重大なセキュリティの影響がある可能性があります（セクション5を参照）。実装者は、含めるものを選択したものを慎重に検討する必要があります。
Note that if the reference was to a non-SIP URI, status in any NOTIFYs to the referrer must still be in the form of SIP Response Status-Lines. The minimal implementation discussed above is sufficient to provide a basic indication of success or failure. For example, if a client receives a REFER to a HTTP URL, and is successful in accessing the resource, its NOTIFY to the referrer can contain the message/sipfrag body of "SIP/2.0 200 OK". If the notifier wishes to return additional non-SIP protocol specific information about the status of the request, it may place it in the body of the sipfrag message.
参照が非SIP URIへの参照である場合、紹介者への通知のステータスは、まだSIP応答ステータスラインの形である必要があることに注意してください。上記で説明した最小限の実装では、成功または失敗の基本的な兆候を提供するのに十分です。たとえば、クライアントがHTTP URLを参照し、リソースへのアクセスに成功した場合、リファラーへの通知には「SIP/2.0 200 OK」のメッセージ/SIPFRAGボディを含めることができます。通知者がリクエストのステータスに関する追加の非SIPプロトコル固有の情報を返したい場合、SIPFRAGメッセージの本文に配置する場合があります。
A REFER creates an implicit subscription sharing the dialog identifiers in the REFER request. If more than one REFER is issued in the same dialog (a second attempt at transferring a call for example), the dialog identifiers do not provide enough information to associate the resulting NOTIFYs with the proper REFER.
参照は、参照要求でダイアログ識別子を共有する暗黙のサブスクリプションを作成します。同じダイアログ（たとえば、コールを転送する2回目の試行）で複数の紹介が発行されている場合、ダイアログ識別子は、結果の通知を適切な紹介に関連付けるのに十分な情報を提供しません。
Thus, for the second and subsequent REFER requests a UA receives in a given dialog, it MUST include an id parameter[2] in the Event header field of each NOTIFY containing the sequence number (the number from the CSeq header field value) of the REFER this NOTIFY is associated with. This id parameter MAY be included in NOTIFYs to the first REFER a UA receives in a given dialog. A SUBSCRIBE sent to refresh or terminate this subscription MUST contain this id parameter.
したがって、2番目と後続の参照要求特定のダイアログでUAが受信するリクエストでは、各通知のイベントヘッダーフィールドにIDパラメーター[2]を含める必要があります。これを参照してくださいNotifyは関連付けられています。このIDパラメーターは、特定のダイアログで受信される最初の参照に通知に含まれる場合があります。このサブスクリプションを更新または終了するために送信されたサブスクライブには、このIDパラメーターが含まれている必要があります。
Each NOTIFY must contain a Subscription-State header field as defined in [2]. The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request).
各notifyには、[2]で定義されているように、サブスクリプション状態のヘッダーフィールドを含める必要があります。紹介に応じて送信された最終通知は、「noresource」の理由でサブスクリプションが「終了」されたことを示す必要があります。（サブスクライブされるリソースは、参照されるリクエストの状態です）。
If a NOTIFY indicates a reason that indicates a re-subscribe is appropriate according to [2], the agent sending the REFER is NOT obligated to re-subscribe.
[2]によると、通知が再保証が適切であることを示す理由を示した場合、紹介を送信するエージェントは再担保されない義務はありません。
In the case where a REFER was accepted with a 202, but approval to follow the reference was subsequently denied, the reason and retry-after elements of the Subscription-State header field can be used to indicate if and when the REFER can be re-attempted (as described for SUBSCRIBE in [2]).
202で紹介が受け入れられたが、参照に従うための承認がその後拒否された場合、サブスクリプション状態のヘッダーフィールドの理由と再試行後の要素を使用して、紹介を再度にすることができるかどうかを示すことができます試み（[2]で購読するために説明されているように）。
A registrar that is unaware of the definition of the REFER method will return a 501 response as defined in [1]. A registrar aware of the definition of REFER SHOULD return a 405 response.
参照メソッドの定義を知らないレジストラは、[1]で定義されているように501応答を返します。紹介の定義を認識しているレジストラは、405の応答を返す必要があります。
This specification places no requirements on redirect server behavior beyond those specified in [1]. Thus, it is possible for REFER requests to be redirected.
この仕様は、[1]で指定されているものを超えて、リダイレクトサーバーの動作に関する要件を掲載していません。したがって、参照要求をリダイレクトすることが可能です。
SIP proxies do not require modification to support the REFER method. Specifically, as required by [1], a proxy should process a REFER request the same way it processes an OPTIONS request.
SIPプロキシでは、参照メソッドをサポートするための変更を必要としません。具体的には、[1]で要求されているように、プロキシはオプション要求を処理するのと同じ方法で参照要求を処理する必要があります。
This document defines an event package as defined in [2].
このドキュメントでは、[2]で定義されているイベントパッケージを定義します。
The name of this event package is "refer".
このイベントパッケージの名前は「参照」です。
This package uses the "id" parameter defined in [2]. Its use in package is described in Section 2.4.6.
このパッケージは、[2]で定義されている「ID」パラメーターを使用します。パッケージでの使用については、セクション2.4.6で説明しています。
SUBSCRIBE bodies have no special meaning for this event package.
サブスクライブボディは、このイベントパッケージに特別な意味がありません。
The duration of an implicit subscription created by a REFER request is initially determined by the agent accepting the REFER and communicated to the subscribing agent in the Subscription-State header field's expire parameter in the first NOTIFY sent in the subscription. Reasonable choices for this initial duration depend on the type of request indicated in the Refer-To URI. The duration SHOULD be chosen to be longer than the time the referenced request will be given to complete. For example, if the Refer-To URI is a SIP INVITE URI, the subscription interval should be longer than the Expire value in the INVITE. Additional time MAY be included to account for time needed to authorize the subscription. The subscribing agent MAY extend the subscription by refreshing it, or terminate it by unsubscribing. As described in Section 2.4.7, the agent accepting the REFER will terminate the subscription when it reports the final result of the reference, indicating that termination in the Subscription-State header field.
紹介要求によって作成された暗黙のサブスクリプションの期間は、最初に紹介を受け入れるエージェントによって決定され、サブスクリプションヘッダーフィールドのsubscribingエージェントと通信されました。この初期期間の合理的な選択は、紹介URIに示されているリクエストのタイプによって異なります。期間は、参照されるリクエストが完了する時間よりも長くなるように選択する必要があります。たとえば、URIへの紹介がSIP Invite URIである場合、サブスクリプション間隔は招待状の有効期限よりも長くなるはずです。サブスクリプションを承認するために必要な時間を考慮するために、追加の時間を含めることができます。購読エージェントは、サブスクリプションを更新して拡張するか、登録解除によって終了する場合があります。セクション2.4.7で説明されているように、紹介を受け入れるエージェントは、参照の最終結果を報告するときにサブスクリプションを終了し、サブスクリプション状態のヘッダーフィールドの終了を示します。
The bodies of NOTIFY requests for event refer are discussed in Section 2.4.5.
イベント紹介の通知要求の団体については、セクション2.4.5で説明します。
Notifier processing of SUBSCRIBE requests is discussed in Section 2.4.4.
サブスクライブリクエストの通知機処理については、セクション2.4.4で説明します。
Notifier generation of NOTIFY requests is discussed in Section 2.4.4.
Notifyリクエストの通知者の生成については、セクション2.4.4で説明します。
Subscriber processing of NOTIFY requests is discussed in Section 2.4.4.
通知要求のサブスクライバー処理については、セクション2.4.4で説明します。
A REFER sent within the scope of an existing dialog will not fork. A REFER sent outside the context of a dialog MAY fork, and if it is accepted by multiple agents, MAY create multiple subscriptions. These subscriptions are created and managed as per "Handling of Forked Requests" in [2] as if the REFER had been a SUBSCRIBE. The agent sending the REFER manages the state associated with each subscription separately. It does NOT merge the state from the separate subscriptions. The state is the status of the referenced request at each of the accepting agents.
既存のダイアログの範囲内で送信された紹介はフォークされません。ダイアログのコンテキストの外で送信される紹介はフォークする場合があり、複数のエージェントによって受け入れられた場合、複数のサブスクリプションを作成する場合があります。これらのサブスクリプションは、[2]の「フォークリクエストの処理」に従って、紹介がサブスクライブであるかのように作成および管理されます。紹介を送信するエージェントは、各サブスクリプションに関連する状態を個別に管理します。別のサブスクリプションから状態をマージしません。状態は、受け入れエージェントのそれぞれで参照される要求のステータスです。
An event refer NOTIFY might be generated each time new knowledge of the status of a referenced requests becomes available. For instance, if the REFER was to a SIP INVITE, NOTIFYs might be generated with each provisional response and the final response to the INVITE. Alternatively, the subscription might only result in two NOTIFY requests, the immediate NOTIFY and the NOTIFY carrying the final result of the reference. NOTIFYs to event refer SHOULD NOT be sent more frequently than once per second.
参照されるリクエストのステータスに関する新しい知識が利用可能になるたびに、イベント参照通知が生成される場合があります。たとえば、紹介がSIPの招待状へのものである場合、通知は各暫定的な応答と招待に対する最終的な応答で生成される可能性があります。あるいは、サブスクリプションの結果、2つの通知リクエストのみが発生する場合があります。即時通知と通知は、参照の最終結果を伝えます。イベントへの通知は、1秒あたり1回より頻繁に送信されるべきではありません。
Separate state agents are not defined for event refer.
イベント参照のために別々の状態エージェントは定義されていません。
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
| |
Here are examples of what the four messages between Agent A and Agent B might look like if the reference to (whatever) that Agent B makes is successful. The details of this flow indicate this particular REFER occurs outside a session (there is no To tag in the REFER request). If the REFER occurs inside a session, there would be a non-empty To tag in the request.
エージェントAとエージェントBの間の4つのメッセージが、エージェントBが作成する（何でも）参照が成功した場合にどのように見えるかの例を以下に示します。このフローの詳細は、この特定の参照がセッションの外部で発生することを示しています（参照要求にはタグがありません）。紹介がセッション内で発生した場合、リクエストにタグを付けることができません。
Message One (F1)
メッセージ1（f1）
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Two (F2)
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
Message Three (F3)
メッセージ3（f3）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
SIP/2.0 100試行
Message Four (F4)
メッセージ4（F4）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Five (F5)
メッセージ5（f5）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
SIP/2.0 200 OK
SIP/2.0 200 OK
Message Six (F6)
メッセージ6（F6）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message One above brings an implicit subscription dialog into existence. Suppose Agent A issued a second REFER inside that dialog:
上記のメッセージ1つは、暗黙のサブスクリプションダイアログを存在にもたらします。エージェントAがそのダイアログ内で2番目の紹介を発行したとします。
Agent A Agent B
| |
| F7 REFER |
|----------------------->|
| F8 202 Accepted |
|<-----------------------|
| F9 NOTIFY |
|<-----------------------|
| F10 200 OK |
|----------------------->|
| |------->
| | (something different)
| |<------
| |
| F11 NOTIFY |
|<-----------------------|
| F12 200 OK |
|----------------------->|
| |
| |
Message Seven (F7)
メッセージセブン（F7）
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Max-Forwards: 70
Refer-To: (some different URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Eight (F8)
メッセージ8（f8）
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
Message Nine (F9)
メッセージナイン（f9）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
SIP/2.0 100試行
Message Ten (F10)
メッセージ10（f10）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Eleven (F11)
メッセージ11（f11）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
SIP/2.0 200 OK
SIP/2.0 200 OK
Message Twelve (F12)
メッセージ12（f12）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
The security considerations described in Section 26 of [1] apply to the REFER transaction. In particular, the implementation requirements and considerations in Section 26.3 address securing a generic SIP transaction. Special consideration is warranted for the authorization polices applied to REFER requests and for the use of message/sipfrag to convey the results of the referenced request.
[1]のセクション26で説明されているセキュリティ上の考慮事項は、紹介トランザクションに適用されます。特に、セクション26.3の実装要件と考慮事項は、一般的なSIPトランザクションの保護に対応しています。リクエストを参照するために申請された承認ポリシーと、参照されるリクエストの結果を伝えるためのメッセージ/SIPFRAGの使用については、特別な考慮事項が保証されています。
This mechanism relies on providing contact information for the referred-to resource to the party being referred. Care should be taken to provide a suitably restricted URI if the referred-to resource should be protected.
このメカニズムは、紹介されている当事者に紹介されたリソースの連絡先情報を提供することに依存しています。紹介されたリソースを保護する必要がある場合、適切に制限されたURIを提供するように注意する必要があります。
As described in Section 2.4.2, an implementation can receive a REFER requests with a Refer-To URI containing an arbitrary scheme. For instance, a user could be referred to an online service such as a MUD using a telnet URI. Customer service could refer a customer to an order tracking web page using an HTTP URI. Section 2.4.2 allows a user agent to reject a REFER request when it can not process the referenced scheme. It also requires the user agent to obtain authorization from its user before attempting to use the URI. Generally, this could be achieved by prompting the user with the full URI and a question such as "Do you wish to access this resource (Y/N)". Of course, URIs can be arbitrarily long and are occasionally constructed with malicious intent, so care should be taken to avoid surprise even in the display of the URI itself (such as partial display or crashing). Further, care should be taken to expose as much information about the reference as possible to the user to mitigate the risk of being misled into a dangerous decision. For instance, the Refer-To header may contain a display name along with the URI. Nothing ensures that any property implied by that display name is shared by the URI. For instance, the display name may contain "secure" or "president" and when the URI indicates sip:agent59@telemarketing.example.com. Thus, prompting the user with the display name alone is insufficient.
セクション2.4.2で説明されているように、実装は、任意のスキームを含むURIに紹介する紹介要求を受信できます。たとえば、ユーザーは、Telnet URIを使用して泥などのオンラインサービスに紹介できます。カスタマーサービスは、HTTP URIを使用して、顧客を注文追跡Webページに紹介できます。セクション2.4.2では、参照されたスキームを処理できない場合、ユーザーエージェントが参照要求を拒否することができます。また、URIを使用しようとする前に、ユーザーエージェントがユーザーから承認を取得する必要があります。一般的に、これは、完全なURIと「このリソース（Y/N）にアクセスしたいですか」などの質問をユーザーに促すことで達成できます。もちろん、URIはarbitrarily意的に長くなり、時には悪意を持って構築される可能性があるため、URI自体（部分的なディスプレイやクラッシュなど）の表示でも驚きを避けるために注意する必要があります。さらに、危険な決定に惑わされるリスクを軽減するために、ユーザーにできるだけ多くの参照に関する情報を公開するように注意する必要があります。たとえば、参照ヘッダーには、URIとともにディスプレイ名が含まれている場合があります。そのディスプレイ名によって暗示されているプロパティがURIによって共有されることを保証するものはありません。たとえば、ディスプレイ名には「セキュア」または「社長」が含まれている場合があり、URIがsip：agent59@telemarketing.example.comを示した場合。したがって、ディスプレイ名のみでユーザーにプロンプトすることは不十分です。
In some cases, the user can provide authorization for some REFER requests ahead of time by providing policy to the user agent. This is appropriate, for instance, for call transfer as discussed in [4]. Here, a properly authenticated REFER request within an existing SIP dialog to a sip:, sips:, or tel: URI may be accepted through policy without interactively obtaining the user's authorization. Similarly, it may be appropriate to accept a properly authenticated REFER to an HTTP URI if the referror is on an explicit list of approved referrors. In the absence of such pre-provided authorization, the user must interactively provide authorization to reference the indicated resource.
場合によっては、ユーザーはユーザーエージェントにポリシーを提供することにより、事前にいくつかの紹介リクエストの承認を提供できます。これは、たとえば、[4]で説明されている通話転送に適しています。ここでは、既存のSIPダイアログ内のSIP：、SIP：、またはTel：URIがユーザーの承認をインタラクティブに取得することなく、ポリシーを通じて受け入れられる場合があります。同様に、紹介者が承認された紹介者の明示的なリストに載っている場合、適切に認証された紹介を受け入れることが適切である場合があります。このような事前に提供された許可がない場合、ユーザーは、指定されたリソースを参照するための許可をインタラクティブに提供する必要があります。
To see the danger of a policy that blindly accepts and acts on an HTTP URI, for example, consider a web server configured to accept requests only from clients behind a small organization's firewall. As it sits in this soft-creamy-middle environment where the small organization trusts all its members and has little internal security, the web server is frequently behind on maintenance, leaving it vulnerable to attack through maliciously constructed URIs (resulting perhaps in running arbitrary code provided in the URI). If a SIP UA inside this firewall blindly accepted a reference to an arbitrary HTTP URI, an attacker outside the firewall could compromise the web server. On the other hand, if the UA's user has to take positive action (such as responding to a prompt) before acting on this URI, the risk is reduced to the same level as the user clicking on the URI in a web-browser or email message.
たとえば、HTTP URIに盲目的に受け入れて行動するポリシーの危険を確認するには、小さな組織のファイアウォールの背後にあるクライアントからのみリクエストを受け入れるように構成されたWebサーバーを検討します。小規模な組織がすべてのメンバーを信頼し、内部セキュリティがほとんどないこのソフトクリーミーミドル環境に位置するため、Webサーバーはメンテナンスに頻繁に遅れており、悪意のあるURIを介して攻撃を受けやすくなります（おそらく任意のコードを実行することになりますURIに提供）。このファイアウォール内のSIP UAが、任意のHTTP URIへの参照を盲目的に受け入れた場合、ファイアウォールの外側の攻撃者はWebサーバーを損なう可能性があります。一方、このURIで行動する前にUAのユーザーが肯定的なアクション（プロンプトに応答するなど）を実行する必要がある場合、ユーザーがWebブラウザーまたは電子メールでURIをクリックするのと同じレベルにリスクが低下しますメッセージ。
The conclusion in the above paragraph generalizes to URIs with an arbitrary scheme. An agent that takes automated action to access a URI with a given scheme risks being used to indirectly attack another host that is vulnerable to some security flaw related to that scheme. This risk and the potential for harm to that other host is heightened when the host and agent reside behind a common policy-enforcement point such as a firewall. Furthermore, this agent increases its exposure to denial of service attacks through resource exhaustion, especially if each automated action involves opening a new connection.
上記の段落の結論は、任意のスキームでURIに一般化されます。特定のスキームでURIにアクセスするために自動化されたアクションを取るエージェントは、そのスキームに関連するいくつかのセキュリティ欠陥に対して脆弱な別のホストを間接的に攻撃するために使用されるリスクが使用されます。このリスクとその他のホストへの危害の可能性は、ホストとエージェントがファイアウォールなどの共通の政策執行ポイントの後ろに存在すると高められます。さらに、このエージェントは、特に各自動化されたアクションが新しい接続を開くことを伴う場合、リソースの疲労を通じてサービス拒否攻撃への暴露を増やします。
User agents should take care when handing an arbitrary URI to a third-party service such as that provided by some modern operating systems, particularly if the user agent is not aware of the scheme and the possible ramifications using the protocols it indicates. The opportunity for violating the principal of least surprise is very high.
ユーザーエージェントは、特にユーザーエージェントがスキームとそれが示すプロトコルを使用した可能性のある影響を認識していない場合、いくつかの最新のオペレーティングシステムによって提供されるようなサードパーティサービスに任意のURIを渡すときに注意する必要があります。校長に違反する機会が最も少ないことは非常に高いです。
Using message/sipfrag bodies to return the progress and results of a REFER request is extremely powerful. Careless use of that capability can compromise confidentiality and privacy. Here are a couple of simple, somewhat contrived, examples to demonstrate the potential for harm.
メッセージ/SIPFRAGボディを使用して、紹介リクエストの進行状況と結果を返すことは非常に強力です。その機能の不注意な使用は、機密性とプライバシーを損なう可能性があります。ここに、害の可能性を示すための単純でやや不自然な例がいくつかあります。
Suppose Alice has a user agent that accepts REFER requests to SIP INVITE URIs, and NOTIFYs the referrer of the progress of the INVITE by copying each response to the INVITE into the body of a NOTIFY.
Aliceには、SIP To Invite URISへの紹介リクエストを受け入れるユーザーエージェントがあり、招待状に各応答をコピーすることにより、招待状の進捗状況を紹介します。
Suppose further that Carol has a reason to avoid Mallory and has configured her system at her proxy to only accept calls from a certain set of people she trusts (including Alice), so that Mallory doesn't learn when she's around, or what user agent she's actually using.
さらに、キャロルにはマロリーを避ける理由があり、彼女が信頼する特定の人々（アリスを含む）からの電話のみを受け入れるように彼女のプロキシで彼女のシステムを構成していると仮定します。彼女は実際に使用しています。
Mallory can send a REFER to Alice, with a Refer-To URI indicating Carol. If Alice can reach Carol, the 200 OK Carol sends gets returned to Mallory in a NOTIFY, letting him know not only that Carol is around, but also the IP address of the agent she's using.
マロリーはアリスに紹介を送ることができ、紹介はウリを指定しているキャロルを示しています。アリスがキャロルに到達できる場合、200 OKキャロルの送信者は通知でマロリーに返され、キャロルが周りにいるだけでなく、使用しているエージェントのIPアドレスも知らせます。
Suppose Alice, with the same user agent as above, is working at a company that is working on the greatest SIP device ever invented - the SIP FOO. The company has been working for months building the device and the marketing materials, carefully keeping the idea, even the name of the idea secret (since a FOO is one of those things that anybody could do if they'd just had the idea first). FOO is up and running, and anyone at the company can use it, but it's not available outside the company firewall.
上記と同じユーザーエージェントを持つアリスが、これまでに発明された最大のSIPデバイスに取り組んでいる会社であるSIP Fooで働いているとします。同社は、デバイスとマーケティング資料の構築を何ヶ月も働いており、アイデアを慎重に維持し、アイデアの秘密さえも秘密にしています（Fooは、最初にアイデアを持っていた場合に誰でもできることの1つです。。Fooは稼働しており、会社の誰でも使用できますが、会社のファイアウォールの外では利用できません。
Mallory has heard rumor that Alice's company is onto something big, and has even managed to get his hands on a URI that he suspects might have something to do with it. He sends a REFER to ALICE with the mysterious URI and as Alice connects to the FOO, Mallory gets NOTIFYs with bodies containing
マロリーは、アリスの会社が何か大きなものになっているという噂を聞いており、彼がそれと関係があるのではないかと疑っているURIを手に入れることさえできました。彼は神秘的なURIでアリスに紹介を送り、アリスがフーに接続すると、マロリーはボディを含む通知を受け取ります
Server: FOO/v0.9.7
サーバー：foo/v0.9.7
For each of these cases, and in general, returning a carefully selected subset of the information available about the progress of the reference through the NOTIFYs mitigates risk. The minimal implementation described in Section 2.4.5 exposes the least information about what the agent operating on the REFER request has done, and is least likely to be a useful tool for malicious users.
これらの各ケースについて、および一般に、通知を介して参照の進捗状況について利用可能な情報の慎重に選択されたサブセットを返すことは、リスクを軽減します。セクション2.4.5で説明されている最小限の実装では、参照要求で動作しているエージェントが行ったことに関する最小限の情報を公開しており、悪意のあるユーザーにとって有用なツールである可能性が最も高くなります。
The mechanism defined in this specification is not directly susceptible to abuse through copying the message/sipfrag bodies from NOTIFY requests and inserting them, in whole or in part, in future NOTIFY requests associated with the same or a different REFER. Under this specification the agent replying to the REFER request is in complete control of the content of the bodies of the NOTIFY it sends. There is no mechanism defined here requiring this agent to faithfully forward any information from the referenced party. Thus, saving a body for later replay gives the agent no more ability to affect the mechanism defined in this document at its peer than it has without that body. Similarly, capture of a message/sipfrag body by eavesdroppers will give them no more ability to affect this mechanism than they would have without it.
この仕様で定義されているメカニズムは、メッセージ/SIPFRAGボディを通知を通知し、将来、同じまたは異なる紹介に関連付けられたリクエストを通知するリクエストから挿入することから、乱用を乱用する可能性がありません。この仕様の下で、紹介要求に返信するエージェントは、送信される通知の本体のコンテンツを完全に制御しています。ここでは、参照された当事者から情報を忠実に転送することをこのエージェントに要求するメカニズムはありません。したがって、後でリプレイのためにボディを保存すると、エージェントがこの文書で定義されたメカニズムに影響を与える能力はなく、その体がないよりも、このドキュメントで定義されています。同様に、盗聴者によるメッセージ/sipfrag本体のキャプチャは、それらが持たないよりもこのメカニズムに影響を与える能力を与えません。
Future extensions may place additional constraints on the agent responding to REFER to allow using the message/sipfrag body part in a NOTIFY to make statements like "I contacted the party you referred me to, and here's cryptographic proof". These statements might be used to affect the behavior of the receiving UA. This kind of extension will need to define additional mechanism to protect itself from copy based attacks.
将来の拡張機能は、通知でメッセージ/SIPFRAGボディの部分を使用することを許可するように応答するエージェントに追加の制約を課すことができます。これらのステートメントは、受信UAの動作に影響を与えるために使用される場合があります。この種の拡張機能は、コピーベースの攻撃から自分自身を保護するための追加のメカニズムを定義する必要があります。
This method was initially motivated by the call-transfer application. Starting as TRANSFER, and later generalizing to REFER, this method improved on the BYE/Also concept of the expired draft-ietf-sip-cc-01 by disassociating transfers from the processing of BYE. These changes facilitate recovery of failed transfers and clarify state management in the participating entities.
この方法は、当初、コール転送アプリケーションによって動機付けられていました。転送として開始し、後に参照するために一般化するこの方法は、BYEの処理から転送を分離することにより、期限切れのドラフト-SIP-CC-01のBYE/概念を改善しました。これらの変更により、故障した転送の回復が容易になり、参加エンティティの国家管理を明確にします。
Early versions of this work required the agent responding to REFER to wait until the referred action completed before sending a final response to the REFER. That final response reflected the success or failure of the referred action. This was infeasible due to the transaction timeout rules defined for non-INVITE requests in [1]. A REFER must always receive an immediate (within the lifetime of a non-INVITE transaction) final response.
この作業の初期バージョンでは、紹介に最終的な応答を送信する前に、紹介アクションが完了するまで紹介するのに応答するエージェントが応答する必要がありました。その最終的な応答は、紹介された行動の成功または失敗を反映しています。これは、[1]の非インバイト要求に対して定義されたトランザクションタイムアウトルールのために実行不可能でした。紹介は、常に（非インバイトトランザクションの寿命以内）最終応答を常に受け取る必要があります。
This document defines a new SIP method name (REFER), a new SIP header field name with a compact form (Refer-To and r respectively), and an event package (refer).
このドキュメントでは、新しいSIPメソッド名（参照）、コンパクトなフォーム（それぞれ参照とR）の新しいSIPヘッダーフィールド名、およびイベントパッケージ（参照）を定義します。
The following has been added to the method sub-registry under http://www.iana.org/assignments/sip-parameters.
以下は、http：//www.iana.org/assignments/sip-parametersに基づいてメソッドサブレジストリに追加されています。
REFER [RFC3515]
[RFC3515]を参照してください
The following information also has been be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
以下の情報は、http：//www.iana.org/assignments/sip-parametersに基づいてヘッダーサブレジストリにも追加されています。
Header Name: Refer-To
ヘッダー名：参照してください
Compact Form: r
コンパクトフォーム：r
Reference: RFC 3515
参照：RFC 3515
This specification registers an event package, based on the registration procedures defined in [2]. The following is the information required for such a registration:
この仕様は、[2]で定義されている登録手順に基づいて、イベントパッケージを登録します。以下は、そのような登録に必要な情報です。
Package Name: refer
パッケージ名：参照
Package or Package-Template: This is a package.
パッケージまたはパッケージテンプレート：これはパッケージです。
Published Specification: RFC 3515
公開された仕様：RFC 3515
Person to Contact: Robert Sparks, rsparks@dynamicsoft.com
連絡先：Robert Sparks、rsparks@dynamicsoft.com
This document is a collaborative product of the SIP working group.
このドキュメントは、SIPワーキンググループの共同製品です。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A。B.、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[3] Sparks、R。、「インターネットメディアタイプメッセージ/Sipfrag」、RFC 3420、2002年11月。
[4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress.
[4] Sparks、R。and A. Johnston、「セッション開始プロトコルコールコントロール - 転送」、進行中の作業。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
Robert J. Sparks Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024
EMail: rsparks@dynamicsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。