CodeIQ MAGAZINECodeIQ MAGAZINE

【祝1周年】基礎からマニアックまで、WebRTCなら何でもOKな「WebRTC Meetup #7」 #webrtcjp

2015.04.06 Category:勉強会・イベント Tag: ,

  • 19
  • このエントリーをはてなブックマークに追加
webrtc-1

3月11日、WebRTCに特化した勉強会「WebRTC Meetup #7」が開催された。

約1年前に1回目が開催され、今回で7回目となるが、毎回WebRTCに関心のある人たちが集結。

登壇者が話す内容はWebRTCの基礎的なことから、かなりマニアックなことまで幅広い。その様子をレポートする。
by 馬場美由紀 (CodeIQ中の人)

1周年を迎えるWebRTCに特化した勉強会「WebRTC Meetup」

WebRTC Meetup Tokyo #1開催から1周年を迎えた「WebRTC Meetup #7」が開催されたのは、東京・渋谷にあるITクリエイターのためのコミュニティスペース「TECH LAB PAAK」。

WebRTCに特化したこの勉強会は、プログラマ、デザイナー、サービスを考える人など、WebRTCに興味のある人なら誰もが参加できる。

今回は1周年を記念して、WebRTCを活用した体験型おもしろ企画も用意され、参加費無料の全編ビアバッシュ形式で行われた。

▲ビールを飲みながら、ゆったりとしたスタイルで話を聞く参加者たち

▲ドリンク・フードスポンサーはNTTコミュニケーションズ

▲ピザの横にそっと置いてみたCodeIQエコバック

WebRTCをビジネスで活用するために必要なこととは?

最初に登壇したのは、時雨堂の@voluntasさん。セッションタイトルは「WebRTCスタックコトハジメ」。

▲発表資料はこちら

「まずは『O’Reilly Japan – ハイパフォーマンス ブラウザネットワーキング』を読むことか一番お勧め」と話す@voluntasさん。今回のセッションでは、ここに書かれていないことが話された。

「WebRTCはブラウザに実装されている技術。遊んだことはある人はあるが、ビジネスで使おうとしている人は日本では少ない。しかし海外ではビジネスで活用しようと、非常に盛り上がっており、カンファレンスなどがバンバン開催されている」と@voluntasさんは言う。その理由は、日本ではブラウザから切り離して話をする人があまりいないからだそうだ。

ビジネスで活用するために、WebRTCの内部で動作している次のようなプロトコルを理解しなければならない。

  • SDP
  • STUN
  • TURN
  • ICE
  • DTLS
  • SRTP
  • RTP
  • RTCP
  • SCTP

またこれらのWebRTCのプロトコルを知るには、「WebRTCを支えるマイナーなプロトコル SRTP/DTLS/SCTPを分かった気になる」を読むのがお勧めとのこと。

WebRTCを支えるマイナーなプロトコル SRTP/DTLS/SCTPを分かった気になる from iwashi86

これらのプロトコルスタックを利用して、WebRTCはブラウザとブラウザのメディアチャネルとデータチャネルという2種類の通信を実現する。メディアチャネルは音声や動画、データチャネルはバイナリを送受信する仕組みである。

「ビジネスにするにはもう少し深いところを知らないといけない」と、@voluntasさんは指摘し、今回のセッションではそれらのプロトコルスタックを紹介していくという。

P2P確立に必要な技術として挙げられたのは、SDP、STUN、TURN、ICE。WebRTCではシグナリングと呼ばれている。クライアント同士がやり取りする内部情報は、SDPというプロトコルが使われる。「読みにくいと有名なプロトコル」なのだとか。

続いてデータチャネルに必要なSCTPというプロトコルを紹介。このプロトコルは1本のコネクションで複数のコネクションが通じるというもの。まだ実践導入はされていないという。

メディアチャネルではSRTPというプロトコルを使用する。これはRAPを暗号化したもの。

「WebRTCで逃げられないのがこの技術」と言い、@voluntasさんがが挙げたのがDTLS。DTLSは通信自体を暗号化する仕組みで、メディアチャネルとデータチャネルのいずれもこの技術で守られている。DTLSには1.0。

1.2のバージョンがあるが、パケットを見る限り、1.0が使われている。音声やデータを通信の途中で見られないようにする「暗号化は非常に重要」と強調。データチャネルではUDPの上にDTLSを載せて、そのアプリケーションデータの上にSCTPを実現している。

一方、メディアチャネルはすごく独特の暗号方式となっており、DTLSはあくまでも鍵交換のためで、DTLSが用意したトンネル自体は使われないのだそう。

WebRTCスタックの必要性

