[要約] RFC 3891は、SIPの"Replaces"ヘッダーに関する仕様を定めており、セッションの置き換えを可能にするための機能を提供します。このRFCの目的は、SIPセッションの置き換えを効率的かつ信頼性の高い方法で実現することです。
Network Working Group R. Mahy
Request for Comments: 3891 Cisco Systems, Inc.
Category: Standards Track B. Biggs
R. Dean
September 2004
The Session Initiation Protocol (SIP) "Replaces" Header
セッション開始プロトコル（SIP）はヘッダーを「交換」します
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative.
このドキュメントでは、セッション開始プロトコル（SIP）マルチパーティアプリケーションとコールコントロールで使用する新しいヘッダーを定義します。交換ヘッダーは、既存のSIPダイアログを新しいSIPダイアログに論理的に置き換えるために使用されます。このプリミティブを使用して、たとえば「参加」や「コールピックアップ」など、さまざまな機能を有効にすることができます。これらの例の特徴の定義は非規範的であることに注意してください。
Table of Contents
目次
1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. User Agent Server Behavior: Receiving a Replaces Header . . . 4
4. User Agent Client Behavior: Sending a Replaces Header . . . . 6
5. Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . . 7
6. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. The Replaces Header . . . . . . . . . . . . . . . . . . 7
6.2. New Option Tag for Require and Supported Headers. . . . 8
7. Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Replacing an Early Dialog at the Originator . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Registration of "Replaces" SIP Header . . . . . . . . . 13
9.2. Registration of "replaces" SIP Option-tag . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References. . . . . . . . . . . . . . . . . . 13
11.2. Informative References. . . . . . . . . . . . . . . . . 14
12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16
This document describes a SIP [1] extension header field as part of the SIP multiparty applications architecture framework [10]. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This is especially useful in peer-to-peer call control environments.
このドキュメントでは、SIP [1]拡張ヘッダーフィールドについて、SIPマルチパルティアプリケーションアーキテクチャフレームワークの一部として説明しています[10]。交換ヘッダーは、既存のSIPダイアログを新しいSIPダイアログに論理的に置き換えるために使用されます。これは、ピアツーピアコールコントロール環境で特に役立ちます。
One use of the "Replaces" header is to replace one participant with another in a multimedia conversation. While this functionality is already available using 3rd party call control [11] style call control, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method of performing these same call control primitives in a distributed, peer-to-peer fashion is very desirable.
「交換」ヘッダーの1つの使用は、マルチメディアの会話で1人の参加者を別の参加者に置き換えることです。この機能は、サードパーティコールコントロール[11]スタイルコールコントロールを使用してすでに利用可能ですが、3PCCモデルには、多くの環境で望ましくない中心的な制御ポイントが必要です。そのため、分散したピアツーピアのファッションでこれらの同じコールコントロールプリミティブを実行する方法は非常に望ましいです。
Use of a new INVITE with a new header for dialog matching was chosen over making implicit associations in an incoming INVITE based on call-id or other fields for the following reasons:
ダイアログマッチングの新しいヘッダーを備えた新しい招待状の使用は、次の理由で、Call-IDまたは他のフィールドに基づいて、着信招待状で暗黙の関連性を作成することに選ばれました。
o An INVITE already has the correct semantics for a new call
o 招待状にはすでに新しい呼び出しのための正しいセマンティクスがあります
o Using an explicit Replaces header in a new request makes the intent of the request obvious.
o 新しいリクエストで明示的な交換ヘッダーを使用すると、リクエストの意図が明らかになります。
o A unique call-id may be given to the replacement call. This avoids dialog matching problems in any of the related User Agents.
o 交換コールに一意のCall-IDが与えられる場合があります。これにより、関連するユーザーエージェントのいずれにおいてもダイアログに一致するダイアログが回避されます。
o There are no adverse effects if the header is unsupported.
o ヘッダーがサポートされていない場合、悪影響はありません。
The Replaces header enables services such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a distributed peer-to-peer way. This list of services is not exhaustive. Although the Replaces header is frequently used in combination with the REFER [8] method as used in a Transfer [12], they may be used independently.
交換ヘッダーは、参加したコール転送、公園からの取得、地元の混合会議から2つのパーティーコールへの移行などのサービスを、分配されたピアツーピアの方法で可能にします。このサービスリストは網羅的ではありません。交換ヘッダーは、転送[12]で使用される参照[8]メソッドと組み合わせて頻繁に使用されますが、個別に使用できます。
For example, Alice is talking to Bob from phone1. She transfers Bob to a Parking Place while she goes to the lab. When she gets there she retrieves the "parked" call from phone2 by sending an INVITE with a Replaces header field to Bob with the dialog information Bob shared with the Parking Place. Alice got this information using some out of band mechanism. Perhaps she subscribed to this information from the Parking Place (using the session dialog package [13]), or went to a website and clicked on a URI. A short call flow for this example follows. (Via and Max-Forwards headers are omitted for clarity.)
たとえば、アリスはPhone1からBobと話しています。彼女はラボに行く間、ボブを駐車場に移動します。彼女がそこに着くと、彼女はBobが駐車場と共有されたダイアログ情報でBOBに交換されたヘッダーフィールドを招待した招待状を送信することにより、Phone2からの「駐車」コールを取得します。アリスは、バンド外のメカニズムを使用してこの情報を入手しました。おそらく、彼女は駐車場からこの情報をサブスクライブし（セッションダイアログパッケージ[13]）、ウェブサイトに行ってURIをクリックしました。この例の短いコールフローが続きます。（viaおよびmax-forwardsヘッダーは明確に省略されています。）
Alice Alice Parking
phone1 phone2 Bob Place
| | | |
|<===============================>| |
| | | |
| Alice transfers Bob to Parking Place |
| | | |
|------------REFER/200----------->| *1 *2 |
|<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->|
|<--NOTIFY/200 (success)----------|<=================>|
|------------BYE/200------------->| |
| | | |
| | | |
| Alice later retrieves call from another phone |
| | | |
| *3 |-INV w/Replaces->| |
| |<--200-----------| |
| |---ACK---------->|----BYE/200------->|
| |<===============>| |
| | | |
Message *1: Bob-> Parking Place
INVITE sip:parkingplace@example.org SIP/2.0
To: <sip:parkingplace@example.org>
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
Referred-By: <sip:alice@phone1.example.org>
Message *2: Parking Place -> Bob
SIP/2.0 200 OK
To: <sip:parkingplace@example.org>;tag=6472
From: <sip:bob@example.org>;tag=7743
Call-ID: 425928@bobster.example.org
CSeq: 1 INVITE
Contact: <sip:parkplace@monopoly.example.org>
Message *3: Alice@phone2 -> Bob
INVITE sip:bob@bobster.example.org
To: <sip:bob@example.org>
From: <sip:alice@phone2.example.org>;tag=8983
Call-ID: 09870@phone2.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone2.example.org>
Require: replaces
Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
This document refers frequently to the terms "confirmed dialog" and "early dialog". These are defined in Section 12 of SIP [1].
このドキュメントは、「確認されたダイアログ」と「初期ダイアログ」という用語を頻繁に参照しています。これらは、SIP [1]のセクション12で定義されています。
The Replaces header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the User Agent (UA) attempts to match this information with a confirmed or early dialog. The User Agent Server (UAS) matches the to-tag and from-tag parameters as if they were tags present in an incoming request. In other words, the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.
交換ヘッダーには、既存のSIPダイアログ（call-id、to-tag、およびfrom-tag）に一致するために使用される情報が含まれています。交換ヘッダーで招待状を受け取ると、ユーザーエージェント（UA）は、この情報を確認されたダイアログまたは初期のダイアログと一致させようとします。ユーザーエージェントサーバー（UAS）は、To-TagおよびTagからのパラメーターと一致しています。言い換えれば、to-tagパラメーターはローカルタグと比較され、From-TAGパラメーターはリモートタグと比較されます。
If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response.
招待状に複数の交換ヘッダーフィールドが存在する場合、または招待以外のリクエストに交換ヘッダーフィールドが存在する場合、UASは400の悪いリクエスト応答でリクエストを拒否する必要があります。
The Replaces header has specific call control semantics. If both a Replaces header field and another header field with contradictory semantics are present in a request, the request MUST be rejected with a 400 "Bad Request" response.
交換ヘッダーには、特定のコールコントロールセマンティクスがあります。矛盾したセマンティクスを持つヘッダーフィールドと別のヘッダーフィールドの両方がリクエストに存在する場合、リクエストは400の「悪い要求」応答で拒否する必要があります。
If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found.
交換ヘッダーフィールドが複数のダイアログと一致する場合、UAは一致しないかのように動作する必要があります。
If no match is found, the UAS rejects the INVITE and returns a 481 Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog which was not created with an INVITE, the UAS MUST reject the request with a 481 response.
一致が見つからない場合、UASは招待を拒否し、481のコール/トランザクションを返しても応答が存在しません。同様に、交換ヘッダーフィールドが招待状で作成されなかったダイアログと一致する場合、UASは481応答でリクエストを拒否する必要があります。
If the Replaces header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response. (If the matched invitation was just terminated, the replacement request should fail as well. Declining the request with a 600-class response prevents an irritating race-condition where the UA rings or alerts for a replacement call which is not wanted.)
交換ヘッダーフィールドがすでに終了しているダイアログと一致する場合、UAは603の低下した応答で要求を拒否するはずです。（一致した招待状が終了した場合、交換要求も同様に失敗するはずです。600クラスの応答でリクエストを拒否すると、UAが必要でない交換コールのアラートが鳴ったり、アラートをしたりすることを防ぎます。）
If the Replaces header field matches an active dialog, the UA MUST verify that the initiator of the new INVITE is authorized to replace the matched dialog. If the initiator of the new INVITE has been successfully authenticated as equivalent to the user who is being replaced, then the replacement is authorized. For example, if the user being replaced and the initiator of the replacement dialog share the same credentials for Digest authentication [6], or they sign the replacement request with S/MIME [7] with the same private key and present the (same) corresponding certificate used in the original dialog, then the replacement is authorized.
ヘッダーの交換フィールドがアクティブなダイアログと一致する場合、UAは、新しい招待のイニシエーターが一致したダイアログを置き換えることを許可されていることを確認する必要があります。新しい招待のイニシエーターが、交換されているユーザーに相当するものとして正常に認証されている場合、交換は許可されます。たとえば、交換されているユーザーと交換ダイアログのイニシエーターがダイジェスト認証のために同じ資格情報を共有している場合、またはそれらが同じ秘密鍵でs/mime [7]で交換要求に署名し、（同じ）を提示する場合元のダイアログで使用される対応する証明書、その後、交換が承認されます。
Alternatively, the Referred-By mechanism [4] defines a mechanism that the UAS can use to verify that a replacement request was sent on behalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the replacement request contains a Referred-By header that corresponds to the user being replaced, the UA SHOULD treat the replacement as if the replacement was authorized by the replaced party. The Referred-By header SHOULD reference a corresponding, valid Refererred-By Authenticated Identity Body [5].
あるいは、紹介されたメカニズム[4]は、UASが一致したダイアログの他の参加者に代わって交換要求が送信されたことを確認するために使用できるメカニズムを定義します（この場合、紹介要求によってトリガーされます）。交換リクエストに、交換されるユーザーに対応する紹介されたヘッダーが含まれている場合、UAは交換が交換された当事者によって許可されているかのように交換を扱う必要があります。紹介されたヘッダーは、対応する、有効な紹介された認証されたアイデンティティ本体を参照する必要があります[5]。
The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply a different policy to the replacement dialog than was applied to the replaced dialog.
UAは、他のローカルポリシーを適用して、リクエストの残りを承認する場合があります。言い換えれば、UASは、交換ダイアログに適用されたダイアログとは異なるポリシーを交換ダイアログに適用する場合があります。
In addition, the UA MAY use other authorization mechanisms defined for this purpose in standards track extensions. Extensions could define other mechanisms for transitively asserting authorization of a replacement.
さらに、UAは、標準のこの目的のために定義された他の認証メカニズムを標準追跡拡張機能を使用する場合があります。拡張は、代替品の許可をトランザティブに主張するための他のメカニズムを定義できます。
If authorization is successful, the UA attempts to accept the new INVITE, reassign the user interface and other resources of the matched dialog to the new INVITE, and shut down the replaced dialog. If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged.
認可が成功した場合、UAは新しい招待状を受け入れ、ユーザーインターフェイスと一致したダイアログのその他のリソースを新しい招待に再割り当てし、交換したダイアログをシャットダウンしようとします。UAが新しい招待状を受け入れられない場合（たとえば、必要なQosまたはキーイングを確立できない、または互換性のないメディアを持っている場合）、UAは適切なエラー応答を返す必要があり、一致したダイアログを変更せずに放置する必要があります。
If the Replaces header field matches a confirmed dialog, it checks for the presence of the "early-only" flag in the Replaces header field. (This flag allows the UAC to prevent a potentially undesirable race condition described in Section 7.1.) If the flag is present, the UA rejects the request with a 486 Busy response. Otherwise, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a BYE. If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a CANCEL.
交換ヘッダーフィールドが確認されたダイアログと一致する場合、交換ヘッダーフィールドに「初期のみの」フラグが存在することをチェックします。（このフラグにより、UACはセクション7.1で説明されている潜在的に望ましくない人種状態を防ぐことができます。）フラグが存在する場合、UAは486のビジー対応で要求を拒否します。それ以外の場合は、200クラスの応答を送信することで新しい招待状を受け入れ、Byeを送信して交換されたダイアログをシャットダウンします。交換ヘッダーフィールドがUAによって開始された初期のダイアログと一致する場合、200クラスの応答を送信することで新しい招待状を受け入れ、キャンセルを送信することで交換されたダイアログをシャットダウンします。
If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 (Call/Transaction Does Not Exist) response to the new INVITE, and leaves the matched dialog unchanged. Note that since Replaces matches only a single dialog, the replacement dialog will not be retargeted according to the same forking logic as the original request which created the early dialog.
交換ヘッダーフィールドがこのUAによって開始されなかった初期のダイアログと一致する場合、新しい招待に対する481（コール/トランザクションは存在しません）応答を返し、一致したダイアログを変更しません。交換は単一のダイアログのみと一致するため、交換ダイアログは、初期ダイアログを作成した元のリクエストと同じフォーキングロジックに従ってリターゲットされないことに注意してください。
(Currently, no use cases have been identified for replacing just a single dialog in this circumstance.)
（現在、この状況で1つのダイアログを置き換えるためのユースケースは特定されていません。）
A User Agent that wishes to replace a single existing early or confirmed dialog with a new dialog of its own, MAY send the target User Agent an INVITE request containing a Replaces header field. The User Agent Client (UAC) places the Call-ID, to-tag, and from-tag information for the target dialog in a single Replaces header field and sends the new INVITE to the target. If the user agent only wishes to replace an early dialog (as in the Call Pickup example in Section 7.1), the UAC MAY also include the "early-only" parameter in the Replaces header field. A UAC MUST NOT send an INVITE with a Replaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field.
単一の既存の早期または確認されたダイアログを独自の新しいダイアログに置き換えたいユーザーエージェントは、ターゲットユーザーエージェントに交換ヘッダーフィールドを含む招待リクエストを送信する場合があります。ユーザーエージェントクライアント（UAC）は、Call-ID、To-Tag、およびTarging From Tag情報をシングルに置き、ヘッダーフィールドを置き換え、新しい招待状をターゲットに送信します。ユーザーエージェントが初期のダイアログのみを置き換えることを希望する場合（セクション7.1のコールピックアップの例のように）、UACには、交換ヘッダーフィールドに「初期のみの」パラメーターも含まれる場合があります。UACは、招待状のターゲットが交換ヘッダーフィールドに由来していない初期のダイアログを交換しようとする交換ヘッダーフィールドの招待状を送信してはなりません。
Note that use of this mechanism does not provide a way to match multiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic. For example, if Alice replaces Cathy in an early dialog with Bob, but Bob does not answer, Alice's replacement request will not match other dialogs to which Bob's UA redirects, nor other branches to which his proxy forwards. Although this specification takes reasonable precautions to prevent unexpected behavior in the face of forking, implementations SHOULD only address replacement requests (i.e., set the Request-URI of the replacement request) to the SIP Contact URI of the target.
このメカニズムの使用は、複数のダイアログを一致させる方法を提供しないことも、コール全体、トランザクション全体に一致させたり、プロキシフォーキングロジックのチェーンに従ったりする方法を提供しないことに注意してください。たとえば、アリスが初期のダイアログでボブとキャシーを置き換えたが、ボブが答えない場合、アリスの代替リクエストは、ボブのUAがリダイレクトする他のダイアログ、または彼の代理が前進する他のブランチと一致しません。この仕様には、フォーキングに直面して予期しない動作を防ぐための合理的な予防措置が必要ですが、実装は、ターゲットのSIP連絡先URIに交換要求のみに対処する（つまり、交換要求のリクエスト-URIを設定）にのみ対処する必要があります。
Proxy Servers do not require any new behavior to support this extension. They simply pass the Replaces header field transparently as described in the SIP specification.
プロキシサーバーでは、この拡張機能をサポートするために新しい動作を必要としません。SIP仕様に記載されているように、交換ヘッダーフィールドを透過的に渡すだけです。
Note that it is possible for a proxy (especially when forking based on some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Replaces header field to a completely orthogonal set of Contacts other than the original request it was intended to replace. In this case, the INVITE request with the Replaces header field will fail.
プロキシが可能であることに注意してください（特に、発信者のスクリーニングや時刻ルーティングなどのアプリケーションレイヤーロジックに基づいてフォークする場合）は、交換ヘッダーフィールドを含む完全な直交の連絡先に招待リクエストを転送することができます。交換することを目的とした元のリクエスト。この場合、交換ヘッダーフィールドの招待リクエストは失敗します。
The Replaces header field indicates that a single dialog identified by the header field is to be shut down and logically replaced by the incoming INVITE in which it is contained. It is a request header only, and defined only for INVITE requests. The Replaces header field MAY be encrypted as part of end-to-end encryption. Only a single Replaces header field value may be present in a SIP request.
交換ヘッダーフィールドは、ヘッダーフィールドによって識別された単一のダイアログがシャットダウンされ、それが含まれている着信招待に論理的に置き換えることを示します。これはリクエストヘッダーのみであり、招待リクエストのみで定義されています。交換ヘッダーフィールドは、エンドツーエンド暗号化の一部として暗号化される場合があります。SIPリクエストには、ヘッダーフィールド値を置き換えるシングルのみが存在する可能性があります。
This document adds the following entry to Table 2 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined respectively in [15], [16], [8], [17], [18], [19], and [20].
このドキュメントは、次のエントリを[1]の表2に追加します。このテーブルへの追加は、このドキュメントの公開時に定義された拡張方法についても提供されます。これは読者への礼儀として提供され、いかなる方法でも規範的ではありません。メッセージ、購読、通知、紹介、情報、更新、プラック、およびパブリッシュは、それぞれ[15]、[16]、[8]、[17]、[18]、[19]、および[20]で定義されています。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Replaces R - - - o - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Replaces R - - - - - - -
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [3]. The syntax below relies on a number of productions from SIP [1].
次の構文仕様では、RFC 2234 [3]に記載されているように、拡張されたバックスノール形式（BNF）を使用しています。以下の構文は、SIP [1]の多くのプロダクションに依存しています。
Replaces = "Replaces" HCOLON callid *(SEMI replaces-param)
replaces-param = to-tag / from-tag / early-flag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
early-flag = "early-only"
A Replaces header field MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching. For compatibility with dialogs initiated by RFC 2543 [9] compliant UAs, a tag of zero matches both tags of zero and null. A Replaces header field MAY contain the early-flag.
ヘッダーの交換フィールドには、一意のダイアログマッチングに必要なため、1つのTOタグとタグから正確に1つを含める必要があります。RFC 2543 [9] Compliant UASによって開始されたダイアログとの互換性については、ゼロのタグはゼロとnullの両方のタグと一致します。ヘッダーの交換フィールドには、早期フラグが含まれている場合があります。
Examples:
例：
Replaces: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only
Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0
This specification defines a new Require/Supported header option tag "replaces". UAs which support the Replaces header MUST include the "replaces" option tag in a Supported header field. UAs that want explicit failure notification if Replaces is not supported MAY include the "replaces" option in a Require header field.
この仕様では、新しい要求/サポートヘッダーオプションタグ「交換」を定義します。ヘッダーの交換をサポートするUASには、サポートされているヘッダーフィールドに「交換」オプションタグを含める必要があります。交換がサポートされていない場合に明示的な障害通知を必要とするUASには、要求ヘッダーフィールドに「交換」オプションが含まれる場合があります。
Example:
例：
Require: replaces, 100rel
要求：交換、100rel
The following non-normative examples are not intended to enumerate all the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see SIP Service Examples [14]. Via and Max-Forwards headers are omitted for clarity and brevity.
次の非規範的な例は、この拡張機能の使用の可能性をすべて列挙することではなく、例やアイデアのみを提供することを目的としています。その他の例については、SIPサービスの例[14]を参照してください。viaおよびmax-forwardsヘッダーは、明確で簡潔にするために省略されています。
In this example, Bob just arrived in the lab and hasn't registered there yet. He hears his desk phone ring. He quickly logs into a software UA on a nearby computer. Among other things, the software UA has access to the dialog state of his desk phone. When it notices that his phone is ringing, it offers him the choice of taking the call there. The software UA sends an INVITE with Replaces to Alice. When Alice's UA receives this new INVITE, it CANCELs her original INVITE and connects Alice to Bob.
この例では、ボブは研究室に到着したばかりで、まだ登録していません。彼は机の電話の指輪を聞きます。彼はすぐに近くのコンピューターでソフトウェアUAにすぐにログインします。とりわけ、ソフトウェアUAは彼のデスク電話のダイアログ状態にアクセスできます。彼の電話が鳴っていることに気づいたとき、それは彼にそこに電話をかけるという選択を提供します。ソフトウェアUAは、Aliceに交代する招待状を送信します。アリスのUAがこの新しい招待状を受け取ると、それは彼女のオリジナルの招待をキャンセルし、アリスをボブに結び付けます。
Bob Bob
Alice desk lab
| | |
*1 |-----INVITE----------->| |
*2 |<----180---------------| Bob hears desk phone |
| | ringing from lab but |
| | isn't REGISTERed yet |
| | |
| |<--fetch dialog state --|
| |---response ----------->|
*3/4 |<-----INVITE with Replaces/200/ACK--------------|
*5/6 |------CANCEL/200------>| |
*7 |<-----487--------------| |
|------ACK------------->| |
| | |
| | |
Message *1: Alice -> Bob's desk phone
INVITE sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
Message *2: Bob's desk phone -> Alice
SIP/2.0 180 Ringing
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
Contact: <sip:bob@bobster.example.org>
Message *3: Bob in lab -> Alice
INVITE sip:alice@phone.example.org
To: <sip:alice@example.org>
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:bob@labpc.example.org>
Replaces: 425928@phone.example.org
;to-tag=7743;from-tag=6472;early-only
Message *4: Alice -> Bob in lab
SIP/2.0 200 OK
To: <sip:alice@example.org>;tag=9232
From: <sip:bob@example.org>;tag=8983
Call-ID: 09870@labpc.example.org
CSeq: 1 INVITE
Contact: <sip:alice@phone.example.org>
Message *5: Alice -> Bob's desk
CANCEL sip:bob@example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:alice@phone.example.org>
Message *6: Bob's desk -> Alice
SIP/2.0 200 OK
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 CANCEL
Contact: <sip:bob@bobster.example.org>
Message *7: Bob's desk -> Alice
SIP/2.0 487 Request Terminated
To: <sip:bob@example.org>;tag=6472
From: <sip:alice@example.org>;tag=7743
Call-ID: 425928@phone.example.org
CSeq: 1 INVITE
The extension specified in this document significantly changes the relative security of SIP devices. Currently in SIP, even if an eavesdropper learns the Call-ID, To, and From headers of a dialog, they cannot easily modify or destroy that dialog if Digest authentication or end-to-end message integrity are used.
このドキュメントで指定された拡張機能は、SIPデバイスの相対的なセキュリティを大幅に変更します。現在SIPでは、盗聴者がダイアログのヘッダーを、およびヘッダーから、コールアイドを学習したとしても、認証またはエンドツーエンドのメッセージの整合性が使用されている場合、そのダイアログを簡単に変更または破壊することはできません。
This extension can be used to disconnect participants or replace participants in a multimedia conversation. As such, invitations with the Replaces header MUST only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism (Digest or S/MIME), and authorized to request a replacement of the target dialog. All SIP implementations are already required to support Digest Authentication. In addition, implementations which support the Replaces header SHOULD also implement the Referred-By mechanism.
この拡張機能を使用して、参加者を切断したり、マルチメディアの会話に参加者を置き換えたりできます。そのため、交換ヘッダーの招待状は、ピア要求の交換品が標準のSIPメカニズム（DigestまたはS/Mime）を使用して適切に認証され、ターゲットダイアログの交換を要求することを許可されている場合にのみ受け入れなければなりません。すべてのSIP実装は、消化認証をサポートするためにすでに必要です。さらに、交換ヘッダーをサポートする実装は、紹介されたメカニズムも実装する必要があります。
How a User Agent determines which requests are legitimately authorized to make dialog replacements is non-trivial and depends on a considerable amount of local policy configuration. In general, there are four cases when an authorization for a replacement is reasonable or warranted.
ユーザーエージェントが、ダイアログの置換を行うことを合法的に許可されている要求を決定する方法は、自明ではなく、かなりの量のローカルポリシー構成に依存します。一般に、交換の許可が合理的または保証される場合、4つのケースがあります。
1. Replacement made by a party considered equivalent to the replaced party
1. 交換されたパーティーに相当すると見なされる当事者によって行われた交代
2. Replacement made on behalf of the replaced party (perhaps transitively)
2. 交換された当事者に代わって行われた交換（おそらく一時的に）
3. Replacement made by a former participant
3. 元参加者による交換
4. Replacement made by a specifically authorized party
4. 具体的に認可された当事者による交換
Starting with #1 for example, if an executive and an assistant both receive requests for a shared address-of-record, if so configured, either should be able to replace dialogs of the other for the shared identity. Both could even share the same keying material (Digest or S/MIME), or one could hold an authorization document signed by the other expressing this relationship. Likewise, in a call center environment, each call center agent could possess credentials to which supervisors also have access.
たとえば、＃1から始めて、エグゼクティブとアシスタントが両方とも共有の住所アドレスのリクエストを受信した場合（そのように構成されている場合）、共有アイデンティティの他のダイアログを交換できるはずです。どちらも同じキーイング素材（ダイジェストまたはs/mime）を共有することもできます。また、この関係を表現する他の人が署名した承認文書を保持することもできます。同様に、コールセンター環境では、各コールセンターエージェントが監督者もアクセスできる資格情報を所有する可能性があります。
The most common use case of a replacement is on the request of the replaced participant (who no longer wants to be involved). This is the case in many features, such as completing an Attended Transfer and converting a 3-way call to a point-to-point call. Such replacements are typically triggered by a REFER [8] request from the replaced participant. The Referred-By [4] mechanism defines one way to identify the apparent original requester and can point to a SIP Authenticated Identity Body [5] (an S/MIME-based signed assertion) to secure this information.
交換の最も一般的なユースケースは、交換された参加者（関与したくない）の要求に基づいています。これは、参加した転送の完了や3ウェイコールのポイントツーポイントコールへの変換など、多くの機能の場合です。このような代替品は、通常、交換された参加者からの紹介[8]要求によってトリガーされます。紹介された[4]メカニズムは、見かけの元の要求者を識別する1つの方法を定義し、SIP認証されたアイデンティティ本体[5]（S/MIMEベースの署名されたアサーション）を指すことができ、この情報を確保します。
In the example in section 1, Alice sends an INVITE with Replaces to Bob. Alice was a former participant in the conversation and had a previous dialog relationship with Bob. Alice can use the same Digest or S/MIME credentials she used to authenticate with Bob during the original call to prove that she was a former participant. Note that this justification for replacing calls is more dangerous than the others, and in most cases is another way to authorize that the replacing participant is available. Implementations SHOULD NOT rely on this method as an authorization mechanism.
セクション1の例では、アリスはボブに交代する招待状を送ります。アリスは会話の元参加者であり、ボブとの以前の会話関係を持っていました。アリスは、元の電話でボブと認証するために使用した同じダイジェストまたはS/MIME資格を使用して、彼女が元参加者であることを証明できます。通話を交換するためのこの正当化は他のものよりも危険であり、ほとんどの場合、交換参加者が利用可能であることを承認する別の方法であることに注意してください。実装は、承認メカニズムとしてこの方法に依存するべきではありません。
The last scenario is the easiest to secure but the least likely to be useful in practice. It is unlikely that an arbitrary host in the Internet is aware of any special authorization relationship between the replaced and the replacing parties. However, this use case may be useful in some environments. Since this usage does not effectively degrade the security of the solution, it is still allowed.
最後のシナリオは最も簡単に保護できますが、実際には役に立つ可能性が最も低いです。インターネット内の任意のホストが、交換された当事者と交換当事者の間の特別な認可関係を認識している可能性は低いです。ただし、このユースケースは、一部の環境で役立つ場合があります。この使用は、ソリューションのセキュリティを効果的に分解しないため、まだ許可されています。
Some mechanisms for obtaining the dialog information needed by the Replaces header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, and notifications after a REFER request. Since manipulating this dialog information could cause User Agents to replace the wrong dialog, use of message integrity protection for this information is STRONGLY RECOMMENDED. Use of end-to-end security mechanisms to encrypt this information is also RECOMMENDED.
交換ヘッダー（call-id、to-tag、from-tag）で必要なダイアログ情報を取得するためのいくつかのメカニズムには、Webページのuris、適切なイベントパッケージへのサブスクリプション、紹介要求後の通知が含まれます。このダイアログ情報を操作すると、ユーザーエージェントが間違ったダイアログを置き換える可能性があるため、この情報のメッセージ整合性保護の使用を強くお勧めします。この情報を暗号化するためのエンドツーエンドのセキュリティメカニズムの使用もお勧めします。
This extension was designed to take advantage of future signature or authorization schemes defined in standards track extensions. In general, call control features benefit considerably from such work.
この拡張機能は、標準トラック拡張機能で定義されている将来の署名または承認スキームを活用するように設計されています。一般に、コールコントロール機能はそのような作業からかなり利益を得ています。
Name of Header: Replaces
ヘッダーの名前：交換
Short form: none
短いフォーム：なし
Normative description: section 6.1 of this document
規範的説明：このドキュメントのセクション6.1
Name of option: replaces
オプションの名前：交換
Description: Support for the SIP Replaces header
説明：SIPの代替ヘッダーのサポート
SIP headers defined: Replaces
定義されたSIPヘッダー：交換
Normative description: This document
規範的説明：このドキュメント
Thanks to Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, and many other members of the SIP WG for their continued support of the cause of distributed call control in SIP.
ロバート・スパークス、アラン・ジョンストン、ダン・ペトリー、ベン・キャンベル、およびSIP WGの他の多くのメンバーに、SIPの分散コールコントロールの原因を継続的に支持してくれたことに感謝します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[4] Sparks、R。、「セッション開始プロトコル（SIP）がメカニズムを参照」、RFC 3892、2004年9月。
[5] Peterson, J., "The Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[5] Peterson、J。、「セッション開始プロトコル（SIP）認証IDボディ（AIB）形式」、RFC 3893、2004年9月。
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[8] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
[10] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[10] Mahy、R。、「セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク」、2003年3月の作業。
[11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[11] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）の第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003.
[12] Sparks、R。and A. Johnston、「セッション開始プロトコルコールコントロール - 転送」、2003年2月の作業。
[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）の招待開始されたダイアログイベントパッケージ」、2003年3月の作業。
[14] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003.
[14] Johnston、A。、およびS. Donovan、「セッション開始プロトコルサービスの例」、2003年3月、進行中の作業。
[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[15] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[16] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[18] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[19] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[19] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003.
[20] Campbell、B。、「Simple Presencion Publication Mechanism」、Progress、2003年2月。
Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Dr Scotts Valley, CA 95066 USA
Rohan Mahy Cisco Systems、Inc。5617 Scotts Valley Dr Scotts Valley、CA 95066 USA
EMail: rohan@cisco.com
Billy Biggs
ビリー・ビッグス
EMail: bbiggs@dumbterm.net
Rick Dean
リック・ディーン
EMail: rfc@fdd.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。