RFC3515 日本語訳
3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. (Format: TXT=47788 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Sparks Request for Comments: 3515 dynamicsoft Category: Standards Track April 2003
スパークがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3515dynamicsoft Category: 標準化過程2003年4月
The Session Initiation Protocol (SIP) Refer Method
セッション開始プロトコル(一口)は方法を参照します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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方法を定義します。 このSession Initiationプロトコル(SIP)拡大は、リソースへの受取人REFERが要求に提供したよう要求します。 それはREFERを送るパーティーが参照をつけられた要求の結果について通知されるのを許容するメカニズムを提供します。 呼び出し転送を含む多くのアプリケーションを可能にするのにこれを使用できます。
In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.
そして、REFER方法、このドキュメントに加えた定義、イベントパッケージを参照してください、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
1. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 方法. . . . . . . . . . . . . . . . . . . . . . 3 2.1を参照してください、.32.2ヘッダーがサポートをさばくヘッダーフィールドを参照してください、方法.42.3メッセージボディー包含を参照してください。 . . . . . . . . . . . . . . . . 5 2.4 .62.4.1Forming a REFER要求. . . . . . . . . . . . . 6 2.4.2Processing a REFERが要求するSIP Userエージェントの振舞い。 . . . . . . . . . . . 6 2.4 .3 言及しているリソースにアクセスします。 . . . . . . . 6 2.4 .4 参照の結果を報告するのに一口出来事を使用します。 . . . . . . . . . . . . . . . . 7 2.4 .5、ボディー、通知してください。 . . . . . . . . . . . . . 8 2.4 .6倍数は出来事に伴う購読州のヘッダーフィールドを使用する.7に参照されるという対話. . . . . . . 9 2.4における要求を参照します。 . . . . . . . . . . . . . 9
Sparks Standards Track [Page 1] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[1ページ]RFC3515をかきたてます。
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
2.5 一口プロキシ. . . . . . . . . . . . . . . . 10 3の一口記録係/再直接のサーバ. . . . . . 9 2.6の振舞いの振舞い。 詳細をパッケージしてください: 出来事は.103.1EventパッケージNameを参照します。 . . . . . . . . . . . . . . . . . . 10 3.2 イベントパッケージパラメタ。 . . . . . . . . . . . . . . . 10 3.3はボディーを申し込みます。 . . . . . . . . . . . . . . . . . . . 10 3.4 登録、NOTIFY Requestsの要求. . . . . . . 11 3.7Notifier Generationの購読Duration. . . . . . . . . . . . . . . . . 10 3.5NOTIFY Bodies. . . . . . . . . . . . . . . . . . . . . 11 3.6Notifier処理。 . . . . . . . . 11 3.8 加入者処理、要求に通知してください。 . . . . . . . 11 3.9 .11 3.11がエージェントを述べるという通知の股状の要求. . . . . . . . . . . . . . 11 3.10率の取り扱い。 . . . . . . . . . . . . . . . . . . . . . 11 4. 対話. . . . . . . . . . . . . . 14 5における例. . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1のPrototypical REFER callflow. . . . . . . . . . . . . . 12 4.2Multiple REFERs。 aを組み立てるセキュリティ問題. . . . . . . . . . . . . . . . . . 16 5.1が.165.2のURI認可問題を示す、参照してください。 . . . . . . . . 17 5.3 メッセージ/sipfragな.185.3.1Circumventing Privacy. . . . . . . . . . . . . . 18 5.3.2Circumventing Confidentiality. . . . . . . . . . 19 5.3.3Limiting Breachの使用のための問題、.195.3、.4Cut、PasteとReplay Considerations。 . . . . . . 19 6. 歴史的な材料. . . . . . . . . . . . . . . . . . . . . 20 7。 IANA問題. . . . . . . . . . . . . . . . . . . . 20 8。 承認. . . . . . . . . . . . . . . . . . . . . . 21 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1引用規格。 . . . . . . . . . . . . . . . . . 21 9.2 有益な参照。 . . . . . . . . . . . . . . . . 21 10. 知的所有権声明。 . . . . . . . . . . . . . . 21 11. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 22 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 23
1. Overview
1. 概観
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]拡大は、リソースへの受取人REFERが要求に提供したよう要求します。
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.
Call Transferを含む多くのアプリケーションを可能にするのにこれを使用できます。 例えば、アリスが、ボブとの呼び出しでいて、ボブが、キャロルと話す必要であると決めるなら、アリスは、キャロルのSIP Contact情報を提供しながら、SIP REFER要求をボブのUAに送るよう彼女のSIPユーザエージェント(UA)に命令できます。 ボブが許可をそれに与えたと仮定すると、ボブのUAは、キャロルをその接触を使用すると呼ぶのを試みるでしょう。 そして、それが、アリスのUAとの接触に達するのに成功したか否かに関係なく、ボブのUAは報告するでしょう。
Sparks Standards Track [Page 2] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[2ページ]RFC3515をかきたてます。
2. The REFER Method
2. 方法を参照してください。
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はRFC3261[1]によって定義されるようにSIP方法です。 REFER方法は、要求に提供された問い合わせ先を使用することで受取人(Request-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]でのBYE要求に、放つプロトコルとREFER要求に応じるのはそれらと同じです。 REFER(または、いかなる他の未知も)方法を実行しない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は対話を作成して、Recordによって発送されているかもしれなくて、したがって、ただ一つのContactヘッダーフィールド価値を含まなければなりません。 既存の対話で起こるREFERsはその対話のRoute/記録ルート論理に従わなければなりません。
2.1 The Refer-To Header Field
2.1、ヘッダーフィールドを参照してください。
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)
=(/「r」について「言及する」)HCOLON(名前addr / addr仕様)*を参照してください。(SEMIジェネリック-param)
The following should be interpreted as if it appeared in Table 3 of RFC 3261.
以下はまるでRFC3261のTable3に現れるかのように解釈されるべきです。
Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Refer-To R - - - - - -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________________ Rを参照してください--、--、--、--、--、-
The Refer-To header field MAY be encrypted as part of end-to-end encryption.
Refer、-、ヘッダーフィールドは終端間暗号化の一部としてコード化されるかもしれません。
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ヘッダーフィールドは、Route/記録ルートメカニズムの重要な部分であり、参照の目標を示すのにおいて使用されているために利用可能ではありません。
Sparks Standards Track [Page 3] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[3ページ]RFC3515をかきたてます。
Examples
例
Refer-To: sip:alice@atlanta.example.com
To:を参照します。 一口: 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:を参照します。 <一口: bob@biloxi.example.net?Accept-Contact =一口: 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>
To:を参照します。 <一口: dave@denver.example.org?Replaces がタグ%3D12345への12345%40192.168.118の.3%の3Bと等しい、%3Bfrom-タグ%3D5FFE-3994>。
Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
To:を参照します。 <一口: carol@cleveland.example.org;method は登録、>と等しいです。
Refer-To: http://www.ietf.org
To:を参照します。 http://www.ietf.org
Long headers field values are line-wrapped here for clarity only.
分野が評価する長いヘッダーは明快だけためにここで線によって包装されています。
2.2 Header Field Support for the REFER Method
2.2ヘッダーがサポートをさばく、方法を参照してください。
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方法でヘッダーフィールド存在について説明して、このテーブルは[1]のテーブル2と3にコラムを加えます。 シンボルのためのキーのための[1]が使用されるのを見てください。 Aが船をこぐ、Refer、-、要求ヘッダー、推論されていて、REFERに義務的であるべきです。 言及、いかなる他の方法においても、適切ではありません。 [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
ヘッダーWhere REFER Accept R o Accept 2xx--Call-インフォメーション--接触R m Contact 1xx--接触2xx m Contact3-6xx o Content-気質o Content-コード化oを415 405mのAcceptをコード化しているR o2xx--コード化を受け入れている415c Accept-言語R o Accept-言語2xx(言語を受け入れている415c Alert-インフォメーション)が許すc Accept-コード化Rr o Allow Authentication-インフォメーション2xx o Authorization R o Call-ID c m受け入れてください。
Sparks Standards Track [Page 4] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[4ページ]RFC3515をかきたてます。
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
満足している言語o Content-長さのoコンテントタイプ*CSeq c m Date o Error-インフォメーション3-6xxなo Expires R o From c m、Inが答える、--前方へマックスR mはMin期限が切れます--MIMEバージョンo Organization o Priority R--oがProxy認証する401をプロキシで認証する407m Proxy-認可R oはR o Record-ルートR o Record-ルート2xxをProxy必要とします; 18x o、Reply、-、--c後のRetry4044億1348万486o後のRetry50万503後の○Retry60万603○Route R c Server r o Subject R--Rを支持するのを必要にしてください、To c(1)m Unsupported420o User-エージェントo Via c(2)m Warning r oが401mにWWW認証する2xx o Timestamp○が407oをWWW認証する
Table 1: Header Field Support
テーブル1: ヘッダーフィールドサポート
2.3 Message Body Inclusion
2.3 メッセージボディー包含
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方法はボディーを含むかもしれません。 この仕様はそのようなボディーに意味を割り当てません。 受信エージェントは、コンテントタイプに従ってボディーを処理するのを選ぶかもしれません。
Sparks Standards Track [Page 5] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[5ページ]RFC3515をかきたてます。
2.4 Behavior of SIP User Agents
2.4 一口ユーザエージェントの振舞い
2.4.1 Forming a REFER request
2.4.1 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要求がちょうど1つを含まなければならない、Refer、-、ヘッダーフィールド値。
2.4.2 Processing a REFER request
2.4.2 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.
SHOULDが、ユーザからの承認を続かせるよう(対話的な質問か構成された方針にアクセスすることを通してこの要望は応じることができるでしょう)要求するよく形成されたREFER要求を受け入れるUA。 可決されるなら、Uaが中でURIによって特定されたリソースに連絡しなければならない、Refer、-、セクション2.4で.3に議論するヘッダーフィールド値
If the approval sought above for a well-formed REFER request is immediately denied, the UA MAY decline the request.
よく形成されたREFER要求のために上で求められた承認がすぐに否定されるなら、UA MAYは要求を断ちます。
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.
要求がゼロか1つ以上を含んだならREFER方法に応じているエージェントが400(悪いRequest)を返さなければならない、Refer、-、ヘッダーフィールド値。
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要求を受け入れるかどうか決定する論理を実行するとき、注意するべきです。 URI SHOULD NOTが受け入れる非SIP REFER要求にそれらにアクセスできない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.
規則に従ってどんな最終的な応答も発生していないなら、REFER取引が期限が切れる前に上に、Uaは202Accepted応答を返さなければなりません。
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に説明されるように、参照してください。
2.4.3 Accessing the Referred-to Resource
2.4.3 言及しているリソースにアクセスすること。
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].
リソースが特定した、Refer、-、URI、そのURIタイプに正常なメカニズムを使用することで、連絡されます。 例えば、URIがINVITE(例えば方法=INVITE URIパラメタを使用する)を示すSIP URIであるなら、UAは、[1]で定義されたINVITEを送るのに正常な規則のすべてを使用することで新しいINVITEを発行するでしょう。
Sparks Standards Track [Page 6] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[6ページ]RFC3515をかきたてます。
2.4.4 Using SIP Events to Report the Results of the Reference
2.4.4 参照の結果を報告するのに一口出来事を使用すること。
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.
参照の状態についてREFERを送るエージェントに知らせるのに[2]で定義されたNOTIFYメカニズムを使用しなければなりません。 それぞれでは、NOTIFYはREFERが登録なら合わせるようにREFERのものに合わなければなりません。対話識別子、(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 MUSTが値があるEventヘッダーフィールドを含むそれぞれがことによると参照されます。イドパラメタ(セクション2.4.6を見ます)。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3].
各NOTIFY MUSTはタイプ「メッセージ/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]によって定義される購読の創造はいつも即座のNOTIFYをもたらします。 登録、それが記録する説明されたコネ、NOTIFYを受け取る準備されていて、REFER MUSTを発行したREFER取引が完成するエージェントにとってケースに類似しています。
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によって作成された暗黙の購読は購読が登録で要求を作成したのと同じです。 REFERを発行するエージェントは、早まって、[2]で説明されたメカニズムを使用することで外すことによって、この購読を終えることができます。 明らかにNOTIFYを外すか、または拒絶することによって購読を終えるのは、参照をつけられた要求が引き下がるべきであるか、または捨てられるべきであるという指示ではありません。 REFERを送るエージェントが購読を終えたので特に、REFER要求SHOULD NOT問題にいずれへのキャンセルを活動させているエージェントがSIP要求に参照をつけた、要求が完了する参照箇所の前に出来事を参照してください。
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による出来事の購読を作成できる唯一のメカニズムが参照されるということです。 登録なら、出来事が参照されるので、既に存在しない購読のために要求を受け取って、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.
登録、REFER取引と異なったそれが要求か応答のどちらかにおける購読のための持続時間を含まないのに注意してください。 加入される状態の寿命は参照をつけられた要求の進歩で決定します。 購読の持続時間は、REFERを受け入れるエージェントによって選ばれていて、購読の初期のNOTIFYでREFERを送るエージェントに伝えられます(Subscription-状態を使用すると、ヘッダーパラメタは吐き出されます)。 REFERを受け入れて、購読状態を保持したがっていないエージェントがこの初期のNOTIFYとの購読を終えることができることに注意してください。
Sparks Standards Track [Page 7] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[7ページ]RFC3515をかきたてます。
2.4.5 The Body of the NOTIFY
2.4.5 ボディー、通知
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.
各NOTIFY MUSTはタイプ「メッセージ/sipfrag」[3]のボディーを含んでいます。 NOTIFY MUSTのボディーは[1]で定義されるようにSIP Response Status-線で始まります。 この状況表示行での応答のクラスは参照された動作の状態を示します。 ボディーは参照をつけられた動作の結果の情報を提供する他の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.
購読状態が未定であるときに、NOTIFYが発生するなら、ボディーは100の応答コードを含む状況表示行だけから成るはずです。
A minimal, but complete, implementation can respond with a single NOTIFY containing either the body:
独身のNOTIFYがボディーを含んでいて、最小量の、しかし、完全な実現は応じることができます:
SIP/2.0 100 Trying
一口/2.0 100トライ
if the subscription is pending, the body:
購読が未定であるならボディー:
SIP/2.0 200 OK
一口/2.0 200OK
if the reference was successful, the body:
参照がうまくいったならボディー:
SIP/2.0 503 Service Unavailable
入手できない一口/2.0 503サービス
if the reference failed, or the body:
参照は失敗したか、そして、ボディー:
SIP/2.0 603 Declined
一口/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を見てください)。 Implementersは、彼らが、何を含んでいるのを選ぶかを慎重に考えなければなりません。
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
非SIP URIに参照があったなら、リファラーへのどんなNOTIFYsの状態もSIP Response Status-線の形にまだあるに違いないことに注意してください。 上で議論した最小限の器具はそうです。
Sparks Standards Track [Page 8] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[8ページ]RFC3515をかきたてます。
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.
成否の基本的なしるしを供給するために、十分です。 例えば、クライアントがHTTP URLにREFERを受けて、リソースにアクセスするのに成功しているなら、リファラーへのNOTIFYは「一口/2.0 200OK」のメッセージ/sipfragボディーを含むことができます。 追加非SIPを返すというnotifier願望が要求の状態に関する特殊情報について議定書の中で述べるなら、それはsipfragメッセージのボディーにそれを置くかもしれません。
2.4.6 Multiple REFER Requests in a Dialog
2.4.6 倍数は対話における要求を参照します。
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の識別子が要求する対話を共有する暗黙の購読を作成します。 1REFERが同じ対話(例えば呼び出しを移すことへの2番目の試み)で発行されるなら、対話識別子は結果として起こるNOTIFYsを適切なREFERに関連づけることができるくらいの情報を提供しません。
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要求のために、それはこのNOTIFYが関連しているREFERの一連番号(CSeqヘッダーフィールド価値からの数)を含むそれぞれのNOTIFYのEventヘッダーフィールドにイドパラメタ[2]を含まなければなりません。 このイドパラメタはNOTIFYsでUAが与えられた対話で受ける最初のREFERに含められるかもしれません。 登録はこの購読をリフレッシュするか、または終えるために送られたこのイドパラメタを含まなければなりません。
2.4.7 Using the Subscription-State Header Field with Event Refer
2.4.7 出来事に伴う購読州のヘッダーフィールドを使用して、参照してください。
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]で定義されるようにSubscription-州のヘッダーフィールドを含まなければなりません。 REFER MUSTに対応して送られた最終的な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]によると、再申し込んだ状態でaを示す理由が適切であることを示すなら、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が再試みられることができるかどうかを示すのにSubscription-州のヘッダーフィールドの要素を使用されることができた後に202でREFERを受け入れましたが、次に参照に続くための許可を否定したケース、理由、および再試行、(説明される、登録[2])で。
2.5 Behavior of SIP Registrars/Redirect Servers
2.5 一口記録係/再直接のサーバの働き
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.
REFER方法の定義に気づかない記録係は[1]で定義されるように501応答を返すでしょう。 REFER SHOULDの定義を意識している記録係は405応答を返します。
Sparks Standards Track [Page 9] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[9ページ]RFC3515をかきたてます。
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]で指定されたものを超えて再直接のサーバの振舞いに要件を全く置きません。 したがって、向け直されるというREFER要求に、それは可能です。
2.6 Behavior of SIP Proxies
2.6 一口プロキシの振舞い
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]でOPTIONS要求を処理する同じようにREFER要求を処理するべきです。
3. Package Details: Event refer
3. 詳細をパッケージしてください: 出来事は参照されます。
This document defines an event package as defined in [2].
このドキュメントは[2]で定義されるイベントパッケージを定義します。
3.1 Event Package Name
3.1 イベントパッケージ名
The name of this event package is "refer".
このイベントパッケージの名前は「参照してください」です。
3.2 Event Package Parameters
3.2 イベントパッケージパラメタ
This package uses the "id" parameter defined in [2]. Its use in package is described in Section 2.4.6.
このパッケージは[2]で定義された「イド」パラメタを使用します。 パッケージにおける使用はセクション2.4.6で説明されます。
3.3 SUBSCRIBE Bodies
3.3はボディーを申し込みます。
SUBSCRIBE bodies have no special meaning for this event package.
登録、ボディーはそうしました。このイベントパッケージのための特別な意味がありません。
3.4 Subscription Duration
3.4 購読持続時間
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要求で作成された暗黙の購読の持続時間は、購読で送られた最初のNOTIFYのヘッダーフィールドのものが吐き出すSubscription-州のパラメタで初めは、REFERを受け入れるエージェントによって決定されて、申し込んでいるエージェントに伝えられます。 この初期の持続時間のための正当な選択を中に示された要求のタイプに頼っている、Refer、-、URI 持続時間SHOULDは選ばれています。完成するために時間が与えられるより参照箇所が、要求する長いです。 例えば、Refer、-、URI、中のExpireより長い値がINVITEであったなら、aはSIP INVITE URI、購読間隔ですか? 時間を説明するために含まれるかもしれない追加時は、購読を認可する必要がありました。 申し込んでいるエージェントは、それをリフレッシュすることによって購読を広げているか、または外すことによって、それを終えるかもしれません。 参照の最終的な結果を報告するとき、セクション2.4.7で説明されるように、REFERを受け入れるエージェントは購読を終えるでしょう、Subscription-州のヘッダーフィールドにおけるその終了を示して。
Sparks Standards Track [Page 10] RFC 3515 The SIP Refer Method April 2003
一口が方法2003年4月に参照する標準化過程[10ページ]RFC3515をかきたてます。
3.5 NOTIFY Bodies
3.5はボディーに通知します。
The bodies of NOTIFY requests for event refer are discussed in Section 2.4.5.
セクション2.4.5で出来事を求める要求が参照するNOTIFYのボディーについて議論します。
3.6 Notifier processing of SUBSCRIBE requests
3.6より多くのNotifierに処理する、登録、要求
Notifier processing of SUBSCRIBE requests is discussed in Section 2.4.4.
登録、要求はそうです。より多くのNotifierに処理する、セクション2.4.4では、議論します。
3.7 Notifier Generation of NOTIFY Requests
3.7Notifier世代、要求に通知してください。
Notifier generation of NOTIFY requests is discussed in Section 2.4.4.
セクション2.4.4でNOTIFY要求のNotifier世代について議論します。
3.8 Subscriber Processing of NOTIFY Requests
3.8加入者処理、要求に通知してください。
Subscriber processing of NOTIFY requests is discussed in Section 2.4.4.
セクション2.4.4でNOTIFY要求の加入者処理について議論します。
3.9 Handling of Forked Requests
3.9 股状の要求の取り扱い
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は分岐しないでしょう。 対話5月のフォークの文脈とそれが複数のエージェントによって受け入れられるかどうかなら送られたREFERは複数の購読を作成するかもしれません。 これらの購読は、[2]の「股状の要求の取り扱い」に従ってまるでREFERが登録かのように作成されて、管理されます。 REFERを送るエージェントは別々に各購読に関連している状態を経営します。 それは別々の購読から状態を合併しません。 状態は受け入れているエージェントの各人での参照をつけられた要求の状態です。
3.10 Rate of Notifications
3.10通知の速度
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による発生して、参照をつけられた要求の状態に関するそれぞれの時間新しい知識が利用可能になるということであるかもしれません。 例えば、SIP INVITEにREFERがあるなら、NOTIFYsはそれぞれの暫定的な応答とINVITEへの最終的な応答で発生するでしょうに。 あるいはまた、購読は参照の最終的な結果を運ぶ2つのNOTIFY要求、即座のNOTIFY、およびNOTIFYをもたらすだけであるかもしれません。 NOTIFYsは出来事をSHOULD NOTを参照します。1秒あたりの一度より頻繁に送ります。
3.11 State Agents
3.11 州のエージェント
Separate state agents are not defined for event refer.
出来事が参照されるので、別々の州のエージェントは定義されません。
Sparks Standards Track [Page 11] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[11ページ]RFC3515をかきたてます。
4. Examples
4. 例
4.1 Prototypical REFER callflow
4.1 Prototypical REFER callflow
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
| |
エージェントはエージェントBです。| | | F1は参照されます。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| F2 202は受け入れました。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F3は通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F4 200OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| |、-、-、-、-、-、--、>|、| (何でも) | | <、-、-、-、-、--、|、|、| F5は通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F6 200OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|
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要求にはToタグが全くありません)示します。 REFERがセッションのときに起こるなら、要求には非空のToタグがあるでしょう。
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
REFER一口: b@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agenta.atlanta.example.com; ブランチ=z9hG4bK2293940223To: <一口: b@atlanta.example.com 、gt;、From: <一口: a@atlanta.example.com 、gt;、; タグは193402342呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 93809823 前方へマックスを参照してください: 70、To:を参照します。 (いかなるURIも) 接触: 一口: a@atlanta.example.com のContent-長さ: 0
Sparks Standards Track [Page 12] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[12ページ]RFC3515をかきたてます。
Message Two (F2)
メッセージ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
一口/2.0 202は以下を通って受け入れました。 一口/2.0/UDP agenta.atlanta.example.com; ブランチ=z9hG4bK2293940223To: <一口: b@atlanta.example.com 、gt;、;=4992881234From:にタグ付けをしてください <一口: a@atlanta.example.com 、gt;、; タグは193402342呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 93809823 接触を参照してください: 一口: b@atlanta.example.com のContent-長さ: 0
Message Three (F3)
メッセージThree(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
NOTIFY一口: a@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9922ef992-25To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993402 前方へマックスに通知してください: 70イベント: Subscription-状態を参照してください: アクティブ;、=を吐き出す、(よる、Refer、-、URI) 接触: 一口: b@atlanta.example.com コンテントタイプ: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 20
SIP/2.0 100 Trying
一口/2.0 100トライ
Message Four (F4)
メッセージFour(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
以下を通って一口/2.0 200OK 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9922ef992-25To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993402 接触に通知してください: 一口: a@atlanta.example.com のContent-長さ: 0
Message Five (F5)
メッセージFive(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
NOTIFY一口: a@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9323394234To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993403 前方へマックスに通知してください: 70
Sparks Standards Track [Page 13] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[13ページ]RFC3515をかきたてます。
Event: refer Subscription-State: terminated;reason=noresource Contact: sip:b@atlanta.example.com Content-Type: message/sipfrag;version=2.0 Content-Length: 16
イベント: Subscription-状態を参照してください: 終わり、; 理由はnoresource Contactと等しいです: 一口: b@atlanta.example.com コンテントタイプ: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 16
SIP/2.0 200 OK
一口/2.0 200OK
Message Six (F6)
メッセージSix(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
以下を通って一口/2.0 200OK 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9323394234To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993403 接触に通知してください: 一口: a@atlanta.example.com のContent-長さ: 0
4.2 Multiple REFERs in a dialog
4.2 対話における複数のREFERs
Message One above brings an implicit subscription dialog into existence. Suppose Agent A issued a second REFER inside that dialog:
上のメッセージOneは暗黙の購読対話を生み出します。 第2のREFERがその対話で発行されたエージェントAを仮定してください:
Agent A Agent B
| |
| F7 REFER |
|----------------------->|
| F8 202 Accepted |
|<-----------------------|
| F9 NOTIFY |
|<-----------------------|
| F10 200 OK |
|----------------------->|
| |------->
| | (something different)
| |<------
| |
| F11 NOTIFY |
|<-----------------------|
| F12 200 OK |
|----------------------->|
| |
| |
エージェントはエージェントBです。| | | F7は参照します。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| F8 202は受け入れました。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F9は通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F10 200OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |、-、-、-、-、-、--、>|、| (何か異なったもの) | | <、-、-、-、-、--、|、|、| F11は通知します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F12 200OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|
Sparks Standards Track [Page 14] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[14ページ]RFC3515をかきたてます。
Message Seven (F7)
メッセージSeven(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
REFER一口: b@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agenta.atlanta.example.com; ブランチ=z9hG4bK9390399231To: <一口: b@atlanta.example.com 、gt;、;=4992881234From:にタグ付けをしてください <一口: a@atlanta.example.com 、gt;、; タグは193402342呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 93809824 前方へマックスを参照してください: 70、To:を参照します。 (何らかの異なったURI) 接触: 一口: a@atlanta.example.com のContent-長さ: 0
Message Eight (F8)
メッセージEight(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
一口/2.0 202は以下を通って受け入れました。 一口/2.0/UDP agenta.atlanta.example.com; ブランチ=z9hG4bK9390399231To: <一口: b@atlanta.example.com 、gt;、;=4992881234From:にタグ付けをしてください <一口: a@atlanta.example.com 、gt;、; タグは193402342呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 93809824 接触を参照してください: 一口: b@atlanta.example.com のContent-長さ: 0
Message Nine (F9)
メッセージNine(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
NOTIFY一口: a@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9320394238995To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993404 前方へマックスに通知してください: 70イベント: 参照してください; イドは93809824Subscription-状態と等しいです: アクティブ;、=を吐き出す、(よる、Refer、-、URI) 接触: 一口: b@atlanta.example.com コンテントタイプ: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 20
SIP/2.0 100 Trying
一口/2.0 100トライ
Message Ten (F10)
メッセージTen(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
以下を通って一口/2.0 200OK 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK9320394238995To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com
Sparks Standards Track [Page 15] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[15ページ]RFC3515をかきたてます。
CSeq: 1993404 NOTIFY Contact: sip:a@atlanta.example.com Content-Length: 0
CSeq: 1993404 接触に通知してください: 一口: a@atlanta.example.com のContent-長さ: 0
Message Eleven (F11)
メッセージEleven(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
NOTIFY一口: a@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK2994a93eb-fe To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993405 前方へマックスに通知してください: 70イベント: 参照してください; イドは93809824Subscription-状態と等しいです: 終わり、; 理由はnoresource Contactと等しいです: 一口: b@atlanta.example.com コンテントタイプ: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 16
SIP/2.0 200 OK
一口/2.0 200OK
Message Twelve (F12)
メッセージTwelve(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
以下を通って一口/2.0 200OK 一口/2.0/UDP agentb.atlanta.example.com; ブランチ=z9hG4bK2994a93eb-fe To: <一口: a@atlanta.example.com 、gt;、;=193402342From:にタグ付けをしてください <一口: b@atlanta.example.com 、gt;、; タグは4992881234呼び出しIDと等しいです: 898234234@agenta.atlanta.example.com CSeq: 1993405 接触に通知してください: 一口: a@atlanta.example.com のContent-長さ: 0
5. Security Considerations
5. セキュリティ問題
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で説明されたセキュリティ問題はREFERトランザクションに適用されます。 特に、セクション26.3の実装要件と問題は、機密保護するのがジェネリックSIPトランザクションであると扱います。 特別の配慮は承認のために保証されます。要求と参照をつけられた要求の結果を伝えるメッセージ/sipfragの使用のためにREFERに適用されて、取り締まります。
5.1 Constructing a Refer-To URI
aを組み立てる5.1がURIについて言及します。
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が言及しているリソースであるなら保護されるべきであるということであるべきです。
Sparks Standards Track [Page 16] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[16ページ]RFC3515をかきたてます。
5.2 Authorization Considerations for REFER
5.2の承認問題、参照
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で説明されるようにaとのa REFER要求を受け取ることができる、Refer、-、任意の体系を含むURI。 例えば、ユーザは、telnet URIを使用することでMUDなどのオンラインサービスを示すことができるでしょう。 顧客サービスは、HTTP URIを使用することでオーダー追跡ウェブページに顧客を差し向けるかもしれません。 セクション2.4 .2 参照をつけられた体系を処理できないとき、ユーザエージェントがREFER要求を拒絶するのを許容します。 また、URIを使用するのを試みる前にユーザから承認を得るのがユーザエージェントを必要とします。 一般に、「あなたはこのリソース(Y/N)にアクセスなどたがっていることなど」の完全なURIと問題でユーザをうながすことによって、これを達成できるでしょう。 もちろん、URIが任意に長い場合があり、時折悪意で構成されるので、URI(部分的なディスプレイかダウンすることなどの)自体のディスプレイさえにおける驚きを避けるために注意するべきです。 さらに、参照のできるだけ緩和するユーザにとって多くの情報が危険な決定にミスリードされるリスクであると暴露するために注意するべきです。 例えば、Refer、-、ヘッダーはURIに伴うディスプレイ名を含むかもしれません。 何も、そのディスプレイ名によって含意されたどんな特性もURIによって共有されるのを確実にしません。 いつがちびちび飲まれるかURIが、示す: 例えば、ディスプレイ名は「安全である」か「社長」を含むかもしれません、そして、 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.
いくつかの場合、ユーザは、早めに、ユーザエージェントに方針を提供することによって、いくつかのREFER要求に承認を提供できます。 例えば、呼び出し転送に、これは[4]で議論するように適切です。 : ここで、適切に認証されたREFERは一口との既存のSIP対話の中で以下を要求して、一口はtel:です。 インタラクティブにユーザの承認を得ないで、方針でURIを受け入れるかもしれません。 同様に、referrorが承認されたreferrorsの明白なリストにあるなら、適切に認証されたREFERを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
例えば、盲目的にHTTP URIを受け入れて、影響する方針という危険を見るには、ウェブサーバーが単に小さい組織のファイアウォールの後ろのクライアントから要求を受け入れるのを構成されたと考えてください。 小さい組織がすべてのメンバーを信じて、ほとんど国内保安を持っていないこの柔らかいクリーム状の中央環境で座るとき、ウェブサーバーはメインテナンスのときに頻繁に遅れています、陰湿に組み立てられたURIを通して攻撃するのを被害を受け易く残して(恐らく実行している勝手な規準をもたらすのはURIに提供されました)。 このファイアウォールの中のSIP UAが盲目的に任意のHTTP URIの参照を受け入れるなら、ファイアウォールの外の攻撃者はウェブサーバーに感染することができるでしょうに。他方では、UAのユーザがそうしなければならないなら、正数を取ってください。
Sparks Standards Track [Page 17] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[17ページ]RFC3515をかきたてます。
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.
このURIに影響する前の動作(プロンプトに応じなどなどの)、危険はウェブブラウザかメールメッセージの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を手渡すとき、ユーザエージェントは注意するべきです、特にユーザエージェントが体系と可能な分岐がそれが示すプロトコルを使用するのを意識していないなら。 少しの驚きの主体に違反する機会は非常に高いです。
5.3 Considerations for the use of message/sipfrag
5.3 メッセージ/sipfragの使用のための問題
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ボディーをREFERの進歩と結果が要求する使用するのは非常に強力です。 その能力の不注意な使用は秘密性とプライバシーに感染することができます。 ここに、害の可能性を示す2、3の簡単で、いくらか人為的な例があります。
5.3.1 Circumventing Privacy
5.3.1 プライバシーを回避すること。
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.
アリスに受け入れるユーザエージェントがいるなら、REFERは、INVITEへの各応答をNOTIFYのボディーにコピーすることによって、SIP INVITE URI、およびNOTIFYsにINVITEの進歩に関するリファラーを要求します。
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を避ける理由を持って、受け入れるだけである彼女のプロキシの彼女のシステムが彼女が信じるあるセットの人々(アリスを含んでいます)から呼ぶのを構成したとさらに仮定してください、Malloryが、いつ、周囲にいるか、そして、または彼女が実際にどんなユーザエージェントを使用しているかを学ばないように。
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.
マロリー・ワイス症候群がaと共にREFERをアリスに送ることができる、Refer、-、キャロルを示すURI。 アリスがキャロルに連絡できるなら、しかし、その上彼にキャロルが周囲にいるのを知らせることができるNOTIFY、彼女が使用しているエージェントのIPアドレスでもOKキャロルが送る200をMalloryに返します。
Sparks Standards Track [Page 18] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[18ページ]RFC3515をかきたてます。
5.3.2 Circumventing Confidentiality
5.3.2 秘密性を回避すること。
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をもっているアリーチェにREFERを送ります、そして、アリスがFOOに接続するとき、ボディーが含んでいて、MalloryはNOTIFYsを届けます。
Server: FOO/v0.9.7
サーバ: FOO/v0.9.7
5.3.3 Limiting the Breach
5.3.3 不履行を制限すること。
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.
それぞれ、これらがケースに入れて、一般に、NOTIFYsを通した参照の進歩に関して利用可能な情報の慎重に選択された部分集合を返すのが緩和する、リスク。 最小限の器具は、REFER要求のエージェント操作がしたことに関して最少の情報を暴露して、セクション2.4.5で説明される中で悪意あるユーザーのための有益な手段である最も傾向がありません。
5.3.4 Cut, Paste and Replay Considerations
5.3.4 問題を切って、貼って、再演してください。
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.
この仕様に基づき定義されたメカニズムはNOTIFY要求からメッセージ/sipfragボディーをコピーして、それらを挿入するか、全体または一部乱用するのにおいて直接影響されやすくはありません、同じくらいに関連している今後のNOTIFY要求か異なったREFERで。 この仕様では、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
今後の拡大は「私があなたが私を差し向けたパーティーに連絡しました、そして、ここに、暗号の証拠があります」のような声明を出すのにNOTIFYでメッセージ/sipfrag身体の部分を使用するのを許容するためにREFERに応じているエージェントに追加規制を置くかもしれません。 これらの声明は使用されるかもしれません。
Sparks Standards Track [Page 19] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[19ページ]RFC3515をかきたてます。
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.
受信UAの動きに影響するように。 この種類の拡張子は、コピーのベースの攻撃から我が身をかばうために追加メカニズムを定義する必要があるでしょう。
6. Historic Material
6. 歴史的な材料
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.
このメソッドは初めは、呼び出し転送アプリケーションで動機づけられました。 REFER、BYE/で改良されたこのメソッドにも総合しながらTRANSFER以降を始めて、分離するのによる満期の草稿ietf一口cc01の概念は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.
この仕事の早めのバージョンは、REFERに応じているエージェントが最終的な応答をREFERに送る前に完了した参照された操作まで待つのを必要としました。 その最終的な応答は参照された動作の成否を反映しました。 これは[1]での非INVITE要求のために定義されたトランザクションタイムアウト規則のために実行不可能でした。 REFERはいつも即座(非INVITEトランザクションの生涯中の)の最終的な応答を受けなければなりません。
7. IANA Considerations
7. IANA問題
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)を定義します、コンパクト形がある新しいSIPヘッダーフィールド名、(言及、r、それぞれ)、そして、イベントパッケージ(参照します)。
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
参照: RFC3515
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.
パッケージかパッケージテンプレート: これはパッケージです。
Sparks Standards Track [Page 20] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[20ページ]RFC3515をかきたてます。
Published Specification: RFC 3515
広められた仕様: RFC3515
Person to Contact: Robert Sparks, rsparks@dynamicsoft.com
連絡する人: ロバート・スパークス、 rsparks@dynamicsoft.com
8. Acknowledgments
8. 承認
This document is a collaborative product of the SIP working group.
このドキュメントはSIPワーキンググループの協力的な製品です。
9. References
9. 参照
9.1 Normative References
9.1 標準の参照
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
R.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 2002年11月の[3]スパーク。
9.2 Informative References
9.2 有益な参照
[4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", Work in Progress.
[4] 「セッション開始プロトコル呼び出しコントロール--移す」というスパークス、R.、およびA.ジョンストンは進行中で働いています。
10. Intellectual Property Statement
10. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Sparks Standards Track [Page 21] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[21ページ]RFC3515をかきたてます。
11. Author's Address
11. 作者のアドレス
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
プラノ、ロバートJ.スパークスdynamicsoft5100テニソンパークウェイSuite1200テキサス 75024
EMail: rsparks@dynamicsoft.com
メール: rsparks@dynamicsoft.com
Sparks Standards Track [Page 22] RFC 3515 The SIP Refer Method April 2003
一口がメソッド2003年4月に参照する標準化過程[22ページ]RFC3515をかきたてます。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Sparks Standards Track [Page 23]
標準化過程をかきたてます。[23ページ]
一覧
スポンサーリンク
