SkyWay – HTML5Experts.jp https://html5experts.jp 日本に、もっとエキスパートを。 Sat, 07 Jul 2018 03:14:05 +0000 ja hourly 1 https://wordpress.org/?v=4.7.19 WebRTC開発者にはたまらない！徹頭徹尾、デベロッパーファーストだった「SkyWay Developer Meetup#1」 /shumpei-shiraishi/24700/ Mon, 13 Nov 2017 01:00:57 +0000 /?p=24700 9月29日に開催された、SkyWay初の開発者向けミートアップ「SkyWay Developer Meetup#1」。

2013年12月からトライアルサービスとして提供されてきたWebRTC Platform SkyWayのビジョンとミッション、基本的な使い方からハックな使い方などが紹介された同イベントの模様を紹介する。

SkyWayのビジョン＆ミッション

2013年12月から、無償のトライアルサービスとして提供されてきたWebRTC Platform SkyWay（以下、SkyWay）。

一部では「WebRTCでサービス開発を行うならSkyWayが必須」と認識されつつある昨今、ついに2017年9月7日、商用サービスとして新たなスタートを切った。

本記事では、SkyWay初の開発者向けミートアップ「SkyWay Developer Meetup#1」の模様をお伝えする。

まず最初に登壇したのは、SkyWayプロダクトマネージャーの水嶋彬貴氏。

▲SkyWayプロダクトマネージャー 水嶋 彬貴氏

6,000人以上の開発者、10,000近くのサービス、300近くの企業に既に利用されているSkyWayは、現在なんと1日あたり50万近くのWebRTC接続を捌いているという。

こうした実績は、「WebRTCを使うとこんなにもたくさんのことができる、と開発者の皆さんに証明していただいた」ことの現れであると水嶋氏は強調。

その上で、新たなスタートを切ったSkyWayのビジョンとミッションを以下のように定義した。

「リアルタイムコミュニケーションを身近な技術に変え、世界中のソフトウェアエンジニアと共に世の中に革新を起こす」

リアルタイムコミュニケーションを身近な技術に変える

ミッションの前半「身近な技術に変える」という部分においてはまず、SkyWayの様々なAPIやSDK、日本語を含めたドキュメントが、WebRTCの難しさを中和してエンジニアの負担を減らすことができるとする。

それによりエンジニアは「WebRTCをどう使うか」ではなく、WebRTCを使ったイノベーションやアイデアに集中することができるようになる。

もうひとつ、身近な技術に変えるというミッションに基づいて提供されているのが、無償の「コミュニティエディション」だ。

無償で利用できる月に500ギガバイトという帯域量は、ボイスチャットであれば5,787日分、ビデオチャットであっても462日分に相当する。

これだけの無料枠を手軽に試せるならば、スタートアップや新規事業に採用するのにためらう必要はない。まさに「リアルタイムコミュニケーションを身近にする」を体現した形だといえる。

──そしてイノベーションを世界に広げる

しかし、と水嶋氏は言う。SkyWayがいくらWebRTCを身近にしたところで、それだけでは世界中に広がるものではない。

ミッションステートメントの後半部分「世界中のソフトウェアエンジニアと共に世の中に革新を起こす」を達成するには、SkyWayを利用する開発者の助けが必要なのだと。

そこで水嶋氏は「（開発者への）お願い」と題して、以下の4つを挙げていた。

  • 横のつながり
  • イノベーションのアイデア共有
  • ノウハウの共有や相互支援
  • 事業の成功と後続の支援

水嶋氏のプレゼン資料はこちらから参照できる。

WebRTC開発者にはたまらない！基本からハック、生Q/A大会まで！

その後は開発者向けにたっぷりと時間が割かれ、SkyWay / WebRTCに関する熱い議論が繰り広げられた。

SkyWayテックリードの岩瀬 義昌氏による「SkyWayを使いこなすために」というセッションは、SkyWayに関する基本から応用、ハックから内部関係者しか知らない情報まで盛りだくさんの内容だった。

▲SkyWayテックリード 岩瀬 義昌氏

あまりの情報量に、とてもではないがここでは内容を紹介しきれないため、詳しくは岩瀬氏のスライドをご覧いただきたい。

以下に、筆者として気になったポイントをいくつか書き記しておく。

*SkyWayは、現在開発が停止したPeerJSをベースに開発されていたが、内部はフルスクラッチで書き直しており、継続的なメンテナンスや機能追加を行っている。「古いのではないか」という心配はあたらない

*SkyWayでは、通常のP2P接続に加えSFU（Selective Forwarding Unit）もサポートしており、しかも無償から利用できる。

SFUとは複数のメディアストリームをサーバ側で一本にまとめてクライアントに配信する仕組みであり、多人数のビデオチャットを行う場合などに、P2Pのフルメッシュ型に比べてネットワーク全体の負荷を大きく低減することができる。

SkyWayが提供するRoom APIでは、フルメッシュとSFUを簡単に切り替えることができる。（SFUについてはSkyWayのドキュメントにある説明がわかりやすい）

*APIドキュメントに書かれていない機能もいくつかあり、統計情報の取得なども行える。気になる方は岩瀬さんのスライドを参照のこと。

*安定性やスケーラビリティについては万全の体制を敷いている。 （後のQ/Aセッションによると、開発チームの人員が5人以上の体制で監視しているほか、運営企業であるNTTコミュニケーションズの監視部隊とも連携しており、24時間365日稼働を保証しているとのこと）

SkyWay開発者によるライトニングトーク大会

以降も、ミートアップはまだまだ続く。

ライトニングトーク大会では4人の登壇者がSkyWay開発に関する実際から「やってみた」まで幅広いトピックでプレゼンテーションを行った。

@jumboOrNot氏による「iOSでのSkyWay開発の勘所とTips」

レアジョブ英会話というサービスで、SkyWayを利用したiOSアプリを開発した際の生々しい話。

Skypeで行っていたサービスをWebRTC化することで開けた展望、そしてiOSアプリ開発で直面した問題に対してGoogle Firebaseを用いて対処したことを紹介していた。

▼講演資料はこちら


@massie_g氏による「SkyWayのビデオチャットを録画しよう。そう、ブラウザでね」

現在のWebブラウザが備えるAPIのみを用いて、ビデオチャットの録画を行う方法を紹介。

▼講演資料はこちら


@leader22氏による「SkyWay JS SDKの歩き方」

SkyWayのJavaScript SDK開発をサポートしたPixelGridの杉浦氏による、JavaScript SDKの読み解きガイド。

講演資料: SkyWay JS SDKの歩き方


@lz650sss氏による「SkyWay×Cognitive Service」

SkyWayで受信したビデオチャットの画像をMicrosoft AzureのCognitive Serviceに送信し、表情を読み取るデモ

講演資料: SkyWay × Cognitive Service


フランクなQ/Aセッション、そして開発者だらけの懇親会。これぞデベロッパーファーストなミートアップだ

アジェンダの最後はQ/Aセッション。事前アンケートで集めた質問に対して、開発チームが自らフランクに答えるセッションで、非常に和気あいあいとした雰囲気の中盛り上がった。

そして（無料の）懇親会。会場の至る所で、Web(RTC)開発者同士のハイコンテクストな会話が繰り広げられていた。

最後に、イベントを通じて筆者が感じたことを述べておく。

SkyWayはもちろんプラットフォームであるが、このイベントを通じてSkyWayチームが実現したかったことは、「開発者コミュニティ」というプラットフォームづくりなのだろうと思う。

SkyWayというプラットフォームを提供してリアルタイムコミュニケーション開発の敷居を下げるだけが彼らの役割ではない。

同時に、開発者基盤としてのコミュニティ構築も図ることで、WebRTCを活用したイノベーションが生まれやすくすることも、また彼らの役割なのだと。

SkyWay開発チームのこうした挑戦が実を結び、日本発のプラットフォームが世界を席巻する日を、筆者は見たい。

※本記事はITエンジニアのためのキャリア応援サイト「CodeIQ MAGAZINE」（※2017年11月18日掲載）からの提供記事です。

]]> エキスパートたちが語り尽くす、WebRTCの「つらみ」ーWebRTC Conferenceパネルディスカッションレポート /mganeko/18386/ Fri, 18 Mar 2016 00:00:41 +0000 /?p=18386

こんにちは、がねこです。この記事では先日開催された「WebRTC Conference Japan 2016」から、2日目に行われたパネル・ディスカッション「ここがつらいよWebRTC – WebRTC開発の落とし穴」の内容をご紹介します。

パネラー紹介

パネラーとして、次の3名にご登壇いただきました。モデレータは私が担当させていただきました。

源 拓洋さん
ソフトバンク株式会社所属。社内、グループ会社間で利用するビデオ会議システムを、WebRTCを使って構築、運用されています。主にAndroidのネイティブアプリを担当されていますが、MCU/SFUといったメディアサーバーにも詳しいです。

吾郷 郷さん
ChatWork株式会社所属。クラウド型ビジネスコミュニケーションツールを提供されていて、そのサービスの一環としてWebRTCを使ったビデオ会議/音声通話を実現されています。担当はPCブラウザが中心とのことです。

飯田 アレン 真人さん
NTTコミュニケーションズ株式会社所属。開発者向けにWebRTCを使うためのPaaSであるSkyWayを提供されています。PCブラウザが中心に、サーバー側も担当されているとのことです。

我如古正志（モデレータ）
インフォコム株式会社所属。WebRTCを使った社内用Webチャットシステムや、イベント配信システムを構築、運用しています。クライアント側からサーバー側まで広く浅く担当しています。


下図のように、WebRTCの使い方や担当領域がそれぞれ異なるパネラーの方に、集まっていただきました。

webrtc_panel_position

クライアントサイドでの「つらみ」

サポート対象のブラウザとOSについて

我如古まずはクライアント側で苦労するポイントと、その対策を聞いてみたいと思います。クライアントサイドではブラウザによって実装が異なるなど、苦労するポイントがあると思いますが、まずどのようなクライアントをサポート対象としているか、教えていただけますか？

源 私のところでは社内のツールとしてはChromeがブラウザとして採用されているので、原則的にはChromeのみに対応しています。なのでここに挙げられているFirefox, Safari, IE, Edgeはすべて切り捨てています。

吾郷 うちではChrome, Firefoxをメインに据えていますが、IE/Safariについてはプラグインというかたちで提供しています。Safariについてはプラグインの対応中という段階ですが。Edgeに関してはまだ手が回っていないですが、今後サポートしていきたいと考えています。

アレン SkyWayではChromeとFirefoxがメインになっていますが、IEとSafariもプラグイン対応しています。Edgeはまだ手がついていません。PCアプリに関しては、Electronなどを使って実装することもできます。(iOSやAndroidといった)モバイルアプリもSDKをリリースしています。

我如古 SkyWay以外では、モバイルアプリは対象とされていないのでしょうか？

源 うちでは、iOSアプリケーションについては提供しています。Androidに関しては幸いにしてAndroid版のChromeブラウザがWebRTCに対応しているんですね。なのでレスポンシブデザインみたいなかたちで、Androidの画面解像度に合わせたWebのインターフェイスを提供して対応しています。

吾郷 うちの場合はPCアプリ、モバイルアプリについてはまだ対応中というかたちです。これも追々対応していきたいというステータスになっています。

プラットフォームの差異をどう扱う？

我如古 ありがとうございます。今の中である程度話に出たかもしれませんが、あるブラウザを切り捨てるかどうかどうか、どんな戦略をとられていますか？　またブラウザの異なるバージョンのサポートにはどのようなポリシーを持たれていますか？

源 その点に関しては、先ほど述べた通り、Chromeブラウザ以外は原則的に捨てています。「自分で頑張る」（頑張って差異を吸収する）ということも、もちろん部分部分ではやっています。一律で社内の人は同じブラウザの同じバージョンを使っているはずではあるんですけれども、個別に異なる環境を使ってらっしゃる方もいるので、そのあたりはJavaScriptで差異を吸収しています。Chromeブラウザ間のバージョン差異というのは当然あるので、そこは頑張って吸収しています。

吾郷 うちの場合だと「自分で頑張る」と「便利ライブラリを使う」の両方対応しているという状況です。IE/Safariのプラグインに関しては adapter.js を使うというのが一般的な手法なのでこれを利用していますが、それでも間に合わないところや、FirefoxやChromeでも特定のバージョンで動きがおかしいところは条件分岐して対応するということも、行っています。

アレン SkyWayでは、利用しているライブラリPeer.jsでかなり吸収されているところはあります。対応しきれていないところは、adapter.jsを使ったりして吸収しています。

我如古 Peer.jsも独自で手を入れ、対応しているとお聞きしていますが？

