デベロッパのためのWebRTCサービスAPI集Respokeは接続管理機能も提供

オープンソースのPBXソフトウェアAsteriskで人気のDigiumが今日(米国時間2/23)、デベロッパのためにWebRTCサービスのバックエンド(API集)を提供するRespokeを立ち上げた。Respokeは、類似のサービスBistriやTelefonicaのTokBoxなどの仲間だ。いずれも、デベロッパのためにWebRTCによる通信/コミュニケーションプラットホームを提供している。

RespokeのAPIを使ってデベロッパは、ビデオ通話、リアルタイムチャット、画面共有などの機能を自分のアプリケーションに加えられる。今はWebで使うためのJavaScriptライブラリとREST APIを提供しているが、今春内にAndroidとiOSのSDKも提供する。Internet ExplorerとSafariは現在、WebRTCをサポートしていないが、Respokeはそれらのためのプラグインをリリースする予定だ。

WebRTCは優れた技術だが、現状では1対1のピアツーピア通信が中心だ。そのような直接接続は、ファイヤーウォールやネットワークの構成によって妨害されることもある。そこで、Respokeのようなバックエンドサービスの出番になる。それらのサービスは、上記のような問題をメディアリレーを使って回避するだけでなく、WebRTCの規格にないログイン認証やアイデンティティ、プレゼンスなどの管理機能も提供する。デベロッパがコミュニケーションのアプリケーションを作ろうとすると、どうしてもそれらの機能が欲しくなるからだ。

Respokeを使うとデベロッパは、アプリケーションのユーザに電話との通話もさせられる。つまり同社の伝統は電話技術だから、Asteriskベースの電話システムを容易に統合できるのだ。

Digiumの社内スタートアッププロジェクトRespokeは、数か月かかって孵化した。数か月前にベータに入り、その後、そのフィードバックで求められた、入呼起呼の処理(電話通話)、画面共有などの機能を実装した。

Respokeの料金は、ユーザが望む並行接続の最大数、メディアリレーの帯域、電話番号の数と電話使用時間で決められる。5つの並行接続でメディアリレイが5GBの帯域までは、無料だ。有料プランは月額50ドル(50接続、帯域50GB、電話番号1、通話時間500分)から始まる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


今年はWebRTC元年になるだろうか?、その促進要因と阻害要因をさぐる

[筆者: Itay Rosenfeld]

編集者注記:Itay RosenfeldはVoxboneのCEO、通信業界で13年の経験がある。

WebRTC(Web Real-Time Communication)は、ブラウザ上でプラグイン不要で音声やビデオによる通話を可能にするオープンソースの標準規格〔APIの定義〕で、2012年にGoogleがW3Cに提案した。WebRTCを使うと、たとえばブラウザの画面に相手を表すボタンがあって、それをクリックすれば音声やビデオによる通話が始まる。

その‘相手’は、個人や会議のプラットホーム、カスタマサポートサービス、ビデオのソースなど、さまざまだ。こういうリアルタイム通信がブラウザ上で簡単にできるようになると、消費者のインターネットの使い方も大きく変わってくるだろう。個人間だけでなく、生活にサービスや物資を供給する企業との関係においても。

WebRTCで従来の通信型式が要らないものになる?

WebRTCが明日からすぐに、たとえば今の電話システムを不要にしてしまうわけではない。しかしそれでも、今年は、従来的な通信とWebアプリケーションの両方を補完し補強するような形で、WebRTCが大規模に採用されるだろう。今すでに芽生えていて、これからさらに大きく伸びると思われるトレンドを、列挙してみよう。

音声とビデオによるリアルタイムのカスタマサポート 企業のWebトラフィックをWebRTCによるコンタクトセンター(お客様承り所)の対話に導くことは、一般的にありえるビジネスケースだ。AmazonのMaydayAMEXのLive Video Chatなどのサービスは、WebRTCの技術でWebアプリケーションのユーザとコンタクトセンターの対話が改良されることを実証している。

カスタマサポートにWebRTCを利用することには、そのほかの利点もある。たとえば、ユーザからの入呼があった時点でその顧客の基本情報が分かるので、カスタマサポートの効率が大幅にアップする。いろいろ質問しなくてもよい。

