VTVジャパン　テレビ会議教科書

テレビ会議教科書　VTVジャパン株式会社

8.1.5 デュアルビデオ制御

1) 背景

 ビジネスや学会などでの発表場面では，古くは，トランスペアレンシーとかOHPフィルムとか呼ばれる透明なフィルムに発表内容を書いたり印刷したりして，OHP（オーバーヘッドプロジェクタ, overhead projector）で投射することが行われていました．しかしPCとスライド作成ソフトの普及とともに，1990年代には図8-12 a)で示しますようにPCの画面内容を液晶プロジェクタで投射することが広まり（注），PCとプロジェクタとの接続も1990年代後半には安定してきました．

（注）エプソンブランド初の液晶プロジェクタが1989年1月に発表されています[8-31]．

 テレビ会議においてもプレゼンテーションに際し，図8-12 b)で示しますような構成で遠隔地にその画面を送りたいとのニーズが認識されました．2000年代初めにはテレビ会議装置メーカ独自の方法が現れ始めて，参加者像を写すと同時に遠隔からのPC画面を表示する方法に対する標準化の機運が高まったのです[8-32]．

図8-12 会議におけるPC利用プレゼンテーション
図8-12 会議におけるPC利用プレゼンテーション

a)は会議室内でのプレゼンテーションで，PCとプロジェクタが直結されています．b)は，テレビ会議システムを利用した会議において遠隔会議室にもプレゼンテーション画面が届けられ表示されます．a)のPC・プロジェクタ間インタフェースにテレビ会議システムが割って入った形です．なおこの図では"Main" videoを片方向のみ表していますが，実際には逆方向にも同じように"Main" videoは存在します．しかし"Presentation" videoの方は片方向に流れます．

2) H.320およびH.323システムで2チャネルの映像を送るための標準H.239

 勧告ITU-T H.239[8-33]は，テレビ会議中にPC画面を表示してプレゼンテーションを行うなど，通常の会議参加者の様子を伝える映像（主映像）に加えて，もう一つの映像（追加映像）を送るための手順を定めています．ISDN上のテレビ会議システムH.320とIP網上のシステムH.323の双方を対象に，また1対1接続の場合だけでなくMCUを介したマルチポイント接続の場合も規定しています．

 この勧告の草案はTandberg社とPolycom社共同で2002年から2003年にかけて作成され，勧告初版は2003年7月に成立しました．それ以前は同一ベンダによるテレビ会議システムでしかできなかったPCによるプレゼンテーションが，異なるベンダのテレビ会議製品間でも可能になりました．

 勧告H.239の原題は"Role management and additional media channels for H.300-series terminals"で，現行版は2014年10月に改訂されたものです．そこには次の項目の仕様が記述されています．

  • H.239能力交換方法
  • C&I（Control and Indication）信号
  • H.245論理チャネル開設
  • チャネルのRole（役割）付与の原則と手順
  • トークン（送信権）の管理
  • H.320システム信号とH.323システム信号の変換
  • H.320システムにおける追加映像チャネルのビット位置

① H.239能力

 H.239能力は第8.1.2項で説明しましたジェネリック・ケイパビリティの形式を取り，H.239サポートはH.245 h239ControlCapabilityメッセージで表されます．これにはflowControlReleaseRequest とflowControlReleaseResponseメッセージのサポートを含みます．追加チャネルの映像能力はH.245 h239ExtendedVideoCapabilityメッセージで表されます．

 H.320システムでは，対応するH.221 BASコードがH.230に定義されています．

 H.245メッセージとH.230コード両者の対応関係は，H.239 Annex Aに記されています．

② Roleと Label

 追加映像チャネルの役割を表すのがroleで，それを受信側に伝える信号がrole labelです．受信側ではrole labelによりチャネル内容を理解し，またそれによってあらかじめ定められた方法に従い追加映像をユーザに提示します．