アレン たまに結構古いバージョン（のブラウザ）では、例えばonnegotiationneededイベントに対応していないブラウザなどで動作を変えるとか、そういうコードは入っています。

源 adaptor.js って、ご存知のかた多いですか？…意外と少ないですね。adaptor.jsというのはwebrtc.orgからオープンソースで公開されているJavaScriptで、Firefox, Chrome, Opera間のWebRTC実装差異を吸収してくれます。ただ先ほど述べられた通り、Trackとか一部の扱いについては残念なところがあるので、その辺に関しては自分で一生懸命吸収しないといけないです。 付加情報としてはIEやSafariのプラグインを提供してくれる会社は、adapter.jsと互換のあるインターフェイスを提供していることが多いです。adapter.jsに対応していれば簡単にプラグインが利用できて、マルチプラットフォーム、クロスプラットフォーム対応にできるという大きな利点があります。

我如古 こちらについては、自分で作るのと、他社のライブラリを使うのと、併せて使うということでしょうか。

吾郷 うちの場合は他の会社と協力して開発を行っています。でも実際のところ、お金を払えば全部お任せでうまくいく…かというとそうでもなくて、こちらでも検証して「この部分がおかしい」とフィードバックしながらお互いにやっていくしかないという状況です。どういう会社を選定するかということにもよると思いますが、費用が高い会社さんととそうでもない会社さんと、もちろんあります。（後者なら）こちらからもコスト（労力）をかけて一緒に開発していくようなかたちになるんじゃないかと、思っています。

アレン SkyWayのIEとSafariプラグインは、他社のものを使っております。そこは実装コストが高いのと、すでに安定して動いているモノがあるので、それを使った方が、SkyWayとして集中すべきところに集中できると思っています。 （JavaScriptの）クライアントライブラリに関してはオープンソースがベースになっていますが、そこに本体で行われた修正のマージとか、SkyWay独自の修正とか、両方入れております。

源 たまにありますよね。海外でこのあいだ話題になったのは「Peer.js（本家）の実装よりもSkyWayの実装の方が早いから、SkyWayの方を改造して使おう」という発言。それぐらいSkyWayは有名です。すごいですね！（会場笑）

デバイスの差異をどう扱う？

我如古 実際同じブラウザ、同じバージョンだとしても、デバイスや機種（スペック）によって動く動かないということがあると思いますが、その辺はサポートはどうされていますか？

吾郷 うちの場合はB2Cの個人宅で使われることもあるので、すべての機種をサポートするのは非常に難しい、というのが正直なところです。例えばマシンのスペックが低い状態、かつネットワークの調子がおかしい、通信している相手が多い、など重なった場合などもあります。どこからというスペックの基準を設けることもある程度検討はしていますが、正直なとろ結構難しい対応になっています。

アレン SkyWayはプラットフォームなので、そこはあまり考えていないです。できるだけ広い機種で使えることは目指していますが、アプリの開発者がこの機種をサポートしたかったら、ビデオをあきらめてオーディオだけにしたり、そういうことをしていただいています。プラットフォームとしてすべてのケースをサポートするのは難しいので、アプリの開発者に任せております。

源 うちの場合は社内利用なので、当然のことならが利用される機種に関しても一定の物に限られているので、そういう点に置いてはテストが簡単という部分はあります。しかしながらサポートするデバイスに関しては、iPhone/iOSは機種の数がそもそも少ないのと実装差異がほとんどないので問題ではなかったりします。Androidの方が実装差異というか、機種依存がありますので、そこの部分を一生懸命に吸収することになります。

企業ユースの場合になりますが、パソコンのマイク/スピーカーはそこまでコミュニケーションに最適化された設計になっていなくて、とりあえず内蔵マイク入れてみました、というのが多いので正直言ってあまりよい動きはしません。音周りについては本来コミュニケーションするために作られた電話機（スマートフォン）というのは凄く有効に使えます。

パソコンに関しては映像はあまり問題が出なんですけど、音に関しては聞こえづらいなと問題がやっぱり出てきます。そういう点に関しては、USBのヘッドセットやUSBの会議用マイクスピーカーを使うということをやるだけで、まったく違うレベルの品質が提供できます。ユーザーサポートとしては会議用マイクスピーカーを一回利用したいという部署に貸し出して試してもらって、良いと思えば買ってもらう、としています。やるとだいたい購入という話になります。それぐらい変わります。

WebRTCの音声品質はもともとものすごく良いんですね。Opusというコーデックで圧縮されているということで、VoLTEレベルの音声品質は普通に出ているはずです。音声品質が悪いのはだいたいパソコン側の要因です。オートゲインコントロールの暴走もあります。そういった現象も回避できるので、Web会議用のスピーカーを利用するというのを、原則として勧めています。

「繋がらない苦労」を共有してみる

我如古 話題が尽きないんですけれども、次の「繋がらない話」に入りたいと思います。（WebRTCを使ったシステムを）実際に動かすと「繋がらない」と言われることがよくあると思います。一言で「繋がらない」と言っても、現象や原因は様々だと思うので、その辺を聞いてみたいと思います。みなさん実際にサービスを提供されていて、「繋がらない」と言われることはよくありますか？ほとんどないですか？

源 「繋がらない」と言われることは、「あるかないか」でいうと、もちろんあります。どういう要因で繋がらないかというとなかなか難しいところではありますけどね。

我如古 じゃあ、繋がらない理由として、 よくあるケースを紹介していただけますか？

吾郷 うちの場合だと、よくある例としてPCのスペックというのもかなり大きくあります。ブラウザの種類の問題というのも、もちろんあるんですが、例えばChromeでつながらないという場合だと、PCのスペックが足りなくて、参加人数が多いと後から来た人が入れないことがあります。ユーザーさんから見て使っていて何が起こっているのかよく分からない状況になってしまうので、それで「繋がらない」という話になってしまいます。

もちろんネットワークの問題とかもあるんですが、最初から全く繋がらないという状態と、途中から入る人が入れないという状態だと、「繋がらない」という問い合わせは後者の方が多いです。

源 追加の方が繋がらないと言われることが多いということですか？

吾郷 実際使っていると、その方が動作に違和感を覚えるという意味です。

源 あー、なるほど。ということは、初期のWebRTC接続に関しては普通に抜けてしまう（繋がる）ケースの方が多い？

吾郷 もちろん、それでつながらないというケースもあるにはあるのですが、その場合だとこちらからもある程度サポートはしやすいというか、切り分けはかなり楽です。そうでない場合、人数が入ってくると後の人が繋がらないという状況になると、どういうふうにサポートしてよいか難しくなるという問題があります。

我如古 プラットフォームだといろいろなケースがあると思いますが？

アレン 一般的に使われている方からはそんなに問い合わせはないんですけど、大企業でデモしたりする時って、やっぱり企業のネットワークってかなり制限が多いので、そこでつながらないことが非常に多いです。そもそもWebSocketが通らないからシグナリングできないとか、Man-in-the-middleで完全にブロックされているとか…。

我如古 最悪ですね（苦笑）。

アレン 本当にそういうケースが多くて、ネットワークポリシーをちょっと変えてもらったら繋がるケースも多いです。やっぱり企業ネットワークはすごく難しいです。

ただ、社内ネットワークの内側同士だったら意外とよく繋がるんですね。弊社でも（PCのポリシーの制約で）カメラとマイクはつなげられないんですけど、DataChannelでファイル送ったりすることはできるので…（笑）。

明るい話をしよう。WebRTCは繋がる！

源 一応「明るい展望の話をしよう」という話になっていたはずなので、ちょっと話の流れ変えていいですか(笑)。繋がらない話ばかりだとみんな「WebRTCはつらい」と思っちゃうでしょうし。

ざっくり言うと大多数の人は繋がります。「繋がらない」と我々がしゃべっているのは、「繋がらない」ケースについて取り上げているだけ、だいたいの人は繋がります。どれぐらい繋がるかというと、

  • 家庭-家庭間ではほぼ間違いなく繋がる
  • 家庭-携帯端末間もほぼ間違いなくつながる
  • 企業-家庭間もほぼ間違いなくつながる
  • 繋がらないのは、企業-企業間

と、こんな感じでまとめられると思います。

企業-企業間に関しては利用頻度が高い場合は、そこのネットワーク管理者に相談して、自分たちのサーバーだけ何とか通してくれという交渉ができると思っているので、原則的には繋がるものだと考えていただいてよいです。「繋がらないというのは、あくまでもレアケース」、ということは持ち帰っていただけると幸いです。

我如古 企業の場合はガードされているけど、理由があれば開けてもらえる、というところがあると思います。

吾郷 ここでどういうふうに開けるかという問題があって、サーバーを分散しているときにそれのIPアドレスを教えてくれと言われて、つらいという話があったりもします。

我如古 動的にIPアドレスがふられる場合ですね。

吾郷 はい。DNSで名前振ってるので、それを指定して開けるのが難しい場合もあって（IPアドレス指定が必要なとき）、そういう時は、結構うーん、というような状況になることがあります。

源 動的な場合は難しいですね…。でもいろいろやりようはあると思っていて、例えば繋がるようにするのであれば、対象となる企業が決まっていれば、その企業向けにTURNサーバーを（固定で）立ててあげるというのも十分良いと思います。そのTURNサーバー向けの通信は全て通してくださいね、というお願いの仕方はあると思っています。

吾郷 うちの場合はそこまで各企業さん向けに大きくカスタマイズして提供することは難しい事情もあります。なので、どういうふうにサービスを提供したいか、だれに対してどのようなかたちでサービスを提供したいか、によってここの解決方法は選択肢があるのかな、と。

逆に言えばそこの部分をかなり考えないと、あとあとすごく大変になってしまうという事態はありえると思ってます。

源 ちなみに弊社におけるつながらない問題に関しては、通信環境の問題で繋がらないというのは、ほぼほぼ無いです。というのは、そういう風にして繋がるように（設定や設置を）工夫しているというのはあるんですが、原則的に繋がらないというのはレアケースになります。

ユーザーから繋がらないという問い合わせが来るもので一番件数が多いのは「カメラとマイク」の問題です。「カメラとマイク、(PCに)つながってませんでした～」とかも結構あるのですが、最多は最初に getUserMedia() でブラウザがユーザに許可を求めて来た際に、「今回は私は映像使わないからとか、見ているだけだから映像音声いらない」ということで一回拒否をしちゃうんですね。

ユーザへの権限許可の求めかた

一回拒否しちゃうと、二回目そのページを開いたときも、ブラウザはその設定を読み込んじゃうんですよ。そうすると二回目以降その人が映像音声使いたくても、ブラウザとしてはポリシーに拒否が設定されているので、ユーザとしては「繋がらない」というかたちで結果が出てきます。

そういうところは（世の中的にも）結構な問題になっていて、FirefoxとChromeではその警告の出方が違うんですね。なので（ユーザへの）案内の仕方とかマニュアルの作り方とかも変わってくるんですね。海外のサービスを見ていると結構おもしろくて、getUserMedia()の許可を取ってねというのは、画面いっぱいにすごくドーンと出るんですよ。あーいうのってすごく重要なんだなーと見ています。

アレン サンプルアプリでChromeとFirefoxに対応して「ここをちゃんとクリックしてね」と出しても、だれも読んでくれないです（笑）。だから全画面でやらないとスルーされてしまうので、そこは注意しなければいけないです。

源 辛いですねー。昨日のセッションで発表されていた Appear.in とかは、なのでちょっと見に行って参考にさせてもらうと、あー、やっぱりこうやらないと問い合わせくるよねー（と思います）。

利用者の多いサービスは問い合わせ件数を下げることに一生懸命になりますから、やっぱりUIとかもそういう工夫していると思います。なので「なんでこうなっているのだろう？」という疑問から入るといろいろ解決していくのかなと。

吾郷 うちの場合いくつかの言語に対応しているので、その部分の多言語対応が必要だったりとかします。単純にメッセージを変えるだけではなく、画面キャプチャーして「この部分のこのアイコンをクリックしてね」というのがその言語ごとに必要になったりして、それかけるブラウザ数になって、「ああああ…」ていうかたちになったりも、しています

源 やっぱり標準化してほしいですよねー。


それでもやっぱり繋がらなかった時の対処法

我如古 じゃあ、いままでですごいレアな、「こんな原因でつながらなかったのか」という例があれば紹介していただけますか？

源 インターネットだけ頑張って抜けるようにしている環境だと、シグナリングサーバー（チャットサーバー）までは来ているのに、その後のWebRTCは繋がらないという特殊な環境の人は、一定数あります。レアケースだとは思います。