クリック一発で会議に参加 WebRTCで仮想会議に参加できる。これまでは、ビデオは一部のハイエンドな会議でしか利用されないし、音声アクセスは電話によるものがほとんどだった。

とくにWebRTCによるオーディオはHDで空間性(サラウンド)ありなので、会議での効果が大きい。しかもそのコストは、会議の主催者とユーザの両方にとって安上がりだ。電話会議にありがちなドジとヘマの数々も防止できる。

グローバル化 スマートフォンなどの電話システムではサービスやビジネスのグローバル化〜多国籍化がなかなか難しいが、WebRTCなら簡単だ。たとえばワイヤレスのキャリアはWebRTCを使って世界中のどんなネットワーク上のどんなデバイスに対してもコミュニケーションサービス(ビデオ、音声、SMS等々)を提供でき、しかもそのために、スマートフォンの機種などを特定する専用アプリは要らない。

たとえばT-Mobileが最近発表したWiFi通話機能は、WebRTCを使えばもっと簡単に実現できる(今はまだ使ってない)。今年のCESでは、AT&Tが合衆国のキャリアとしては初めてWebRTCのサポートを発表した。

新しいサービスやビジネス 従来の通信サービスを超えるような新しいサービスがいくつかすでに登場している。それらはWebアプリケーションの一部としてリアルタイム通信を使い、中にはまったく新しいビジネスモデルもある。たとえばPopExpertなどのミニミニコンサルティングサービスは、消費者とエキスパートをビデオチャットで結びつける。

またNTTのSkyTalkは、WebRTCによる音声とビデオの対話をベースとするソーシャルアプリだ。2015年にはさらに新しい多様なWebRTCの利用例が、数多く登場するだろう。

WebRTCの本格普及の前提

以上のように、すでにいろいろなトレンドが芽生えている中で、WebRTCの大量採用(大衆化)の決め手となるビジネスモデルは何だろうか? ぼくの考えでは、WebRTCはこれまでのような新しくて珍しくて無料のコミュニケーションのベースになるものから、企業向けのソリューションや、消費者向けの会費制のソリューションに移行していくだろう。その主役は、企業向けでは会議サービス、消費者向けではエキスパートによるコンサルテーションサービスだ。

しかし、上記のようなWebRTCの大普及のためには、二つのことが必要だ:

1. MicrosoftとGoogleとAppleがWebRTCをめぐる抗争をやめること

この抗争がWebRTCの初期からずっとあるので、今だにChromeとFirefox以外のブラウザがWebRTCをサポートしていない。これでは、大衆化は無理。使用するコーデックをめぐっても抗争があるので、それが解決しないかぎりWebRTCによるビデオの利用は普及しない。

昨年後半にGoogleとMicrosoftはWebRTCの普及を妨げている障害物の除去に向けて一歩を踏み出した。願わくば近い将来には、ChromeとInternet ExplorerとFirefoxの三者がWebRTCによるビデオをサポートしてほしいし、そうなれば一挙に、怒涛のような大普及が始まる。SafariのWebRTCサポートに関しては、まだ音沙汰がない。

2. ユーザ体験の質的向上

WebRTCが有料サービスでも利用されるためには、今の消費者が慣れている電話ネットワークのそれと並ぶ、あるいはそれを凌(しの)ぐ、高品質なユーザ体験が必要だ。インターネット通信が落ちたり低品質になることは誰もが経験しているが、サービスの多くが無料だからみんな我慢しているだけだ。

WebRTC、つまりWeb上のリアルタイム通信は、便利だし、HDのオーディオやビデオは魅力だが、通信の品質が悪すぎると、なかなかユーザ数は増えないだろう。今そのためのソリューションが開発中ではあるけど。

安定した通信の質が確保できること、そして既存のコーデックがすべてサポートされ、またメジャーなブラウザのすべてがWebRTCをサポートすれば、2015年はWebRTCが離陸する年になるだろう。しかし、そのためにやるべきことは、とても多い。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


MozillaがWebRTCプロバイダのTokBoxと組んでブラウザ本体に汎用コミュニケーション機能を持たせる実験を開始

