(57)【特許請求の範囲】
【請求項１】
自側端末が相手側端末へ送信するカメラ映像の品質を自側端末において評価する方法において、
自側端末のWebブラウザが主導して、相手側端末のWebブラウザとの間にWebRTCによる第１リアルタイム映像通信路を確立する手順と、
自側端末のWebブラウザから相手側端末のWebブラウザへ前記第１リアルタイム映像通信路でカメラ映像を送信する手順と、
前記カメラ映像を受信した相手側端末のWebブラウザが主導して、自側端末のWebブラウザとの間にWebRTCによる第２リアルタイム映像通信路を確立する手順と、
相手側端末のWebブラウザから自側端末のWebブラウザへ前記受信したカメラ映像を前記第２リアルタイム映像通信路で折返し送信する手順と、
自側端末のWebブラウザが前記折返し送信されたカメラ映像を表示する手順とを含むことを特徴とするリアルタイム映像通信の品質評価方法。
【請求項２】
自側端末のWebブラウザは、前記送信したカメラ映像を前記折返し送信されたカメラ映像と共に表示することを特徴とする請求項１に記載のリアルタイム映像通信の品質評価方法。
【請求項３】
自側端末が前記送信したカメラ映像および折返し送信されたカメラ映像の品質統計情報を取得する手順を更に含み、
前記自側端末のWebブラウザは、前記各品質統計情報を前記送信したカメラ映像および折返し送信されたカメラ映像と共に表示することを特徴とする請求項２に記載のリアルタイム映像通信の品質評価方法。
【請求項４】
自側端末が相手側端末へ送信するカメラ映像の品質を自側端末において評価するシステムにおいて、
自側端末のWebブラウザが、
相手側端末のWebブラウザとの間にWebRTCによる第１リアルタイム映像通信路を確立する手段と、
前記第１リアルタイム映像通信路でカメラ映像を送信する手段とを具備し、
相手側端末のWebブラウザが
自側端末のWebブラウザとの間にWebRTCによる第２リアルタイム映像通信路を確立する手段と、
受信したカメラ映像を前記第２リアルタイム映像通信路で折返し送信する手段とを具備し、
前記自側端末のWebブラウザがさらに、
前記折返し送信されたカメラ映像を受信して表示する手段を具備したことを特徴とするリアルタイム映像通信の品質評価システム。
【請求項５】
前記カメラ映像を表示する手段は、前記送信したカメラ映像を前記折返し送信されたカメラ映像と共に表示することを特徴とする請求項４に記載のリアルタイム映像通信の品質評価システム。
【請求項６】
前記自側端末が前記送信したカメラ映像および折返し送信されたカメラ映像の品質統計情報を取得する手段を更に具備し、
前記自側端末のWebブラウザは、前記各品質統計情報を前記送信したカメラ映像および折返し送信されたカメラ映像と共に表示することを特徴とする請求項５に記載のリアルタイム映像通信の品質評価システム。
【請求項７】
前記自側端末が前記カメラ映像を生成するカメラを具備したことを特徴とする請求項４ないし６のいずれかに記載のリアルタイム映像通信の品質評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイム映像通信の品質評価方法およびシステムに係り、特に、WebRTCによるリアルタイム映像通信の品質評価に好適な品質評価方法およびシステムに関する。
【背景技術】
【０００２】
従来、PC、スマートフォンあるいはタブレット等の情報端末を利用してビデオ通話を行うには、端末に専用のソフトウェアを別途にインストールする必要があったため、情報端末の操作に慣れていないユーザにとっては導入の敷居が高かった。
【０００３】
しかしながら、近年、Webブラウザだけで手軽に音声や映像のリアルタイム映像通信を行えるようにする技術として、WebRTC（Web Real-Time Communication）が注目されており、例えば非特許文献１，２に開示されている。
【０００４】
WebRTCは、Webブラウザでリアルタイムなコミュニケーションを可能にするAPIであり、通常、Webブラウザは最初からPCやスマートフォンにインストールされているため、ユーザは新たにインストールする必要はない。また、WebRTCによれば、PCやスマートフォン、タブレット端末に接続もしくは内蔵されたマイクやカメラなどのデバイスにJavaScript(登録商標) API経由でアクセスできる。
【０００５】
このため、ユーザは図６に示したように、WebRTCサービスを記述するJavaScript(登録商標)を含むWebページにアクセスするだけで、WebRTC技術を利用したビデオ通話等のリアルタイム映像通信サービスを実行することができる。
【０００６】
WebRTCの標準規格は、ブラウザ対応API（主にJavaScript(登録商標)で実現）はW3C（World Wide Web Consortium）、ブラウザ間の通信プロトコルはIETF（Internet Engineering Task Force）にて策定されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2014-90364号公報
【非特許文献】
【０００８】
【非特許文献１】WebRTC 1.0: Real-time Communication Between Browsers [http://www.w3.org/TR/webrtc/]
【非特許文献２】Rtcweb Status Pages [http://tools.ietf.org/wg/rtcweb/]
【発明の概要】
【発明が解決しようとする課題】
【０００９】
WebRTCに限らず、ユーザが一般的なビデオ通話サービスやアプリケーションを利用する際は、予め接続確認や映像送受信等のテストを実施することが多い。例えば、一般的なテスト項目として、(1) 発信テスト（自身発で相手とのコネクションを確立できるか）、(2) 着信テスト（相手からの発信を受け入れて、相手とのコネクションを確立できるか）、(3) 映像送信テスト（確立したコネクション上で相手に適切な品質で映像を送信できるか）、(4) 映像受信テスト（確立したコネクション上で、相手からの映像を適切な品質で受信できるか）、などがある。
【００１０】
そして、上記一連のテストを通じて、接続や映像品質の確認、テストがうまく行かない場合は障害切り分けが行われる。ここで、上記(2)の着信テストを実施するには、一般的には相手側端末において人による発信操作が必要なため、上記一連のテストを実施する際、相手側端末を管理する相手とのスケジュール調整や、相手側端末を監視、操作する人の手配等が必要となり、確認までに時間と手間がかかる。
【００１１】
特許文献１には、一つの拠点のみで伝送端末の映像の接続確認を可能とする技術が開示されている。この技術によれば、相手との調整等は必要なく、送信者のみでテストを実施することができる。
【００１２】
しかしながら、特許文献１はネットワークに設置された中継装置を経由して映像を伝送する形態を前提としており、P2Pのように、送受信端末間で中継装置を介さずに直接映像を送受信する形態は想定していない。
【００１３】
また、特許文献１による映像送受信テストにおいては、発着信端末は同一の端末であり、映像は自側端末から中継装置でループバックされて自側端末に戻る形となる。このため、実際の通信相手となる相手側端末からの接続確認や、相手側端末から受信する映像の品質を確認することはできない。
【００１４】
本発明の目的は、上記の技術課題を解決し、ビデオ通話における映像通信テストの際に、上記(1)〜(4)の各テストを相手側との調整を必要とすることなく、自側の操作のみで簡易に実施できるようにすることにある。
【００１５】
特に、WebRTC技術を利用することで、ユーザが端末の更新やソフトウェアアップデート等を自ら実施する必要がなく、また端末に自動アップデート機能を備える必要もなく、Webサーバから呼び出されるJavaScript(登録商標)を変更するだけで上記の技術課題を解決することを目的とする。
【課題を解決するための手段】
【００１６】
上記の目的を達成するために、本発明は、自側端末が相手側端末へ送信するカメラ映像の品質を自側端末において評価する方法において、以下の構成を具備した点に特徴がある。
【００１７】
(1) 自側端末のWebブラウザが主導して相手側端末のWebブラウザとの間に第１リアルタイム映像通信路を確立し、カメラ映像を送信する手順と、カメラ映像を受信した相手側端末のWebブラウザが主導して自側端末のWebブラウザとの間に第２リアルタイム映像通信路を確立し、前記受信したカメラ映像を折返し送信する手順と、自側端末のWebブラウザが前記折返し送信されたカメラ映像を受信して表示する手順とを含むようにした。
【００１８】
(2) 自側端末のWebブラウザは、送信したカメラ映像および折返し送信されたカメラ映像を表示するようにした。
【００１９】
(3) 自側端末は、送信したカメラ映像および折返し送信されたカメラ映像の品質統計情報を取得し、各品質統計情報をカメラ映像と共に表示するようにした。
【発明の効果】
【００２０】
本発明によれば、以下のような効果が達成される。
【００２１】
(1) WebRTC技術を利用した映像通信において、自側端末が送信したカメラ映像を受信した相手側端末は、これを自側端末に自動で折り返し送信するので、自側端末では、相手側端末におけるカメラ映像の再生状態を相手側端末でのユーザ操作なし確認することができる。したがって、リアルタイム映像通信の品質評価を相手側との調整不要かつ手軽に実施できるようになる。
【００２２】
(2) 自側端末では、折返し送信されたカメラ映像のみならず、自側端末が相手側端末へ送信したカメラ映像も表示されるので、映像通信の品質変化を主観的な視点で評価できるようになる。
【００２３】
(3) 自側端末では、送信したカメラ映像および折返し送信されたカメラ映像のみならず、各カメラ映像を送受した際の定量的な品質統計情報も併せて表示されるので、映像通信の品質を客観的にも評価でき、通信に問題が発生した場合の簡易的な原因切り分けを行うことも可能となる。
【図面の簡単な説明】
【００２４】
【図１】本発明を適用したWebRTC映像通信システムの機能ブロック図である。
【図２】自側および相手側の各端末がWebサーバからテスト用Webページを取得する様子を示した図である。
【図３】品質統計情報の評価方法を示した図である。
【図４】自側および相手側の端末間での映像通信のシーケンスフローである。
【図５】自側端末における通信品質の評価結果の表示例を示した図である。
【図６】WebRTCについて説明するための図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明を適用したWebRTC映像通信システムの主要部の構成を示した機能ブロック図である。
【００２６】
本実施形態のシステムは、カメラ機能が実装または接続された自側端末Nsと、カメラ映像を表示する相手側端末Ndと、各端末にテスト用のWebページを提供するWebサーバと、Webブラウザ間にRTC Peer Connectionを確立するための情報交換を仲介するシグナリングサーバと、Webブラウザ間でのP2P通信を中継するリレーサーバとを、ネットワークに接続して構成される。
【００２７】
前記自側端末Nsのカメラ機能はハードウェアに限定されるものではなく、仮想カメラソフトウェアがインストールされていてもよい。
【００２８】
自側端末Nsおよび相手側端末Ndは、図２に示したように、予め実装されているWebブラウザを利用してWebサーバにアクセスし、Webページを構成するhtmlファイルや、WebRTC技術を利用して映像通信を行うためのJavaScript(登録商標)ファイルをダウンロードする。また、自側端末Nsおよび相手側端末Ndの各Webブラウザは、各ブラウザを識別するブラウザIDをシグナリングサーバへ予め登録する。
【００２９】
自側端末Nsは、相手側端末NdのブラウザIDを指定して当該相手側端末Ndとのリアルタイム映像通信を開始する。その際、自側端末Nsおよび相手側端末NdのWebブラウザは、シグナリングサーバを介して、WebRTCによる映像通信路（RTC Peer Connection）を確立するための情報を送受する。
【００３０】
自側端末Nsと相手側端末Ndとの間での映像通信は、可能であればサーバ等を経由せずP2P通信により実施し、P2P通信が不可である場合は、リレーサーバ経由で行う。リレーサーバ経由での通信を実現するための通信プロトコルおよびサーバの動作については、IETFにおいてRFC5766として標準化されているTURN（Traversal Using Relay NAT）を利用できる。
【００３１】
自側端末NsのWebブラウザにおいて、通信路確立部１０１は、自らが主導して相手側端末のWebブラウザとの間に第１リアルタイム映像通信路 (RTC Peer Connection) を確立する。映像通信部１０２は、相手側端末NdのWebブラウザへ前記第１リアルタイム映像通信路でカメラ映像（送信映像）を送信し、さらに後述する第２リアルタイム映像通信路で相手側端末Ndから折り返し送信されるカメラ映像（受信映像）を受信する。
【００３２】
映像評価部１０３は、前記送信映像および受信映像をディスプレイ（図示省略）に表示する。品質統計情報評価部１０４は、前記送信映像および受信映像の品質統計情報を取得し、それぞれ送信映像および受信映像と共に表示する。
【００３３】
本実施形態では、図３に示したように、第１リアルタイム映像通信路による映像通信の品質統計情報として、フレームレート、送信レート、RTTおよびパケットロス率を評価する。また、第２リアルタイム映像通信路による映像通信の品質統計情報として、フレームレート、受信レートおよびパケットロス率を評価する。
【００３４】
相手側端末NdのWebブラウザにおいて、通信路確立部２０１は、自らが主導して自側端末のWebブラウザとの間に第２リアルタイム映像通信路 (RTC Peer Connection) を確立する。折返し送信部２０２は、自側端末NsのWebブラウザから前記第１リアルタイム映像通信路で送信映像を受信し、これを前記第２リアルタイム映像通信路で自側端末Nsへ折り返し送信する。
【００３５】
図４は、自側端末Nsと相手側端末Ndとの間でテストの開始から映像通信までの間に実施される処理の手順を示したシーケンスフロー図であり、時刻t1〜t6では、カメラ映像の送受に先だって、前記図２に示したように、自側端末Nsおよび相手側端末NdがWebサーバからテスト用Webページを取得する手順が実行される。
【００３６】
時刻t1では、予め相手側端末NdからWebサーバへページ取得要求が送信される。時刻t2では、Webサーバから相手側端末Ndへページ応答が送信される。Webサーバは、WebRTCの映像送受信テストサービスを提供し、そのページ応答には、WebRTC技術を利用して映像通信を実行するためのスクリプト（JavaScript(登録商標)）が含まれる。
【００３７】
前記スクリプトは、テスト用ページの中に直接記述されていても良いし、あるいはテスト用ページにおいて、当該スクリプトファイルへのリンクが含まれていてもよい。時刻t3では、相手側端末Ndの当該ブラウザに固有のIDが当該相手側端末Ndによってシグナリングサーバへ登録される。
【００３８】
その後、時刻t4において、自側端末NsからWebサーバへページ取得要求が送信される。時刻t5では、Webサーバから自側端末Nsへページ応答が送信される。時刻t6では、自側端末Nsの当該ブラウザに固有のIDがシグナリングサーバへ登録される。前記シグナリングサーバへの接続は、前記スクリプトの実行を契機に実行される。
【００３９】
なお、相手側端末側Ndでは、テスト開始前に予め任意のタイミングでID登録までの一連の手順を実行しておけば、以降は人による操作が不要となる。
【００４０】
また、自側端末Nsおよび相手側端末Ndとシグナリングサーバとのコネクションは、以降で説明するSDPメッセージを送受信するために常時確立されており、シグナリングサーバでは、コネクション確立時に各端末から送信されたIDとそのコネクションとを紐付ける。
【００４１】
次いで、WebRTC標準で規定された手順に従って、自側端末Nsと相手側端末Ndの間にリアルタイム映像通信用の通信路（RTCPeerConnection）を確立する手順が実行される。
【００４２】
すなわち、時刻t7では、自側端末Nsから相手側端末Ndへ、シグナリングサーバ経由でSDP offerメッセージが送信される。このSDP（Session Description Protocol）メッセージには、メディアの種類（音声、映像）やコーデック形式、IPアドレスやポート番号、データ転送で利用するプロトコル（TCP、UDP等）などの情報が含まれる。
【００４３】
相手側端末Ndは、自側端末Nsから前記SDP offerを受信すると、時刻t8において、SDP answerメッセージで同様の情報を自側端末Nsへ送信する。時刻t9では、自側端末Nsと相手側端末Ndとの間で接続確認が実行され、P2Pで通信できるIPアドレスおよびポート番号のペアが決定される。
【００４４】
なお、P2Pで通信できない場合は、リレーサーバ経由での通信となる。前記手順の詳細は、IETFにてICE（Interactive Connectivity Establishment）と呼ばれる手法が標準化されている（RFC 5245）。
【００４５】
時刻t9の手順により自側端末Nsと相手側端末Ndの間にRTC Peer Connection（第１リアルタイム映像通信路）が確立されると、時刻t10では、自側端末Nsから相手側端末Ndへ向けてカメラ映像が送信される（図２ではP2Pの場合のみ記載しているが、P2P通信できない場合は、リレーサーバ経由でカメラ映像を送信する）。
【００４６】
ここで、カメラ映像は物理的なカメラデバイスからの入力映像でもよいし、外部から取得した映像ファイルを仮想カメラ経由で入力したものでもよい。
【００４７】
相手側端末Ndは、前記カメラ映像を受信すると、時刻t11において、自側端末Nsへ向けてRTC Peer Connectionの確立を試みる。相手側端末Ndにおける手順は前記自側端末Nsから試みる場合の手順と同様である。
【００４８】
時刻t13において、RTC Peer Connection（第２リアルタイム映像通信路）が確立されると、相手側端末Ndは自側端末Nsから受信したカメラ映像を、時刻t14において、前記RTC Peer Connectionを利用して自側端末Nsに折り返し送信する。
【００４９】
以上の手順により、自側端末Nsは自身の映像が相手側端末に届いているかどうかを確認することができる。すなわち、前記(1)の発信テスト、および前記(3)の映像送信テストが、相手側端末Ndでの操作を必要とすることなく実施できる。
【００５０】
また同時に、相手側端末Ndから自側端末Nsを呼び出せるかどうか、呼び出し後に相手側端末Ndから送信された映像を自側端末Nsで受信できるかどうかを確認することができる。すなわち、前記(2)の着信テスト、および前記(4)の映像受信テストも、相手側端末Ndでの操作を必要とすることなく実施できる。
【００５１】
図５は、リアルタイム映像通信の自側端末Nsにおける評価結果の表示例であり、自側端末Nsから相手側端末Ndへ送信したカメラ映像（送信映像）V1と、相手側端末Ndから自側端末Nsへ折返し送信されたカメラ映像（受信映像）V2とが並列表示されている。
【００５２】
さらに、本実施形態では自側端末Nsから相手側端末Ndへカメラ映像を送信した際の品質統計情報（ここでは、フレームレート、送信レート、RTTおよびパケットロス率）が表示され、さらに相手側端末Ndから自側端末NsへRTC Peer Connectionでカメラ映像を折返し送信した際の品質統計情報（ここでは、フレームレート、受信レートおよびパケットロス率）も表示される。
【００５３】
Web RTC技術においては、RTC Peer Connectionの統計情報を取得できるJavaScript(登録商標) APIが定義されており、自側端末NsがWebサーバより取得するスクリプトにおいて、前記APIを定期的に呼び出すプログラムを記述することで、自側端末Nsにおいて自側から相手側向きのRTC Peer Connection、および相手側から自側向きのRTC Peer Connectionにおける統計情報を定期的に取得、更新することができる。
【００５４】
以上のように、カメラ映像の統計情報を表示することで、自側で自身の映像が相手側端末に届いているかどうかだけでなく、その品質も主観的および定量的に確認することができる。
【００５５】
また、通信に問題が発生した場合に、簡易的な原因切り分けも可能となる。例えば、受信映像が表示されない場合に、送信映像の品質統計情報が表示されていれば、相手側から自側への通信で問題が発生していることが分かる。
【符号の説明】
【００５６】
１０１…通信路確立部，１０２…映像通信部，１０３…映像評価部，１０４…品質統計情報評価部，２０１…通信路確立部，２０２…折返し送信部，Ns…自側端末，Nd…相手側端末
【図１】
0006532159.tif 000002
【図２】
0006532159.tif 000003
【図３】
0006532159.tif 000004
【図４】
0006532159.tif 000005
【図５】
0006532159.tif 000006
【図６】
0006532159.tif 000007