吾郷 OSのファイアーウォールの設定だとか、ネットワーク上は通信はできるのに、そのPCの設定や中のファイアーウォールの設定で繋がりにくかった、それも全く繋がらないわけではない、という状況になったことはあります。

アレン これは繋がらないわけではないのですがちょっと面白い話で、社内のハッカソンをやった時に、家庭用ルーターを使ってみんなアプリを作っていました。何時間か経ってアプリが動き始めたら、フルメッシュで10×10の通信が家庭用ルータを通って、融けました（笑）。それ以降通信できなくなってしまいました。家庭用ルーターでむっちゃ大量通信する場合は注意してください。

源 あります、あります。それはあります。社内利用の場合にはある特定のフロアでみんなが利用して、そのフロアの無線LANルーターが死亡して、解像度が下がって画質がすごく悪くなったんだけど…（と言われる）。それは皆が使うと帯域狭くなって画質が動的に下げられてしまうので、悪くなるのは当たり前なんですけど、そういうことは起こりますね。

我如古 いろいろ原因があると思いますが、何か切り分けとか情報収集とかする仕組みって用意されていますか？　あるいはユーザーが自分で切り分けられるツールとか、そういう工夫があれば教えてください。

源 そういう点に関してはtest.webrtc.orgというサイトがあって、そこで一通りのテストは通せるので、それの社内版を作って（ユーザーに）テストしてもらうということを、我々の場合にはやっています。

我如古 自分でやってもらうということですね？

源 ユーザーにやってもらう形になります。もちろん社内利用なのでブラウザから出てくるの情報であったり、接続用の交換情報であったりはログとして取ってあるので、繋がらないという連絡を受けた時はその人のログを追いかけて、その人の接続系の情報を見てそこから判断することも、実際にやっています。

アレン こちらも似た感じで、シンプルなアプリでまず試してもらってます。あと Peer.js というライブラリを使っているので、開発者にログを見てもらって、setRemoteDescriptio()でコケたとかいうのが分かるので、それで見てもらいます。それでも解決しなかったら、ログを収集して、結構シンプルなところで落ちていることが多いので、例えばAPIキーが間違っているとか、そういう手段を使っています。

吾郷 うちの場合は一緒に開発してくださっているベンダーさんといろいろやり取りしながら、その上で状態が分かるエクステンションを使ったりすることはあるのですが、一般ユーザーの方が情報を得られるというかたちでは現状できていないです。

源 この（資料のページ）の下二つは良いですね。「現地に見に行く」と、「超能力で透視する」（笑）。

我如古 社内だと（見に行くは）ありますよね？

源 そういうこともやりたいのですけど、なかなか難しいんですよね。現地見に行こうとすると片道4時間かかるからこの日飛ぶよねーとかもあるので、現地見に行くというのはなかなか厳しいなーと思います。でもそれって、情報欲しいじゃないですか？どうやって収集するのかと考えるんですけど、そこのネットワーク構成教えてくださいと言っても、ネットワーク構成した人がすでにいなかったりするので、そうすると全然わからないんですよね。なので現地見に行くっていうのはかなり難しいなと思います。
WebRTC界隈の人で集まると、だいたいの人が超能力で透視しているので、ちょっとそれはどうなんだろうなーと思ったりします（笑）。

サーバサイドもつらい？

我如古 残り時間も少なくなってきたので、最後サーバーサイドの話をしたいと思います。WebRTCでブラウザ同士がP2P通信するというので最初やろうとすると私も躓いたのですが、なんだサーバーが要るじゃないの、全然嘘じゃんと思うんですよね。

いろんな環境で使おうとすると(TURNなど)サーバーの種類が増えて、さらに大規模に使おうとするとサーバーこそがちゃんと作らないと繋がらないということになりますよね。その辺を聞いてみたいと思います。

シグナリングはどうされていますか？　既存の互換の仕組みを使うケースもあるし、独自の仕組みを作るケースもあるし、あるいはサービスを使うケースもあると思うんですけど？

吾郷 うちの場合は自社ではなくて、一緒に開発しているところの方を使っています。どこがお勧めか、と書かれているのですが、正直なところケースバイケースで、簡単に言えば金額が高いところは丸っと収まる回答になると思うのですが、なかなかそういう（高い金額を出す）のも難しかったりすると、選択は難しいです。

実際、シグナリングサーバーの安定性だとか、通信の繋がる/繋がらないの問題だとかに関して、どのくらいノウハウを持っていてそれが製品に反映されていくのかというのが、外から見ているとほとんど分からないというのがあるので、ここはかなり難しい問題だなと思ってます。

アレン 自社で持っています。おすすめするならSkyWayです（笑）。

我如古 これで違うのが出てきたらびっくりしますね（笑）。

源 SkyWayさん、すごく検証されていますもんね。えっと、うちも自社で持っています。ちょっと前まで違う物を使っていたのですが、最近(node.jsの)Socket.ioという流行りのものに変えてみようかなーと、一人で画策しています。なので、実装的にはWebSocketになります。

ただ、WebSocket意外と抜けないんです。WebSocket抜けないのにWebRTC抜けるというネットワークが平然と存在しているのが結構断崖でして、抜けるという点においては、XHRとかSSE(Server Sent Events)とかは意外と普通に抜けるので、接続系だけでもそっちにした方がよいのかなと思いつつも、クライアントの負荷が増大するので、難しいなと思っている今日この頃ですね。

我如古 ありがとうございます。シグナリングが終わってもSTUN/TURNといったNAT/Firewallを超えるためのサーバーを使うと思いますが、こちらも自分で運用するか、他社のを使うか。自分で運用にするにしても（地理的に）地球上のどこに置くか、というのがあると思うのですが、その辺はどんなか考えを持たれていますか？

吾郷 うちの場合はシグナリングサーバーと同じように外部で提供してもらっているサーバーを使用しています。地理的なところで言うとUSのAWSの中なんですが、ただ使ってて実際に国内to国内でTURNを使った環境っていうので通信をすることがあるのですが、その辺に関して直接繋げるときと比べてすごく遅延が発生しているという感覚はそこまで大きくないですね。

今のところここに関しては、そんなに問題になってないです。もちろんこちらに、日本に置いてほしいという要望は上げてはいるのですが、そこに関しては現状そこまで大きな問題とは認識していないです。

アレン TURNサーバーも自社で提供しております。これは弊社のCloudnというクラウドサービスに乗っているので日本にあります。 主にお客様が日本のかたが多いので、あまりそれで問題はないです。ただ今後世界中に展開したいという話があります。

源 採用しているアーキテクチャの都合上TURNサーバーというのはほとんど使わない仕様にもなっているんですけれども、TURNサーバー自体は通信会社ですので、自社の基盤の上に持っています。当然日本にあります。

我如古 そうすると次の質問はあんまり問題にならないのでしょうかね？ TURNサーバーお金かかりますよねということを聞こうと思ったのですが、基盤を持っている会社さんはあまりその辺は気にならないというところがあるのでしょうか？

源 気にならないというとこももちろんあるんですけれども、そもそもTURNを使うというのはそれなりにレアケースなので、普通に提供していたとしてもそれほど気にならないです。というのは、1サーバーTURNで立っているくらいの認識ですね。

アレン SkyWayでもかなり接続数がありますけども、今のところTURN 1台で足りておりますので、あんまりそこは気にしておりません。

吾郷 うちの場合もお願いしているので具体的にどういう風にスケール対策をしているかというところまで、こちらから大きく踏み込んで何か調査だとか依頼だとかしていることではないのですが、ただWebRTCを使うときのコストに関して言うとおそらくTURNサーバーを使うかどうかというところで非常に大きく変わるのかなと思っていまして、ここはやっぱりどんぐらいお金を払うかというところにかなり依存します。

最初に使うだけで結構金額がかかるっていう会社さんと、TURNサーバーを使うかどうかで金額が変わる会社さんと、2種類あって、TURNサーバーを使うかどうかはその辺でかなり変わってくるのですが。

この質問のスケーリングというところだけに関して言うと、外部のベンダーさんに依頼している場合はそこまで問題にならない。うちの場合もTURNサーバーが遅いだとか、止まるっていう事態に関してはそこまで問題にはなっていないので。

源 平均1日1万セッションのSkyWayさんでもTURNが1台でよいというのは、何か元気が湧いてきますね（笑）。

我如古 ほとんどTURNを使わずに済むということですね。

源 でかいコスト要因だと思うんですけどもね。


会場からのQ&A

我如古 この辺りで来場のみなさんの質問を受けつけたいと思います。何か質問とかある方は、手を挙げてください。

会場から1 貴重な話ありがとうございます。つながらない問題にちょっと近いところなんですけれども、弊社で社内で利用するためにシグナリングサーバー立ててやろうとしているんですけれども、DataChannel使ったファイル転送みたいなことをやろうとしていて、ファイルのサイズがそんなに大きくない間は比較的安定稼働するんですけれども、ファイルが100MB, 1GB、10GBというふうになってくると、ネットワークの帯域の問題は置いておいたとしても、ブラウザが応答しなくなるとか、受け側が突然何にも言わなくなるみたいな事象が出てしまっていて、何をどうしたらよいのか分からないという感じになってしまっているのですが、もしそのあたり何かお知恵があれば教えていただきたいなと思っております。

アレン 弊社で使っているものは結構細かく、数百キロバイトぐらいに分けて送っております。たしか、そこを直接書いていないので正確には覚えていませんが、たしかバッファーが足りないとかの問題で上手くいかないので、細かく分けて送る方法の方が良いともいます。

会場から1 いまPeer.jsに手を入れて使っているんですけども、SkyWayさんのライブラリだとそのあたりがもう少し安定するという感じなんですね？

アレン そこはPeer.jsの実装と同じなので、アプリ側で分けて送信するという仕組みが必要になります。

会場から1 ありがとうございます

我如古 他にいかがでしょうか？

会場から2 SkyWayに関して質問です。SkyWayを使ってアプリを作ろうとしているんですが、SkyWayは同時接続に関してどれぐらいのテストをされているのですか？

アレン （同時接続に関しては）テストはそれほどしておりません。ただ今のところ同時接続数が多すぎて落ちたことはないと思います。仕様上、WebSocketの接続は、同時10万セッション可能としております。ただそこまで上がったことがないので、なんとも。

我如古 今の（質問）はシグナリングサーバーの接続数のことでしょうか？　それともブラウザ側の接続数のことでしょうか？

会場から2 シグナリングする時にクライアント側から一気に同時接続かかった場合、サーバーがもつのかどうか？　という話なんですが

アレン 今のところ問題になるような接続数はないですが。

会場から2 （今後）もしかしたらあるかもしれない、ということですよね。分かりました。

我如古 何か最後言い残したこととか、他の人に聞いてみたいこととかあれば、一人ずつどうぞ。

源 言い残したところという訳でもないのですが、原則的には繋がるテクノロジーなので、特に問題はないとは思っています。 先ほどの同時接続の話にしても、サーバー側が受け付けられる上限よりも、ブラウザー側が同時に通信できる上限の方が先に到達してしまうので、ボトルネック要素というのは常に変わっていくのかな、と思っています。

吾郷 実際ちゃんとしたビデオ会議システムと言いますか、すごく大手の方が作られているものと同じものを作ろうとすると、WebRTCというのは全然まだまだ発展途上で辛いという問題が多いのですが、ただそうでない方法、クラウド上で簡単に通話だとか会話だとか、もしくはP2Pのデータ送信ができるというところで捉えると、もっとかなり可能性の大きいものなんじゃないかと、思っています。 それであれば今でも十分使えるし、ユースケースもこれからももっともっと広がっていく、広げていくところに、価値があるんじゃないかと私は考えています。

アレン じゃあ二人に質問があるんですけれど、WebRTCって本当に毎月何かが変わっているんですけど、変更にどうやって追い付いていくかを、ちょっとお聞きしたいんですけれど。結構いろいろ参加しているのに、結構落としているところがあるので、そこだけ。

我如古 じゃあ、一言ずつどうでしょう？

源 どうやって追い付くかという点においては、テストするしかないです。これは新しいChromeブラウザが出ると一通りの機能についてはちゃんとテストをしています。

吾郷 うちの場合には基本的には外部の会社さんにお願いしているというのと、弊社でも実際これを使いながら仕事をしているので、その上で見つけていく、自分たちでドッグフーディングしていく、ということしかないかなと思います。

源 一言だけ追加で。http://webrtcjp.info/ というページがあるんですね。これは確かSkyWayの方々やっておられると思うんですけど、そこにslackがあります。このslack、結構今回登壇している方だとかが入っています。なので質問するとすぐ答えてくれます。WebRTC開発やろうという方は、とりあえずつまったらそのSlackに投稿してみてください。だれか答えてくれるはずです。しかも、かなり高い精度で答えてきます。