ここでプロトコルの紹介は終了。話はWebRTCスタックの必要性について。「なぜ、必要かというとサーバで録画をするためだ」と@voluntasさんは語る。WebRTCはP2Pをブラウザで使えるようにした技術だが、その概念をクライアントとサーバに置き換えることができる。

つまり、WebRTCをサーバーサイドで吸収して配信するのである。すでに海外では録画可能なWebRTCのシステムが登場しており、Janus,Licode,Mantisなどはその一例だ。「今までブラウザとブラウザの間で見てきたWebRTCはホビーでしかない。

サーバーサイドアプローチなら、例えばニコ生みたいなのが、ブラウザだけで作れるようになる。WebRTCをビジネスで活用するにはサーバ経由の通信が重要になる」と@voluntasさん。

それを可能にするのが、MCU(Multipoint Control Unit)とFSU(Selective Forwarding Unit)という仕組み。MCUは全ての接続を 1 本に統合してくれる素敵な仕組みで、これを実現するにはWebRTCスタックが必須となる。

サーバですべての暗号化を解き、動画や音声を合成し再配布するため、CPU的に非常に優しくない。そのため、@voluntasさんは「個人的にはあまり嬉しい場面がなさそう」と感想をもらす。

一方のSFUは上りを1本に抑え、下りを複数本にする仕組み。こちらもWebRTCスタックが必須となる。米Tokboxという企業では、この仕組みを使って、リアルタイムビデオとオーディオのチャットプラットフォームを実現。同社はかなり成功しているという。

実装での懸念点もあると指摘する。MCUは接続数自体を抑えることができるが、音声合成が大変なのと、合成に伴う遅延が気になると@voluntasさんは言う。

「ハードで解決するところもあるため、会議システムを開発している会社でない限り、ビジネスで使うのは難しい」とアドバイスする。またSFUでは、1クライアントに対する接続管理がその会議に参加しているユーザー数+1になる。

つまり10人で会議をしようとすると、1サーバで100の接続を支える必要がある。企業に導入されることを考えると、会議はそれだけでは済まない。つまりかなり接続されても大丈夫な仕組みが求められるというわけだ。

しかしそこに「ビジネスチャンスがある。MCUやSFUは既存のカンファレンスサービスや会議システムの代替になる。ぜひ、そこにチャレンジする人が出てきてほしい」。最後にこう語り、@voluntasさんのセッションは終了した。

WebRTCの機能を使ったかくれんぼ

「まじめな話は終わり。ここからは楽しんでいきましょう」と主催者・仲さんの合図で始まったのが、おもしろ企画「WebRTCかくれんぼ」。登壇したのは、NTTコミュニケーションズの小松健作さん。

小松さんの手にはChromebookが。この企画はWebRTCの機能を使い、モザイクアートの中に自分の動画を埋め、かくれんぼをするというもの。近くにいる人たちでチームを組み、スクリーンにモザイクアートが映し出されてかくれんぼがスタート。

最後まで見つけられなかったチームには、なんと一体型エディケーショナルロボット「Romo(ロモ)」が贈呈された。優勝したのは@Jxckさん。

アスラテック社による人型ロボットOS「V-Sido」デモ

おもしろ企画終了後の休憩時間は、アスラテックが提供する人型ロボットOS「V-Sido」のデモが行われた。今回、デモをしたのは@akhkkdmさん。「V-Sido」を、WebRTCを用いてWebから遠隔コントロールする開発プラットフォーム「Web Controller for V-Sido Connect」を披露した。

このシステムではAndroidアプリとWebインタフェースを用いてロボットを操作できるようになるという。主な特徴はAPIを用いることで、JavaScriptだけでロボットアプリケーションの開発が可能になること。

またWebRTCやWebGLなど、HTML5技術のみで実装されている。実装例も紹介し、Web UIの操作画面に表示されたロボットの右腕を上げると、リアルタイムで実際のロボットがその動きを追随などのデモを実施。「この機能はNTTコミュニケーションズのSkyWayを使って実装している」のだそうだ。

「WebRTCはこれまで人間同士のコミュニケーション、P2Pに用いるケースがほとんどだったが、これからはH2R、つまり人間とロボットとのリアルタイムコミュニケーションにも活用できる。デモでも見せたように、WebRTCは実用レベルの転送レイテンシーを実現している。今回、初めてWebRTCを活用してみたが、IoT的なモノをリアルタイムで制御する試みとしてはうまくいったと思う」と語り、@akhkkdmさんのデモは終了。

SDNの読み方、四方山話etc.…基礎からマニアックまで飛び出したLT

MCUとネイティブの四方山話

勉強会は後半に突入。最初のライトニングトーク(LT)に登壇したのは@tonofoさん。トークタイトルは「MCUとネイティブの四方山話」。