Mozillaが今日(米国時間5/29)、WebRTC APIのプロバイダTokBox提携してブラウザ本体にWebRTCによるコミュニケーション機能を持たせる実験を開始する、と発表した。当面その実験は、FirefoxのNightlyリリースに実装されるだけなので、一般ユーザの利用はまだ先の話だが、たいへん興味深い取り組みであることは確かだ。

WebRTCは、ブラウザ間でリアルタイムデータやオーディオ、ビデオなどをプラグイン不要で送受するための規格で、FirefoxとChromeはすでに通常バージョンでサポートしている。Microsoftのブラウザはこれをサポートせず、独自の規格をスタンダードとして提案している。

MozillaのFirefox担当プロダクト管理部長Chad Weinerによると、同社は現在のコミュニケーションおよびソーシャルネットワーキングの市場が分断化されていることを懸念している。

Weinerは次のように語る: “Mozillaなら、それらの壁を壊してあげることができるのではないか、と考えた。つまり、とてもたくさんの人が使っているブラウザの本体に、オープンで相互運用性に富むコミュニケーション機能が備わっていれば、よいのではないか”。

またWeinerによると、長期的な展望としてはMozillaがWebRTCのエコシステムを作って、それがすべてのデバイスとオペレーティングシステムを横断する、ないしカバーする形にしたい。そもそもWebRTCのねらいが、それだから。WebRTCを使ったサービスはすでにいろんなものが、完成製品に近い形で作られてはいるが、どれもまだ実験段階だ、と彼は言う。

Mozillaがこの機能の実験のためにパートナーとしてTokBoxを選んだことは、意外ではない。TokBoxは2012年にスペインのキャリアTelefonicaに買収されたが、長年、WebRTCの世話役のような役割を担ってきた。現状のWebRTCのプロトコルは帯域の変動に対する自己調整機能がない、マルチユーザチャットがサポートされていない、などの短所があるので、TokBoxのような有能な第三者が介入して、そういう高度な機能を構成し提供する必要があるのだ。TokBoxのビデオチャットがFirefoxのサポートをローンチしたのは、1年あまり前だ

ぼくが見たかぎりでは、その新しい実験的WebRTCアプリケーションはまだNightlyに登場していない(隠れ機能になっているのか…)。NightlyのURLはここなので、いずれ近いうちに、ダウンロードできるようになるだろう。安定版ではないことを十分承知のうえで、試してみられることを、おすすめしたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


TokBoxのWebRTCプラットホームOpenTokがネイティブAndroidアプリをサポート

TokBoxの今日(米国時間11/19)の発表によると、同社のWebRTCプラットホームOpenTokが拡張され、ネイティブのAndroidアプリの構築もサポートすることになった。これによりデベロッパは、彼らのネイティブのAndroidアプリにOpenTokを使ってリアルタイムビデオとオーディオによるチャットを含めることができる。同社の発表によるとデベロッパは、このプラットホームを使ってビデオをアーカイブしたり、アプリケーションの中でそれらを再生したりも、できるようになる。

同社によるとこれらの機能は、同社のデベロッパコミュニティからの要望がもっとも熱烈だったツールに属する。TokBoxが同社のAndroid SDKの初期のバージョンをローンチしたのは、今からちょうど1年前だが、それにはWebRTCは使われていなかった。

アーカイビング機能により、会話を単一のH.264/AAC MP4ファイルに保存でき、それをデベロッパはダウンロードして、任意のプレーヤーによりストリーミングできる。

TokBoxはこのほか、OpenTokプラットホームに品質向上機能を2つ加える。今回のリリースでは、デベロッパはビデオストリームのフレームレートをリアルタイムで設定できるようになり、帯域リソースの管理を充実させる。それは、WebRTC自身にはない機能だ。さらにもう一つ、TokBoxはTCPのサポートにTURNを加え、これまでファイヤウォールのために動けなかったWebRTCアプリケーションが動けるようにする。

今週行われるWebRTC ExpoとWebRTC Conferenceで、この新しい技術(WebRTC)に関する詳しい話が、いろいろと聞けるだろう。たとえばWeemoは今朝、WebRTCによるビデオチャットの、ネイティブのiOS/Androidアプリサポートを発表した。ただし技術的には似ていても、WeemoのビジネスモデルはTokBoxとは違って、デベロッパではなくソフトウェアのベンダが顧客だが。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Chrome 29ベータはAndroidにWebRTCとWeb Audio APIを実装, デスクトップではOmniboxを改良