我如古 では、これで終わりたいと思います。どうもありがとうございました。

]]> SkyWay iOS/Android SDKを使って、WebRTCアプリを開発しよう /sho-y/17863/ Thu, 24 Dec 2015 00:00:53 +0000 /?p=17863 連載： WebRTCプラットフォーム ”SkyWay” 入門 (5)

連載5回目の今回は、12月にアップグレードされたSkyWayのiOS/Android用SDKのチュートリアルをお届けします。

iOS/Android用SDKを使うことで、SkyWayの特徴である「WebRTCを使ったP2P通信を簡単に実現」することができます。 また、APIもJavaScript版とほぼ同じで、JavaScript版をすでに利用されている方にも実装しやすく、JavaScript/iOS/Android間での通信もサポートしています。

この記事では、そんなiOS/AndroidのSDKの利用方法を、それぞれサンプルアプリのビルド方法や解説を交えながらご紹介していきます。

まずは、iOSのサンプルアプリのビルド方法からご紹介します。Androidのみ開発される方は読み飛ばしてください。

iOSのサンプルアプリのビルド方法

まず、まだSkyWayに登録されていない方はSkyWayのサイトから開発者登録を行ってください。その際の利用可能ドメインですが、ドメインをお持ちでない方は「localhost」等、適当な文字列を指定してください。

次に、iOS SDKをダウンロードします。
iOS SDKのダウンロードページにアクセスして下さい。

iOS SDKのダウンロード方法

ページ下部のDownloadsからダウンロードして下さい。 解凍したフォルダの中に「SkyWay.framework」というものが入っており、これがiOS SDK本体になります。

次はサンプルアプリプログラムのダウンロードを行います。
SkyWay-iOS-Sampleのレポジトリをクローンするかダウンロードを行って下さい。（下図はダウンロードする場合） iOSサンプルアプリのダウンロード方法

次に、サンプルアプリのフォルダにはSDKが含まれていないので、サンプルアプリプロジェクトにSDKを入れます。 iOS SDKのコピー

先ほどのSkyWay.frameworkを「SkyWay-iOS-Sample > frameworks」内にコピーします。

サンプルアプリを動かすためには、開発者登録をした際のAPIキーとドメインを設定する必要があります。
では、サンプルアプリプロジェクトを開いて設定してみましょう。

SkyWay-iOS-Sample.xcodeprojをXcode（本記事ではVersion 7.1.1）で開き、
SkyWay-iOS-Sample > SkyWay-iOS-Sample内の「DataConnectionViewController.m」を開きます。

//
// MediaConnectionViewController.m
// SkyWay-iOS-Sample
//

#import "MediaConnectionViewController.h"

#import <AVFoundation/AVFoundation.h>

#import <SkyWay/SKWPeer.h>

#import "AppDelegate.h"
#import "PeersListViewController.h"


// Enter your APIkey and Domain
// Please check this page. >> https://skyway.io/ds/
static NSString *const kAPIkey = @"yourAPIKEY";
static NSString *const kDomain = @"yourDomain";


typedef NS_ENUM(NSUInteger, ViewTag)
{
  TAG_ID = 1000,
  TAG_WEBRTC_ACTION,
  TAG_REMOTE_VIDEO,
  TAG_LOCAL_VIDEO,
};

コードの上方部分に、上図のような箇所があるので、ここにAPIキーとドメインを設定して保存しましょう。

「MediaConnectionViewController.m」にも同様の箇所があるため、こちらも修正します。 iOSサンプルアプリのビルド

ここまで終わったら、ビルドする端末を接続・選択して、ビルドをします。 以上がiOSのサンプルアプリのビルド方法です。

次はAndroidのサンプルアプリのビルド方法をご紹介します。 iOSのみ開発される方は飛ばしてください。

Androidのサンプルアプリのビルド方法

まずはiOSと同じく、まだSkyWayに登録されていない方はSkyWayのサイトから開発者登録を行ってください。その際の利用可能ドメインですが、ドメインをお持ちでない方は「localhost」等、適当な文字列を指定してください。

次に、Android SDKをダウンロードします。
Android SDKのダウンロードページにアクセスして下さい。 Android SDKのダウンロード方法

ページ下部のDownloadsからダウンロードして下さい。 解凍したフォルダの中に「SkyWay.aar」というものが入っており、これがAndroid SDK本体になります。

次はサンプルアプリプログラムのダウンロードを行います。
SkyWay-Android-Sampleのレポジトリをクローンするかダウンロードを行って下さい。（下図はダウンロードする場合） Androidサンプルアプリのダウンロード方法

次に、サンプルアプリにはSDKが含まれていないので、サンプルアプリ内にSDKを入れます。 Android SDKのコピー

先ほどのSkyWay.aarを「app > libs」内にコピーします。

サンプルアプリを動かすためには、開発者登録をした際のAPIキーとドメインを設定する必要があります。
では、サンプルアプリプロジェクトを開いて設定してみましょう。

サンプルアプリのフォルダををAndroid Studio（本記事ではVersion 1.4）で開き、
app > src > main > java > io.skyway.testpeerjava 内の「DataActivity.java」を開きます。

package io.skyway.testpeerjava;

import ...   //省略


public class DataActivity
    extends Activity
{
  private static final String TAG = DataActivity.class.getSimpleName();

  private Peer           _peer;
  private DataConnection _data;
  private Handler _handler;
  private String   _id;
  private String[] _listPeerIds;
  private Boolean  _bConnecting;
  private Runnable     _runAddLog;
  private List<String> _aryLogs;
  private Bitmap _image;


  @Override
  protected void onCreate(Bundle savedInstanceState)
  {
    super.onCreate(savedInstanceState);

    Window wnd = getWindow();
    wnd.addFlags(Window.FEATURE_NO_TITLE);

    setContentView(R.layout.activity_chat);
    _handler = new Handler(Looper.getMainLooper());

    Context context = getApplicationContext();


    //////////////////////////////////////////////////////////////////////
    //////////////////  START: Initialize Peer ///////////////////////////
    //////////////////////////////////////////////////////////////////////


    // connect option
    PeerOption options = new PeerOption();

    // Please check this page. >> https://skyway.io/ds/
    //Enter your API Key and registered Domain.
    options.key = "";
    options.domain = "";

    // PeerOption has many options. Please check the document. >> http://nttcom.github.io/skyway/docs/

    _peer = new Peer(context, options);
    setPeerCallback(_peer);

コードの上方部分に、上図のような箇所があるので、ここにAPIキーとドメインを設定して保存しましょう。

「MediaActivity.java」にも同様の箇所があるため、こちらも修正します。 Androidサンプルアプリのビルド

ここまで終わったらビルドを行い、端末を選択します。 以上がAndroidのサンプルアプリのビルド方法です。

では、コードを参考にしながら、簡単にAPIの使い方を見ていきましょう。

ビデオチャットのコード

iOSとAndroidの二種類のSDKをご紹介をしましたが、この二つのAPIは細かいところを除いては、ほぼ同じです。また、サンプルアプリのコードもほぼ似通ったものとなっています。
そのため、ここではAndroidのビデオチャットのコードを参考にしながら、簡単にAPIの使い方をご紹介します。

また、WebRTC技術についての説明は割愛します。 詳しいWebRTCの仕組みについては、がねこまさしさんが書かれたコチラの記事をお読みください: 壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう

ではまず、APIの使い方の前に、サンプルアプリの動作を確認します。

android_sample_seq1

android_sample_seq2

このように、

  • シグナリングサーバ*1との接続とPeerIDの取得
  • 自分の映像の取得と表示
  • PeerIDの一覧取得
  • 選択したPeerIDへの通話呼び出し
  • 相手の映像の取得と表示

を行う、とてもシンプルなアプリです。

では、この動作に沿ってコードを見ていきましょう。
まずは、SkyWayとのサーバとの接続です。

//////////////////////////////////////////////////////////////////////
    //////////////////  START: Initialize SkyWay Peer ////////////////////
    //////////////////////////////////////////////////////////////////////

    // Please check this page. >> https://skyway.io/ds/
    PeerOption options = new PeerOption();

    //Enter your API Key.
    options.key = "";
    //Enter your registered Domain.
    options.domain = "";


    // SKWPeer has many options. Please check the document. >> http://nttcom.github.io/skyway/docs/

    _peer = new Peer(context, options);
    setPeerCallback(_peer);

    //////////////////////////////////////////////////////////////////////
    ////////////////// END: Initialize SkyWay Peer ///////////////////////
    //////////////////////////////////////////////////////////////////////

ここではSkyWayのシグナリングサーバとの接続を行っています。

まず、接続を行う時のオプションをPeerOptionクラスで設定します。
このクラスでまず必須なのは、SkyWayを利用するためには必須となる「APIキー」や「ドメイン」の設定です。
そのほかにも、SkyWayが提供するTURNサーバの利用を選択する「turn」プロパティや、自前のSTUN/TURNサーバを設定する「config」プロパティ等の設定が可能です。もっと詳しく知りたい方はドキュメントをご参照ください。

次に16行目では、このオプションを使ってシグナリングサーバと接続を行っています。
このPeerクラスはシグナリングサーバとの接続を管理しており、「connect/call」メソッドでのP2Pのデータ/メディア通信の開始や、「listAllPeers」メソッドでのAPIキー毎のアクティブなPeerIDを取得、などができます。
実際にサンプルアプリでは、「Calling」というボタンを押すとlistAllPeersメソッドを呼び出し、PeerID一覧の取得を行っています。

続いて17行目では、このPeerオプジェクトのコールバックを設定しています。
コールバックの説明の前に、ローカルの映像取得部分を見てみます。

//////////////////////////////////////////////////////////////////////
    ////////////////// START: Get Local Stream   /////////////////////////
    //////////////////////////////////////////////////////////////////////
    Navigator.initialize(_peer);
    MediaConstraints constraints = new MediaConstraints();
    MediaStream _msLocal = Navigator.getUserMedia(constraints); 

    Canvas canvas = (Canvas) findViewById(R.id.svSecondary);
    canvas.addSrc(_msLocal, 0);

    //////////////////////////////////////////////////////////////////////
    //////////////////// END: Get Local Stream   /////////////////////////
    //////////////////////////////////////////////////////////////////////

ここでは、ローカルの映像取得を行って、得た映像ストリームをViewに表示しています。
NavigatorオブジェクトのgetUserMediaメソッドを呼び出すことで、MediaSteamオブジェクトの映像ストリームを得ることができます。その際に、MediaConstraintsというオプションを指定することで、映像/音声の利用可否の指定、インカメラ/アウトカメラの指定、などを行うことができます。

また、CanvasクラスはGLSurfaceViewを継承しており、得た映像ストリームはCanvasオブジェクトのaddSrcメソッドで表示することができます(iOSのSKWVideoオブジェクトはUIViewを継承しています)。

では、話を戻してPeerオブジェクトのコールバックを見てみましょう。

//////////////////////////////////////////////////////////////////////////////////
    ///////////////////// START: Set SkyWay peer callback   //////////////////////////
    //////////////////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    // !!!: Event/Open
    peer.on(Peer.PeerEventEnum.OPEN, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバと接続された
        _id = (String) object;

        updateUI();
      }
    });

    // !!!: Event/Call
    peer.on(Peer.PeerEventEnum.CALL, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 相手から通話がかかってきた
        _media = (MediaConnection) object;

        _media.answer(_msLocal);

        setMediaCallback(_media);

        updateUI();
      }
    });

    // !!!: Event/Close
    peer.on(Peer.PeerEventEnum.CLOSE, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバとの接続ステータスがdestroyedとなった
      }
    });

    // !!!: Event/Disconnected
    peer.on(Peer.PeerEventEnum.DISCONNECTED, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバとの接続ステータスがdisconnectedとなった
      }
    });

    // !!!: Event/Error
    peer.on(Peer.PeerEventEnum.ERROR, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 何かしらのエラーが発生した
      }
    });

    //////////////////////////////////////////////////////////////////////////////////
    /////////////////////// END: Set SkyWay peer callback   //////////////////////////
    //////////////////////////////////////////////////////////////////////////////////

ここでは、シグナリングサーバから送られたイベントに対し、処理を行っています。

7行目は、シグナリングサーバとの接続が確立した際の「OPEN」イベントでの処理です。
ここでのObjectは、シグナリングサーバから自分に割り当てられたPeerIDが格納されており、サンプルアプリでは、そのPeerIDを表示しています。PeerIDはnew Peer時にIDを指定することもできますし、指定せずにランダムなIDを取得することもできます。

