Network Working Group R. Sparks
Request for Comments: 3515 dynamicsoft
Category: Standards Track April 2003
The Session Initiation Protocol (SIP) Refer Method
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.
著作権（C）インターネット協会（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.
この文書は、REFERメソッドを定義します。受信者がリクエストで提供されるリソースを参照して、このセッション開始プロトコル（SIP）の拡張を要求。それは、参照要求の結果が通知されるようにREFER送信パーティを許可するメカニズムを提供します。これは、コール転送など、多くのアプリケーションを、有効にするために使用することができます。
In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.
REFERメソッドに加えて、この文書は参照イベントパッケージと参照の-する要求ヘッダを定義しています。
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.
この文書は、REFERメソッドを定義します。この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がキャロルのSIP連絡先情報を提供ボブのUAにREFERリクエストを送信するために彼女のSIPユーザエージェント（UA）を指示することができます。ボブはそれを許可を与えていると仮定すると、ボブの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.
REFER [1] RFC 3261によって定義されるSIP方法です。 REFERメソッドは、（要求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].
特に明記しない限り、REFER要求に放出し、応答するためのプロトコルは、[1]にBYE要求のものと同一です。 SIPエンティティが参照実装（または任意の他の未知の）メソッドが明示的に定義されていないの動作[1]。
A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2].
REFERリクエストは、暗黙的に参照するイベントへのサブスクリプションを確立します。イベント・サブスクリプションは、[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要求は、INVITEで作成されたダイアログの範囲外に配置されてもよいです。 REFERダイアログを作成し、レコード・ルーティングすることができる、したがって単一Contactヘッダーフィールド値を含まなければなりません。そのダイアログのルート/レコード・ルート・ロジックに従わなければならない既存のダイアログ内で発生指します。
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]で定義されるようにリクエストヘッダフィールド（リクエストヘッダ）です。それだけでREFERリクエストに表示されます。なお、基準へのURLを提供します。
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param)
参照してください-TO =（ "を参照してください-へ" / "R"）HCOLON（名前-addrに/ ADDR-SPEC）*（SEMIジェネリック-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.
Contactヘッダーフィールドは、ルート/レコードルートメカニズムの重要な部分であり、参照の対象を示すために使用することができません。
Examples
例
Refer-To: sip:alice@atlanta.example.com
参照してください-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>
参照してください-TO：<SIP：？bob@biloxi.example.netのAccept-問い合わせ=一口：bobsdeskを。 biloxi.example.net＆コール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>
参照-た：<SIP：dave@denver.example.orgが置き換え= 12345パーセント40192.168.118.3％3Bにタグ％3D12345％3Bfromタグ％の3D5FFE-3994>
Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
参照-TO：<SIP：carol@cleveland.example.org;メソッド= SUBSCRIBE>
Refer-To: http://www.ietf.org
参照してください-TO：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.
このテーブルは、REFERメソッドのヘッダフィールドの存在を記述する、表2及び[1]における3に列を追加します。使用される記号のためのキーの[1]を参照してください。参照のために、リクエストヘッダの行を参照してください必須の、推論されるべきです。参照してください-へは、他の方法には適用されません。 [1]でプロキシ列は未修飾REFERメソッドに適用されます。
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
R oは2XXを受け入れる受け入れREFERヘッダーは - cが415を受け入れたAccept-エンコーディングR Oの2xxエンコーディング-受け入れ - 受け入れエンコード415を受け入れ、言語C R 0たAccept-Languageの2xxを - 受け入れ言語415 Cアラート情報を - Rrのoが許可許可認可のR OコールIDのCMコール情報O 405メートル認証-情報の2xx - 連絡先R mの連絡先の1xx - 連絡先の2xxメートルの接触3-6xx OのContent-処分コンテンツエンコーディング〇〇
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
CMでは、返信先から、O含有量言語0のContent-Length OのContent-Typeの*のCSeqセンチ日付Oエラー-情報3-6xx oがRの有効期限 - マックス・フォワードR mは分を、有効期限 - MIME-バージョン組織Oの優先順位O R - プロキシ認証401 Oプロキシ認証407メートルプロキシ認証Rプロキシ必要R OレコードルートR Oレコードルート2XX、18X O返信に対するO - リトライ後404413480486 Oリトライ後500503°Cの要求リトライ後の被験体のR RO 600603 OルートR Cはサーバ - R、（1）Cを介してoをサポートしていない420 OのUser-AgentをM（2）は、M警告RO WWW認証401メートルWWW認証407℃にOタイムスタンプO 2XXサポート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方法は、本体を含むかもしれません。この仕様は、このような体に何の意味が割り当てられていません。受信エージェントは、そのコンテンツタイプに応じて体を処理することもできます。
REFER is a SIP request and is constructed as defined in [1]. A REFER request MUST contain exactly one Refer-To header field value.
REFER SIPリクエストであり、[1]で定義されるように構成されています。 REFER要求は、フィールド値をヘッダ丁度一つを参照し、含まなければなりません。
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は、（この要求はインタラクティブクエリで、または設定されたポリシーにアクセスを介して満足することができる）に進行するためにユーザからの承認を要求する必要があり整形式REFER要求を受け付けます。承認が許可された場合、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.
承認が即座に拒否されたREFER整形式の要求に対して上記求められた場合、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.
要求は0または1を参照してください、よりフィールド値をヘッダ以上が含まれている場合REFERメソッドに応答するエージェントは400（悪いRequest）を返さなければなりません。
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.
REFER要求を受け入れるか否かを決定するロジックを実装する際には注意が必要です。 UA非SIP URIをアクセスすることはできないが、それらの要求をREFER受け入れるべきではありません。
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.
何最終応答は、上記の規則に従って生成されていない場合REFERトランザクションが満了する前に、UAは、202 ACCEPTEDレスポンスを返さなければなりません。
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.
REFERリクエストは（つまり、の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がINVITE（メソッドを使用=例えばURIパラメータをINVITE）を示すSIP URIである場合、例えば、UAは、新しい[1]で定義された招待を送信するための通常のルールの全てを用いてINVITE発行します。
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機構は、基準の状態のREFER送信エージェントに通知するために使用されなければなりません。各ダイアログの識別子（へ、から、およびCall-ID）は、彼らがREFERがSUBSCRIBEリクエストされていたかのようにREFERのものと一致しなければなりませんNOTIFY。
Each NOTIFY MUST contain an Event header field with a value of refer and possibly an id parameter (see Section 2.4.6).
各々が参照値とおそらくidパラメータ（セクション2.4.6を参照）でEventヘッダフィールドを含まなければならないNOTIFY。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3].
各[3]「メッセージ/ sipfrag」タイプのボディを含まなければなりませんNOTIFY。
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]で定義されたサブスクリプションの作成は常にNOTIFY即時になります。その文書で説明したSUBSCRIBEのため、REFERを発行したエージェントがREFERトランザクションが完了する前にNOTIFY受け取ることを準備する必要がある場合と同様に。
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.
REFERによって作成された暗黙のサブスクリプションは、SUBSCRIBEリクエストで作成され、サブスクリプションと同じです。 REFER発行エージェント[2]に記載の機構を用いて退会することにより早期にこのサブスクリプションを終了することができます。サブスクリプションを終了し、明示的に退会またはNOTIFY拒否することによって、参照要求が取り下げあるいは放棄されるべきであるという指示はありません。エージェントは、参照リクエストが完了する前に参照するイベントへのサブスクリプションを終了REFER送信するので、特に、REFERリクエストに作用する薬は、任意の参照先のSIPリクエストにCANCELを発行するべきではありません。
The agent issuing the REFER may extend its subscription using the subscription refresh mechanisms described in [2].
REFER発行エージェント[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.
REFER参照してくださいイベントへのサブスクリプションを作成することができます唯一のメカニズムです。参照してくださいイベントのSUBSCRIBEリクエストがまだ存在していないサブスクリプションのために受信された場合、それは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.
SUBSCRIBEとは異なり、REFERトランザクションが要求または応答のいずれかでサブスクリプションの期間が含まれていないことに注意してください。加入している状態の寿命は、参照要求の進捗状況によって決定されます。サブスクリプションの期間はREFER受付エージェントによって選択されると、サブスクリプションの初期にREFER送信エージェントに伝達される（サブスクリプション・ステートを使用してヘッダパラメータを期限切れに）NOTIFY。エージェントがREFER受け入れ、この最初の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.
各[3]「メッセージ/ sipfrag」タイプのボディを含まなければなりませんNOTIFY。 [1]で定義されるようにNOTIFYのボディは、SIP応答ステータス行で始まる必要があります。このステータス行のレスポンスクラスは呼ばアクションのステータスを示します。本体は、参照アクションの結果に関する情報を提供するために、他のSIPヘッダーフィールドを含むかもしれません。このボディは呼ばアクションのステータスの完全なステートメントを提供します。参照してくださいイベントパッケージは、状態デルタをサポートしていません。
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).
REFER要求を得ることができ、参照を追跡するために、承認の前に受け入れられ、その承認がその後に拒否された場合（第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にした場合、参照元へのNOTIFYを中ステータスがまだ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.
REFER REFERリクエストのダイアログ識別子を共有する暗黙のサブスクリプションを作成します。 1は、REFER以上が同じダイアログ（たとえばコールを転送における第二の試み）に発行された場合、ダイアログ識別子は、REFER適切と結果のNOTIFYを関連付けるための十分な情報を提供していません。
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.
したがって、UAは、所与のダイアログで受信する第2及び後続のREFER要求のため、それはidパラメータを含まなければなりません[2]それぞれのイベントヘッダフィールド内のシーケンス番号（CSeqヘッダーフィールド値の数）を含むNOTIFYこれが関連付けられているNOTIFY REFER。 UAが与えられたダイアログで受け取るREFERこのidパラメータは、最初にNOTIFYを中に含まれるかもしれません。このidパラメータを含まなければならない。このサブスクリプションをリフレッシュするか、終了するために送られたSUBSCRIBE。
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).
各[2]で定義されるようにSubscription-Stateヘッダフィールドを含まなければならないNOTIFY。最終的にはREFERに応答して送信されたNOTIFYサブスクリプションは、「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.
NOTIFY再加入[2]、REFER送信エージェントが再加入する義務はないに応じて適切であることを示す理由を示す場合。
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]).
REFERが202で受け入れられたが、いつ参照している場合、その理由をその後拒否された基準に従って、再試行-後Subscription-Stateヘッダフィールドの要素に承認を示すために使用することができる場合に再ことができます（[2]にSUBSCRIBEについて記載したように）試みました。
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]において定義されるようにREFERメソッドの定義を知らないレジストラ501は応答を返します。 REFERの定義を知っレジストラは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プロキシはREFERメソッドをサポートするための修正を必要としません。 [1]によって必要とされる具体的に、プロキシはREFER要求を、それがOPTIONS要求を処理するのと同じ方法で処理しなければなりません。
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.
SUBSCRIBE体は、このイベントパッケージのための特別な意味を持ちません。
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.
REFER要求によって作成された暗黙的なサブスクリプションの持続時間は、最初REFER受付エージェントによって決定され、最初のサブスクリプションに送信NOTIFYにSubscription-Stateヘッダフィールドの期限切れパラメータにサブスクライブしているエージェントに伝達されます。この最初の期間のための合理的な選択肢は参照してください-にURIで示された要求の種類によって異なります。期間は、参照要求を完了するために、与えられている時間よりも長くなるように選択する必要があります。参照してください-にURIがSIP URIをINVITEであれば、例えば、サブスクリプション間隔が長くINVITEで期限切れ値よりもする必要があります。追加の時間は、サブスクリプションを許可するために必要な時間を考慮して含まれるかもしれません。サブスクライブするエージェントは、それをリフレッシュすることにより、サブスクリプションを延長する、または退会により、それを終了することができます。セクション2.4.7で説明したように、Subscription-Stateヘッダフィールドにその終了を示す基準の最終結果を報告するとき、REFERを受け入れるエージェントは、サブスクリプションを終了します。
The bodies of NOTIFY requests for event refer are discussed in Section 2.4.5.
イベントのNOTIFYリクエストのボディは、セクション2.4.5で説明されている参照してください。
Notifier processing of SUBSCRIBE requests is discussed in Section 2.4.4.
SUBSCRIBEリクエストの通知処理は、セクション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.
NOTIFYリクエストのサブスクライバ処理はセクション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.
フォークせず、既存のダイアログの範囲内で送信され参照してください。 REFERダイアログMAYフォークの文脈外で送信され、それは複数のエージェントによって受け入れられた場合、複数のサブスクリプションを作成することができます。 REFERがSUBSCRIBEされていたかのようにこれらのサブスクリプションが作成され、[2]の「フォーク状要求の処理」に従って管理されています。 REFER送信エージェントは、個別に各サブスクリプションに関連付けられている状態を管理します。これは、別のサブスクリプションから状態をマージしません。状態は、受付エージェントのそれぞれで参照要求のステータスです。
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.
イベントNOTIFY参照してくださいは、参照リクエストのステータスのたびに新しい知識が利用できるようになるに生成される可能性があります。例えば、参照している場合、INVITE SIPであったのNOTIFYは、各暫定的な応答と、INVITEに対する最終応答して生成されるかもしれません。また、サブスクリプションのみNOTIFYリクエストを二つになる可能性があり、すぐには通知し、参照の最終結果を運ぶNOTIFY。イベントへのNOTIFYは、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.
ここでは、エージェントBが行う（何でも）への参照が成功した場合、エージェントAとエージェントBとの間に4件のメッセージがどのように見えるかの例があります。このフローの詳細は、この特定のセッション外で発生REFER示す（REFERリクエストにタグ付けするために何が存在しません）。 REFERは、セッション内で発生した場合は、要求にタグを付けるには非空であるだろう。
Message One (F1)
メッセージワン（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
SIP REFER：b@atlanta.example.comをSIP / 2.0経由：SIP / 2.0 / UDP agenta.atlanta.example.com;ブランチ= z9hG4bK2293940223へ：<SIP：b@atlanta.example.com>から<SIP： @ atlanta.example.com>;タグ= 193402342コールID：898234234@agenta.atlanta.example.comのCSeq：93809823はREFERマックス・フォワード：70参照してください-た：（どんなURI）連絡先：SIP：a@atlanta.example .COMのContent-Length：0
Message Two (F2)
メッセージつ（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
SIP / 2.0 202受理経由：SIP / 2.0 / UDP agenta.atlanta.example.com;ブランチ= z9hG4bK2293940223へ：<SIP：b@atlanta.example.com>;タグ= 4992881234から：<SIP：a@atlanta.example .COM>;タグ= 193402342コールID：898234234@agenta.atlanta.example.comのCSeq：SIP：b@atlanta.example.comのContent-Length：93809823連絡先をREFER 0
Message Three (F3)
メッセージスリー（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
a@atlanta.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP agentb.atlanta.example.comを、ブランチ= z9hG4bK9922ef992-25へ：<SIP：a@atlanta.example.com>;タグ= 193402342 <一口：b@atlanta.example.com>;タグは= 4992881234コールID：から898234234@agenta.atlanta.example.comのCSeq：1993402マックス-前方にNOTIFY：70イベント：サブスクリプションのステートを参照してください：アクティブ;有効期限が切れます= （参照の対URIに依存して）連絡先：SIP：b@atlanta.example.comのContent-Type：メッセージ/ sipfrag、バージョン= 2.0のContent-Length：20
SIP/2.0 100 Trying
SIP / 2.0 100試行
Message Four (F4)
メッセージ四（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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP agentb.atlanta.example.com;ブランチ= z9hG4bK9922ef992-25へ：<SIP：a@atlanta.example.com>;タグ= 193402342から：<SIP：B @アトランタ.example.comと>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.comのCSeq：SIP：a@atlanta.example.comのContent-Length：1993402連絡先をNOTIFY 0
Message Five (F5)
メッセージファイブ（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
a@atlanta.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP agentb.atlanta.example.comを、ブランチ= z9hG4bK9323394234へ：<SIP：a@atlanta.example.com>;タグ= 193402342から： <SIP：b@atlanta.example.com>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.comのCSeq：1993403は最大前方にNOTIFY：70
Event: refer Subscription-State: terminated;reason=noresource Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 16
イベント：サブスクリプションのステートを参照してください：終了;理由= NORESOURCEお問い合わせ：SIP：b@atlanta.example.comのContent-Type：メッセージ/ sipfrag;バージョン= 2.0のContent-Length：16
SIP/2.0 200 OK
SIP / 2.0 200 OK
Message Six (F6)
メッセージ六（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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP agentb.atlanta.example.com;ブランチ= z9hG4bK9323394234へ：<SIP：a@atlanta.example.com>;タグ= 193402342から：<SIP：b@atlanta.example .COM>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.comのCSeq：SIP：a@atlanta.example.comのContent-Length：1993403連絡先をNOTIFY 0
Message One above brings an implicit subscription dialog into existence. Suppose Agent A issued a second REFER inside that dialog:
メッセージの一つは、上記の存在に、暗黙的なサブスクリプションダイアログをもたらします。エージェントAがそのダイアログ内のREFER秒を発行したと仮定します。
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
b@atlanta.example.com SIP / 2.0経由：SIPをREFER SIP / 2.0 / UDP agenta.atlanta.example.com;ブランチ= z9hG4bK9390399231へ：<SIP：b@atlanta.example.com>;タグ= 4992881234から： <SIP：a@atlanta.example.com>;タグ= 193402342のCall-ID：898234234@agenta.atlanta.example.comのCSeq：93809824は最大前方にREFER：70参照の-TO：（いくつかの異なるURI）連絡先：SIP： a@atlanta.example.comのContent-Length：0
Message Eight (F8)
メッセージ八（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
SIP / 2.0 202受理経由：SIP / 2.0 / UDP agenta.atlanta.example.com;ブランチ= z9hG4bK9390399231へ：<SIP：b@atlanta.example.com>;タグ= 4992881234から：<SIP：a@atlanta.example .COM>;タグ= 193402342コールID：898234234@agenta.atlanta.example.comのCSeq：SIP：b@atlanta.example.comのContent-Length：93809824連絡先をREFER 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
a@atlanta.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP agentb.atlanta.example.comを、ブランチ= z9hG4bK9320394238995へ：<SIP：a@atlanta.example.com>;タグ= 193402342から： <SIP：b@atlanta.example.com>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.comのCSeq：1993404最大前方にNOTIFY：70イベント：参照; ID = 93809824サブスクリプション・ステート：活性; 20：; SIP：：：b@atlanta.example.com Content-Typeのバージョン= 2.0のContent-Lengthメッセージ/ sipfrag =（参照の対URIに依存する）の接触満了します
SIP/2.0 100 Trying
SIP / 2.0 100試行
Message Ten (F10)
メッセージテン（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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP agentb.atlanta.example.com;ブランチ= z9hG4bK9320394238995へ：<SIP：a@atlanta.example.com>;タグ= 193402342から：<SIP：b@atlanta.example .COM>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY Contact: sip:a@atlanta.example.com Content-Length: 0
CSeq：1993404連絡先をNOTIFY：SIP：a@atlanta.example.comのContent-Length：0
Message Eleven (F11)
メッセージセブンイレブン（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
a@atlanta.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / UDP agentb.atlanta.example.com;ブランチ= z9hG4bK2994a93eb-FEた：<SIP：a@atlanta.example.com>;タグ= 193402342 <一口：b@atlanta.example.com>;タグは= 4992881234コールID：から898234234@agenta.atlanta.example.comのCSeq：1993405マックス-前方にNOTIFY：70イベント：参照してください; ID = 93809824のサブスクリプション・ステート：終了;理由= NORESOURCEお問い合わせ：SIP：b@atlanta.example.comのContent-Type：メッセージ/ sipfrag;バージョン= 2.0のContent-Length：16
SIP/2.0 200 OK
SIP / 2.0 200 OK
Message Twelve (F12)
メッセージ十二（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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP agentb.atlanta.example.com;ブランチ= z9hG4bK2994a93eb-Feに対する：<SIP：a@atlanta.example.com>;タグ= 193402342から：<SIP：アトランタ@ B .example.comと>;タグ= 4992881234のCall-ID：898234234@agenta.atlanta.example.comのCSeq：SIP：a@atlanta.example.comのContent-Length：1993405連絡先をNOTIFY 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] REFER取引に適用されるのセクション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任意スキームを含有するREFER要求を受信することができます。例えば、ユーザは、このようなtelnetのURIを使用してMUDなどのオンラインサービスを参照することができます。カスタマーサービスは、HTTP URIを使用してWebページを追跡するために顧客を参照することができます。 2.4.2項では、それが参照スキームを処理できない場合、ユーザエージェントは、REFER要求を拒否することができます。また、URIを使用する前に、そのユーザからの承認を得るために、ユーザーエージェントが必要です。一般的に、これは完全なURIを持つユーザーと、そのような「あなたは、このリソース（Y / N）にアクセスしますか」などの質問を促すことによって達成することができます。もちろん、URIは任意の長さにすることができ、時には悪意で構成され、ケアしては、（このような部分の表示やクラッシュなど）でも、URI自体の表示に驚きを避けるために注意しなければなりません。さらに、ケアは危険な意思決定に惑わされるリスクを軽減するために、ユーザーに可能な限り参照についてできるだけ多くの情報を公開するために取られるべきです。例えば、参照のために、URIと共に表示名を含むことができるヘッダ。何もその表示名によって暗黙の任意のプロパティは、URIによって共有されていることを保証しません。 agent59@telemarketing.example.com：たとえば、表示名が「安全」や「社長」とURIがSIPを示す場合に含まれていてもよいです。このように、単独の表示名をユーザーに促すことは不十分です。
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]で説明したように、これは、例えば、コール転送のために、適切です。ここでは、正しく認証すする:,またはTEL :,一口に既存のSIPダイアログ内のリクエストを参照してください。URIは、インタラクティブにユーザーの許可を得ることなく、政策を通じて受け付けすることができます。同様に、referrorが承認referrorsの明示的なリスト上にある場合は、HTTP 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サーバーを検討してください。それは小さな組織がそのすべてのメンバーを信頼し、少しの内部のセキュリティを持っているこのソフトクリーミー中間の環境で座っているように、ウェブサーバは、メンテナンス上の背後に頻繁にある、任意のコードを実行するには、おそらくその結果（悪意を持って構築されたURIを通じて攻撃に対して脆弱にそれを残しますURIで提供）。 SIP UAは、このファイアウォールの内側に盲目的に任意のHTTP URIへの参照を受け入れた場合、ファイアウォールの外部の攻撃者がWebサーバーを危険にさらす可能性があります。 UAのユーザーがこのURIに作用する前に（例えば、プロンプトへの応答として）積極的な行動を取ることがある一方、リスクは、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.
REFERリクエストの進捗状況と結果を返すために、メッセージ/ 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.
アリスはURIをSIP招待するために要求をREFER受け付けるユーザエージェントを有し、NOTIFYの体内にINVITEに対する各応答をコピーすることによって、INVITEの進行のリファラのNOTIFYと仮定する。
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.
マロリーは、参照してください-にURIキャロルを示すとともに、アリスにREFERを送信することができます。アリスがキャロルに達することができる場合は、200 OKキャロルは、彼はキャロルが周りにあることだけではなく、知っているが、また彼女が使っているエージェントのIPアドレスせ、NOTIFYにマロリーに返される送ります。
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 FOO - 仮定アリスは、上記と同じユーザエージェントと、これまでに発明され、最大のSIPデバイス上で作業している会社で働いています。同社は慎重にアイデア、発想の秘密のも、名前を保つ、デバイスを構築ヶ月やマーケティング資料のために働いてきた（FOOは、彼らはちょうど最初のアイデアを持っていたたければ誰でも行うことができるとものの一つであるため） 。 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とALICEを参照してくださいを送信し、アリスがFOOに接続するよう、マロリーは含む機関とのNOTIFYを取得します
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.
これらの場合の各々について、一般的に、のNOTIFYを介して基準の進行状況に関する利用可能な情報の慎重に選択されたサブセットを返すことは、リスクを軽減します。セクション2.4.5で説明した最小限の実装は、REFERリクエストに応じて動作し、エージェントが行っているかについて、少なくとも情報を公開して、悪意のあるユーザーのための便利なツールであることが最も可能性が高いです。
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.
本明細書で定義されたメカニズムは、将来的に同じ又はREFER異なる関連付けられたNOTIFYリクエストを、全体的にまたは部分的に、NOTIFYリクエストからのメッセージ/ sipfragボディをコピーし、それらの挿入を介して乱用に直接影響を受けにくいです。この仕様ではREFERリクエストに応答するエージェントは、送信するNOTIFYのボディの内容を完全に制御しています。忠実に参照関係者から任意の情報を転送するために、この薬を必要とし、ここで定義されたメカニズムはありません。このように、後で再生するために体を保存すると、エージェントにそれが体なしているよりも、そのピアでこの文書で定義されたメカニズムに影響を与えるためにこれ以上の機能を提供します。同様に、盗聴者によるメッセージ/ 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.
将来の拡張機能は、「私はあなたが私を呼ばパーティーを接触させ、ここでは暗号化証明だ」のような文を作るためにNOTIFYでメッセージ/ 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.
このメソッドは、最初のコール転送アプリケーションによって動機づけられました。 TRANSFERとして出発し、後で参照するために一般化、この方法は、BYEの処理から転送を解離することによって期限切れドラフトIETF-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]で非INVITEリクエストに対して定義されたトランザクションのタイムアウト規則に実行不可能でした。 REFER常に（非INVITEトランザクションの存続期間中に）最終的な応答を即時に受け取る必要があります。
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メソッド名（REFER）、コンパクト形（参照してください - であり、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]をREFER
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
人への問い合わせ先：ロバート・スパークス、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2]ローチ、A. B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[3]、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月スパークス。
[4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress.
「 - 転送セッション開始プロトコル呼制御」が進行中で働いています[4]、R.とA.ジョンストン、スパークス。
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
ロバートJ.がdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024スパークス
EMail: rsparks@dynamicsoft.com
メールアドレス：rsparks@dynamicsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。