Googleが今日(米国時間7/16)、Chrome 29のデスクトップAndroid用バージョンのベータをリリースした。とくにAndroid版に重要な変化があり、オーディオ合成処理のためのWeb Audio APIと、リアルタイム通信のための最新API WebRTCをサポートしている。

デスクトップ版(Windows、Mac、Linux)のアップデートには、omniboxの改善提案が取り入れられ、ユーザが最近訪れたWebサイトが尊重されるようになった。このほかデスクトップバージョンでは、WebMによるビデオ再生でGoogle自身のVP9コーデックがサポートされた。


ただしWeb Audio APIが当面使えるのは、NEONオプティマイゼーションをサポートするARMデバイスのみである。これは、ARM Cortex-A8プロセッサで導入された新しい命令を実行する方法のことだ。Web Audio APIをサポートしている実機の上では、ここでそのデモを楽しめる。デスクトップのChromeでは、かなり前からサポートされている。またiOSと、今回のAndroid用ベータもサポートしている。

なおFirefoxは、先週のNightlyがこのAPIをサポートしている。

WebRTCは、このAPIを使うとビデオとオーディオによるリアルタイム通信がプラグイン不要でできる。それが、今回はAndroid用ベータでサポートされた。デスクトップのChromeは、このAPIを早くからサポートしたブラウザの一つだ。実装が今後さらに普及すれば、多くのデベロッパの関心がそれに向かい、Webブラウザのほとんど標準的な機能になるだろう。ChromeとFirefoxはすでにサポートしているが、MicrosoftはInternet Explorer 11までお預けのようだ。

WebRTCに関しては、Googleのビデオチャットのデモがここにある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Firefox 22安定版リリース―asm.jsとWebRTCをサポートでウェブ・アプリ開発全般にも大きな影響

今日(米国時間6/25)、MozillはFirefox 22リリースした。これはWebRTCプロトコルasm.js JavaScriptサブセットをサポートする最初の安定版Firefoxだ。

Microsoftの場合を除けば、現在、ブラウザのアップデートは日常的ルーチンになっている。しかし今回のWebRTCとasm.jsの追加は今後のウェブアプリの開発のあり方を大きく変える可能性がある。当面Firefoxをターゲットにしていないデベロッパーもこの変化には注目しておく必要があるだろう。

 

ビルトインWebRTCのサポート

デベロッパーはWebRTCを利用してビデオチャットや音声通話、ファイル共有などの機能をビルトインしたアプリを開発することができる。サードパーティのプラグインやソフトウェアを組み込む必要はない。Tokboxを始め多くの企業がWebRTCに社運を掛けている。しかし現在までWebRTCをサポートする有力ブラウザはGoogle Chromeだけだった。今回Firefox安定版がWebRTCをサポートしたことでスタートアップも既存大企業もこぞってこのテクノロジーの利用を始めるだろう。今のところMicrosoftだけがWebRTCとは異なる規格の採用を決めているが、将来Internet ExplorerにもWebRTCが採用される可能性は大いにある。

asm.js

asm.jsもゲームのルールを変える可能性のある重要なテクノロジーだ。われわれが3月の記事で詳しく紹介したとおり、asm.jsはJavaScriptのサブセットで、ウェブブラウザ内でネーティブアプリに匹敵する高速で作動する。MozillaのCTO、BrendanEichは私の取材に対して、「メモリが安全ではないC、 C++のような言語に対して安全なバーチャルマシンを構成できるJavaScript言語のサブセットだ」と説明した。EmscriptenのようなC and C++をasm.js向けにコンパイルできるツールのおかげで、デベロッパーは既存のC、C++プログラムをブラウザ内で安全に作動させることができるようになる。

この新機能はMozillaのBananaBreadゲーム・デモで試すことができる。このデモにはWebGL、Emscripten、asm.js、WebRTCが使われており、ハイエンドの3Dマルチプレイヤー・ゲームをブラウザ内で高速に作動させることができることを証明している。

その他Firexfox 22ではWebGLのレンダリングのパフォーマンスの向上などいくつかのマイナー・アップデートがある。詳細なリリースノートはこちら

[原文へ]