20行目では、他のPeerから通話がかかってきた際の「CALL」イベントでの処理です。
ここでのObjectはMediaConnectionクラスであり、answerメソッドを呼ぶことで、先ほど作成した自分の映像ストリームを返しています。引数を与えないことで、映像ストリームを返さないことも可能です。
そのあと、30行目でMediaConnectionのコールバックを設定しています。

このように、相手からの通話を受ける際は、Peerオブジェクトのコールバック内で「CALL」イベントで処理を行います。
自分から通話する場合は、下記のようにPeerオブジェクトのcallメソッドを呼びます。

//////////////////////////////////////////////////////////////////////
    ////////////////// START: Calling SkyWay Peer   //////////////////////
    //////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    CallOption option = new CallOption();

    _media = _peer.call(strPeerId, _msLocal, option);

    setMediaCallback(_media);

    //////////////////////////////////////////////////////////////////////
    /////////////////// END: Calling SkyWay Peer   ///////////////////////
    //////////////////////////////////////////////////////////////////////

この部分は、listAllPeersメソッドで得られたPeerIdの一覧から、通話したいPeerIDをタップした時に呼ばれます。

このように、呼び出し時のオプションを設定し（このコードでは何も設定していませんが）、通話をしたいPeerIDと自分の映像ストリームを指定してcallメソッドを実行します。返り値は通話がかかってきた際と同様、MediaConnectionクラスで、MediaConnectionのコールバックを設定しています。

では、MediaConnectionのコールバックを見てみましょう。

//////////////////////////////////////////////////////////////////////////////////
    //////////////  START: Set SkyWay peer Media connection callback   ///////////////
    //////////////////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    // !!!: MediaEvent/Stream
    media.on(MediaConnection.MediaEventEnum.STREAM, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        _msRemote = (MediaStream) object;

        Canvas canvas = (Canvas) findViewById(R.id.svPrimary);
        canvas.addSrc(_msRemote, 0);
      }
    });

    // !!!: MediaEvent/Close
    media.on(MediaConnection.MediaEventEnum.CLOSE, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        Canvas canvas = (Canvas) findViewById(R.id.svPrimary);
        canvas.removeSrc(_msRemote, 0);

        _msRemote = null;
        _media = null;

        updateUI();
      }
    });

    // !!!: MediaEvent/Error
    media.on(MediaConnection.MediaEventEnum.ERROR, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 何かしらのエラーが発生した
      }
    });

    //////////////////////////////////////////////////////////////////////////////////
    ///////////////  END: Set SkyWay peer Media connection callback   ////////////////
    //////////////////////////////////////////////////////////////////////////////////

7行目は、通話相手の映像ストリームを取得した際の「STREAM」イベントでの処理です。ここでのObjectは、MediaStreamオブジェクトです。自分の映像ストリームと同じくCanvasオブジェクトを利用して表示しています。

20行目では、通話相手との通話が切断された際の「CLOSE」イベントでの処理です。

ここまでが、簡単なSkyWayを使ったWebRTCの処理になります。

最後に、最近のアップデートで追加されたメソッドについてご紹介します。

Button switchCameraAction = (Button)findViewById(R.id.switchCameraAction);
    switchCameraAction.setOnClickListener(new View.OnClickListener()
    {
      @Override
      public void onClick(View v)
      {
        Boolean result = _msLocal.switchCamera();
        if(true == result)
        {
          //Success
        }else
        {
          //Failed
        }
      }
    });

MediaStreamオブジェクトがローカルの映像ストリームの場合、switchCameraメソッドを呼び出すことができます。
これにより、今まではできなかった、「getUserMedia後のインカメラ/アウトカメラ切り替え」が可能になります。

以上が、サンプルアプリの簡単なコード解説になります。今回はビデオチャットだけの紹介でしたが、ほぼ同じようなAPIでテキストや画像が送れるデータチャットも可能です。

おわりに

今回は、SkyWayのiOS/Android用SDKのチュートリアルをお届けしました。

JavaScript版と同じように、手軽にWebRTCが利用可能です。 是非ご自身のアプリケーションに組み込んでみてください！

]]> SkyWay ScreenShareを使ってWebRTCの画面共有機能を実装しよう /yusuke-naka/16445/ Fri, 28 Aug 2015 00:00:15 +0000 /?p=16445 連載： WebRTCプラットフォーム ”SkyWay” 入門 (4)

連載4回目の今回は、7月28日にリリースされた、SkyWay ScreenShareのチュートリアルをお届けします。

SkyWay ScreenShareは、WebRTCのWebアプリケーションで画面共有を簡単に実装できるライブラリ、画面共有に必要なChrome・Firefox向けのExtensionが簡単に実装できるソースコードが含まれています。

画面共有機能の概要

WebRTCの画面共有機能は、ブラウザ画面やPCのデスクトップ画面をリアルタイムで相手に配信できる機能です。

Chromeでの画面共有の様子

Chromeでの画面共有の様子

WebRTCの画面共有機能はChrome 34以上または、Firefox 33以上で利用可能です。

Chromeでの実装

画面共有機能は、Chrome 26で初めてブラウザに実装されました。当初は、Chromeのchrome://flagsからEnable screen capture support in getUserMedia()というフラグをONにし、getUserMedia()のオプションを指定することで、実現できていました。しかし、セキュリティ上の問題からChrome 34でそのフラグが削除され、代わりにChrome Extensionをインストールするか、Chrome Appsからしか利用できなくなりました。

Firefoxでの実装

Firefoxについては、Firefox 33から画面共有機能が実装されています。Firefoxの場合は、Chromeとは方式が異なり、about:configのmedia.getusermedia.screensharing.enabledという設定をtrueに設定し、media.getusermedia.screensharing.allowed_domainsという設定項目に、画面共有機能を許可するWebサイトのドメインを追加することで利用できるようになります。また、media.getusermedia.screensharing.allowed_domainsには、Mozillaが許可したサービスのドメインが予め設定されています。こちらにドメインを追加してもらいたい場合は、このサイトの下部に掲載されているフォームから申請が可能です。（筆者は申請したことはありませんが、恐らく審査があると思われます）

標準化の状況

WebRTCのJavaScriptAPIの標準化はW3Cで行われています。この画面共有機能についても、今年の２月に仕様書が作られて標準化が進められています。仕様書は「Screen Capture」です。仕様書についての詳細な解説は割愛しますが、現在、ChromeとFirefoxで実装されている画面共有機能はブラウザベンダごとの独自実装であり、今後実装が変更になる可能性は高いと考えられます。

SkyWay ScreenShareの使い方〜ビルド編〜

ここからSkyWay ScreenShareの使い方を説明します。はじめに、github.com/nttcom/SkyWay-ScreenShareからファイル一式をローカル環境にcloneして下さい。また、ここに書いている内容の詳細はREADMEにも掲載していますので、合わせてご覧ください。

Chrome Extensionの作成

まずはマニフェストファイルを修正します。JSONファイルのひな形にそって必要な項目を入力して下さい。アイコンファイルも必要です。

{
  "name": "Your extension name here",
  "short_name": "Your extension short_name here",
  "version": "Your extension version number here",
  "manifest_version": 2,
  "description": "Your extension description here",
  "icons": {
    "16": "icon16.png",
    "48": "icon48.png",
    "128": "icon128.png"
  },
  "permissions": [
    "desktopCapture",
    "tabs"
  ],
  "background": {
    "scripts": ["background.js"],
    "persistent": false
  },
  "content_scripts": [{
    "matches": [""],
    "js": ["content.js"],
    "all_frames": true,
    "run_at": "document_end"
  }]
}

尚、ここで重要なのは matchesです。ここには、このExtensionのりようを許可するWebサイトのURLを記載します。必ずご自身のWebサイトのURLを指定して下さい。ワイルドカードを利用して複数のURLにマッチさせることも可能ですが、その場合は、あなたのExntensionを他のWebサイトで利用される可能性があります。セキュリティ上もよろしくありません。

例："matches": ["https://*.skyway.io/*"]

次にビルドしましょう。SkyWay-ScreenShareではビルド用のgulpタスクとnpm-scriptでエイリアスコマンドを用意しています。SkyWay-ScreenShareディレクトリの直下で、次の２行のコマンドを実行します。npmコマンドは事前に使えるようにしておいて下さい。

npm install
npm run build-chrome

ビルドが完了したら、出来上がったファイルをChromeに読み込ませましょう。chrome://extensions/ にアクセスし、デベロッパーモードを有効にします。そして、パッケージ化されていない拡張機能を読み込むをクリックし、以下のディレクトリを指定します。

SkyWay-ScreenShare/chrome-extension/screenshare_chrome_extension/

読み込むと以下のようになります。（この画像はChromeウェブストアからダウンロードしたものが写っています）

Chrome Extensionを読み込みます

Chrome Extensionを読み込みます

また、ディレクトリと同一フォルダにあるscreenshare_chrome_extension.zipは、Chromeウェブストアにアップロードする際に利用できます。

これでChrome Extensionの作成は完了です。

Firefox Extensionの作成

（注意）SkyWay-ScreenShareのリポジトリには、「Firefox Add-On」という表記で記載しておりますが、画面共有機能を利用するために作成するモノは、Firefox Extension（拡張機能）となります。Add-OnはFirefoxの拡張機能やテーマ等全ての総称となるため、リポジトリの表記とは異なりますが、本記事中では、Firefox Extensionと表記を統一させて頂きます。

Firefox Extensionでは、メインプログラムとパッケージファイルの二つを修正します。まずは、メインプログラムです。

var pageMod = require('sdk/page-mod');
var self = require('sdk/self');
var __temp = require('chrome');
var Cc = __temp.Cc;
var Ci = __temp.Ci;

var domains_to_add = [''];
var addon_domains = [];
var allowed_domains_pref = 'media.getusermedia.screensharing.allowed_domains';
var enable_screensharing_pref = 'media.getusermedia.screensharing.enabled';

 ~~ 省略 ~~

ここではdomains_to_add = [''];に、画面共有機能を有効にするWebサイトのドメインを指定して下さい。指定方法は以下のようになります。

例：domains_to_add = ['*.skyway.io']

次にパッケージファイルを修正します。ここではExtensionの基本情報を入力していきます。ひな形にそって必要な情報を入力して下さい。アイコンファイルも必要です。

{
    "name": "your_add-on_name_here",
    "title": "Your add-on title here",
    "description": "Your add-on description here",
    "author": "Your add-on author here",
    "version": "Your add-on version number here",
    "license": "Your add-on license here",
    "homepage": "Your add-on homepage url here",
    "icon64": "icon64.png",
    "icon": "icon48.png"
}

次にFirefox Extensionのビルドに必要なツール「cfx」をインストールします。インストール方法はこのサイトを参考にして下さい。

ツールのインストールが完了したら、まずはプレビルド（pre build）を行います。ExtensionをビルドするためにはランダムなIDを予めパッケージファイルに記載しておく必要があるため、初回のプレビルドで、パッケージファイルにIDを挿入しています。

npm install
npm run pre-build-firefox

初回のプレビルドでIDが挿入された場合、以下の様なエラーが発生します。これは問題ありません。

No 'id' in package.json: creating a new ID for you.
package.json modified: please re-run 'cfx xpi'

再度以下の通り、ビルドを行って下さい。

npm run build-firefox

ビルドが完了したら、Firefoxに読み込ませて動作確認を行いましょう。about://addonsにアクセスし、作成したExtension本体である、SkyWay-ScreenShare/firefox-addon/screenshare_firefox_addon.xpiをドラッグ・アンド・ドロップさせます。

Firefox Extensionを読み込みます

Firefox Extensionを読み込みます

Firefox Extensionの配布は、通常のWebサーバ上に上記xpiファイルを設置し行って下さい。

これでFirefox Extensionの作成は完了です。

JavaScriptライブラリの作成

SkyWay-ScreenShareには今まで作成したExtensionを利用するためのJavaScriptライブラリ「screenshare.js」が同梱されています。自分でビルドする場合は、以下のように行って下さい。

npm install
npm run build-library

ビルドに成功すると、以下の通りライブラリが生成されます。

SkyWay-ScreenShare/dist/screenshare.js
SkyWay-ScreenShare/dist/screenshare.min.js

また、ライブラリはCDNでも提供しています。

<script src="https://skyway.io/dist/screenshare.js"></script>
<script src="https://skyway.io/dist/screenshare.min.js"></script>

最後に、ライブラリの修正や機能追加などは大歓迎です。TypeScriptのソースファイルを同梱していますので、その際はご利用下さい。Pull Reqestもお待ちしています！

SkyWay ScreenShareの使い方〜アプリ開発編〜

