Network Working Group J. Rosenberg Request for Comments: 4353 Cisco Systems Category: Informational February 2006 セッション開始プロトコル(SIP)による カンファレンスのフレームワーク A Framework for Conferencing with the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティに情報を提供するためのものであ る。いかなるインターネット標準も規定しない。本文書の配信は無制限で ある。 著作権表記 Copyright (C) The Internet Society (2006). 概要 セッション開始プロトコル(Session Initiation Protocol/SIP)は、ユー ザーエージェント間のメディアセッションの開始、変更、終了に対応して いる。 メディアセッションは、SIPダイアログで管理される。SIPダイアログは1組 のユーザーエージェント間にあるSIPの関係性を表す。ダイアログは1組の ユーザーエージェント間にあるため、2者間通信(電話の通話など)というSIP の用法は明らかである。複数参加者との通信セッションは、一般的にカン ファレンスと呼ばれ、2者間よりも複雑である。本文書は、こうしたカン ファレンスが発生する状況のフレームワークについて定義する。このフレー ムワークでは、多者間カンファレンスに必要な全体のアーキテクチャ、用 語、プロトコルコンポーネントについて説明する。 目次 1. はじめに ....................................................... 2 2. 用語 ........................................................... 3 3. カンファレンスアーキテクチャの概要 ............................. 6 3.1. URIの用法 ................................................. 9 4. 要素の機能 .................................................... 10 4.1. フォーカス .............................................. 10 4.2. カンファレンスポリシーサーバー .......................... 11 4.3. ミキサー ................................................ 11 4.4. カンファレンス通知サービス .............................. 12 4.5. 参加者 .................................................. 13 4.6. カンファレンスポリシー .................................. 13 5. 共通の操作 .................................................... 13 5.1. カンファレンスの作成 .................................... 13 5.2. 参加者の追加 ............................................ 14 Rosenberg Informational [Page 1] RFC 4353 Conferencing Framework with SIP February 2006 5.3. 参加者の削除 ............................................ 15 5.4. カンファレンスの破棄 .................................... 15 5.5. メンバーシップ情報の取得 ................................ 16 5.6. メディアの追加と削除 .................................... 16 5.7. カンファレンスの宣言と記録 .............................. 16 6. 物理的認識 .................................................... 18 6.1. 中央サーバー ............................................ 18 6.2. エンドポイントサーバー .................................. 19 6.3. メディアサーバーコンポーネント .......................... 21 6.4. 分散型ミキシング ........................................ 22 6.5. カスケード型ミキサー .................................... 24 7. セキュリティの考慮事項 ........................................ 26 8. 寄稿者 ........................................................ 26 9. 謝辞 .......................................................... 26 10. 有益な参考文献 .............................................. 27 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP) [1]は、ユー ザーエージェント間のメディアセッションの開始、変更、終了に対応して いる。メディアセッションは、SIPダイアログで管理される。SIPダイアログ は1組のユーザーエージェント間にあるSIPの関係性を表す。ダイアログは1 組のユーザーエージェント間にあるため、2者間通信(電話の通話など)とい うSIPの用法は明らかである。ただし、複数の参加者がいる通信セッショ ンは、より複雑である。SIPは多数の多者間通信モデルに対応することがで きる。1つは、弱連結カンファレンス(loosely coupled conference)と呼ば れ、マルチキャストメディアグループを利用する。弱連結モデルでは、カン ファレンスの参加者間にシグナリングの関係はない。また、制御サーバーま たはカンファレンスサーバーの中央ポイントはない。参加は、カンファレン スの一部として渡される制御情報によって(たとえば、リアルタイム制御プ ロトコル(RTCP) [2]を使用して)、徐々に知らされる。SIPでは、セッション 記述内でマルチキャストアドレスを使用することで、弱連結カンファレンス に簡単に対応することができる。 もう1つのモデルは、完全分散型多者間カンファレンス(fully distributed multiparty conferencing)と呼ばれ、各参加者がSIPを使用して多の参加者 とのシグナリング関係を維持する。また、制御の中央ポイントはなく、参加 者間で完全に分散されている。このモデルは本文書の範囲外である。 もう1つのモデルは、しばしば強連結カンファレンス(tightly coupled conference)と呼ばれ、制御の中央ポイントがある。各参加者は、この中央 ポイントに接続する。中央ポイントには多様な機能があり、メディアミキシ ング機能を実行する場合もある。強連結カンファレンスは、RFC 3261で直接 対処されていないが、追加のプロトコルに対応することなく、基本的な参加 は可能である。 Rosenberg Informational [Page 2] RFC 4353 Conferencing Framework with SIP February 2006 本文書は、強連結SIPカンファレンスに関する全体のフレームワークを提示 する。以降、本文書では、単に「カンファレンス」と呼ぶ。また、このフ レームワークでは、こうしたカンファレンスの一般的なアーキテクチャモデ ルを提示し、カンファレンスの議論に使用する用語についても提示する。さ らに、SIP自体がカンファレンスに関与する方法についても論じる。このフ レームワークの目的は、[3]に概説されているカンファレンスの一般的な要 件に適合することである。本仕様では、いくつかのカンファレンス機能を達 成するために、非SIP固有のメカニズムについてほのめかしている。ただし、 このようなメカニズムは本仕様の範囲外である。 2. 用語 カンファレンス(Conference): カンファレンスは使い古された用語であり、 状況に応じて意味は異なる。SIPでは、カンファレンスとは多者間通話の インスタンスである。本仕様の場合、カンファレンスとは常に強連結カ ンファレンスである。 弱連結カンファレンス(Loosely Coupled Conference): 参加者間に協調的な シグナリング関係がないカンファレンスである。多くの場合、弱連結カ ンファレンスは、カンファレンスのメンバーシップの配信にマルチキャ ストを使用する。 強連結カンファレンス(Tightly Coupled Conference): フォーカスと呼ばれ る単一のユーザーエージェントが、各参加者とのダイアログを維持する カンファレンスである。フォーカスはカンファレンスの集中マネージャ の役割を果たし、カンファレンスURIでアドレスを指定する。 フォーカス(Focus): フォーカスは、カンファレンスURIでアドレスを指定さ れるSIPユーザーエージェントであり、カンファレンスを識別する(カン ファレンスが多者間通話の一意のインスタンスであることを思い出す)。 フォーカスはカンファレンス内の各参加者とのSIPシグナリング関係を維 持する。フォーカスは、カンファレンスを構築するメディアを各参加者 が確実に受信することに、何らかの方法で責任を持つ。また、フォーカ スはカンファレンスポリシーも実装する。フォースは論理的役割である。 カンファレンスURI (Conference URI): カンファレンスのフォーカスを識別 するURI。通常はSIP URI。 参加者(Participant): ユーザーまたは自動装置をカンファレンスに接続す るソフトウェア要素。最低でもSIPユーザーエージェントを実装するが、 追加機能のために非SIP固有のメカニズムを実装することもある。 Rosenberg Informational [Page 3] RFC 4353 Conferencing Framework with SIP February 2006 カンファレンスステート(Conference State): カンファレンスの状態には、 フォーカスの状態、カンファレンスに接続する参加者群、対応する各ダ イアログの状態が含まれる。 カンファレンス通知サービス(Conference Notification Service): フォー カスが提供する論理的機能。フォーカスはノーティファイア[4]として動 作することができる。この場合、カンファレンスステートへのサブスク リプションを受け入れ、カンファレンスステートの変化に関するサブス クリプションを通知する。 カンファレンスポリシーサーバー(Conference Policy Server): カンファレ ンスポリシーを格納し、操作する論理的機能である。 この論理的機能はSIP固有のものではなく、物理的に存在しない場合も ある。プロトコルとカンファレンスポリシーのインターフェースとなる コンポーネントを指す。 カンファレンスポリシー(Conference Policy): 特定のカンファレンスを規 定する完全な規則群。 ミキサー(Mixer): 同じ種類のメディアストリーム群を受信し、種類固有の 方法でメディアを結合し、その結果を各参加者に再配信する。ミキサー には、RTP [2]を使用して送信されるメディアも含まれる。結果として、 インスタンスメッセージングセッション[5]などの非RTPに基づくメディ アも許容しているため、本文書で定義される用語は、RFC 3550で定義さ れているミキサーの概念の上位集合である。 カンファレンスを意識しない参加者(Conference-Unaware Participant): 実 際はカンファレンスに参加しているのに、それを意識していないカン ファレンスの参加者。そのUAに関する限り、これはポイント間の通話で ある。 カスケード型カンファレンス(Cascaded Conferencing): 何らかの形式で フォーカス間で通信させることで、カンファレンス群を連結するグルー プ通信のメカニズム。 単信カスケード型カンファレンス(Simplex Cascaded Conferences): あるカ ンファレンスのフォーカスであるユーザーエージェントが、別のカン ファレンスではカンファレンスを意識しない参加者であるように連結さ れているカンファレンスグループ。 カンファレンスを意識する参加者(Conference-Aware Participant): 自動的 な方法で、カンファレンスに参加していることを認識しているカンファ レンスの参加者。カンファレンスを意識する参加者は、追記機能のた めに、カンファレンス通知サービスまたは追加の非SIP固有のメカニズム を使用することができる。 カンファレンスサーバー(Conference Server): カンファレンスサーバー は、最低でもフォーカスを含む物理サーバーである。また、カンファレ ンスポリシーサーバーとミキサーも含むことがある。 Rosenberg Informational [Page 4] RFC 4353 Conferencing Framework with SIP February 2006 大量招待(Mass Invitation): 多数のユーザーをカンファレンスに追加しよ うとする試み。 大量削除(Mass Ejection): 多数のユーザーをカンファレンスから削除しよ うとする試み。 サイドバー(Sidebar): 「カンファレンス内のカンファレンス」としてサイ ドバー内にユーザーへ表示される。これは、当事者ではない他の参加者 に対する、参加者の一部の間の会話である。 匿名参加者(Anonymous Participant): カンファレンス通知サービス経由で 他の参加者に知られるが、身元は公表されない参加者。 Rosenberg Informational [Page 5] RFC 4353 Conferencing Framework with SIP February 2006 3. カンファレンスアーキテクチャの概要 +-----------+ | | | | |Participant| | 4 | | | +-----------+ | |SIP |Dialog |4 | +-----------+ +-----------+ +-----------+ | | | | | | | | | | | | |Participant|-----------| Focus |------------|Participant| | 1 | SIP | | SIP | 3 | | | Dialog | | Dialog | | +-----------+ 1 +-----------+ 3 +-----------+ | | |SIP |Dialog |2 | +-----------+ | | | | |Participant| | 2 | | | +-----------+ 図1 SIPカンファレンスの(文字どおり)中央のコンポーネントはフォーカスで ある。フォーカスはカンファレンス内の各参加者とのSIPシグナリング関係 を維持する。結果は図1に示すように星形のトポロジである。 フォーカスは、カンファレンスを構成するメディアストリームを、カンファ レンスの参加者に利用できるようにする責任がある。この場合、1つまたは 複数のミキサーを利用し、各ミキサーは多数の入力メディアストリームを組 み合わせて、1つまたは複数の出力メディアストリームを作成する。フォー カスはメディアポリシーを使用して、適切なミキサーの構成を決定する。 Rosenberg Informational [Page 6] RFC 4353 Conferencing Framework with SIP February 2006 フォーカスには、各カンファレンスなどに存在するカンファレンスポリシー へのアクセス権がある。実質的に、カンファレンスポリシーは、カンファレ ンスの操作方法を記述するデータベースの一種として考えることができる。 カンファレンスポリシーを実施するのは、フォーカスの責任である。フォー カスには、データベースの読み取りアクセス権が必要なだけでなく、デー タベースの変更時を知る必要もある。このような変更の結果、SIPシグナリ ングが発生することがある(たとえば、BYEを使用してカンファレンスから ユーザーを削除など)。また、カンファレンスステートに影響がある変更に は、カンファレンス通知サービスを使用してサブスクライバに通知を送信す る必要がある。 カンファレンスは、フォーカスを識別するURIで表される。 各カンファレンスには、固有のフォーカスと、そのフォーカスを識別する固 有のURIがある。カンファレンスURIへのリクエストは、その固有のカンファ レンスのフォーカスにルーティングされる。 ユーザーは、通常、INVITEをカンファレンスURIに送信することでカンファ レンスに参加する。カンファレンスポリシーが許す限り、フォーカスによ るINVITEは受け入れられ、ユーザーはカンファレンスに追加される。 ユーザーは、通常の通話と同様に、BYEを送信することでカンファレンスか ら退席する。 同様に、カンファレンスポリシーが変わり、参加者がそのカンファレンスで 許可されなくなった場合、フォーカスはその参加者とのダイアログを終了す ることができる。また、参加者をカンファレンスに追加するためにINVITEを 開始することもできる。 カンファレンスを意識しない参加者の概念は、このフレームワークでは重要 である。カンファレンスを意識しない参加者は、通信相手のUAが偶然フォー カスであることを知ることすらない。カンファレンスを意識しない参加者か ら見ると、フォーカスのUAは他のUAと同様に見える。フォーカスは、当然な がら自身がフォーカスであることを認識しており、操作するカンファレンス に必要なタスクを実行する。 カンファレンスを意識しない参加者は、多数の機能にアクセス権を持つ。 SIPを使用してカンファレンスへ参加したりカンファレンスから退席したり、 また刺激シグナリング([6]参照)によってより高度な機能を取得することも できる。ただし、機能的なシグナリングプロトコルを使用して参加者がカン ファレンスの側面を明示的に制御したい場合、参加者はカンファレンスを意 識する必要がある。 Rosenberg Informational [Page 7] RFC 4353 Conferencing Framework with SIP February 2006 ..................................... . . . . . . . . . . . . . . . +-----------+ //-----\\ . . | | || || . non-SIP . | Conference| \\-----// . +---------------->| Policy | | | . | . | Server |----> | | . | . | | |Conference| . | . +-----------+ | Policy | . | . | | . | . | | . +-----------+ . +-----------+ | | . | | . | | \ // . | | . | | \-----/ . |Participant|<--------->| Focus | | . | | SIP . | | | . | | Dialog . | |<-----------+ . +-----------+ . |...........| . ^ . | Conference| . | . |Notification . +------------>| Service | . Subscription. +-----------+ . . . . . . . . . ..................................... カンファレンス機能 図2 Rosenberg Informational [Page 8] RFC 4353 Conferencing Framework with SIP February 2006 カンファレンスを意識する参加者は、追加のプロトコルによって高度な機能 へのアクセス権を持つ参加者である。また、SIP以外の独自メカニズムに よってカンファレンスポリシーにアクセス権を持つ可能性もある。このやり 取りのモデルを図2に示す。参加者は、強化された呼制御機能[7]にアクセス するために、REFERなど、既存の拡張を使用してやり取りすることができる。 参加者はカンファレンスURIにSUBSCRIBEできる。また、フォーカスが提供す るカンファレンス通知サービスに接続できる。このメカニズムによって、参 加者(事実上、ダイアログとメディアの状態)の変化を認識できる。 参加者は、何らかのSIP以外の独自メカニズムを使用して、カンファレンス ポリシーサーバーと通信できる。また、それによってカンファレンスポリ シーに影響が及ぶ可能性がある。カンファレンスポリシーサーバーは、すべ ての各カンファレンスで使用可能にする必要はないが、常にカンファレンス ポリシーは存在する。 フォーカスとカンファレンスポリシー間のインターフェース、カンファレン スポリシーサーバーとカンファレンスポリシー間のインターフェースは、非 SIPの独自メカニズムである。SIPに基づくカンファレンスの目的から、イン ターフェースは、物理的な分離を表すのとは対照的に、カンファレンスに関 係する論理的役割として機能する。要件が明確になるように、これらの機能 の分離について本文書で説明する。このアプローチによって各SIP実装の柔 軟性が高くなり、各インターフェースを完全に開発しなくても、拡張性と堅 牢性に優れたカンファレンスシステムを構築することができる。 3.1. URIの用法 カンファレンスはURIによって固有に識別され、このURIによってカンファレ ンスに責任を持つフォーカスが識別される、ということは、このフレーム ワークの基礎である。カンファレンスURIは固有なので、2つのカンファレン スが同じカンファレンスURIを持つことはない。カンファレンスURIは常に SIPまたはSIPS URIである。 カンファレンスURIは、そのURIを使用する可能性がある参加者には不透明で ある。URIを見て、そのURIがフォーカスを示すかどうかを確実に知る方法は ない。これはPSTNゲートウェイ上のユーザーまたはインターフェースとは対 照的である。これはURIの用法の一般的な理念[8]と一致する。ただし、URI がカンファレンスを表すことが、URI周辺の文脈的な情報(SIPヘッダーパラ メータなど)に示される場合もある。 SIPリクエストがカンファレンスURIに送信されると、そのリクエストは フォーカスにのみルーティングされる。カンファレンスURIを作成する要素 またはシステムは、このプロパティを保証する責任がある。 カンファレンスURIは、長期のカンファレンスや、 「sip:discussion-on-dogs@example.com」など関係するグループを表すこと ができる。このURIが特定するフォーカスは常に存在し、現在参加している 参加者に関係なく、常にカンファレンスを管理する。また、カンファレン スURIは、アドホックカンファレンスなど、短期のカンファレンスを表すこ ともできる。 Rosenberg Informational [Page 9] RFC 4353 Conferencing Framework with SIP February 2006 理想的には、ユーザーがカンファレンスURIを構築または推測することは ない。代わりに、カンファレンスURIは多くのメカニズムによって認識され る。カンファレンスURIには、電子メールまたはインスタントメッセージを 送信できる。カンファレンスURIにはWebページからリンクできる。カンファ レンスURIは、何らかの非SIPメカニズムから取得することもできる。 SIP URIがフォーカスを表すことを判断するには、URI機能の検出に関する標 準的な技術を使用できる。特に、着呼側機能の仕様[9]には、UAがそのダイ アログでフォーカスとして動作していることを示す「isfocus」機能がある。 着呼側機能パラメータは、フォーカスがカンファレンス通知サービスに対応 することを示すためにも使用される。これを実現するには、SUBSCRIBEメソッ ドへの対応と、カンファレンスURIと関連付けられた発呼側プリファレンス 機能パラメータの関連パッケージへの対応を宣言する。 URIによって、カンファレンスの他の機能を表すこともできる。カンファレ ンスポリシーは、Webアプリケーション経由で公開される場合、HTTP URIで 識別される。明示的なプロトコルを使用してアクセスする場合、そのプロト コルについて定義されたURIになる。 カンファレンスURIをはじめ、カンファレンスの他の論理エンティティの URIも、カンファレンス通知サービスを使用して認識することができる。 4. 要素の機能 このセクションでは、各要素で一般的に実装される機能について、より詳細 に説明する。 4.1. フォーカス 名前が示すように、フォーカスはカンファレンスの中心である。カンファレ ンスの全参加者はSIPダイアログによってフォーカスに接続する。 フォーカスは、自身に接続するダイアログを維持する責任がある。 また、メンバーシップポリシーの定義に従い、カンファレンスに参加するこ とが許可されている参加者群とダイアログを確実に接続する。さらに、各参 加者がカンファレンスの全メディアを確実に取得できるように、フォーカス はSIPを使用してメディアセッションを操作する。このとき、フォーカスは ミキサーを利用する。 Rosenberg Informational [Page 10] RFC 4353 Conferencing Framework with SIP February 2006 フォーカスはINVITEを受信すると、カンファレンスポリシーをチェックす る。ポリシーは、その参加者が参加を許可されていないことを示すことが ある。この場合、通話が拒否される可能性がある。モデレータとして動作す る別の参加者が、その新しい参加者を承認する必要がある、というポリシー も考えられる。この場合、INVITEは、music-on-holdサーバーで保持するか、 進捗を示す183応答を送信することができる。通知は、カンファレンス通知 サービスを使用してモデレータに送信される。すると、この新しい参加者が 参加することをモデレータが許可できるようになる。さらに、フォーカス はINVITEを受け入れることができるようになる(またはmusic-on-holdサー バーからパークを解除できるようになる)。フォーカスによるポリシーの解 釈は、ローカルポリシーの問題であり、標準化の対象ではない。 カンファレンスから(確認ダイアログありで)SIP参加者を削除する必要があ る場合、フォーカスはBYEをその参加者に送信して参加者を削除する。この 処理は、多くの場合、カンファレンスからユーザーの「退出(ejecting)」と 呼ばれる。また、多数のユーザーに対して実行する場合、「大量退出 (mass ejection)」と呼ばれる。同様に、新しいSIP参加者をカンファレンス に追加する必要がある場合、フォーカスはINVITEリクエストをその参加者に 送信する。大量のユーザーに対して実行される場合、この処理は大量招待 (mass invitation)と呼ばれる。最後に、SIP参加者のセッションのメディア についてプロパティを変更する必要がある場合(たとえば、ビデオの削除 など)、フォーカスは、その参加者への新しいオファーを含めてre-INVITEま たはUPDATE [15]リクエストを送信することで、その参加者セッション記述 を更新することができる。 多くの場合、参加者の退出や追加など、フォーカスが実行するシグナリング 動作は、カンファレンスのメディア構成を変化させる。このような変更に影 響を及ぼすために、フォーカスはミキサーとやり取りする。このやり取りに よって、確実に、すべての有効な参加者がメディアストリームのコピーを受 信し、各参加者がメディアをミキサー上のIPアドレスとポートに送信するこ とができる。この結果、カンファレンスの他のメディアと適切にミキシング される。フォーカスがミキサーとやり取りする手段は、本仕様の範囲外で ある。 4.2. カンファレンスポリシーサーバー カンファレンスポリシーサーバーは、システムの論理コンポーネントであ る。このサーバーは、クライアントと、カンファレンスの操作を管理するカ ンファレンスポリシーとのインターフェースを示す。クライアントは、非 SIP固有のメカニズムを使用して、カンファレンスポリシーサーバーとやり 取りする。 4.3. ミキサー ミキサーには、カンファレンスを構成するメディアストリームを結合し、受 信者(参加者の場合と他のミキサーの場合がある)に配信する1つまたは複数 の出力ストリームを生成する責任がある。メディアを結合する処理は、メ Rosenberg Informational [Page 11] RFC 4353 Conferencing Framework with SIP February 2006 ディアタイプに固有のものであり、メディアポリシーに記載されている規則 の指針に従って、フォーカスが指示する。 ミキサーは「カンファレンス」自体をエンティティとして意識していない。 ミキサーはメディアストリームを入力として受信し、フォーカスによる指示 に基づいて、メディアストリームを出力として生成する。メディアストリー ムをミキシングする方法を説明したポリシー以外に、メディアストリームの グループ化はない。 ミキサーは、直接的または間接的に、常にフォーカスの制御下にある。 フォーカスには、メディアポリシーを解釈して、ミキサーに適切な規則をイ ンストールする責任がある。フォーカスが直接的にミキサーを制御している 場合、ミキサーがフォーカスと同居している可能性、または何らかのプロト コルによって制御されている可能性がある。フォーカスが間接的にミキサー を制御している場合、ミキシングを参加者(それぞれが自分のミキサーを持 つ)へ委任する。これについては、セクション6.4を参照のこと。 4.4. カンファレンス通知サービス フォーカスはカンファレンス通知サービスを提供することができる。この役 割では、RFC 3265 [4]の定義に従い、ノーティファイアとして動作する。カ ンファレンスURIについてクライアントからサブスクリプションを受け入れ、 クライアントに対する通知をカンファレンス変更の状態として生成する。 カンファレンスの状態には、フォーカスに接続する参加者と、参加者に関連 するダイアログに関する情報も含まれる。新しい参加者が参加すると、この 状態は変化し、通知サービス経由で報告される。同様に、誰かが退出したと きもこの状態が変化するため、サブスクライバは退出について知ることがで きる。 参加者が匿名の場合、カンファレンス通知サービスは、他のカンファレンス 参加者から新規参加者のIDを引き出すか、匿名参加者のプレゼンスに関し て、他のカンファレンス参加者に通知しない。アプローチの選択は、匿名参 加者に提供する匿名性のレベルによって変わる。 Rosenberg Informational [Page 12] RFC 4353 Conferencing Framework with SIP February 2006 4.5. 参加者 カンファレンスの参加者は、フォーカスがあるダイアログを持つ任意のSIP ユーザーエージェントである。このSIPユーザーエージェントはPCアプリ ケーション、SIP電話機、またはPSTNゲートウェイの可能性がある。また、 別のフォーカスの可能性もある。他のカンファレンスのフォーカスである参 加者がいるカンファレンスは、単一カスケード型カンファレンスと呼ばれ る(simplex cascaded conference)。また、地域的なサブカンファレンスが あり、それぞれがメインカンファレンスに接続しているような、拡張性が高 いカンファレンスを実現するためにも使用できる。 4.6. カンファレンスポリシー カンファレンスポリシーには、フォーカス操作の指針となる規則が含まれ る。この規則は、カンファレンスで許可されている参加者セットを定義する アクセスリストなど、単純な可能性がある。また、ルールは信じられないほ ど複雑な可能性もある。たとえば、他の参加者のプレゼンスに関する条件に 基づいて、参加者に関する日時主体の規則を指定するなどの場合である。 カンファレンスポリシーでカプセル化することができる規則の種類につい ては、制限がないと理解することが重要である。 カンファレンスポリシーは、Webアプリケーションまたは音声アプリケー ションによって操作することができる。また、非SIP固有の規格または独自 のプロトコルで操作することもできる。 5. 共通の操作 ユーザーがカンファレンスとやり取りとする方法は多数ある。ユーザーは 参加、退出、ポリシーの設定、メンバーの承認などを行うことができる。こ のセクションの目的は、主なカンファレンス操作については、操作方法を要 約して概説することである。SIPメカニズムのより詳細な例については、[7] を参照のこと。 共通のカンファレンス操作の概要を説明するだけでなく、このセクションの 各サブセクションでは、操作を支援するSIPメカニズムについても説明して いる。非SIPメカニズムも可能だが、本文書では論じない。 5.1. カンファレンスの作成 カンファレンスを作成する方法は多数ある。カンファレンスの作成によっ て、同時に複数の要素が実際に構築される。その結果、フォーカスとカン ファレンスポリシーが作成される。また、結果としてカンファレンスURIが 構築される。このURIは、フォーカスを一意に特定する。カンファレンスURI は一意である必要があるため、カンファレンスを作成する要素は、一意性を 保証する責任がある。この処理は、(カンファレンスURIのレコードを維持す Rosenberg Informational [Page 13] RFC 4353 Conferencing Framework with SIP February 2006 るか、URIをアルゴリズム的に生成することで)確定的に達成される可能性が ある。または、または、(競合する可能性が十分に低い状態で、ランダムな URIを作成することで)確率的に達成される可能性がある。 カンファレンスポリシーが作成されると、実装に依存するデフォルトの規則 で確立される。カンファレンスの作成者が、この規則を変更したい場合、 非SIPメカニズムを使用して実行する。 カンファレンスアプリケーションに対してINVITEを送信することで、中央 サーバーでホストされるカンファレンスを作成するときにSIPを使用するこ とができる。このINVITEによって、新しいカンファレンスが自動的に作成 され、ユーザーが配置される。 エンドポイントにフォーカスが存在するカンファレンスの作成については、 操作が異なる。この場合、エンドポイント自体がカンファレンスURIを作成 し、参加者になる他のエンドポイントに渡す。事例ごとの差異は、カンファ レンスを作成することをエンドポイントが決定する方法である。 重要な事例の1つは、セクション6.2で説明するアドホックカンファレンスで ある。この場合、エンドポイントは、ローカルポリシーに基づいてカンファ レンスを作成することを、一方的に決定する。このUAに接続されているダイ アログは、re-INVITEまたはUPDATEを使用してエンドポイントがホストする フォーカスに移行され、カンファレンスURIが新しく参加した参加者に渡さ れる。 または、あるUAが別のUAに対して、エンドポイントがホストするカンファレ ンスを作成するように要求する可能性がある。これは、SIP Joinヘッダーで 達成される[10]。招待でJoinヘッダーを受け取るUAは、新しいカンファレン スURIを作成する必要がある(参加しているダイアログがすでにカンファレン スの一部である場合、新しいURIは不要である)。次に、カンファレンスURI は、re-INVITEまたはUPDATEを使用して、最近参加した参加者に渡される。 5.2. 参加者の追加 参加者をカンファレンスに追加するメカニズムは多数ある。 どの場合でも、参加者の追加は、ファーストパーティ(ユーザーが自身を追 加)の場合、またはサードパーティ(ユーザーが別のユーザーを追加)の場合 がある。 SIPを使用した最初の個人の追加は、自明のことだが、標準のINVITEで達成 される。参加者はINVITEリクエストをカンファレンスURIに送信することが できる。また、カンファレンスポリシーが参加者による参加を許容している 場合、参加者はカンファレンスに追加される。 UAはカンファレンスURIを知らないが、(たとえばダイアログイベントパッ ケージ[11]を使用することで、)カンファレンスに接続されているダイアロ グについては認識している場合、UAは、ダイアログに参加するJoinヘッダー を使用して、カンファレンスに参加することができる。 Rosenberg Informational [Page 14] RFC 4353 Conferencing Framework with SIP February 2006 SIPよるサードパーティの追加は、REFER [12]を使用して実施される。クライ アントはREFERリクエストを参加者に送信し、参加者に対してINVITEリクエ ストをカンファレンスURIに送信するように要求することができる。さらに、 クライアントは、REFERリクエストをフォーカスに送信し、INVITEを参加者 に送信するように要求することができる。後者の技術には、REFERメソッド に未対応のカンファレンスを意識しない参加者を、クライアントが追加でき るという利点がある。 5.3. 参加者の削除 追加と同様に、退出にもいくつかのメカニズムがある。 削除も一人称と三人称の可能性がある。 一人称の退席は、自明ではあるが、フォーカスにBYEリクエストを送信する ことで達成される。これによって、フォーカスとのダイアログが終了し、カ ンファレンスから参加者は削除される。フォーカスも、BYEを送信すること でカンファレンスから参加者を削除できる。いずれの場合でも、フォーカス はミキサとやり取りし、退出した参加者がカンファレンスメディアを受信し ないようにし、参加者からのメディアがカンファレンスにミキシングされな いようにする。 三人称の退出もSIPのREFERメソッドによって実行できる。 5.4. カンファレンスの破棄 カンファレンスは複数の方法で破棄できる。一般的に、こうした手段が特定 のカンファレンスに適用できるかどうかは、カンファレンスポリシーのポリ シーによる。 カンファレンスが破棄されると、関連付けられたカンファレンスポリシーが 破棄される。ポリシーの読み取りまたは書き込みの試みは、プロトコルエ ラーになる。さらに、カンファレンスURIは無効になる。 INVITEまたはSUBSCRIBEの送信を試みても、SIPエラー応答の結果になる。 通常、参加者がいるときにカンファレンスを破棄する場合、フォーカスはカ ンファレンスを実際に破棄する前に参加者に対してBYEを送信する。同様に、 カンファレンス通知サービスにサブスクライブしているユーザーがいた場 合、実際の破棄前に、サーバーがそのサブスクリプションを停止する。 Rosenberg Informational [Page 15] RFC 4353 Conferencing Framework with SIP February 2006 SIPにはカンファレンスを破棄する明示的な手段はない。ただし、カンファレ ンスは、カンファレンスを退出するユーザーの副産物として破棄することが できる。これは、BYEで実行できる。特に、カンファレンスポリシーで、最後 のユーザーまたは特定ユーザーが退出するとカンファレンスが破棄されると 規定している場合、そのユーザーが(SIP BYEリクエストを使用して)退出す ると、カンファレンスは破棄される。 5.5. メンバーシップ情報の取得 カンファレンスの参加者は、多くの場合、カンファレンスの他のユーザーを 知りたいと希望する。この情報は、さまざまな方法で取得できる。 カンファレンス通知サービスによって、カンファレンスを意識する参加者 はサービスにサブスクライブし、参加者リストを含む通知を受信する。新し い参加者が参加または退出すると、サブスクライバに通知される。カンファ レンス通知サービスも、最新のリストを取得するために「フェッチ」[4]を 実行することができる。 5.6. メディアの追加と削除 各カンファレンスは、フォーカスが管理しているメディア群で構成される。 たとえば、カンファレンスにはビデオストリームと音声ストリームが含まれ る場合がある。カンファレンスを構成するメディアストリーム群は、参加者 が変更できる。カンファレンスのメディア群が変化すると、各参加者に対し てそのメディアストリームを追加/削除するために、フォーカスは各参加者 にre-INVITEを生成する必要がある。メディアストリームを追加するときに、 参加者は提供されたメディアストリームを拒否できる。この場合、その参加 者はそのストリームを送受信しなくなる。参加者がストリームを拒否して も、ストリームがカンファレンスの一部ではなくなったわけではなく、その 参照のみが関与しなくなっただけである。 SIP re-INVITEは、メディアストリームの追加/削除を行うために参加者が使 用することもできる。この場合、メディアストリームをセッションに追加す る標準的なオファー/アンサー技術が使用される[13]。これはフォーカス自 身がre-INVITEを生成するトリガとなる。 5.7. カンファレンスの宣言と記録 多くの場合、カンファレンスの宣言と記録は、実際のカンファレンスシステ ムで重要な役割を果たす。たとえば、以下のような機能である。 o 点呼に対応するために、ユーザーがカンファレンスに参加する前に名前 を名乗るようにユーザーに求める。 Rosenberg Informational [Page 16] RFC 4353 Conferencing Framework with SIP February 2006 o ユーザーが他に誰がカンファレンスに参加しているかを認識できるよ うに、ユーザーが点呼を要求することを許可する。 o ユーザーがキーパッドの何らかのキーを押して、カンファレンスを記録 することを許可する。 o ユーザーがキーパッドの何らかのキーを押して、人間のオペレータに接 続することを許可する。 o ユーザーがキーパッドの何らかのキーを押して、回線をミュート/ミュー ト解除することを許可する。 User 1 +-----------+ | | | | |Participant| | 1 | | | +-----------+ |SIP |Dialog Conference |1 Policy +---|--------+ User 2 Server | | | Application +-----------+ +-----------+ | non-SIP ************* | | | | |-------- * * | | | | | * * |Participant|-----------| Focus |------------*Participant* | 2 | SIP | | | SIP * 4 * | | Dialog | |--+ Dialog * * +-----------+ 2 +-----------+ 4 ************* | | |SIP |Dialog |3 | +-----------+ | | | | |Participant| | 3 | | | +-----------+ User 3 図3 Rosenberg Informational [Page 17] RFC 4353 Conferencing Framework with SIP February 2006 このフレームワークでは、各機能はカンファレンスの参加者として動作する アプリケーションとしてモデリングされている。これについては図3に示す。 このカンファレンスには4人の参加者がいる。 参加者のうち3人はエンドユーザーであり、4つめは宣言アプリケーションで ある。 宣言アプリケーションが全カンファレンスメンバーに対して宣言を再生する には(たとえば、参加の宣言)、他の参加者と同様に、ミキサーに対してメ ディアを送信するだけである。宣言は会話にミキシングされ、参加者に対し て再生される。 同様に、生成するメディアが対象ユーザーにのみ聞こえるようにするカン ファレンスポリシーを設定することで、宣言アプリケーションは特定のユー ザーに対して宣言を再生できる。次にアプリケーションは目的の宣言を生成 すると、選択した受信者のみに宣言が聞こえる。 宣言アプリケーションは、カンファレンス経由で特定ユーザーからの入力を 受信することもできる。この場合、アプリケーション対話フレームワーク[6] を利用できる。このフレームワークによって、(キーパッド刺激などの方法 で)ユーザーの入力を収集し、何らかの行動を取る。 6. 物理的認識 このセクションでは、多様な問題を解決するために基本的な機能を組み合わ せる方法がわかるように、各ポリシーの物理的なインスタンス化について説 明する。 6.1. 中央サーバー このフレームワークの最も単純な実現方法では、ネットワークに単一の物理 サーバーがあり、そのサーバーがフォーカス、カンファレンスポリシーサー バー、およびミキサーを実装している。図4に示すように、これは伝統的な 「ワンボックス」ソリューションである。 Rosenberg Informational [Page 18] RFC 4353 Conferencing Framework with SIP February 2006 Conference Server ................................... . . . +------------+ . . | Conference | . . |Notification| . . | Server | . . +------------+ . . +----------+ . . |Conference| +-----+ . . | Policy | +-------+ +-----+| . . | Server | | Focus | |Mixer|+ . . +----------+ +-------+ +-----+ . ................//.\.....***....... // \ *** * // *** * RTP SIP // *** \ * // *** \SIP * // *** RTP \ * / ** \ * +-----------+ +-----------+ |Participant| |Participant| +-----------+ +-----------+ 図4 6.2. エンドポイントサーバー もうひとつの重要なモデルは、ローカルでミキシングされたアドホックカン ファレンスのモデルである。このシナリオでは、2人のユーザー(AとB)が通常 のポイント間通話に参加している。参加者の1人(A)は、第3の参加者Cをカン ファレンスに参加させようと決定する。そのために、Aはフォーカスとして 動作し始める。Bとの既存のダイアログは、フォーカスに帰属する第1ダイア ログになる。AはそのダイアログでBをre-INVITEし、フォーカスを識別する 新しい値にContact URIを変更する。要するに、Aは単一ユーザーUAから フォーカス + 単一ユーザーUAに「突然変異」し、その変異の仮定で、Aの URIが変化する。次に、フォーカスはINVITEをCに対して送信する。Cが受け 入れると、AはBとCからのメディアをミキシングし、その結果を再配信する。 ミキシングされたメディアはローカルでも再生される。図5は、この遷移を 示している。 Rosenberg Informational [Page 19] RFC 4353 Conferencing Framework with SIP February 2006 B B +------+ +------+ | | | | | UA | | UA | | | | | +------+ +------+ | . | . | . | . | . | . | . Transition | . | . ------------> | . SIP| .RTP SIP| .RTP | . | . | . | . | . | . | . | . | . +----------+ +------+ | +------+ | SIP +------+ | | | |Focus | |----------| | | UA | | |C.Pol.| | | UA | | | | |Mixers| |..........| | +------+ | | | | RTP +------+ | +------+ | A | + | C | + <..|....... | + | . | +------+ | . | |Parti-| | . | |cipant| | . | | | | . | +------+ | . +----------+ . A . . Internal Interface 図5 このモデルの外部インターフェース(AとB間、BとC間)は、中央サーバーモデ ルで使用されるインターフェースとまったく同じであることに注意。ユー ザーAは、カンファレンスポリシーとカンファレンス通知サービスも実装し ているため、参加者は必要に応じてアクセスすることができる。フォーカス が参加者と同居しているからと言って、動作や外部インターフェースの側面 が変わる訳ではない。 Rosenberg Informational [Page 20] RFC 4353 Conferencing Framework with SIP February 2006 6.3. メディアサーバーコンポーネント +------------+ +------------+ | App Server| SIP |Conf. Cmpnt.| | |-------------| | | Focus | non-SIP | Focus | | C.Pol |-------------| C.Pol | | | | Mixers | |Notification| | | | | | | +------------+ +------------+ | \ .. . | \\ RTP... . | \\ .. . | SIP \\ ... . SIP | \\ ... .RTP | ..\ . | ... \\ . | ... \\ . | .. \\ . | ... \\ . | .. \ . +-----------+ +-----------+ |Participant| |Participant| +-----------+ +-----------+ 図6 図6に示すこのモデルでは、各カンファレンスが2つの中央サーバーを含んで いる。各サーバーの1つは、「アプリケーションサーバー」と呼ばれ、メン バーシップとメディアポリシーを所有および管理し、各参加者とのダイアロ グを保守している。結果として、カンファレンスの全参加者からは、その サーバーがフォーカスであるように見える。ただし、このサーバーはメディ アサポートを何も実行していない。実際のメディアミキシング機能を実行す るには、第2サーバーを利用する。これは「ミキシングサーバー」と呼ばれ る。このサーバーはフォーカスを含み、カンファレンスポリシーを実装す るが、カンファレンス通知サービスを持っていない。このサーバーのカン ファレンスポリシーは、トップレベルのフォーカスから送信された全招待は 受け入れることである。必要に応じて、アプリケーションサーバーのフォー カスはサードパーティ呼制御を使用し、各ユーザーのメディアストリームを ミキシングサーバーに接続する。アプリケーションサーバーのフォーカスが カンファレンスポリシーの制御コマンドをクライアントから受信した場合、 同じメディアポリシーの制御コマンドを発行することで、ミキシングサー バーに委任する。 Rosenberg Informational [Page 21] RFC 4353 Conferencing Framework with SIP February 2006 このモデルは、ミキシングサーバーが、さまざまなカンファレンスアプリ ケーションのリソースとして使用されることを考慮している。これは、カン ファレンスアプリケーションはカンファレンスポリシーを意識していないた めである。カンファレンスアプリケーションは、トップレベルサーバーの 「スレーブ」になることはほとんどなく、必要に応じて何でも実行する。 6.4. 分散型ミキシング 分散型ミキシングカンファレンスでも、フォーカスを実装する中央サー バー、カンファレンスポリシーサーバー、メディアポリシーサーバーがあ る。ただし、中央管理ミキサーはない。その代わり、各エンドポイントには ミキサーとカンファレンスポリシーサーバーがある。フォーカスは、サー ドパーティ呼制御[14]を使用して各参加者間でメディアストリームを移動す ることで、メディアを配信する。その結果、カンファレンスにN人の参加者 がいる場合、各参加者とフォーカス間に単一のダイアログがあるが、そのダ イアログに関連付けられたセッション記述は、メディアが全参加者に配信さ れるように構築される。これについて、図7に示す。 Rosenberg Informational [Page 22] RFC 4353 Conferencing Framework with SIP February 2006 +---------+ |Partcpnt | media | | media ...............| |.................. . | Mixers | . . |C.Pol.Srv| . . +---------+ . . | . . | . . | . . dialog | . . | . . | . . | . . +---------+ . . |Cnf.Srvr.| . . | | . . | Focus | . . |C.Pol.Srv| . . / | | \ . . / +---------+ \ . . / \ . . / \ . . / dialog \ . . / \ . . /dialog \ . . / \ . . / \ . . / \ . . . +---------+ +---------+ |Partcpnt | |Partcpnt | | | | | | | ......................... | | | Mixers | | Mixers | |C.Pol.Srv| media |C.Pol.Srv| +---------+ +---------+ 図7 ミキシングのためにメディアを各参加者に配信する方法はいくつかある。マ ルチキャストモデルでは、各参加者はメディアのコピーを各参加者に送信す る。この場合、セッション記述はN-1個のメディアストリームを管理する。 マルチキャストモデルでは、各参加者は共通のマルチキャストグループに参 加し、各参加者はメディアストリームの単一コピーをそのグループに送信 する。基礎となるマルチキャストインフラストラクチャは、各参加者がメ ディアのコピーを取得できるように、そのメディアを配信する。単一ソース Rosenberg Informational [Page 23] RFC 4353 Conferencing Framework with SIP February 2006 マルチキャストモデル(single-source multicast model/SSM)では、各参加 者はユニキャストを使用して中央ポイントにメディアストリームを送信す る。中央ポイントは、マルチキャストを使用して、全参加者にメディアを再 配信する。フォーカスには、メディア配信の様式を選択し、混合機能ととも にクライアントから必要とされる合成を処理する責任がある。 新しい参加者が参加するか、追加されると、フォーカスは必要なサードパー ティ呼制御を実行して、新しい参加者からのメディアを他の全参加者へ配信 し、またその反対方向も配信する。 中央カンファレンスサーバーも、カンファレンスポリシーに対するインター フェースを公開する。当然ながら、中央カンファレンスサーバーは、メディ ア操作またはメディアポリシーを直接実装できない。その代わり、実装を各 参加者に委任する。たとえば、ある参加者は、全体のカンファレンスモード を「音声をアクティブ化」から「継続的プレゼンス」に切り替える場合、中 央カンファレンスポリシーサーバーと通信する。次に、カンファレンスポ リシーサーバーは、何らかの非SIP固有のメカニズムを使用して、各参加者 に同居しているカンファレンスポリシーサーバーと通信し、「継続的プレゼ ンス」を使用するように指示する。 このモデルは、ユーザーエージェントの追加機能を(そのような機能の有無 にかかわらず)要求する。したがって、参加者は、フォーカスにこの機能を 通知できなる必要がある。 6.5. カスケード型ミキサー 非常に大規模なカンファレンスの場合、全メディアを処理できる単一のミ キサーを用意するのは不可能な場合がある。この問題を解決するには、カ スケード型ミキサーを使用する。このアーキテクチャでは、中央フォーカス はあるが、ミキシング機能は複数のミキサーが実装している。各ミキサーは ネットワークの各所に分散している。各参加者はミキサーの1つにのみ接続 する。フォーカスは何らかの制御プロトコルを使用して各ミキサーを接続 し、全参加者が互いの音声を聞き取れるようにする。 このアーキテクチャを図8に示す。 Rosenberg Informational [Page 24] RFC 4353 Conferencing Framework with SIP February 2006 +---------+ +-----------------------| |------------------------+ | ++++++++++++++++++++| |++++++++++++++++++ | | + +------| Focus |---------+ + | | + | | | | + | | + | +-| |--+ | + | | + | | +---------+ | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | +---------+ | | + | | + | | | | | | + | | + | | | Mixer 2 | | | + | | + | | | | | | + | | + | | +---------+ | | + | | + | |... . .... | | + | | + .|....| . .|.... | + | | + ...... | | . | ..|... + | | + ... | | . | | ....+ | | +---------+ | | +---------+ | | +---------+ | | | | | | | | | | | | | | | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | | | | | | | | | | | | | | | +---------+ | | +---------+ | | +---------+ | | . . | | . . | | . . | | . . | | .. . | | .. . | | . . | | . . | | . . | +---------+ . | +---------+ . | +---------+ . | | Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . | | 1 | . | | 3 | . | | 5 | . | +---------+ . | +---------+ . | +---------+ . | . | . | . | +---------+ +---------+ +---------+ | Prtcpnt | | Prtcpnt | | Prtcpnt | | 2 | | 4 | | 6 | +---------+ +---------+ +---------+ ------- SIPダイアログ ....... メディアフロー +++++++ 呼制御 図8 Rosenberg Informational [Page 25] RFC 4353 Conferencing Framework with SIP February 2006 7. セキュリティの考慮事項 多くの場合、カンファレンスを適切に操作するために、セキュリティ機能が 必要である。カンファレンスポリシーで、特定の参加者のみが参加できる こと、または特定の参加者が新しいポリシーを作成できることを規定するこ とがある。一般的に、カンファレンスアプリケーションは、認可の決定に大 きく関与している。このような認可規則の確立と実施を行うメカニズムを持 つことは、本文書全体の中心的な概念である。 当然ながら、認可規則には認証が必要である。ここで説明するカンファレン スの認可メカニズムには、通常のSIP認証メカニズムで十分である。 プライバシはカンファレンスの重要な側面である。ユーザーは、無言で聞く だけで、自分が参加したことを他の参加者に知られたくない場合がある。他 のアプリケーションの例では、ある参加者は自分の身元を他の参加者に隠す が、プレゼンスは通知する。このような機能は、カンファレンスシステムが 提供する必要がある。 8. 寄稿者 本文書は、カンファレンス設計チーム内の議論から作成された。チームのメ ンバーは以下のとおり。 Alan Johnston Brian Rosen Rohan Mahy Henning Schulzrinne Orit Levin Roni Even Tom Taylor Petri Koskelainen Nermeen Ismail Andy Zmolek Joerg Ott Dan Petrie 9. 謝辞 Mary Barnes、Chris Boulton、Rohan Mahyからいただいたコメントに感謝を 述べたい。Allison Mankinには、コメントと本文書の支援に感謝したい。 Rosenberg Informational [Page 26] RFC 4353 Conferencing Framework with SIP February 2006 10. 有益な参考文献 [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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Campbell, B., "The Message Session Relay Protocol", Work In Progress, October 2004. [6] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work In Progress, February 2005. [7] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", Work in Progress, February 2005. [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Rosenberg Informational [Page 27] RFC 4353 Conferencing Framework with SIP February 2006 [14] 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. [15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. 著者の連絡先 Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Informational [Page 28] RFC 4353 Conferencing Framework with SIP February 2006 完全な著作権表記 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情 報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Rosenberg Informational [Page 29]