③ 追加映像の提示手順

 H.239では，次の2種類のroleを規定しています．

  • Live role -- 通常の方法で提示される映像を示し，参加者を撮して主映像の補助をします．双方向の伝送が行われ，複数端末が同時にこのroleで送信可能です．
  • Presentation role -- トークン（送信権）管理をして，一つの端末からのみ全参加者が見るべきコンテンツ映像をすべての端末に配信します．映像の流れは片方向で，PC画面を用いたプレゼンテーションが該当し，この映像が受信されると最優先で表示されます．

 最初にLive role手順を説明します．MCUでの手順と端末での手順があります．

 MCUの手順では，ある端末からのLive role映像は，その主映像と同じ宛先に送られます．どの端末にどの映像を送るかは，標準では規定されずMCUの設計に従って決まります．どの端末からの映像であるかはその端末番号を示すH.245会議表示信号（terminalYouAreSeeing，H.320システムではH.230 VIN）で伝えられます．VINはVideo Indicate Numberを意味します．

 端末での手順では，Live role映像を送るには，そのための論理チャネルを開設し，H.245送信開始表示信号（logicalChannelActive，H.320システムではH.230 VIA, VIA2）を送って，ストリームを送出します．VIAはVideo Indicate Activeを意味します．

 次にPresentation role手順を説明します．こちらも，MCUでの手順と端末での手順があります．

 MCUでの手順では，ある端末からのPresentation role映像は，MCUにより会議参加の全端末に送られます．またMCUは次に述べるトークン管理を行って，トークンを認めたり，場合によっては取り消したりします．どの端末がプレゼンテーションを行っているかは，その端末番号を示すH.245会議表示信号（terminalYouAreSeeing，H.320システムではH.230 VIN）によって受信端末に伝えられます．

 端末での手順では，プレゼンテーションを行う端末は，まずトークンを取得し，論理チャネルを開設，H.245送信開始表示信号（logicalChannelActive，H.320システムではH.230 VIA, VIA2）を送って，ストリームを送出します．プレゼンテーションを終了するときは，H.245送信停止表示信号（logicalChannelInactive，H.320システムではH.230 VIS）を送って，ストリーム送信を停止し，必要に応じ論理チャネルを閉鎖します．またトークンは返却しなければなりません．VISはVideo Indicate Suppressedを意味します．

④ トークン管理

 端末におけるトークンの取得，返却は次のように行われます．

  • トークンを保有していなくてプレゼンテーションを開始したい場合

    •  H.245 presentationTokenRequestメッセージを送出します．presentationTokenResponse(acknowledge)メッセージを受信すると，トークンの保有が確定します．その結果が得られるまでに他の端末からpresentationTokenRequestメッセージを受けた場合，すなわちトークン要求が衝突した場合，メッセージ中のsymmetryBreakingパラメータが示すランダム数字の大小でじゃんけんを行ってrequestを取りやめるか，再要求するか，あるいは他端末の要求を拒否するかします．

  • トークンを保有していて，それを返却したい場合

    •  H.245 presentationTokenReleaseメッセージを送出します．

  • トークンを保有していて，それを継続したい場合

    •  H.245 presentationTokenIndicateOwnerメッセージを周期的に送出します．もし，他の端末からpresentationTokenRequestメッセージを受信したら，トークンを諦めてpresentationTokenResponse(acknowledge)を返します．

  • トークンを保有していなくて，プレゼンテーションも行わない場合

    •  他端末からのH.245 presentationTokenRequestメッセージを受信すると，presentationTokenResponse(acknowledge)を返して，トークンを認めます．

     MCUでは，端末からのトークンを中継しながら，どの端末がトークンを保有するかを制御します．MCUが自らトークンを保有することはありません．その具体的方法は設計依存とされています．ただし，その場合でも上述した端末のふるまいを前提にしなければなりません．従って，以下の規定は，標準上は必須ではなく推奨の扱いです．

 Master MCUでのトークン処理は次の通りです．

  • 会議の最初はどの端末もトークンを保有していません．
  • 何らかの理由でMCUが認識していないH.245 presentationTokenIndicateOwnerメッセージを受けると，その端末にpresentationTokenRequestメッセージを送ってトークンの返却をうながします．
  • ある端末AからpresentationTokenRequestメッセージを受信すると，MCUはsymmetryBreaking値を0に変えて，他端末に中継します．
  • その結果他の端末からの応答がすべてpresentationTokenResponse(acknowledge)であれば，MCUは端末AにpresentationTokenResponse(acknowledge)を返し，端末Aのトークン保有が確定します．MCUからは，どの端末がトークンを保有しているかをpresentationTokenIndicateOwnerメッセージで他の端末に周知します．
  • もし端末BもpresentationTokenRequestメッセージを送ったところであれば，MCU経由で受信した端末AのsymmetryBreaking値が0なので，端末Bがじゃんけんに勝つことになり，presentationTokenResponse(reject)メッセージをMCUに返します．そうするとMCUは端末Aと端末B二つのpresentationTokenRequestメッセージを受けた状態になり，どちらを拒否するかはMCUの設計によります．
  • いずれかの端末がトークン保有中にMCUが別の端末からpresentationTokenRequestメッセージを受信すると，もとの保有者に転送して，トークンを譲渡させます．

 また，Slave MCUでのトークン処理は次の通りです．

  • 配下の端末あるいはSlave MCUから送られてきたメッセージは，Master MCUに中継します．
  • Master MCUからのメッセージは，そこに含まれるterminalLabelパラメータで転送先を決定します．