ExtensionとJavaScriptライブラリの準備ができたところで、同梱しているサンプルアプリケーションを例に、画面共有機能を使ったアプリの開発方法をご紹介します。

まず、newでオブジェクトを作成します。debugオプションを指定するとコンソールログにデバッグログが出力されます。

// スクリーンキャプチャの準備
var screen = new SkyWay.ScreenShare({debug: true});

次に、startScreenShare()メソッドを利用して、画面共有機能を開始するためのコードを実装していきます。このメソッドの第一引数には、取得する映像の縦横サイズとフレームレートを指定します。第二引数のコールバック関数は、正しく取得できた場合に呼ばれ引数としてStream Objectが返ってきます。これをVideo要素に入れてあげれば画面が表示されます。

また、第四引数についてはChromeのみ利用できるオプショナルなコールバック関数で、画面共有が何らかの方法で終了した場合に呼ばれます。Firefoxでは現状終了検知が出来ないため、Chrome限定です。

screen.isEnabledExtension() はExtensionが利用しているブラウザで有効かどうか（インストール済みかどうかも含めて）を判定します。

// スクリーンシェアを開始
$('#start-screen').click(function () {
	if(screen.isEnabledExtension()){
			screen.startScreenShare({
					Width: $('#Width').val(),
					Height: $('#Height').val(),
					FrameRate: $('#FrameRate').val()
			},function (stream){
					$('#my-video').prop('src', URL.createObjectURL(stream));
					if(existingCall != null){
							var _peerid = existingCall.peer;
							existingCall.close();
							var call = peer.call(_peerid, stream);
							step3(call);
					}
					localStream = stream;

			},function(error){
					console.log(error);
			},function(){
					alert('ScreenShareを終了しました');
			});
	}else{
			alert('ExtensionまたはAddonをインストールして下さい');
	}

});

次に、画面共有をプログラム側で終了させる場合のコードを実装していきます。現在は終了のための専用メソッドは用意していません。先ほど取得したStream Objectを保持しておき、終了したいタイミングでstop()メソッドを読んで下さい。これで、画面共有が止まります。いずれ、Stream Objectの管理機能を実装する予定なので、その時には専用のメソッドを用意します。

// スクリーンシェアを終了
$('#stop-screen').click(function () {
	localStream.stop();
});

アプリ開発方法の紹介は以上です。

おわりに

今回は、SkyWay-ScreenShareを使った、WebRTCの画面共有機能の実装方法をご紹介しました。画面共有機能は様々なユースケースで活用できる機能ですので、是非ご自身のアプリケーションに組み込んでみてください！

次回は、同じく7月28日にリリースされたSkyWay-DrivingVehicleについてのチュートリアルをお届けいたします。

]]> SkyWay音声認識機能を使ってみよう！ /iwase/16439/ Wed, 26 Aug 2015 00:00:22 +0000 /?p=16439 連載： WebRTCプラットフォーム ”SkyWay” 入門 (3)

連載3回目の今回は、SkyWayの付加機能としてリリースされているSkyWay音声認識機能の利用方法についてお届けいたします。SkyWay音声認識機能とは、クライアント（ブラウザ側）でマイク等を通じて入力した自由発話音声を、サーバ（SkyWay側）と連携して、文字列として受け取る機能のことです。いますぐ試してみたい方は、デモサイトから試用可能です。(注：WebSocketが疎通する環境でないと、正常に動作しません)

同様の機能を実現するAPIとして、Speech Recognition APIがありますが、caniuse.comでも示されるように対応するブラウザが限定されています。SkyWay音声認識機能では、標準では対応していないFirefox等のブラウザも対応可能です。

準備

以降で記載するサンプルコードの中で、SkyWayが提供しているAPIキーが必要となります。実際にお手元で試される場合は、SkyWay公式サイトから開発者登録を行ってください。本記事のサンプルで利用するには、利用可能ドメインに「localhost」と書いた、APIキーを取得する必要があります。

今回作成するサンプル

作成するサンプルは、「音声認識を開始するボタン」と「認識結果を表示するエリア」の2要素のみで構成するシンプルな音声認識アプリケーションです。

スクリーンショットはこちらです。

SkyWay音声認識スクリーンショット

SkyWay音声認識スクリーンショット

こちらを構成しているサンプルコードは以下の通りです。

<!DOCTYPE html>
<html lang="ja">
<head>
	<title>SkyWay Speech Recognition Sample</title>
</head>
<body>

<!-- 音声認識開始用のボタン、および結果表示用のエリア -->
<button id="start_rec">start</button>
<div id="result"></div>

<!-- 必要なライブラリ群の読み込み  -->
<script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="https://skyway.io/dist/msgpack.codec.js"></script>
<script src="https://skyway.io/dist/libspeexdsp.js"></script>
<script src="https://skyway.io/dist/resampler.min.js"></script>
<script src="https://skyway.io/dist/speechrec.min.js"></script>

<!-- 音声認識用のコードサンプル -->
<script>
SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});
</script>

</body>
</html>

上記HTMLを任意の名前で保存してください。本記事ではsample.htmlという名前で保存します。また、htmlを格納するディレクトリと同じ階層に

の2ファイルを保存して置いてください。音声認識に必要なライブラリとなります。　

動かしてみよう

既にApacheやNginxをインストールされている場合はそちらも活用できますが、今回はpythonからシンプルなWebサーバを起動してみます。コマンドはpython -m SimpleHTTPServerです。

localhostの8000番でWebサーバが起動するので、http://localhost:8000/sample.htmlへ、Chrome/Firefox/Operaのいずれかでアクセスしてみましょう。画面が表示されたら、「start」ボタンをクリックすると、マイク使用許可確認のポップアップが表示されますので、Allow/許可を押下します。その後に自由に発話して、適当なタイミングで発話をやめてください。音声認識結果が上手くいくと、数秒以内に音声認識結果の文字列が表示されます。

コードのポイント解説

SkyWay音声認識機能を利用するためには、大きく分けて2つの処理が必要になります。

1. コンフィグの設定・コールバックの設定

まずSpeechRec.config関数を利用して、SkyWayKeyおよびlibopus.worker.jsへのパスを設定します。サンプルでは、以下のようにconfigを設定しています。

SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

SpeechRec.configには、その他のパラメータも設定可能であり、ドキュメントから確認できます。

次に各種コールバックの設定をします。サンプルでは2種類のコールバックを設定しています。

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});

1つ目のon_procは、発話時の音声ボリュームを取得できた場合に発火するコールバック関数です。サンプルでは、コンソール画面に音量を表示するようにしています。

2つ目のon_resultは、音声認識結果を取得できた場合に発火するコールバック関数です。サンプルでは、結果をコンソール画面に表示する処理、および#resultで指定されるdivエリアに、音声認識結果を書き込む処理をしています。

サンプルでは分かりやすいように、コールバックを2つのみしか設定していませんが、実際にはさらに多くのコールバックを設定可能です。詳細はコールバック関数一覧をご確認ください。

2. 開始・停止の実行

コンフィグおよびコールバックの設定が完了したら、実際に音声認識を開始・停止するための関数を呼び出します。サンプルでは、#start_recボタンがクリックされた際に呼び出すSpeechRec.startが、音声認識を開始するための処理に該当します。

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

なお、開始だけではなく任意のタイミングで音声認識を終了させるSpeechRec.stop等もあります(サンプルでは省略)。その他の関数はドキュメントから確認いただけます。

おわりに

いかがでしたでしょうか。今回はSkyWayの付加機能である、音声認識機能について解説いたしました。

次回は画面共有を簡単に実現するSkyWayScreenShareライブラリについてお届けします。

]]> SkyWay MultiPartyを使ってグループチャットを作ろう /sakkuru/16397/ Mon, 24 Aug 2015 00:00:21 +0000 /?p=16397 連載： WebRTCプラットフォーム ”SkyWay” 入門 (2)

連載2回目の今回は、7月28日にリリースされたライブラリ、SkyWay MultiPartyのチュートリアルをお届けします。 SkyWay MultiPartyは、一言で言うと多人数によるビデオ・テキストチャットを『簡単に』作るためのライブラリです。

本ライブラリを使用することで、グループビデオチャットやテキストチャットを、 ほんの20行程度のJavaScriptコードで実装をすることができます。

サンプルコードを用意していますので、手元で実行しながら進めてみましょう。

10行ビデオチャット

以下のスクリーンショットをご覧ください。

videoチャットサンプル

まずはこのような複数人が参加できるビデオチャットシステムを、10行程度のJavaScriptコードで実装してみましょう。 サンプルコードを以下に記載します。

<!doctype html>
<html>
<head>
  <script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
  <script src="https://skyway.io/dist/0.3/peer.min.js"></script>
  <script src="https://skyway.io/dist/multiparty.min.js"></script>
  
  <style> video { width:200px; } </style>

</head>
<body>

  <div id="streams"></div>

<script>

  // MultiParty インスタンスを生成
  multiparty = new MultiParty( {
    "key": "********-****-****-****-************"  /* SkyWay keyを指定 */
  });

  multiparty.on('my_ms', function(video) {
    // 自分のvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");
  }).on('peer_ms', function(video) {
    // peerのvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");
  }).on('ms_close', function(peer_id) {
    // peerが切れたら、対象のvideoノードを削除する
    $("#"+peer_id).remove();
  });

  // サーバとpeerに接続
  multiparty.start()

</script>
</body>
</html>

早速動かしてみましょう。

上のコードを、videochat.htmlという名前で保存します。

19行目でSkyWayのAPIキーが必要となりますので、使用する際はSkyWayから開発者登録を行ってください。 本サンプルで使用するには、利用可能ドメインに『localhost』と書いて、APIキーを取得する必要があります。

PCにApacheやNginxなどのサーバがインストールされている場合は、そちらで動かしても問題ありませんが、 入っていない場合は、以下の様にPythonのコマンドでWebサーバを起動できます。

python -m SimpleHTTPServer

localhostの8000番ポートでWebサーバが起動するので、Chrome、Firefox、Operaのいずれかのブラウザでアクセスしてみましょう。

videoチャットサンプル

次に別のタブやブラウザで、もう2、3個同じページを開いてみます。

複数人のグループvideoチャット

複数人参加のビデオチャットが実装できていることがわかります。

ビデオチャットのコード

それではコードを見てみましょう。

今回はjQueryを使用するので、4行目でjQueryを読み込んでいます。 (SkyWay MultiPartyを使用するのにjQueryが必須というわけではありません) 5行目と6行目で、SkyWayライブラリ(peer.min.js)とSkyWay MultiPartyライブラリ(multiparty.min.js)を読み込んでいます。 13行目で、ビデオを表示するためのdivを1つ用意しています。

18〜33行目がJavaScriptコードです。大きくMultiPartyオブジェクトの生成部分と、イベントハンドラ部分に分かれています。

SkyWay MultiPartyでは、最初にコンストラクタを呼ぶことで MultiPartyオブジェクトを生成します。引数にはAPIキーが必要となります。

// MultiParty インスタンスを生成
  multiparty = new MultiParty( {
    "key": "********-****-****-****-************"  /* SkyWay keyを指定 */
  });

続くコードがmultipartyオブジェクトのイベントハンドラになります。

multiparty.on('my_ms', function(video) {
    // 自分のvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");

  }).on('peer_ms', function(video) {
    // peerのvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");

  }).on('ms_close', function(peer_id) {
    // peerが切れたら、対象のvideoノードを削除する
    $("#"+peer_id).remove();
  });

SkyWay MultiPartyでは、

multiparty.on('イベント名', コールバック関数)

の形式で、イベントハンドラを設定することができます。

サンプルでは3つのイベントに対し、ハンドラを定義していることがわかります。

1つ目が'my_ms'で、これは自分のメディアストリームの準備が整った際に発生するイベントです。メディアストリームとは取得した映像や音声を扱うためのオブジェクトで、例えばPCのカメラやマイクから取得した映像・音声がこれにあたります。 コールバックとして呼ばれる関数には、メディアストリームから生成したオブジェクトURLとidがオブジェクトとして渡されます。 ライブラリにはそのオブジェクトからvideoノードを生成するユーティリティが用意されていますので、それを使用しvideoノードを生成・表示しています。

2つ目は、'peer_ms'というイベントに対するコールバックで、これはチャットの相手(peer)のメディアストリームを取得する準備が整った際に発生するイベントです。 こちらも自分のメディアストリームと場合と同様、videoノードを生成・表示しています。

3つ目のイベントは'ms_close'で、peerのメディアストリームの切断を検知した際に発生します。 このコールバックでは、peerのvideoノードを削除する処理を書いています。

