Experts.jp日本に、もっとエキスパートを。Conferenceパネルディスカッションレポートがねこまさし(インフォコム株式会社)SkyWay,WebRTC2016年3月18日0click03269こんにちは、がねこです。WebRTC開発の落とし穴」の内容をご紹介します。パネラー紹介パネラーとして、次の3名にご登壇いただきました。モデレータは私が担当させていただきました。グループ会社間で利用するビデオ会議システムを、WebRTCを使って構築、運用されています。Androidのネイティブアプリを担当されていますが、MCU/SFUといったメディアサーバーにも詳しいです。郷さんChatWork株式会社所属。クラウド型ビジネスコミュニケーションツールを提供されていて、そのサービスの一環としてWebRTCを使ったビデオ会議/音声通話を実現されています。担当はPCブラウザが中心とのことです。けにWebRTCを使うためのPaaSであるSkyWayを提供されています。PCブラウザが中心に、サーバー側も担当されているとのことです。我如古正志(モデレータ)インフォコム株式会社所属。WebRTCを使った社内用Webチャットシステムや、イベント配信システムを構築、運用しています。クライアント側からサーバー側まで広く浅く担当しています。下図のように、WebRTCの使い方や担当領域がそれぞれ異なるパネラーの方に、集まっていただきました。クライアントサイドでの「つらみ」サポート対象のブラウザとOSについて我如古まずはクライアント側で苦労するポイントと、その対策を聞いてみたいと思います。私のところでは社内のツールとしてはChromeがブラウザとして採用されているので、原則的にはChromeのみに対応しています。Edgeはすべて切り捨てています。Firefoxをメインに据えていますが、IE/Safariについてはプラグインというかたちで提供しています。Safariについてはプラグインの対応中という段階ですが。Edgeに関してはまだ手が回っていないですが、今後サポートしていきたいと考えています。SkyWayではChromeとFirefoxがメインになっていますが、IEとSafariもプラグイン対応しています。Edgeはまだ手がついていません。PCアプリに関しては、Electronなどを使って実装することもできます。(iOSやAndroidといった)モバイルアプリもSDKをリリースしています。うちでは、iOSアプリケーションについては提供しています。Androidに関しては幸いにしてAndroid版のChromeブラウザがWebRTCに対応しているんですね。レスポンシブデザインみたいなかたちで、Androidの画面解像度に合わせたWebのインターフェイスを提供して対応しています。うちの場合はPCアプリ、モバイルアプリについてはまだ対応中というかたちです。これも追々対応していきたいというステータスになっています。ありがとうございます。その点に関しては、先ほど述べた通り、Chromeブラウザ以外は原則的に捨てています。「自分で頑張る」(頑張って差異を吸収する)ということも、もちろん部分部分ではやっています。一律で社内の人は同じブラウザの同じバージョンを使っているはずではあるんですけれども、個別に異なる環境を使ってらっしゃる方もいるので、そのあたりはJavaScriptで差異を吸収しています。Chromeブラウザ間のバージョン差異というのは当然あるので、そこは頑張って吸収しています。うちの場合だと「自分で頑張る」と「便利ライブラリを使う」の両方対応しているという状況です。使うというのが一般的な手法なのでこれを利用していますが、それでも間に合わないところや、FirefoxやChromeでも特定のバージョンで動きがおかしいところは条件分岐して対応するということも、行っています。SkyWayでは、利用しているライブラリPeer.jsでかなり吸収されているところはあります。対応しきれていないところは、adapter.jsを使ったりして吸収しています。古いバージョン(のブラウザ)では、例えばonnegotiationneededイベントに対応していないブラウザなどで動作を変えるとか、そういうコードは入っています。ご存知のかた多いですか?...意外と少ないですね。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のスペックが足りなくて、参加人数が多いと後から来た人が入れないことがあります。ユーザーさんから見て使っていて何が起こっているのかよく分からない状況になってしまうので、それで「繋がらない」という話になってしまいます。ネットワークの問題とかもあるんですが、最初から全く繋がらないという状態と、途中から入る人が入れないという状態だと、「繋がらない」という問い合わせは後者の方が多いです。実際使っていると、その方が動作に違和感を覚えるという意味です。それでつながらないというケースもあるにはあるのですが、その場合だとこちらからもある程度サポートはしやすいというか、切り分けはかなり楽です。ない場合、人数が入ってくると後の人が繋がらないという状況になると、どういうふうにサポートしてよいか難しくなるという問題があります。一般的に使われている方からはそんなに問い合わせはないんですけど、大企業でデモしたりする時って、やっぱり企業のネットワークってかなり制限が多いので、そこでつながらないことが非常に多いです。そもそもWebSocketが通らないからシグナリングできないとか、Man-in-the-middleで完全にブロックされているとか...。本当にそういうケースが多くて、ネットワークポリシーをちょっと変えてもらったら繋がるケースも多いです。企業ネットワークはすごく難しいです。社内ネットワークの内側同士だったら意外とよく繋がるんですね。弊社でも(PCのポリシーの制約で)カメラとマイクはつなげられないんですけど、DataChannelでファイル送ったりすることはできるので...(笑)。一応「明るい展望の話をしよう」という話になっていたはずなので、ちょっと話の流れ変えていいですか(笑)。繋がらない話ばかりだとみんな「WebRTCはつらい」と思っちゃうでしょうし。言うと大多数の人は繋がります。「繋がらない」と我々がしゃべっているのは、「繋がらない」ケースについて取り上げているだけ、だいたいの人は繋がります。家庭-家庭間ではほぼ間違いなく繋がる家庭-携帯端末間もほぼ間違いなくつながる企業-家庭間もほぼ間違いなくつながる繋がらないのは、企業-企業間と、こんな感じでまとめられると思います。企業-企業間に関しては利用頻度が高い場合は、そこのネットワーク管理者に相談して、自分たちのサーバーだけ何とか通してくれという交渉ができると思っているので、原則的には繋がるものだと考えていただいてよいです。「繋がらないというのは、あくまでもレアケース」、ということは持ち帰っていただけると幸いです。企業の場合はガードされているけど、理由があれば開けてもらえる、というところがあると思います。ここでどういうふうに開けるかという問題があって、サーバーを分散しているときにそれのIPアドレスを教えてくれと言われて、つらいという話があったりもします。動的にIPアドレスがふられる場合ですね。DNSで名前振ってるので、それを指定して開けるのが難しい場合もあって(IPアドレス指定が必要なとき)、そういう時は、結構うーん、というような状況になることがあります。動的な場合は難しいですね...。やりようはあると思っていて、例えば繋がるようにするのであれば、対象となる企業が決まっていれば、その企業向けにTURNサーバーを(固定で)立ててあげるというのも十分良いと思います。そのTURNサーバー向けの通信は全て通してくださいね、というお願いの仕方はあると思っています。うちの場合はそこまで各企業さん向けに大きくカスタマイズして提供することは難しい事情もあります。いうふうにサービスを提供したいか、だれに対してどのようなかたちでサービスを提供したいか、によってここの解決方法は選択肢があるのかな、と。逆に言えばそこの部分をかなり考えないと、あとあとすごく大変になってしまうという事態はありえると思ってます。ちなみに弊社におけるつながらない問題に関しては、通信環境の問題で繋がらないというのは、ほぼほぼ無いです。いうのは、そういう風にして繋がるように(設定や設置を)工夫しているというのはあるんですが、原則的に繋がらないというのはレアケースになります。ユーザーから繋がらないという問い合わせが来るもので一番件数が多いのは「カメラとマイク」の問題です。ブラウザがユーザに許可を求めて来た際に、「今回は私は映像使わないからとか、見ているだけだから映像音声いらない」ということで一回拒否をしちゃうんですね。ユーザへの権限許可の求めかた一回拒否しちゃうと、二回目そのページを開いたときも、ブラウザはその設定を読み込んじゃうんですよ。すると二回目以降その人が映像音声使いたくても、ブラウザとしてはポリシーに拒否が設定されているので、ユーザとしては「繋がらない」というかたちで結果が出てきます。いうところは(世の中的にも)結構な問題になっていて、FirefoxとChromeではその警告の出方が違うんですね。(ユーザへの)案内の仕方とかマニュアルの作り方とかも変わってくるんですね。海外のサービスを見ていると結構おもしろくて、getUserMedia()の許可を取ってねというのは、画面いっぱいにすごくドーンと出るんですよ。あーいうのってすごく重要なんだなーと見ています。サンプルアプリでChromeとFirefoxに対応して「ここをちゃんとクリックしてね」と出しても、だれも読んでくれないです(笑)。全画面でやらないとスルーされてしまうので、そこは注意しなければいけないです。見に行って参考にさせてもらうと、あー、やっぱりこうやらないと問い合わせくるよねー(と思います)。利用者の多いサービスは問い合わせ件数を下げることに一生懸命になりますから、やっぱりUIとかもそういう工夫していると思います。「なんでこうなっているのだろう?」という疑問から入るといろいろ解決していくのかなと。うちの場合いくつかの言語に対応しているので、その部分の多言語対応が必要だったりとかします。標準化してほしいですよねー。インターネットだけ頑張って抜けるようにしている環境だと、シグナリングサーバー(チャットサーバー)までは来ているのに、その後のWebRTCは繋がらないという特殊な環境の人は、一定数あります。レアケースだとは思います。OSのファイアーウォールの設定だとか、ネットワーク上は通信はできるのに、そのPCの設定や中のファイアーウォールの設定で繋がりにくかった、それも全く繋がらないわけではない、という状況になったことはあります。これは繋がらないわけではないのですがちょっと面白い話で、社内のハッカソンをやった時に、家庭用ルーターを使ってみんなアプリを作っていました。何時間か経ってアプリが動き始めたら、フルメッシュで10×10の通信が家庭用ルータを通って、融けました(笑)。それ以降通信できなくなってしまいました。家庭用ルーターでむっちゃ大量通信する場合は注意してください。