長らく更新してなかったブログですが、ここに書くのが適当かなぁというネタなのでw
次世代Webカンファレスという素敵なWebの未来を語るイベントが2015/10/18に法政大学で開かれました。
http://nextwebconf.connpass.com/event/19699/
そのなかでWebRTCのセッションでリーダーのiwashiさんに呼んでいただけたので喋ったのですが、テーマ通り聞いている人を置いていく感じだったので、改めて自分で聞き直してみてメモを起こしたので公開します。
ちなみに動画はこちらでみられます。
Togetterは開発の人たちがまとめてくれたのでこちら
http://togetter.com/li/888361
■WebRTCていまどうなの？
> 一言で言うと「割とつらい」
過去の遺産の代表はSDPを指す。結局ちょっと変わったことをやろうとすると、SDPを加工せねばならずSDPは改行やスペースで区切られた文字列として得られるので文字列のパーサを組むことになる。JSONじゃないんですよ。つらい。
> ネットにある2-3行でWebRTCができるというのは、ビジネスにできない裏返し。
> Skywayの中の人でもつらい
> つながらないとか。僕は生で書きたくないという人がいるが調べるにはスタックやプロトコルを見ねばならない。
映像品質が悪いであったり音声が途切れるという話が出てきたときには、このレベルで見に行くことになる。つらい。
> プラットフォーム側のひとはがんばってる。
> ブラウザが独自進化し続け歩み寄らないので吸収せねばならない。
> 全ブラウザが6週間程度で更新していく
実際のところ、ほとんどの人はjavascriptで吸収することになると思うが、これが本当につらい。
> ChromeやFirefoxはオートアップデート
このオートアップデートで突然繋がらなくなるのは、すでに状況としてかなり辛くなっている。CanaryやNightlyで検証しておくしかないのだが、繋がらないことが判明しても問題がSFU/MCU側になった場合は対応を急ぐことになる。当然変更によっては間に合わないこともある。つらい。
Chrome M46の件は当日朝にjavascriptでSDPを加工して回避した。つらい。
■運用のつらい話
> SDPとCandidateが読めないと仕事にならない。
SDPはOfferとAnswerで合意が取れていると接続される。繋がらなかった場合は何処で合意が取れていないかをOfferとAnswerを読んで認識し対策を打つことになる。Chrome M46の場合はまさにこのケースだった。
> CandidateもSDPも問題ないのにつながらない
これもある。原因は実はWebRTCのスタック自体が対応していなかったり、ネットワーク環境の問題だったり、謎のproxyが端末に設定されていたりすることが原因だったりする。後者の場合はユーザーのPCを見に行かないとわからない。つらい。
> お客様のネットワークを知ることができないが、繋げないと困ると言われる
逃げ場がなさすぎてつらい。経験からエスパーするしかないと思う。
> 映像音声の画質が悪いという話が来る
> マシンの性能や帯域依存の話になる
これは意外と多い。逃げ場がないのでつらい。
■もともとSIPやってた人にとっては当たり前の話
> 今まで専門家が持っていた知識を得ないとならない
SDPの知識などはまさにそれ、じゃあSIP屋さんが突然やってきてどうにかできるかというと、WebRTCの独自仕様やJavascriptの実装ノウハウの世界が出てくるのでやっぱりつらいと思う。
> ネットワーク環境を整えるとほぼほぼつながる。
ちゃんとメンテされているjavascriptでブラウザ依存を攻略していればほとんどつながる。これはほんと。
> 携帯電話網最強！
これは確認済み。ただ、WiFiルータとかの機種までは見てない。あと端末設定の問題はついて回る。
> 社内ネットワークはつらい
proxyとか謎FWとか多重NATとか。。。
> UDPがぬけないとつらい。TCPの場合TURNが要る
> 社内ネットワークはUDPがセキュリティに引っかかって抜けられない場合が多い
> TCPでTURN経由は結局サーバ経由
> SIPの技術では当たり前、NAT越えを理解しなければならない
抜けられないのは何が原因か、そしてどうすれば抜けるのかを見るにはNAT越えの理解が必須。CandidateやWiresharkを見ながら粘ることになる。つらい。
> NAT越えの仕様が変わることに追従しなければならない
これはSFUやMCUが絡んだ場合に強く出る話。外注している場合はSFUやMCUメーカーに状況を伝える。作っている側はお客さんの情報からエスパーする。もしくは収集してもらう。文句なしでつらい。
> SIPの人が通ってきたみちを通る
そのとおり、SIPは相当やばいと思う。独自仕様満載で相当辛そうだった
> この辺りを吸収してくれるところにSDKを提供してもらう代わりに金をはらう
一番楽な選択。責任転嫁できる。最高！でも、選ぶときは慎重に選ばなければならない。対応が早くて、技術力があるところを。。。
> SDKを使わない場合は専任のエンジニアが必須
> SDPを読めるレベルまで行ってる人が運用フェーズで占有される。
ただでさえ、学習コストの高いシステムで追従のため継続的な開発が必須なのに、開発できる人が運用に消えることになる。これは非常につらい。
> ChromeとFirefoxでSDPがちがう。
それを頭の隅に置いて、SDPを読むことになる。
> ChromeとFirefoxだとFirefoxの方がUnified Planということで先行している。
MultiStreamの話。ChromeはPlanB。Unifiedで行こうと決まったのでChromeはそれを載せなければならないが、いつになるのやら。。。
> Hangoutの足かせはおおきいの？→ホントか？
> GoogleはHangoutが動けば困らない
じゃぁ、FirefoxでHangoutがどう動くのかは試してみたいところ
■追従しないと困るのは僕らだけ、Googleは困らない
SIPの頃と同じ、メーカーは独自拡張でも閉鎖系を組めばいい話。違機種間をつなごうとする人が頑張って仲を取り持つ。つらい話。ただ、Googleの独自拡張により高い品質が得られているのもまた事実。まさにSIPと同じ。
> Firefoxが先端だが、WebRTCの次世代であるORTCも見なければならない。ORTCはどうなんだ。
> WebRTCの仕様がわかりにくいからJSONになった。あと機能が細分化されて色々な組み合わせができるようになった。
これは恐ろしい話だけど合理的だと思ってる。簡単に利用したい人はSDKを利用する。本気で利用する人はSDPをいじってカスタムする。であれば、本気の人向けにより低いレイヤーのAPIを使えるようにしましょうになる。なったのではと思っている。
> APIでできそうなことが、本当にどこまで、できるはずのことが、できるかは謎。
これは現状のjavascriptのAPI状況から来る話。純粋にできないだけではなく、正しい使い方がわかってない場合もある。でも、できそう。やってみてもできない。特定条件を満たすとできる。Firefoxだとできる。ある日アップデートでできるようになる。つらい。
> サイマルキャストどうするか、現状動画の品質が一本だけ。
これはやることを増やすに従ってネックになってくる。
サイマルキャストで端末性能や帯域の不足から解放されるのは非常に大きい。
■WebRTCはP2Pという世界ではない
満足すると上を見る。P2Pでは6人くらいが限界です。それを越えようとするとSFU/MCUが必要になる。
要求に応えるには用意しなければならない。それが当然になる。サービスとして提供する際には必須になる。というオチ。つらい。
> MCUはトランスコードする
これを聞くと遅延が酷いのではという人が多いが、全然問題ない。最近のCPUすごい。
> MCUはエンコーダーが一つ
WebRTCの理想としては端末に対して1エンコーダが理想。でも会議室あたりにしないとサーバースペックが足りずメリットが生かせなくなる。多人数配信と引き換えに画質を失う。つらい。だから、MCUからサイマルしたい。でもエンコーダーが増える。1台あたりで捌ける会議数が減る。つらい。
> 現在ではMCUが最適解
多人数配信ができ、非力なマシンでも良い。最適解。
ただコストが高い。つらい。
> 会議の録画したい
満足すると上を見る。以下略。つらい。
> SFUの合成つらい
SFUは暗号解いた動画ストリームを転送している。クライアントからすると複数の動画ファイルを同時に再生している状態。
> SFUは時間軸を合わせて録画する必要
会議とかの場合は会話する。再生した時には会話が成立しなければならない。動画を同時に再生する必要がある。しかし、参加時間も退室時間も人によって違うし、滞在時間も違う。尺の違う動画をタイミングとって再生ボタンを押して会話を成立させる。これはプログラムの仕事。考えるだけでつらい。
> WebRTCはRTCP
RTCPの制御がWebRTCをこそが実現している。RTCPの無いWebRTCはありえない。
> MCUのあきらめ
エンコーダーを多人数配信向けにカスタムできるという強みがでると思う
> SFUはつらい
SFUつらい。MCUと違ってSFUはjavascriptの系が複雑になる。複数動画同時再生だかんね！
■WebRTCやってる人には優しくしてね
つらい話ばっかりなので。。。
> 世界は閉じたつもりでいても実は空いている
セキュリティホールの話ではなく、社内利用といいつつ社外の人がつかうシチュエーションというのが必ずでてくる。社外の人と話したいというニーズもある。そしてそれはお客様対応になるわけで。。。
> FirefoxのSDPは美しい
これは本当。見てみるとわかる。
> Electron最高！
でも、できることが増える→やりたいことが増える。つらい。
> RasPi2 ですね
RasPi2ほど速くて手頃に手に入るデバイスはないです。本当。
> EncoderはHW Encoderが鍵
これは難しい話で、じゃぁHW EncoderがベストかというHW EncoderはHWである以上アップデートができない。
つまり、より良いEncodeの手法が見つかっても対応できないという難点があったりする。でも、鍵であるのも間違いない。
> 後ろにメーカー名がついている
メーカー独自の（以下略）つらい。
■WebRTCはライセンス料がかからない
実はWebRTCはこれが前提なので、ライセンス料はかからない。これも大きい。
> IPv6になってもNAT越えは要る
グローバルにパソコンを曝しますか？いや、やらないでしょう。企業は特に。
> 一つのハードから複数に配信できない
パソコンでもつらいのにRasPiで複数人配信なんて。。。という話。
> 接続開始や終了を制御する。
WebRTCの接続情報はビジネス提供側のWebSocketサーバなりで交換することになるので制御可能のです。
というかSDKですし！
> SFUとSVCが合流になるので。。。らく？
いまでもエンコーダーは帯域推定して自動制御されてるから、それをSVCにおける解像度選択に利用。。。いや、それがすでにつらいな。つらい。っていう話です。
■あとがき
中間の■はてきとうにつけました。まず、主催のjxckさんには感謝を！非常に楽しいイベントでしゃべらせてもらいました。Vさんもiwashiさんも一緒にやらせていただき、ありがとうございました。また、準備や受付、誘導などを一緒にやったスピーカーの皆さん。ありがとうございました。とても素敵なイベントになったと思います。
聞いてると、僕しゃべりたいこと喋ってて会話になってないところがありますね。反省。
WebRTCつらいですが、楽しんでやってますよ！なので、一緒につらい思いをしている方は是非その苦労を分かち合いましょう。という話でした。