以上で、ビデオチャット機能を実装することができました。

10行テキストチャット

続いてテキストチャット機能も実装してみましょう。

まず、テキストの入力と表示を行うためのHTML要素を追加します。 以下のコードを『<div id="streams"></div>』の下に追加してみましょう。

<div>
    <form>
      <input type="text"><button type="submit">send</button>
    </form>
    <div id="message"></div>
  </div>

次に、以下のJavaScriptコードを、『</script>』の前に追加します。

//テキストを入力し、submitしたとき
  $("form").on("submit", function(ev) {

    //onsubmitのデフォルト動作（reload）を抑制
    ev.preventDefault();

    //テキストを取得
    var $input = $(this).find("input[type=text]"); 
    var data = $input.val();
    $input.val("");

    //テキストを表示
    $("#message").append(data + "<br>");

    //peerにメッセージを送信
    multiparty.send(data);

  });

  // peerからテキストメッセージを受信したとき
  multiparty.on('message', function(mesg) {
    $("#message").append(mesg.data + "<br>");
  });

それでは先ほどのページをリロードしてみましょう。

textチャットサンプル

入力フォームが追加されたことがわかります。 文字を入力し、エンターキーを押すと、そのテキストが表示されます。

複数人のグループチャット

他のタブや、ブラウザから入力したテキストも表示できることが確認できます。

テキストチャットのコード

それではコードを見てみましょう。 テキストチャットのコードは、データを送信する際の処理と、データを受信する際の処理に分かれています。

以下のコードで、テキストが入力され、送信されるまでの処理を記述しています。

//テキストを入力し、submitしたとき
$("form").on("submit", function(ev) {

  //onsubmitのデフォルト動作（reload）を抑制
  ev.preventDefault();

  //テキストを取得
  var $input = $(this).find("input[type=text]"); 
  var data = $input.val();
  $input.val("");

  //テキストを表示
  $("#message").append(data + "<br>");

  //peerにメッセージを送信
  multiparty.send(data);

});

multiparty.send()で、テキストをそのまま送信していることがわかります。

そして以下の部分で、メッセージを受信した際に発生するイベント'message'に対する、コールバックを設定しています。

// peerからテキストメッセージを受信したとき
multiparty.on('message', function(mesg) {
  $("#message").append(mesg.data + "<br>");
});

簡易ではありますが、テキストチャットを実現することができました。

おわりに

今回は、SkyWay MultiPartyを使ったビデオ・テキストチャットの作り方をお届けしました。 少しのコードで簡単に実装できることがお分かりいただけたかと思います。

次回は、同じく7月28日にリリースされたSkyWay音声認識APIについてのチュートリアルをお届けいたします。

]]> ビデオチャット＆テキストチャット作成チュートリアル！WebRTCを簡単＆柔軟に使える「SkyWay」を使ってみよう /katsura/16331/ Thu, 06 Aug 2015 00:00:06 +0000 /?p=16331 連載： WebRTCプラットフォーム ”SkyWay” 入門 (1)

WebRTCを簡単に利用するためのプラットフォームSkyWayをご存知ですか？本連載では、WebRTCを簡単に利用するためのプラットフォームSkyWayについて、基本的なチュートリアルから、各種ライブラリの紹介までしていきます。

連載第1回目である今回は、まず、WebRTCの基本的な説明をした後に、実際にSkyWayを使って、ビデオチャットの作成とデータチャンネルを使ったチャットの作成をしていきます。

WebRTCとは

WebRTCとは、ブラウザやアプリ間でビデオや音声、データのやり取りをP2P(Peer to Peer)で行うことを可能にする規格です。 従来のビデオチャットは互換性のない独自技術で実装されていましたが、WebRTCはオープン標準として仕様が作成・公開されており、相互接続が保証されています。

また、ブラウザで動作することから特別なアプリケーションをインストールする必要がありませんし、すでにあるウェブアプリケーションに埋め込むことで、シームレスにビデオチャットを動かすこともできます。さらに、オープンソースのコードを利用することで、ブラウザだけに限らず、ネイティブアプリにWebRTCを組み込むことも可能です。

image_webrtc

WebRTCの仕組み

WebRTCはビデオ等のデータをP2Pでやり取りすることが出来ますが、実際にブラウザ間で直接接続をするためには、まず、互いに自分のIPアドレス／ポート番号等の情報を教え合わなければなりません。一般的に、この情報交換を行うためにシグナリングサーバというサーバを用意する必要があります。

交換する情報はIPアドレス、ポート番号以外にもいくつかあります。

※交換する情報はIPアドレス、ポート番号以外にもいくつかあります。

また、お互いがNATの内側に存在する場合やFirewallの内側にいる場合、シグナリングサーバだけでは接続することができません。そのために利用するのが、STUN／TURNサーバです。ここでは具体的な説明は省略しますが、作成したアプリケーションをユーザに広く使ってもらうためには、これらのサーバも用意する必要があります。

(詳細を知りたい方は、がねこまさしさんが書かれたコチラの記事をお読みください: 壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう)

SkyWayとは

今までの説明を見てWebRTCは「大変そうだ」と思った方は多いと思います。実際、シグナリングサーバやSTUN/TURNサーバを用意するのは容易ではないです。

そこで登場するのがWebRTC開発者向けプラットフォーム「SkyWay」です。SkyWayは、以下の図で示す通り、複雑なシグナリング処理を担うAPI郡とJavascriptライブラリ／Android,iOSライブラリ、STUN/TURNサーバで構成されています。

このSkyWayを利用することで、シグナリングサーバやSTUN/TURNサーバを独自に用意する必要はなく、開発者はP2P通信部分のプログラミングにのみ集中することができます。

利用者登録が必要です

SkyWayは現在トライアルサービス中で、誰でも無料で使うことができます。さっそくウェブサイトから利用者登録をしてみましょう。

http://skyway.io/

ss01

「登録を行う」ボタンをクリックして、開発者登録画面に向かいます。

ss02

必要事項を入力します。ここで入力するドメイン名は、セキュリティ向上を目的として行っているOriginチェックのために必要となっています。ここのドメイン名は開発者登録後に変更可能ですので、まずは「localhost」とだけ入力しておいてください。

ss03

登録が正常に完了したら、ログインページへ行き、ログインしてください。ログインが完了すると以下の画面のような開発者ダッシュボードが表示されます。

ss04

右に表示されいるのがAPIキーです（上図ではマスクしています）。こちらをJavaScriptやiOS/Androidのコード内に埋め込み、SkyWayのAPIにアクセスします。

ちなみに、設定変更ボタンをクリックすると、利用ドメインの編集やRestAPIの有効無効の切り替え、そしてAPIキーの削除が可能です。

これでSkyWayを利用するための準備が整いました。早速ビデオチャットを実装してみましょう。

簡易ビデオチャットの作成と実行

まず、ビデオチャットを実装するにあたり、以下の環境をご用意ください。

  • Chorme, Firefox, Operaのいずれかのブラウザ
  • カメラ／マイク （PCに接続可能なもの）

まずは以下の内容で、HTMLを書きます。適当なフォルダに「videochat.html」というファイル名でHTMLファイルを作成してください。



    
    
    


    
Simple Video Chat

    

        
        
    

    

        
MyID: -

        
PeerID: -

HEADタグ内で、jQueryとSkyWayライブラリ、そして今回作成するビデオチャット用のJavaScriptを読み込んでいます。jQueryはボタンクリック時のイベントを設定するときに使用します。SkyWayライブラリは今まで説明してきたとおり、シグナリング部分の処理を全部行ってくれるライブラリです。

次にJavaScriptのコードを書きます。先ほどのHTMLと同じフォルダに、「videochat.js」というファイル名でJavaScriptのファイルを作成してください。ここで、APIキーは先ほど入手したものに置き変えて入力してください。

// カメラ／マイクにアクセスするためのメソッドを取得しておく
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;

var localStream;    // 自分の映像ストリームを保存しておく変数
var connectedCall;  // 接続したコールを保存しておく変数

// SkyWayのシグナリングサーバーへ接続する (APIキーを置き換える必要あり）
var peer = new Peer({ key: 'YourApiKey', debug: 3});

// シグナリングサーバへの接続が確立したときに、このopenイベントが呼ばれる
peer.on('open', function(){
    // 自分のIDを表示する
    // - 自分のIDはpeerオブジェクトのidプロパティに存在する
    // - 相手はこのIDを指定することで、通話を開始することができる
    $('#my-id').text(peer.id);
});

// 相手からビデオ通話がかかってきた場合、このcallイベントが呼ばれる
// - 渡されるcallオブジェクトを操作することで、ビデオ映像を送受信できる
peer.on('call', function(call){
  　
    // 切断時に利用するため、コールオブジェクトを保存しておく
    connectedCall = call;

    // 相手のIDを表示する
    // - 相手のIDはCallオブジェクトのpeerプロパティに存在する
    $("#peer-id").text(call.peer);

    // 自分の映像ストリームを相手に渡す
    // - getUserMediaで取得したストリームオブジェクトを指定する
    call.answer(localStream);

    // 相手のストリームが渡された場合、このstreamイベントが呼ばれる
    // - 渡されるstreamオブジェクトは相手の映像についてのストリームオブジェクト
    call.on('stream', function(stream){

        // 映像ストリームオブジェクトをURLに変換する
        // - video要素に表示できる形にするため変換している
        var url = URL.createObjectURL(stream);

        // video要素のsrcに設定することで、映像を表示する
        $('#peer-video').prop('src', url);
    });
});

// DOM要素の構築が終わった場合に呼ばれるイベント
// - DOM要素に結びつく設定はこの中で行なう
$(function() {

    // カメラ／マイクのストリームを取得する
    // - 取得が完了したら、第二引数のFunctionが呼ばれる。呼び出し時の引数は自身の映像ストリーム
    // - 取得に失敗した場合、第三引数のFunctionが呼ばれる
    navigator.getUserMedia({audio: true, video: true}, function(stream){

        // このストリームを通話がかかってき場合と、通話をかける場合に利用するため、保存しておく
        localStream = stream;

        // 映像ストリームオブジェクトをURLに変換する
        // - video要素に表示できる形にするため変換している
        var url = URL.createObjectURL(stream);

        // video要素のsrcに設定することで、映像を表示する
        $('#my-video').prop('src', url);

    }, function() { alert("Error!"); });

    // Start Callボタンクリック時の動作
    $('#call-start').click(function(){

        // 接続先のIDをフォームから取得する
        var peer_id = $('#peer-id-input').val();

        // 相手と通話を開始して、自分のストリームを渡す
        var call = peer.call(peer_id, localStream);
            
        // 相手のストリームが渡された場合、このstreamイベントが呼ばれる
        // - 渡されるstreamオブジェクトは相手の映像についてのストリームオブジェクト
        call.on('stream', function(stream){
            // 相手のIDを表示する
            $("#peer-id").text(call.peer);

            // 映像ストリームオブジェクトをURLに変換する
            // - video要素に表示できる形にするため変換している
            var url = URL.createObjectURL(stream);

            // video要素のsrcに設定することで、映像を表示する
            $('#peer-video').prop('src', url);
        });
    });

    // End　Callボタンクリック時の動作
    $('#call-end').click(function(){
        // ビデオ通話を終了する
        connectedCall.close();
    });
});

これらはローカルのファイルとして開いても動作しません。ローカルPC上にサーバを立ててファイルをホスティングしてあげる必要があります。このためだけにローカルPCにApacheやNginxを入れるのもの大変なので、今回はPHP付属のビルトインサーバを利用します。 ターミナルを開いて次のコマンドを入力してください (要PHP5.4.0以上)

$ cd {HTML/Javascriptのあるフォルダ}
$ php -S localhost:8888

これで準備が全て整いました。早速ブラウザで開いてみましょう。WebRTCは現在のところChrome, Firefox, Operaでしか動作しないため、それらのブラウザを利用する必要があります。また現在も開発が続けられている分野ですので、最新バージョンを利用するのが望ましいです。

今回は、ビデオ通話を開始する側と受ける側の両方を自分で試してみます。ですので、以下のURLを2つのウィンドウ（またはタブ）で開いてみてください。

http://localhost:8888/videochat.html

ss05

無事に表示されたでしょうか？

アクセス時に、カメラとマイクへのアクセスについて許可を求められるので、許可しておきましょう。許可すると、カメラ映像が画面左に表示されます。

それでは、早速通話を開始してみたいと思います。まず、接続相手のIDを渡す必要があります。ビデオ通話を受ける側のIDをコピーして、かける側のテキストボックスに貼り付けてください。相手のIDをちゃんと貼り付けることができたなら、隣の「Start Call」を押します。

