WebRTCと SFU

TAG Developer Summit@sakkuru

Saki Homma@sakkuru

NTT Communications

WebRTC

クライアント間で映像・音声・データをP2Pでリアルタイムにやり取りできる技術

事例

WebRTCのプラットフォームを開発・運用しています

実際WebRTCの開発をしていると・・・

• つらいつらいことがめっちゃある

WebRTC開発つらいリスト• ブラウザの互換の問題• プロトコル多すぎ• IP, UDP, TCP, TLS, RTP…• DTLS, SRTP, SCTP…• SDP, NAT, NAT traversal, ICE...• TURN, STUN, MCU, SFU• レイヤ 4の知識は当然いるよ• レイヤ 3の知識も当たり前にいるよ• コーデックの知識もいるよ• 問題の切り分けが難しい• W3Cや IETFの仕様書が多い• どんどん変化する仕様• ハイスペックが要求されるマシン• なぜかつながらない• なぜかつながる• なぜか切れる• なぜか音は流れるのに映像がでない

• なぜか片方だけ映像がでる• なぜかデモのときだけ失敗する• 開発中自分の顔がずっと映る

もっとあると思う

つらい 01

ブラウザ互換の問題の例

WebRTCの通信がはじまるまで

こういう映像をこういうコーデックで送るよあと IPアドレスこれね

WebRTCの通信がはじまるまで

OK!こっちはこういう映像をこういうコーデックで送るよこっちの IPはこれね

WebRTCの通信がはじまるまで

WebRTCの通信がはじまる

ブラウザ違っても通信できる！

複数の映像をやりとりしたい

そのままではできない

なぜか ?こういう映像をこういうコーデックで送るよあと IPアドレスこれね

このとき

v=0o=- 2488805575470474716 2 IN IP4 127.0.0.1s=-t=0 0a=group:BUNDLE audio videoa=msid-semantic: WMS 8WozN5N6ncERDDK3jSxrUzqWriXmcstBeW5qm=audio 9 RTP/SAVPF 111c=IN IP4 0.0.0.0a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:X3J3a=ice-pwd:wJvn+Tv+CfdqsqFKuOazBDsLa=fingerprint:sha-256 26:E2:BF:B8:57:80:92:FC:7C:6E:1E:F6:C4:84:7B:92:29:65:6D:29:A9:D6:9D:33:A7:13:BA:36:E5:0C:D4:91a=setup:activea=mid:audioa=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-levela=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-timea=sendrecva=rtcp-muxa=rtpmap:111 opus/48000/2a=fmtp:111 minptime=10;useinbandfec=1a=ssrc:2563974588 cname:x6dRh6wS7Lw9igqNa=ssrc:2563974588 msid:8WozN5N6ncERDDK3jSxrUzqWriXmcstBeW5q f2013dbf-2038-4849-8fb3-f0b4d07bf09da=ssrc:2563974588 mslabel:8WozN5N6ncERDDK3jSxrUzqWriXmcstBeW5qa=ssrc:2563974588 label:f2013dbf-2038-4849-8fb3-f0b4d07bf09dm=video 9 RTP/SAVPF 100c=IN IP4 0.0.0.0a=rtcp:9 IN IP4 0.0.0.0a=ice-ufrag:X3J3a=ice-pwd:wJvn+Tv+CfdqsqFKuOazBDsLa=fingerprint:sha-256 26:E2:BF:B8:57:80:92:FC:7C:6E:1E:F6:C4:84:7B:92:29:65:6D:29:A9:D6:9D:33:A7:13:BA:36:E5:0C:D4:91a=setup:activea=mid:videoa=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-timea=sendrecva=rtcp-muxa=rtpmap:100 VP8/90000a=rtcp-fb:100 ccm fira=rtcp-fb:100 nacka=rtcp-fb:100 nack plia=rtcp-fb:100 goog-remba=ssrc:1414028774 cname:x6dRh6wS7Lw9igqNa=ssrc:1414028774 msid:8WozN5N6ncERDDK3jSxrUzqWriXmcstBeW5q 027a33e3-05bd-4fce-b67b-60b53d8e98a0a=ssrc:1414028774 mslabel:8WozN5N6ncERDDK3jSxrUzqWriXmcstBeW5qa=ssrc:1414028774 label:027a33e3-05bd-4fce-b67b-60b53d8e98a0

やり取りしてるのはこんな文字列

ブラウザによってフォーマットが違うΣ(￣ロ￣ lll)

Chrome: PlanB SDPFirefox: Unified Plan SDP

でも近々 Unified Planに統合される予定年末~1月くらい？

1つの映像 /音声 /データ

SDPの差はほぼない (少しある )→ Chrome-FF間で通信可能

複数の映像 /音声 /データ

SDPの差が大きい→ Chrome-FF間では SDPの変換・生成が必要

SFUのはなしSFU = Selective Forwarding Unit

SFU

上りも下りも人数分

上りは 1本下りは人数分

P2P

クライアントの負荷が小さいので通信可能な人数が増える

SFUのサーバ

両方の SDPフォーマットを解釈しSDPの差を吸収可能

8月から SFU機能の α版を無償で提供しています

SFUモードはGoogle Chromeのみ

先週@SkyWay開発チーム

Firefoxで SFU動きました！

やばい何この安定感

Awesome job!      

近日中にFirefoxにも対応するよ！

おしまい