⑤ 追加映像の伝送方法

 H.320システムでは，ビット多重の方法でマルチメディア多重が行われていて，従来の主映像の場合，他の音声信号，データ信号，制御信号が占めていないビット位置は全て映像で埋めて送るのが，H.221の定める規則です．しかし，H.221には追加映像チャネルの規定は存在しませんので，H.239 Annex Bで新たに追加映像チャネルの送り方が規定され，具体的には何本の8 kbit/sサブチャネルを用いるかのコマンドを送って，追加映像チャネルのビット位置を示し，音声，データ，制御，追加映像以外の残りのビット位置は，従来通り主映像チャネルに割り当てられます．

 H.323システムでは，もともと複数のメディアチャネルを別々のRTPチャネルで送ることが規定されていて，追加映像の伝送に新たな規定は必要ないため，H.239では記述がありません．ただし，論理チャネル開設時のRTP sessionID値は，H.323で1（音声）, 2（映像）, 3（データ）が固定的に決められているため，追加映像チャネルでは動的に4以上の値を設定しなければなりません．

⑥ H.239制御にかかわるH.245メッセージの例

 テレビ会議の実施中に記録したWiresharkデータから，追加映像の動作に関わるパケットを抽出して図8-13に示します．特に追加チャネルで使用する映像符号化のジェネリック・ケイパビリティとroleLabelの規定を図8-14に示します．

図8-13 プレゼンテーション開始から終了までのパケット記録例
図8-13 プレゼンテーション開始から終了までのパケット記録例

IPアドレス202.32.143.189の端末を210.148.19.7の相手と接続し，H.239プレゼンテーションを繰り返して試験したときの記録です．ここにはプレゼンテーションに関わるH.245の通信制御パケットに加え．メディア情報を送るRTPパケット，呼制御を実行するH.225.0パケットも抽出しています．H.239トークン管理が本文で記述したように行われていることが確認できます．なお，開設される論理チャネルの記述には，対応する能力メッセージが用いられます．ここでは映像符号化にH.263を用いていますが，テレビ会議端末装置は通常DSPで実装され，処理能力の制限からメインの映像にはH.264が，プレゼンテーション映像にはH.263が選択されていました．

図8-14 H.263復号能力（Dual VideoのPresentation映像）
図8-14 H.263復号能力（Dual VideoのPresentation映像）

ジェネリック・ケイパビリティ形式による能力表示です．H.239プレゼンテーションのためにcustomPictureFormatとしてXGA（1024画素x768画素，フレームレートは最大5フレーム/秒）が設定されています．論理チャネル開設には通常対応する能力表示が用いられますが，roleLabelの項は，能力では保有する機能の両方（LiveとPresentation）が示され，論理チャネル開設時はいずれかのみ（今の場合Presentation）となります．

3) SIPシステムにおけるデュアルビデオ制御

 H.323システムにおけるH.239デュアルビデオ制御と同様の機能を，SIPシステムではRFC 4582[8-34]が規定するBFCP (Binary Floor Control Protocol)で行うことが想定されています．デュアルビデオ制御の全体像は，IMTC (International Multimedia Telecommunications Consortium)[8-35]のBest Practices文書が記述しています．

 IMTCは相互接続試験の場を提供するInteropイベントを中心に，マルチメディアサービスの普及を目的とした活動を展開しているコンソーシアムです．標準化機関ではありませんが，活動の一部としてH.323システムとSIP制御テレビ会議システムの相互接続性に資するBest Practicesを整理して発行しています．現時点で発行済みなのは，H.323システムとSIPシステムがゲートウェイを介して相互接続しやすくするための基本的なテレビ会議音声，映像パラメータなどをまとめた"SIP Video Profile Best Practices"[8-36]です．

 同じようにPC画面の伝送について，H.239の方法と調和した制御のBest Practicesを作業中です．2011年7月時点の草案は，"Best Practices for Role-Based Video Streams (RBVS) in SIP"[8-37]と題されています．技術的にはRFC 4582を利用してH.239相当の画面共有制御を実現しようとしています．ただし，RFC 4582では伝送チャネルにTCPが規定されているのですが，TCPはNAT/Firewall越えに難があることから，IMTC文書ではUDPでBFCPメッセージを送ることとなっています．UDP伝送も規定するRFC 4582の改訂版が作業中で2016年5月現在Internet Draft第16版が検討されています．この完成を待って，IMTC文書が発行される予定です．

 IMTC Best Practices文書草案では，デュアルビデオ制御に関し，H.323システムとSIPシステムの間で図8-15の対応関係が記されています．ここでSIPシステムのrole表示にはRFC 4796[8-38]が参照されています．SDPメッセージ"a=content"行のパラメータとして"slides", "speaker", "sl" (sign language, "main", "alt" (alternate)を表示する規定です．

図8-15 H.323システムとSIPシステムのデュアルビデオ制御
図8-15 H.323システムとSIPシステムのデュアルビデオ制御

両システムにおける対応関係を示します．a)はデュアルビデオ制御方法について，b)はトークン制御メッセージについて，マッピングを示しています．デュアルビデオ制御の主たる規定はH.323システムではH.239，SIPシステムではBFCPですが，その他周辺のH.245やオファー・アンサー・モデル規定も必要になります．