@tonofoさんは都内の通信事業者に務めている回路設計者。「最近、MCUネタはエキスパートな人たちが出てきてつらくなったし、Native Code Packageネタは実装していないことや大幅に変更されることも多く追従が難しいので、さらに話すのがつらくなってきた。そこで今日はMCUやSFUの話をする」と前振りし、四方山話が始まった。

JanusやHP、Vodeobridge、Dialogicなど、WebRTCのプラットフォームを分類し、それぞれを簡単に紹介。中でも@tonofoさんが気になっているのが、2月にリリースされたDialogic Powermedia XMS 2.4。

最新バージョンにはEncode Sharingという機能が追加されており、この機能を使えばエンコーダーを会議室単位で共有できるようになるという。つまり多人数会議における処理効率が大幅に向上し、「100人会議ができる」と@tonofoさん。またOpenWebRTCはRaspberry Piでも動くようになるという。

@tonofoさんはRaspberry Pi2とWebRTCWebを用いてWebカメラを作ったという。Janusのゲートウェイを通すことでRTCをWebRTCに変換し、Firefoxに映像を出すというものだ。

一般的にWebRTC対応のブラウザというとChromeだが、なぜFirefoxを選んだのか。その理由は「H264対応はFirefoxだけだから」だと言う。しかしベースライブラリはChromeと同じはずなのに、Chromeでは動かないので、Firefoxはかなり手を入れていると思われる、と@tonofoさん。

そこでChromeでもFirefoxでも見られるようV8を使いたいと考え、gstreamerで処理を行ったという。すると「Chromeでもほぼ静止画だけど、映った」という。「VP8ハードウェアエンコーダのすごさが実感できた」と語り、四方山話は終了した。

自前WebRTCコードで痛い目にあう

次に登壇したのは清水智行(@othersight)さん。清水さんはKDDI研究所の開発主査。平日はほぼJavaScriptをコーディングしている。トークタイトルは「自前WebRTCコードで痛い目にあう」。

会社でWebRTCを試してみようということになり、まっさきにPEERJSで試してみたという清水さん。

しかし通信に利用するのにIDが長く、第一印象が悪かったという。この使いづらさを解消したい、そしてWebRTCの中身をよく知りたい、自由にわかりやすいアカウントを設定したいという思いから、自前でWebRTCのプレゼンス、シグナリングなどの機能を作ってみたという。2014年時点ではとりあえず動いている。

ここまではすんなりきたが、「今年に入りブラウザのアップデートにより、苦戦中だ」だと清水さん。特にFirefox33での仕様変更により、現バージョンのChromeとの互換性は取れていないという

。「この手の仕様はどんどん変わっていく。自分でRTCのコードを書くと、痛い目に遭うのは諦めなければならない」と清水さんは警鐘を促す。

このように自前でWebRTCのコードを書くと互換性やAPI仕様変更などによりいろいろと痛い目にあうが、「アカウント管理やつなぎ方など、いろいろ自由にいじり倒せるのがメリットだ」と言う。その一例として紹介したのが、WebRTCで「ピー」音を流すというデモ。気になる人はこのURLで詳細をチェックしてほしい。

「複雑なことをしたいと思ったら、面白いのでぜひ、チャレンジを」こう最後に会場に呼びかけ、清水さんのLTは終了。

getUserMedia

次に登壇したのは、本勉強会の進行役でもある仲裕介さん。仲さんはNTTコミュニケーションズコミュニケーションズでWebRTC開発者向けフレームワーク「SkyWay」の開発に携わっている。

トークタイトルは「getUserMedia」。getUserMediaはWebブラウザでマイクやカメラが利用できる便利なAPIである。「getUserMediaを使ったことのある人いますか?」という呼びかけから始まった仲さんのLT。参加者の大半が手を上げた。

コードにはベンダープレフィックスが付いており、実装途中でブラウザごとに使える機能が違うのだ。ChromeとFirefoxでどう違うのか。W3Cの仕様書では画像の横幅や縦幅の指定、映像のアスペクト比、映像のフレームレート、カメラの選択、音声ボリュームなどいろいろできると定義されている。実際、これらは使えるのか。

まずはWidthとheightについて。これは「Chromeでしか動かない」と仲さんは続ける。「使ったことのある方なら分かると思うが、VGAで取得しても一緒。Firefoxは指定しても意味がない」と言う。次にaspectRatio。これはChromeもFirefoxともに動かないという。

grameRateはChromeのみ、facingMode(カメラのリアとフロントを切り替える)はChrome、Firefox双方で動かないという結果に。つまりほぼFirefoxではgetMediaは使えないということだが、「aboutConfigをいじると同じようなことができるようになるので、FirefoxでWebRTCのアプリを開発する場合は参考に」と仲さんは語り、LTを終えた。