ss06

2つの映像が表示されれば成功です。

以上が簡単なビデオチャットのチュートリアルでした。非同期処理が中心でかつ、通話を開始する側と受ける側の両方の処理を書く必要があるため、慣れるまでコードの理解が難しいですが、ここさえ乗り越えればスムーズにコードを書くことができますので、少しづつ理解してみてください。

データ通信を使った文字ベースチャット

続いてWebRTCを用いたデータ通信を使ったチャットアプリを作ってみたいと思います。既にビデオチャットを理解できていれば、全く難しいことはありません。

先ほどと同様に、以下の内容で、HTMLを書きます。適当なフォルダに「datachat.html」というファイル名でHTMLファイルを作成してください。



    
    
    


    
Chat

    

        
        
        
    

    

        
MyID: -

        
PeerID: -

次はJavaScriptです。先ほどのHTMLと同じフォルダに「datachat.js」というファイル名でJavaScriptのファイルを作成してください。 APIキーについてもビデオ通話と同様に、先ほど入手したものに置き変えてください。

var conn;     // データ通信用connectionオブジェクトの保存用変数 

// SkyWayのシグナリングサーバーへ接続する  (APIキーを置き換える必要あり）
var peer = new Peer({ key: 'YourApiKey', debug: 3});

// シグナリングサーバへの接続が確立したときに、このopenイベントが呼ばれる
peer.on('open', function(){
    // 自分のIDを表示する
    // - 自分のIDはpeerオブジェクトのidプロパティに存在する
    // - 相手はこのIDを指定することで、通信を開始することが出来る
    $('#my-id').text(peer.id);
});
 
// 相手からデータ通信の接続要求イベントが来た場合、このconnectionイベントが呼ばれる
// - 渡されるconnectionオブジェクトを操作することで、データ通信が可能
peer.on('connection', function(connection){
  　
    // データ通信用に connectionオブジェクトを保存しておく
    conn = connection;

    // 接続が完了した場合のイベントの設定
    conn.on("open", function() {
        // 相手のIDを表示する
        // - 相手のIDはconnectionオブジェクトのidプロパティに存在する
        $("#peer-id").text(conn.id);
    });

    // メッセージ受信イベントの設定
    conn.on("data", onRecvMessage);
});

// メッセージ受信イベントの設定
function onRecvMessage(data) {
    // 画面に受信したメッセージを表示
    $("#messages").append($("
").text(conn.id + ": " + data).css("font-weight", "bold"));
}

// DOM要素の構築が終わった場合に呼ばれるイベント
// - DOM要素に結びつく設定はこの中で行なう
$(function() {

    // Connectボタンクリック時の動作
    $("#connect").click(function() {
        // 接続先のIDをフォームから取得する
        var peer_id = $('#peer-id-input').val();

        // 相手への接続を開始する
        conn = peer.connect(peer_id);

        // 接続が完了した場合のイベントの設定
        conn.on("open", function() {
            // 相手のIDを表示する
            // - 相手のIDはconnectionオブジェクトのidプロパティに存在する
            $("#peer-id").text(conn.id);
        });

        // メッセージ受信イベントの設定
        conn.on("data", onRecvMessage);
    });

    // Sendボタンクリック時の動作
    $("#send").click(function() {
        // 送信テキストの取得
        var message = $("#message").val();

        // 送信
        conn.send(message);

        // 自分の画面に表示
        $("#messages").append($("
").html(peer.id + ": " + message));

        // 送信テキストボックスをクリア
        $("#message").val("");
    });

    // Closeボタンクリック時の動作
    $("#close").click(function() {
        conn.close();
    });
});

では、ローカルにHTTPサーバを立てて開いてみましょう。

$ cd {HTML/Javascriptのあるフォルダ}
$ php -S localhost:8888

http://localhost:8888/datachat.html

ss07

先程と同様に、接続を開始する側と接続を受ける側の両方が必要なため、2つ開いてください。無事に表示されましたでしょうか？

それでは、データ通信を開始してみたいと思います。接続相手のIDをコピーして、接続を開始する側のテキストボックスに貼り付けて、Connectボタンを押してください。

ss08

相手のIDがお互いの画面に表示されれば接続できています。では、チャット欄に文字を入力してSendボタンを押してみましょう。 相手の画面と自分の画面、両方に表示されれば成功です。

ss09

以上が簡単なテキストチャットのチュートリアルでした。WebRTCを使えば、テキストだけじゃなく、JavaScriptのオブジェクトやファイル等も送ることが可能です。

おわりに

今回はSkyWayを使った、簡単なビデオチャット／文字ベースチャットのチュートリアルをお届けしました。WebRTCは便利で高機能な反面、自分で実装しようとすると大変ですが、SkyWayを使うことで手軽に利用可能です。

次回はSkyWayを使って、Android/iPhoneでWebRTCを簡単に使う方法をお伝えしたいと思います。

]]> WebRTC開発者向けライブラリ「PeerJS」はこうして作られた /yusuke-naka/3693/ Thu, 09 Jan 2014 02:00:26 +0000 /?p=3693 NTT Communications（以下、NTT Com）が提供するWebRTC開発用プラットフォーム SkyWayはPeerJSをベースに構成されています。この記事ではPeerJS開発者であるEric Zhang氏の素顔に迫ります！

はじめに

2013年11月19日から21日にアメリカで開催されたWebRTC Conference & Expoに合わせて、NTT ComのSkyWay開発担当者がアメリカを訪れ、PeerJS開発者の一人であるEric Zhang氏にインタビューを行いました。

アレンとエリック

（写真左：NTT com SkyWay開発チームの飯田アレン真人氏、写真右：PeerJS開発者のEric Zhang氏）

──PeerJSとは？

WebRTCを活用したアプリケーションを開発できるようにするためのJavaScriptライブラリ。PeerServer Cloud serviceというWebRTCを実現するための仲介サーバ機能も提供している。

http://peerjs.com/

──SkyWayとは？

Web開発者が高度な知識の習得や環境の整備をすることなく、WebRTCを活用したアプリケーションを開発できるように、PeerJS互換のJavaScriptライブラリ、仲介サーバ機能、WebAPI、日本語の開発ドキュメントを提供している。

http://nttcom.github.io/skyway/

学生時代に二人で開発をスタート

──どのような方が開発に携わられているのですか？

私とMichelle Buの二人で開発しています。私は、過去にBinaryJSやNowJSなどを開発していました。特に、ネットワーク系の技術を簡単に使いやすくするためのライブラリ開発が得意です。MichelleはGoogleでインターンシップをしていたこともあり、JavaScriptを用いた開発経験が豊富なんです。

──PeerJSはいつごろから開発を始めたのですか？

私やMichelleがカリフォルニア大学バークレー校に在籍していた、2012年の12月にスタートしました。

WebRTCが流行るのはわかっていた

──WebRTCという技術に触れてみて、最初はどう思いましたか？

WebRTC DataChannelを利用してみると、多くの問題があることがわかりました。APIはブラウザごとに互換性がない、データのシリアライゼーションができない、そもそもシグナリングサーバが存在しないため利用するハードルが高いなど、とにかく使いにくい印象でした。しかし、ブラウザ上で動くWebアプリケーションはネイティブアプリケーションに比べて、ネットワーク技術を活用した開発を苦手としています。そのため、今後WebRTCは間違いなく流行る技術だと確信しました。

──なぜPeerJSを開発しようと考えたのですか？

私はもともと、JavaScriptの機能を簡単に利用できるようにするJavaScriptライブラリが好きでした。だからWebRTCの機能をみんなが簡単に使えるライブラリが、もっとあれば便利だと考え、開発をスタートしました。当初は開発者向けのチュートリアルも少なく、W3Cの仕様も毎週のように変わっていたこともあってかなり苦労しましたが、なんとか公開することができました。頑張ったかいあって、公開初日にGitHubにて700スターを頂きました。私が今までに開発したJavaScriptライブラリの中で、最も大規模なライブラリになりましたね。

PeerJS開発の日々

──開発はどのように進めているのですか？

私とMichelleは仕事をしながら、プライベートの時間でPeerJSの開発を進めてきました。現在も、毎日仕事から帰ってきたらメールとPeerjs – Google Groupを確認し、個別の質問への回答やバグ修正などを行っています。Chromeのコミットログも定期的に確認し、WebRTCに関する実装の進み具合も把握するようにしています。

PeerJSに求めることは互換性と安定性

──今後PeerJSに新しい機能追加を行う予定はありますか？

PeerJSへの機能追加は最小限にしたいと考えています。WebRTCの仕様自体が変化し続けているため、ブラウザのバージョンが上がるたびに使えなくなるという事態は避けなければなりません。WebRTC Working Groupの動向をウォッチし、仕様の変化に迅速に対応するとともに、高い安定性と互換性を維持していく方針です。もちろん、私達以外の開発者によるPeerJSへの機能追加は大歓迎です。そのためにMITライセンスで公開していますので、ぜひ、新しい機能をいろいろと追加してみてください。

──最近はどのような開発をしているのでしょうか？

PeerJSは2013年9月20日に、Version 0.2.xから0.3.xへメジャーバージョンアップを行いました。主な変更は、WebRTCのMediaChannelへの対応です。2ヶ月ほどの開発で、同時にコア部分のリファクタリングも行いました。ループ処理を極力省き、信頼性や処理速度の向上などを目的にしたコードの最適化を行っています。処理速度向上のアプローチとしては、WebScoketsによる接続を行う前に、XHRにて通信することで、50msほど処理を速くすることができました。これは価値があることだと考えています。

今はバグ修正と処理速度の高速化に注力しています。例えば、Chrome 31からSCTP DataChannelがデフォルトで有効になりました。Chromeの実装ではデータを一時保管するバッファーサイズが1MBしかないため、データ転送速度が速いとデータが溢れてしまう可能性があります。そのため、これに対処するためのバッファーインターフェースを実装する必要があります。（※1）その他にもエラー処理や、ユーザのイベント処理を改善していきたいと考えています。

※１・・・この機能はVersion 0.3.6 Beta (3 Dec 2013)にて実装されました。

──PeerJSのマネタイズはどう考えていますか？

公開しているPeerServer Cloud serviceの運用には、費用はかかります。ですが、開発者の方に素早くサービスを開発してもらうことに重点を置いているため、私達でサーバを維持できるかぎり、有償化するつもりはありません。

WebRTCは課題も多いけど、新しい可能性を秘めた技術

エリック──WebRTCに関して課題だと感じていることはありますか？

WebRTCはPeer-to-Peerを前提にしているので、グループビデオチャットを簡単に実装することができません。サーバ側でミキシングを行い、複数人でチャットなどができる商用サービスはいくつか存在します。しかし、オープンソースで公開されているものはありません。今後はnpm installで簡単にインストールできる、オープンソースのサーバプロダクトが出てくることを願っています。

──WebRTCを活用した新しいユースケースはありますか？

PeerCDNというサービスは面白いと思います。これは、Webサイト上の画像や音声、動画などのコンテンツを、その時に同じようにWebサイトを閲覧しているユーザ同士でシェアしあうサービスです。WebRTCの機能を使い、Peer-to-Peerの片方がCDNの役割を果たし、コンテンツを他方に配信します。サーバからダウンロードするよりも高速にコンテンツが取得できるようになれば、多くの人から注目されるでしょう。

WebRTCは新しくてとても魅力的なAPIです。今後の可能性に期待しています。

終わりに

今回はPeerJSの開発者であるEric Zhang氏へのインタビューをお送りしました。残念ながら、Michelle Bu氏には時間が合わずお話を伺うことができませんでしたが、Eric氏は一人のエンジニアとしてすごくバイタリティにあふれている方でした。また、HTML5とJavaScriptでつくるエコシステムにすごい可能性を感じており、ちょっと大げさかもしれませんが、同時にWeb技術への愛が感じられました。今後の活躍を大いに期待したいと思います。

NTT ComのSkyWay開発チームは、今後もSkyWayをはじめとするWebRTCに関する情報発信を行っていきますので、ご期待ください。

ここだけの話、ErichとMichelleはお付き合いしているそうです。二人がこの先もうまくいくといいですね。

エリック顔_small
[Eric Zhang/エリック・ザング] 中国生まれで2000年からアメリカに在住。2009年にカリフォルニア大学バークレー校に入学。在学中にFlotype incにてNowJSの開発に携わる。2012年には同じく学生だったMichelle Buと共にPeerJSの開発を始める。現在はLever incの開発に携わりつつ、PeerJSの開発も継続して行っている。JavaScriptライブラリの開発が得意でBinaryJSの開発なども行っている。http://ericzhang.com/

]]>