Network Working Group R. Mahy Request for Comments: 3891 Cisco Systems, Inc. Category: Standards Track B. Biggs R. Dean September 2004 セッション開始プロトコル(SIP)「Replaces」ヘッダー The Session Initiation Protocol (SIP) "Replaces" Header 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)の マルチパーティアプリケーションおよび呼制御で利用する新規ヘッダーを定義 する。Replacesヘッダーは、既存のSIPダイアログを新しいダイアログで論理 的に置換するために使用される。この要素は、「セカンダリコールありの転送 (Attended Transfer)」や「コールピックアップ(Call Pickup)」など、様々な 機能に使用できる可能性がある。この例示した機能の定義は仕様ではないとい うことに留意のこと。 Mahy, et al. Standards Track [Page 1] RFC 3891 The SIP "Replaces" Header September 2004 目次 1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 規約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ユーザーエージェントサーバーの動作: Replacesヘッダーの受信 . 4 4. ユーザーエージェントクライアントの動作: Replacesヘッダー の送信 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. プロキシの動作 . . . . . . . . . . . . . . . . . . . . . . . 7 6. 構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Replacesヘッダー . . . . . . . . . . . . . . . . . . . 7 6.2. RequireおよびSupportedヘッダーのための新規オプション タグ . . . . . . . . . . . . . . . . . . . . . . . . 8 7. 使用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. 発信側でのearlyダイアログの置換 . . . . . . . . . . . . 9 8. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . 11 9. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. 「Replaces」SIPヘッダーの登録 . . . . . . . . . . . . . 13 9.2. 「replaces」SIPオプションタグの登録 . . . . . . . . . . 13 10. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . 13 11.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 14 12. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 15 13. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . 16 1. 概要 本文書は、SIPのマルチパーティアーキテクチャフレームワーク(参考文献 [10])の一部として、SIP(参考文献[1])の拡張ヘッダーフィールドについて述 べる。Replacesヘッダーは、既存のSIPダイアログを新しいダイアログで論理 的に置換するために使用される。これはピアツーピアの呼制御環境において特 に有用である。 Replacesヘッダーの用法のひとつは、マルチメディア会話で1人の参加者を別 の参加者と置き換えることである。この機能はすでに、サードパーティ呼制御 (参考文献[11])型の呼制御を用いることで可能だが、サードパーティ呼制御 (3pcc)モデルは、多くの環境において好ましくない可能性のある、制御の中心 点を必要とする。したがって、分散したピアツーピア型で、これらと同じ呼制 御概念を実行する手法が大変望ましいのである。 以下の理由から、Call-IDまたは他のフィールドに基づいて、送られてくる INVITEで暗黙の関連付けを行う上で、ダイアログのマッチングのための新規 ヘッダーを持つ新規のINVITEを使用することが選択された。 o INVITEはすでに新しい呼のための正しいセマンティクスを持っている。 o 新規リクエストで明示的にReplacesヘッダを使用することは、リクエスト の目的を明確にする。 Mahy, et al. Standards Track [Page 2] RFC 3891 The SIP "Replaces" Header September 2004 o 置換する呼に一意のCall-IDを与えることができる。これによって、関連付 けられるユーザーエージェントでのダイアログマッチング問題を防ぐ。 o ヘッダーが対応されていない場合の悪影響はない。 Replacesヘッダーによって、セカンダリコールありの転送、パークからの回 収、ローカルでミックスされた会議から分散型ピアツーピア方式の2者間通話 への遷移といったサービスが可能になる。この列挙したサービスがすべてでは ない。転送(参考文献[12])]と同様に、ReplacesヘッダーはREFER(参考文献 [8])メソッドと組み合わせてよく使用されるが、単独で使用されることもあ る。 例えば、Aliceがphone1からBobと通話しているとする。彼女は、研究所に向 かっているあいだ、Bobをパーキング場所に転送(transfer)する。彼女が研究 所に着くと、Bobとパーキング場所で共有しているダイアログ情報で、 Replacesヘッダーフィールドを持つINVITEをBobに送って、パークされている 呼をphone2から回収する。Aliceはこの情報を帯域外の何らかの仕組みを用い て取得する。彼女はおそらくこの情報にパーキング場所から(参考文献[13]の セッションダイアログパッケージを使用して)サブスクライブしたか、あるい はWebサイトを訪れてURIをクリックした可能性がある。以下は、この例の簡単 なコールフローである。(わかりやすくするために、ViaとMax-Forwardsヘッ ダーは省略した。 Alice Alice Parking phone1 phone2 Bob Place | | | | |<===============================>| | | | | | | AliceはBobをParking Placeに転送する | | | | | |------------REFER/200----------->| *1 *2 | |<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->| |<--NOTIFY/200 (success)----------|<=================>| |------------BYE/200------------->| | | | | | | | | | | Aliceは後で別の電話から通話を受け取る | | | | | | *3 |-INV w/Replaces->| | | |<--200-----------| | | |---ACK---------->|----BYE/200------->| | |<===============>| | | | | | Mahy, et al. Standards Track [Page 3] RFC 3891 The SIP "Replaces" Header September 2004 メッセージ *1: Bob-> Parking Place INVITE sip:parkingplace@example.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@bobster.example.org CSeq: 1 INVITE Contact: Referred-By: メッセージ *2: Parking Place -> Bob SIP/2.0 200 OK To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@bobster.example.org CSeq: 1 INVITE Contact: メッセージ *3: Alice@phone2 -> Bob INVITE sip:bob@bobster.example.org To: From: ;tag=8983 Call-ID: 09870@phone2.example.org CSeq: 1 INVITE Contact: Require: replaces Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472 2. 規約 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC2119(参考文献[2])のBCP 14 に記載されるとおりに解釈されるべきである。 本文書中では「confirmedダイアログ」および「earlyダイアログ」という用語 を頻繁に使用する。これらの用語はSIP(参考文献[1])のセクション12で定義さ れている。 3. ユーザーエージェントサーバーの動作: Replacesヘッダーの受信 Replacesヘッダーは、既存のSIPダイアログをマッチするために使用する情報 を含む(Call-ID、to-tag、from-tag)。Replacesヘッダーを持つINVITEを受信 すると、ユーザーエージェント(User Agent/UA)はこの情報を、confirmedまた はearlyダイアログとマッチさせようと試みる。ユーザーエージェントサー バー(User Agent Server/UAS)は、to-tagとfrom-tagパラメータは、送られて Mahy, et al. Standards Track [Page 4] RFC 3891 The SIP "Replaces" Header September 2004 くるリクエストに存在するタグであるかのようにマッチングする。言い換える と、to-tagパラメータはローカルのタグと比較され、from-tagパラメータはリ モートのタグと比較される。 INVITEに2つ以上のReplacesヘッダーフィールドが存在する場合、あるいは INVITE以外のリクエストにReplacesヘッダーフィールドが存在する場合、UAS は400(Bad Request)応答でそのリクエストを拒否しなければならない[MUST]。 Replacesヘッダーは固有の呼制御セマンティクスを持つ。Replacesヘッダー フィールドとそれに相反するセマンティクスを持つ別のヘッダーフィールドが リクエスト中に存在する場合、そのリクエストは400(Bad Request)応答で拒否 されなければならない[MUST]。 Replacesヘッダーフィールドが2つ以上のダイアログにマッチする場合、UAは マッチするものが見つからなかったように動作しなければならない[MUST]。 マッチするものが見つからなかった場合、UASはINVITEを拒否し、481(Call/ Transaction Does Not Exist)応答を返す。同様に、Replacesヘッダーフィー ルドがINVITEで生成されたのではないダイアログにマッチする場合、UASは481 応答でリクエストを拒否しなければならない[MUST]。 Replacesヘッダーフィールドが既に終了しているダイアログにマッチする場 合、UAは603(Declined)応答でリクエストを断るべきである[SHOULD]。(マッチ した招待がちょうど終了すると、置換されたリクエストも同様にエラーにな る。600クラス応答でリクエストを拒否することで、望まれていない置換コー ルのためにUAが電話をかけたりアラートする場合の面倒な競合条件を防ぐこと ができる。) Replacesヘッダーフィールドがアクティブなダイアログにマッチする場合、UA は、マッチしたダイアログをその新規INVITEのイニシエータが置換することが 認可(authorized)されているかどうかを確認しなければならない[MUST]。新規 INVITEのイニシエータが、置換されるユーザーに相当すると認証 (authenticated)された場合、置換は認可される。例えば、置換されるユー ザーと置換ダイアログのイニシエーターが、ダイジェスト認証の資格情報 (credential)を共有する場合、あるいは同じプライベートキーを持つS/MIME (参考文献[7])で置換リクエストに署名し、元のダイアログで使用されるもの と対応する同じ証明書を提示する場合、置換は認可される。 別の方法として、Referred-Byの仕組み(参考文献[4])で、置換リクエストが、 マッチされたダイアログ内の他の参加者の代理で送信された(この場合、REFER リクエストがトリガとなった)ということを、UASが検証に使用できる仕組みが 定義されている。置換リクエストが置換されているユーザーに対応する Referred-Byヘッダーを含む場合、置換は置換されるパーティに認可されてい ると、UAは扱うべきである[SHOULD]。Referred-Byヘッダーは、対応する有効 なRefererred-By認証済みアイデンティティボディ (Refererred-ByAuthenticated Identity Body)(参考文献[5])を参照すべき である[SHOULD]。 Mahy, et al. Standards Track [Page 5] RFC 3891 The SIP "Replaces" Header September 2004 UAは、その他のリクエストを認可するために、他のローカルポリシーを適用し てもよい[MAY]。言い替えると、UASは、置換ダイアログに適用されたのとは別 のポリシーを、置換ダイアログにに適用してもよい。 さらに、UAは標準化過程(standards track)の拡張でこの目的のために定義さ れた他の認可の仕組みを使用してもよい[MAY]。拡張によって、置換の認可を 推移的にアサート(transitively asserting)[訳注]するための他の仕組みを定 義できる。 [訳注:推移的に(transitively)に関する補足情報。a R b、b R cのとき、 a R cが成立するとき、Rは推移的(transitive)と言う。 例:・a = b、b = c のとき a = cと言える場合→ イコールは推移的 ・a < b、b < c のとき a < cと言える場合→ 大なりは推移的 ・ドメインa-b間に信頼関係、b-c間に信頼関係が成立するとき、 a-c間にも信頼関係が成立する場合→ 推移的な信頼関係] 認可が成功した場合、UAは、新規INVITEを受け入れ、マッチしたダイアログの ユーザーインターフェースと他のリソースを新規INVITEに再割り当てし、置き 換えられたダイアログを終了しようとする。UAが新規INVITEを受け入れできな い場合(例えば、要求されたQoSやキーを確立できなかったり、互換性のないメ ディアを持っている)、UAは適切なエラー応答を返さなければならず[MUST]、 マッチしたダイアログに変更を加えずにそのままにしなければならない [MUST]。 Replacesヘッダーフィールドがconfirmedダイアログにマッチする場合、 「early-only」フラグがReplacesヘッダーフィールドにあるかどうかが確認さ れる。(このフラグによって、UACはセクション7.1に記載されている、望まし くない可能性のある競合状態防ぐことができる。)フラグがある場合、UAはリ クエストを486 Busy応答で拒否する。あるいは、200クラス応答を送信して新 規のINVITEを受け入れ、BYEを送信して置換ダイアログをシャットダウンす る。ReplacesヘッダーフィールドがUAに初期化されたearlyダイアログに マッチする場合、200クラス応答を送信して新規のINVITEを受け入れ、 CANCELを送信して置換ダイアログをシャットダウンする。 Replacesヘッダーフィールドが、このUAの初期化していないearlyダイアログ にマッチする場合、新規のINVITEに対して481 (Call/Transaction Does NotExist)応答を返し、マッチしたダイアログはそのままにする。Replacesは1 個のダイアログにのみマッチするので、置換のダイアログは、フォークの同じ ロジックに従って、earlyダイアログを生成した元のリクエストとして再び ターゲットにされることはない、ということに注意。 (現在のところ、この環境で、ただ1個のダイアログを置換するための使用例は 確認されていない) 4. ユーザーエージェントクライアントの動作: Replacesヘッダーの送信 既存の1つのearlyあるいはconfirmedダイアログをそれ自身の新規ダイアログ で置換することを望むユーザーエージェントは、ターゲットのユーザーエー ジェントにReplacesヘッダーフィールドを含むINVITEを送信してもよい [MAY]。ユーザーエージェントクライアント(User Agent Client/UAC)は、1つ のReplacesヘッダーフィールド中に、ターゲットダイアログのためにCall- ID、to-tag、およびfrom-tag情報を置き、ターゲットに新規INVITEを送信す る。ユーザーエージェントがearlyダイアログの置換のみを行いたい場合(セク ション7.1のコールピックアップ例のように)、UACは「early-only」パラメー Mahy, et al. Standards Track [Page 6] RFC 3891 The SIP "Replaces" Header September 2004 タをReplacesヘッダーフィールドに含めてもよい[MAY]。UACは、Replacesヘッ ダーフィールドを持つINVITEのターゲットが始めたのではない、earlyダイア ログを置換しようとするReplacesヘッダーフィールドを持つINVITEを送信して はならない[MUST NOT]。 この仕組みの使用によって、複数のダイアログにマッチする手段は提供され ず、また、すべての呼にマッチする手段、すべてのトランザクションにマッチ する手段、プロキシのフォークロジックチェーンを追跡する手段も提供されな いということに注意すること。例えば、Aliceがearlyダイアログにおいて CathyをBobと置換したがBobが出なかった場合、Aliceの置換リクエストはBob のUAがリダイレクトする別のダイアログにマッチせず、またBobのプロキシが 転送(forward)する別のブランチにもマッチしない。本仕様は、フォークを考 慮して、十分な予防措置をとっているが、実装では、ターゲットのSIP Contact URIに対してのみ、置換リクエストはアドレス指定する(つまり置換リ クエストのリクエストURIを設定する)べきである[SHOULD]。 5. プロキシの動作 この拡張に対応するためにプロキシサーバーに要求される新らしい動作はな い。プロキシサーバーはSIP仕様に述べられているように、単にReplacesヘッ ダーフィールドを透過的に通過させる。 プロキシがReplacesヘッダーフィールドを含むINVITEリクエストを(特に、発 呼側スクリーニングや時間によるルーティングといったアプリケーションレイ ヤーのロジックに基づいてフォークするときに)それが置換しようとしていた オリジナルリクエストではなく、完全に独立したContactsのセットに転送 (forward)することも可能だということに注意すること。この場合、Replaces ヘッダーフィールドを持つINVITEリクエストは失敗する。 6. 構文 6.1. Replacesヘッダー Replacesヘッダーフィールドは、そのヘッダーフィールドによって特定される 1つのダイアログが終了され、それが含まれる送られてきたINVITEによって論 理的に置換されることを示す。それはリクエストヘッダーのみであり、INVITE リクエストに対してのみ定義されている。Replacesヘッダーフィールドは、エ ンドツーエンドの暗号の一部として暗号化してもよい[MAY]。SIPリクエストに 存在してもよいのは、1個のReplacesヘッダーフィールド値のみである。 本文書では、参考文献[1]の表2に以下のエントリを追加する。この表への追加 は、本文書の発行時点で定義されている拡張メソッドにも与えられる。これは 読者のために提供されているものであり、規範とはならない。MESSAGE、 SUBSCRIBEおよびNOTIFY、REFER、INFO、UPDATE、PRACK、PUBLISHはそれぞれ、 参考文献[15]、[16]、[8]、[17]、[18]、[19]、[20]で定義されている。 Mahy, et al. Standards Track [Page 7] RFC 3891 The SIP "Replaces" Header September 2004 Header field where proxy ACK BYE CAN INV OPT REG MSG ------------ ----- ----- --- --- --- --- --- --- --- Replaces R - - - o - - - SUB NOT REF INF UPD PRA PUB --- --- --- --- --- --- --- Replaces R - - - - - - - 以下の構文仕様は、RFC2264(参考文献[3])に記載される通り、拡張BNF (augmented Backus-Naur Form)を使用する。以下の構文は、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" Replacesヘッダーフィールドは、一意なダイアログマッチングに必要となるの で、正確に1つのto-tagと、正確に1つのfrom-tagを含まなければならない [MUST]。RFC 2543(参考文献[9])に準拠するUAが開始したダイアログとの互換 性を保つために、ゼロのタグは、ゼロとNULLの双方にマッチする。Replaces ヘッダーフィールドはearly-flagを含んでもよい［MAY］。 例: 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 6.2. RequireおよびSupportedヘッダーのための新規オプションタグ 本仕様では、新規Require/Supportedヘッダーオプションタグ「replaces」を 定義する。Replacesヘッダーに対応するUAは、Supportedヘッダーフィールド に「replaces」オプションタグを含めなければならない[MUST]。Replacesが対 応されていない場合に明示的な失敗通知を望むUAは、Requireヘッダーフィー ルドに「replaces」オプションを含めてもよい[MAY]。 例: Require: replaces, 100rel Mahy, et al. Standards Track [Page 8] RFC 3891 The SIP "Replaces" Header September 2004 7. 使用例 以下の非規範的な例は、本拡張の可能性のすべてを列挙するのではなく、単に 用例あるいはアイデアを提供することを意図している。他の例については、 SIP Service Examples(参考文献[14])を参照のこと。簡潔でわかりやすくする ために、ViaとMax-Forwardsヘッダーは省略している。 7.1. 発信側でのearlyダイアログの置換 この例では、Bobはたった今研究所にやってきたばかりで、その場所をまだ登 録していない。Bobは彼の机の電話が鳴るのを聞く。Bobはそばにあるコン ピュータのソフトウェアUAに急いでログインする。ソフトウェアUAは数ある機 能の1つとして、彼の机の電話のダイアログステートにアクセスできる。ソフ トウェアUAが彼の電話が鳴っていることを認知すると、Bobにその場で通話を するかどうかの選択肢を提供する。ソフトウェアUAはReplacesを持つINVITEを Aliceに送信する。AliceのUAがこの新規INVITEを受信すると、彼女のオリジナ ルINVITEをCANCELし、AliceとBobを接続する。 Bob Bob Alice desk lab | | | *1 |-----INVITE----------->| | *2 |<----180---------------| Bobはラボで机の電話が | | | 鳴るのを聞いたがまだ | | | REGISTERされていない | | | | | |<--fetch dialog state --| | |---response ----------->| *3/4 |<-----INVITE with Replaces/200/ACK--------------| *5/6 |------CANCEL/200------>| | *7 |<-----487--------------| | |------ACK------------->| | | | | | | | メッセージ *1: Alice -> Bobの机の電話 INVITE sip:bob@example.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@phone.example.org CSeq: 1 INVITE Contact: Mahy, et al. Standards Track [Page 9] RFC 3891 The SIP "Replaces" Header September 2004 メッセージ *2: Bobの机の電話 -> Alice SIP/2.0 180 Ringing To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@phone.example.org CSeq: 1 INVITE Contact: メッセージ *3: 研究所にいるBob -> Alice INVITE sip:alice@phone.example.org To: From: ;tag=8983 Call-ID: 09870@labpc.example.org CSeq: 1 INVITE Contact: Replaces: 425928@phone.example.org ;to-tag=7743;from-tag=6472;early-only メッセージ *4: Alice -> 研究所にいるBob SIP/2.0 200 OK To: ;tag=9232 From: ;tag=8983 Call-ID: 09870@labpc.example.org CSeq: 1 INVITE Contact: メッセージ *5: Alice -> Bobの机の電話 CANCEL sip:bob@example.org SIP/2.0 To: From: ;tag=7743 Call-ID: 425928@phone.example.org CSeq: 1 CANCEL Contact: メッセージ *6: Bobの机の電話 -> Alice SIP/2.0 200 OK To: From: ;tag=7743 Call-ID: 425928@phone.example.org CSeq: 1 CANCEL Contact: Mahy, et al. Standards Track [Page 10] RFC 3891 The SIP "Replaces" Header September 2004 メッセージ *7: Bobの机の電話 -> Alice SIP/2.0 487 Request Terminated To: ;tag=6472 From: ;tag=7743 Call-ID: 425928@phone.example.org CSeq: 1 INVITE 8. セキュリティの考慮事項 本文書で規定されている拡張は、SIPデバイスに関連するセキュリティを大幅 に変更する。現状SIPでは、たとえ盗聴者がダイアログのCall-ID、To、および Fromヘッダーを知ったとしても、ダイジェスト認証またはエンドツーエンドの メッセージ完全性(message integrity)が使用されていれば、容易にそのダイ アログを改竄あるいは破壊できない。 本拡張はマルチメディア会話において、参加者を切断、あるいは置換するため に使用できる。そのため、Replacesヘッダーを持つ招待(invitation)は、置換 を要求しているピアがSIPの標準的な仕組み(ダイジェストまたはS/MIME)を用 いて適切に認証され、ターゲットダイアログの置換を要求することを認可され た場合にのみ、受け入れなければならない[MUST]。すべてのSIP実装は、まず ダイジェスト認証に対応する必要がある。さらに、Replacesヘッダーに対応す る実装では、Referred-Byの仕組みも実装すべきである[SHOULD]。 ダイアログを置換するためにどのリクエストが正当に認可されるかについて ユーザーエージェントが決めることは、瑣末なことではなく、また、非常に多 くの点でローカルポリシーを考慮する必要である。一般的に、置換に対する認 可が適切とされるあるいは保証されるには、4つのケースがある。 1. 置換されるパーティと同一と考えられるパーティによる置換 2. 置換されるパーティの代わりに(おそらく推移的に)行われる置換 3. 前の参加者(former participant)による置換 4. 明確に認可されたパーティによる置換 例えば、1項目から始めると、重役とアシスタントの双方が共有の Addresses-of-Recordに対するリクエストを受信した場合、設定されている場 合は、他方のダイアログを共有のアイデンティティへ置換することを双方がで きるべきである。双方が同じ重要なもの(ダイジェストまたはS/MIME)を共有す Mahy, et al. Standards Track [Page 11] RFC 3891 The SIP "Replaces" Header September 2004 ることもでき、または、一方がこの関係を表す署名をした認可書を、もう一方 も保持できる。コールセンター環境でも同様に、各コールセンターの各担当者 は、監督者もまたアクセス権を持つ資格情報(credential)を所有する可能性が ある。 置換の最も一般的な使用例は、(今後は関わる意思のない)置換された参加者の リクエスト時である。これは、セカンダリコールありの転送を完了させたり、 また、3者会議を2者間の通話へ変換するなど、多くの機能にあるケースであ る。このような置換は一般的に、置換された参加者からのREFER(参考文献[8]) リクエストがトリガーとなる。Referred-By(参考文献[4])の仕組みによって、 明確な元のリクエスト送信者を識別する方法のひとつと、また、この情報を保 護するために、SIP認証アイデンティティボディ(参考文献[5])(S/MIMEベース の署名されたアサーション)を指定することができる。 セクション1の例では、AliceはBobへReplaces付きのINVITEを送信する。Alice は会話の前の参加者であり、Bobと前にダイアログの関係を持っていた。Alice は、自身が前の参加者であると証明する元の通話中にBobとの認証に使用した のと同じダイジェストまたはS/MIMEの資格情報を使用することができる。呼に 置換に対するこの正当化は、他の方法よりも危険であり、多くの場合、参加者 の置換を認可するには別の方法が利用できる、ということに注意。実装では、 認可の仕組みとしてこの方法に依存すべきではない[SHOULD NOT]。 最後のシナリオは、最も簡単に保証する方法だが、最も実用的ではないもので ある。インターネット内にある任意のホストが、置換される側とする側の間の 特別な認可関係に注意を払うというのは、あまり考えられない。だが、この ケースは、環境によっては有効な場合がある。この用法は実質的に解決方法の セキュリティを劣化させるものではないので、まだ考慮の余地がある。 Replacesヘッダーフィールドが必要とするダイアログ情報(Call-ID、to-tag、 from-tag)を取得する仕組みの一部には、Webページ上のURIや、適切なイベン トパッケージへのサブスクリプト、REFERリクエスト後の通知が含まれる。こ のダイアログ情報を操作することによって、ユーザーエージェントが誤ったダ イアログを置換してしまう可能性があるため、この情報に対してメッセージの 完全性保護を使用することが強く推奨され[RECOMMENDED]。この情報を暗号化 するエンドツーエンドのセキュリティの仕組みを使用することもまた推奨され る[RECOMMENDED]。 本拡張は、標準化過程の拡張で定義される将来の署名または認証スキームを利 用するように設計された。一般的に、呼制御機能はこのような研究から大きな 恩恵を受ける。 Mahy, et al. Standards Track [Page 12] RFC 3891 The SIP "Replaces" Header September 2004 9. IANA条項 9.1. 「Replaces」SIPヘッダーの登録 ヘッダー名: Replaces 省略形: なし 仕様の記載: 本文書のセクション6.1 9.2. 「replaces」SIPオプションタグの登録 オプション名: replaces 説明: SIP Replacesヘッダーへの対応 定義されたSIPヘッダー: Replaces 公開されている仕様: 本文書 10. 謝辞 SIPにおける分散呼制御の原因についての継続的なサポートをしてくれた、 Robert Sparks、Alan Johnston、Dan Petrie、Ben Campbell、そしてその他多 くのSIPワーキンググループのメンバーに感謝する。 11. 参考文献 11.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. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [5] Peterson, J., "The Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. Mahy, et al. Standards Track [Page 13] RFC 3891 The SIP "Replaces" Header September 2004 [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. [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 11.2. 有益な参考文献 [8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [10] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2003. [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. [12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003. [13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", Work in Progress, March 2003. [14] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003. [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. Mahy, et al. Standards Track [Page 14] RFC 3891 The SIP "Replaces" Header September 2004 [19] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003. 12. 著者の連絡先 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 Mahy, et al. Standards Track [Page 15] RFC 3891 The SIP "Replaces" Header September 2004 13. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記 載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Mahy, et al. Standards Track [Page 16]