(翻訳:滑川海彦 Facebook Google+


WebRTCとWeb AudioとWebGLのパワーを見せつけるためにオープンソースのPongクローンをGoogleがローンチ

Googleが今日(米国時間6/12)、PongゲームのクローンCube Slamを、オープンソース立ち上げた。ブラウザの上で、友だちやコンピュータと対戦できる。そのこと自体はあまりエキサイティングでもないが、しかしGoogleはこのゲームを、WebRTCとWeb AudioとWebGLのデモとして作ったのだ。

多くの人、とくにデベロッパにとって、WebRTCは、ブラウザ上でできるプラグイン不要のビデオ会議を意味しているが、しかしCube Slamはこの通信技術を使って、プレイ中にライブのビデオとオーディオのストリームを友だちの仮想スクリーンに映し出す。

とりわけ重要なのは、このゲームがWebRTCのRTCPeerConnectionRTCDataChannelを使って、オーディオとビデオと“ゲームの同期を維持するためのあらゆるデータ”を、二つのマシン間で送受していることだ。WebRTCのこの二つの部位は、これまで知らなかったデベロッパが多いと思う。

Googleの主張によるとCube Slamは、“ RTCDataChannelを使った初めての大規模なアプリケーションであり、そのAPIはWebSocketに似ているが、しかしデータをRTCPeerConnectionのピアツーピアリンクで送る”。

明らかにここでGoogleが見せたいのは、WebRTCのパワーだ。すでにWebSocketに関しては同様のことを実験作Racer Chromeでやっている。そしてまた同時に、WebGLとWeb Audioで何ができるかも、見せつけたいのだ。

このゲームのインフラストラクチャはGoogleのCompute Engineがホストし、そのコードはここで入手できる。

今Cube Slamを動かせるのはデスクトップのChromeとChrome OSだ。今年後半にはAndroidのChromeでも遊べるようになる。ただし今でも、chrome://flagsのメニューで”WebRTC Android”を有効にすると、Android上で試用できる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


トラフィックの真ん中にクラウドを置いてWebRTCの制約を克服–TokBoxが複数者ビデオチャットを可能に

TelefonicaのTokBoxが今日(米国時間4/25)、WebRTCを使うOpenTokサービスの重要なアップグレードを発表した。新たに作られたメディア分散フレームワークMantisにより、ビデオの分散に関するWebRTCの制約を克服するのだ。つまり、WebRTCはピアツーピアの通信形式だが、しかしそのために、そのままではビデオチャットなどは二者間でしかできない。そこで、クラウドインフラであるMantisが仲立ちをすることによって、三者以上の複数者間のビデオチャットが可能になる。しかも、単純なピアツーピアだけでむりやりマルチ(複数者間自由通信)をやる場合のように大量の帯域を使うこともなく、複雑なメッシュ的アーキテクチャも要らない。

TokBoxのCEO Ian Smallによると、この技術で将来はビデオストリームをユーザの帯域条件やデベロッパのニーズに合わせて最適に構成できるようになる。“Mantisによってわれわれは、WebRTCのインフラに頭脳を持たせたのだ。将来は、今のようにトラフィックをルーティングするのではなく、トラフィックを構成できるようになる”。

Mantisの今の機能の中でもとくにクールなのは、SIPの相互運用性だ。デベロッパがWebRTCアプリを書くと、ユーザはそれを標準の電話回線から呼べる。だからWebRTCのビデオチャットをマルチでやる場合も、参加者の一部が通常の電話回線から参加できる。

今現在のOpenTokのマルチチャットは最大10名までだが、ウェビナーのように一人だけがしゃべりっぱなしというタイプでは、100名以上でも対応できる。Mantisのベータテストは、LiveNinjaRoll20の協力により行われた。

しかしWebRTCの部分は抽象化/ブラックボックス化されているので、デベロッパがそれに関してとくに何かをする必要はない。デベロッパは、必要なトポロジー(P2Pか、マルチパーティーかなど)作って、通信を開始するだけだ。あとは、いっさいをクラウドが引き受ける、とSmallは言う。クラウドに一元化されていると、今後の新機能の導入/展開もやりやすい。

WebRTCはまだ成熟途上の技術だが、Smallはそのことを認めつつ、たとえば今後Firefoxの安定版がそれをサポートするようになれば本格的な普及段階に入るだろう、と言う。今はまだ、少数のデベロッパたちによる実験段階に過ぎず、アーリーアドプター(新し物好きの先進ユーザ)たちすらいない、と。

TokBoxのWebRTCが使えるのは、目下、ChromeとデスクトップのFirefoxだけだ。Chrome FrameからならInternet Explorerも使える。モバイルでは、Android上のChromeと、OpenTok SDKによるiOSネイティブアプリで使える。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


あなたのページにWebRTCのビデオチャットを埋め込める–Fresh Tilled Soilの一連の実験より

WebRTCを使ってデベロッパは、自分のWebアプリケーションにプラグインなしでリアルタイムの音声通話やビデオチャット、ファイル共有などの機能を導入できる。ChromeとFirefoxはすでにこれをサポートしているが、そのほかのブラウザもいずれ彼らに続くだろう。しかし現段階ではWebRTCは規格も実装も実験段階で、まだ多くのサイトがこぞって採用するまでには至っていない。また自分のサイトへの導入も、Conversat.ioのようなプロジェクトはあるものの、まだ容易ではない。

WebRTCを試してみたい、WebRTCを使ったビデオチャットウィジェットを自分のサイトに載せてみたい、と考えている人たちのために、ボストンのUI/UXデザイン会社Fresh Tilled Soilが、WebRTCによる埋め込み可能なビデオチャットウィジェットをローンチした。

本誌TechCrunchはベースが裸のWebサーバではなくWordPressなので、少なくともその現状の設定ではウィジェットを正しく埋め込めないが、ご自分のサイトで試してみたい方はここを訪ねてみられよ。

多くのこの種のプロジェクトと同様に、ユーザがすることといえば、チャネルの名前を決めて、それを友だちと共有し、そうすると数秒後にはチャットを開始できるはずだ。

ただし今現在は、デスクトップのChrome最新安定バージョンとAndroidのChrome Betaでしか使えない。もうすぐ、Firefoxもサポートされる。WebRTCはピアツーピア通信なので、ホストは最初のハンドシェイクを処理するだけだ。だからサーバの負荷はとても低い。

WebRTCのこの実験は、Fresh Tilled Soilがこれまでやってきた一連のテストの最新のものだ。これまでのものの中には、WebAudioAPIを使った音声処理や、音声入力のためのメディアキャプチャとストリームなどもある。また同社のこのクールで小さな実験では、Webカメラを使ってユーザと画面との距離を測り、フォントのサイズを調節する。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Firefox 20がローンチ: プライベートウィンドウ, ダウンロードマネージャの刷新, WebRTCとHTML5の実装が充実, など

Firefox 20がリリースされ、今日(米国時間4/2)からダウンロードできる。この新バージョンの最大の目玉は“プライベートウィンドウで開く”という閲覧モードができたことだ。これでデスクトップのFirefoxユーザは、ブラウザを終了しなくてもプライベートウィンドウを開けるようになった。またFirefox for Androidのユーザは“プライベートタブ”を開ける。このほか新バージョンでは、デスクトップのダウンロードマネージャが改良され、モバイルではホーム画面のショートカットにお気に入りのサイトを置け、そしてHTML5とWebRTCのサポートがさらに充実した

Firefox for Androidの新バージョンは非力なARMv6プロセッサを使っているデバイスもサポートする(Samsung Galaxy Next, Dart, Pop, Q; HTC Aria, Legend; ほか)。

プライベートウィンドウ/タブについてMozillaは、“それまでの閲覧を妨害されずにお誕生日プレゼントの買い物をプライベートウィンドウでできる。複数のメールアカウントを同時にチェックできる”、という説明をしている。

でも、ユーザが最初に気づく機能は、新しいダウンロードマネージャだろう。下のビデオはそれを解説している:

デベロッパ向けには、今度のバージョンでWebRTCのgetUserMediaがサポートされた。これを呼び出してデベロッパはユーザのカメラやマイクにアクセスできる(パーミッションがあるなら)。HTML5では<canvas>でブレンドモード(色を重ねる)がサポートされ、また<audio>と<video>の実装が改善された。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


TokBoxのWebRTCによるビデオチャットがFirefoxのNightlyとAuroraに対応

tokbox_firefox_logo

スペインのTelefónicaが2012年に買収したTokBoxは、ビデオチャットサービスの中では早くからWebRTC(Web Real-Time Communication API)を採用した企業の一つだが、今WebRTCは、プラグインが要らずブラウザ本体の中でビデオやオーディオのリアルタイム通信ができる技術として、標準規格の整備が急がれている。TokBoxは、今年初めにChromeで使えるようになったのに続き、今日(米国時間2/25)はMozillaのFirefoxにも対応した。ただしFirefoxの最終安定バージョンではなく、先進機能をテストしているバージョンであるAuroraとNightlyにおいてだ。そこでFirefoxのデベロッパたちはTokBoxのWebRTCバージョンであるOpenTokプラットホームを利用して、自分のアプリにビデオ通信機能、たとえばビデオチャットなどを実装できることになった。そのチャットは今や、iOSとChromeとFirefoxのユーザ間で可能だ。

WebRTCがFirefoxの先行リリースバージョンに載ったということは、安定リリースバージョンではバージョン21か22あたりでWebRTCがサポートされるのかもしれない(今はバージョン19)。

tokbox screenshot

TokBoxのCEO Ian Smallの話では、同社がMozillaとの共同作業を開始したのは昨年の11月ごろだ。彼のチームはMozillaによるWebRTCの実装に初期段階からアクセスできることになり、実装の安定化に向けてのMozillaの努力につきあってきた。TokBoxのOpenTokプラットホームは、デベロッパがWebRTCのブラウザごとの実装の違いを気にする必要がなく、またビデオを大量のビューワにブロードキャストしたり、ビデオを録画するなど、ふつうのブラウザネイティブのWebRTCアプリケーションにはないようなサービスも提供している。OpenTokは、同社(TokBox)によれば、7万あまりの企業や団体が使っており、その中にはMajor League Baseball、Ford、Bridgestone、それにリモートプレゼンスを提供するスタートアップDouble Roboticsなどがいる。

Smallによると、“Firefox 21(近未来)とChrome 25(現在)の間で、安定的な相互運用性が得られるようになるだろう”、という。彼によると、WebRTC自身がまだ幼児期であり、ブラウザ内のネイティブバージョンを使って2人の人間のチャットは可能でも、グループチャットや録画は多くの実装がサポートしていない。またWebRTCの標準規格も、それらの機能ははサポートしていない。またTokBoxにおけるSmall自身のWebRTC体験に基づくと、その仕様はGoogleのVP8形式以外のビデオコーデックにも対応すべきだ。そしてまた、アプリケーションがユーザにより多くの帯域を許容できるために、帯域の割り当てをWebRTCの標準規格に(標準機能として)盛り込むべきだ、と彼は語った。

このように、課題や問題はいろいろあるけど、Small曰く、今年の後半はWebRTCがデベロッパ界隈で本格普及期に入る。今やモバイルでもデスクトップでも、主なブラウザがすべて、WebRTCをサポートしているのだから。

[原文へ]

(翻訳:iwatani(a.k.a. hiwa))

Firefoxの先行テスト版がWebRTC, H.264, MP3をデフォルトでサポート

Mozilla_Nightly_icon_2011

Firefoxブラウザのテスト専用の先進的バージョンFirefox Nightlyで、WebRTCがデフォルトでサポートされた。WebRTCは、プラグインなしでブラウザ自身がリアルタイムのUDP通信を行う規格で、とくにオーディオやビデオによる対話やコンテンツ配布に適している。これまではFirefox Nightlyのオプションとしてサポートされていたが、これがデフォルトになったことにより、数か月後には安定版(正規リリース版)の工程に組み入れられることが期待される。

MozillaのPaul RougetとRober Nymanが今日の発表声明の中で、“これは大きな前進である。これにより特殊な設定や構成を必要とせずにWebRTCを直接、Webブラウザの中で動かせるようになる”、と書いている。

おそらく今年いっぱい、WebRTCがにぎやかな話題になるだろう。主なブラウザがこぞって、その実装を開始しているからだ。Chromeはすでにバージョン23から安定版でWebRTCをサポートしており、最近Mozilla とGoogleは、二つのブラウザのユーザ同士がWebRTCを使って対話できる、というデモを公開した。

なお今回のFirefox Nightlyでは、H.264とMP3形式がサポートされる。ただしデコードはオペレーティングシステムが行い、今はWindowsの7以上のみでサポートされる。MacとLinuxのサポートは、目下開発中だ。

Mozillaが今週初めに発表したように、このNightlyリリースはWindows 8のMetroインタフェイスをサポートしている。

WebGLのデモも…

ちょっと関係のない話題だが、Mozillaは今日(米国時間2/20)、WebGLの すばらしいデモ発表したACTISKUのAnthony Liotが書いたこのデモは、Webブラウザもついにここまで来たか!と思わせる最先端のグラフィクスであり、しかもデベロッパはプラグインに依存せずにクロスプラットホームな体験をユーザに容易に提供できる。ただし現状では、Internet ExplorerがまだWebGLをサポートしていない。

webgl_demo_actisku

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

グループビデオチャットのTenHandsがChromeのWebRTCで実装–プラグイン不要に

tenhands_logo

Webアプリケーションとモバイルアプリ向けにビデオコラボレーションサービスを提供しているTenHandsが、WebRTCのサポートを発表した。WebRTCはブラウザ内でプラグインを使わずにオーディオやビデオによる通話ができるためのJavaScriptライブラリで、TenHandsのAPIは、ユーザがChrome 24より上のブラウザを使っている場合には自動的にWebRTCによるオーディオビデオ通話を行う。

これまでの(そしてデフォルトの)TenHandsは、Chromeの場合のようにブラウザがWebRTCをサポートしていなければ、自分のWebRTCプラグインをインストールするので、デベロッパは相互運用性を心配する必要がない。しかしTenHandsは、いずれどのブラウザもWebRTCをネイティブでサポートする、と予測している。その標準規格化に関して、Microsoftだけは独自の考えのようだが、いずれにしても今すでにWebRTCの普及に期待しているベンダは多い。Skypeを抱えるMicrosoftも当然、このレースに加わるはずだから、向こう数か月の標準規格をめぐる議論からは目を離せない。

gI_78803_Screen Shot 2012-11-12 at 11.27.08 AM

TenHandsのCOO Jack Blaeserによれば、どのWebブラウザも標準規格として確定したWebRTCをサポートするようになれば、ビデオの民主化に向けての大きな前進になる。これからは個々のアプリケーションやベンダ(AT&T, Verizon, Skype, …)に閉じこめられることなく、どんなユーザでも、どんなアプリケーションでも、ブラウザの上で、HDビデオと音声によるコミュニケーションができるようになる。そのための特殊なハードウェアやソフトウェアは要らない。

Blaeserの見方では、それによって数々の新しいユースケースも生まれる。たとえばコールセンターは、Webでもモバイルでも、ビデオと音声でリアルタイムの対話ができるようになる。またWebRTCの標準化と普及により、遠距離学習や遠隔医療などがより簡単にできるようになり、イノベーションを加速する。“ブラウザが情報へのアクセスに革命をもたらしたように、WebRTCによってそのブラウザがさらに、ビデオと音声によるコミュニケーションのメインの手段になり、通信市場全体が大きく変貌する”。ということはつまり、これまでの携帯キャリアとか放送局〜放送会社など、大量の通信帯域を特定目的だけのために独占していた業態は、不要になると思われる。インターネットでも、Skypeに代表されるような私企業的規格に基づくアプリケーションは、おそらく御用済みになる。

TenHandsがさらに主張するのは、同社が“GoogleによるWebRTCの実装を利用する、初めての、Flashに依存しない、リアルタイムの商用ビデオソリューション”であることだ。ただし、TwilioPlivoTokBoxなどのビデオプラットホームもすでに、各種のWebRTCベースのサービスを提供している(多くはまだベータだが)。

TenHandsの創業は2011年で、それ以降今日まで、レーダーに映らない低空飛行を続けてきた。しかしこのところ、WebRTCがホットな話題になってきたので、同社のステルスモードもあと数か月で終わるだろう。Chrome向けの、ネイティブWebRTCによる実装のローンチを記念して同社は、2月9日にAPIのハッカソンを行う。優勝賞金は4000ドルだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))