SDP for WebRTC

最後のLTはiwashi86さん。トークテーマは「SDP for WebRTC」。iwashi86さんもNTTコミュニケーションズでSkyWayの裏側の開発運用に従事している。今回は会場には現れず、遠隔地と結んでのLTとなった。

冒頭で「今日はSDPの話をする。ORTCが来たら、だいたい忘れていいことが多いが、本質的に通信に必要な情報(ICEとか)はORTCでも同じであるため、今後もう役立つと思います」と宣言し、iwashi86さんのLTはスタート。

SDPのコードを画面に映し、「VoIP上がりの人はSDPを多少読めると思うが、Webデベロッパーにとっては象形文字に見えているはず」と言う。象形文字がコードに見えるよう、SDPの読み方の基本および少しマニアックな部分を理解し、嫌悪感を軽減するための説明が始まった。

SDP for WebRTC – From Basics to Maniacs – from iwashi86

まずはなぜSDPが必要なのか。それは柔軟にメディア(音声、映像など)を通信するには、通信条件のネゴシエーションが必要だからだ。このようなモデルをオファーアンサーモデル(RFC3264)と呼ぶ。

オファーアンサーはセッション(親)とメディア(子)の概念がある。そのため、SDPはセッション記述部とメディア記述部がある。セッション記述部とメディア記述部の見分け方はm=で始まる行を探せばよい、とiwashi86さんは言う。

そしてiwashi86さんはセッション記述部の見方を説明していく。a=以降は拡張属性なので、WebRTC的には重要になると言う。特に重要なのが、a=gourp;BUNDLEとa=ice-options;trickle。前者は音声(audio)と映像(video)を多重化、後者はTrickleICEを利用することを表している。

次にメディア記述部について。メディア記述部には必要なメディアの数だけ「m=」で始まるブロックが存在する。オーディオでWebRTC的に重要な項目の説明では、1行目のm=にはメディア種別、ポート、プロトコル、ペイロードタイプが記されているとのこと。

またペイロードタイプは2カ所に分かれて記載されている。2カ所目は拡張属性a=rtpmapで記載。1行目のペイロードタイプの数字は優先度順になっている。「最初の数字が最優先で使いたいコーデックとなる」とiwashi86さんは説明する。

2行目のc=にはIPアドレスが書かれており、それ以降はa=ですべて拡張属性となる。もちろん拡張属性の「a=は重要だ」と語り、それぞれの拡張属性の説明を続けた。

例えばa=fandidateはICE候補(詳細はRFC5245参照)、a=sendrecvは双方向通信、a=end-of-candidatesはtrickleICEの完了という意味を表すように。

「象形文字がちゃんとSDPに見えているはず」こう語り、iwashi86さんのLTは終了。iwashi86さんは当日のイベントレポートを公開しているので、より理解を深めるためにもご覧いただきたい。

次回は5月ぐらいに開催予定

最後に仲さんが登壇し、締めの挨拶を行った。

「次回は5月ぐらいに開催する予定です。今日マニアックな話が多かったが、ライトな楽しい話をしてくれる方も募集しています。開催の予定などは『webrtcjp.info』をチェックしてください」

まったく堅苦しくない雰囲気が魅力の勉強会、WebRTC Meetup。WebRTCを学びたい人にとっては、非常に有意義な時間を過ごせるはず。関心のある方はTwitterをチェックし、次回ぜひ参加をしてみては!

当日の動画中継は以下からご覧いただけます

自分の書いたコードを誰かに評価されたいエンジニアは、けっこう多い?

ITエンジニアのための実務スキル評価サービス『CodeIQ』で出題されている「コード銀行」問題に挑戦すると、あなたのコードが評価されます。

評価(1)出題者からの評価  ⇒評価フィードバック例を見る

  • 企業ではたらくという観点からあなたのコードをチェックします
  • フィードバックされた観点をふまえてコードを書くと世の中の企業にとって「いいコード」が書けるようになります

評価(2)企業からの評価  ⇒評価フィードバック例を見る

  • 「あなたと一緒にはたらきたい」という企業からスカウトが届きます
  • あなたのコードが社会でどこまで通用するか、リアルな評価が得られます

興味を持った方はこちらからチャレンジを!

  • 19
  • このエントリーをはてなブックマークに追加

■関連記事

リラックスして楽しみながらWebRTCが学べる「WebRTC Meetup Tokyo」 #webr... プログラマだけではない。WebRTCに関心のある人なら誰でも参加できる 「この勉強会のターゲットはプログラマだが、Webデザイナーやサービスを考える人など限定はない。これからは1カ月もしくは2カ月に1回の割合で同勉強会を開催していく予定。このような集まりをきっかけに、日本でWebRTCを流行ら...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