はじめに

この資料はSkyWay UG Tokyo #3の発表資料です。
資料URL: https://goo.gl/V7YtWJ

自己紹介

なかゆうすけ（@yusuke84）
仕事:
- WebRTC Platform SkyWay
  - Technical solutions
  - Technical support
  - Developer relations
コミュニティ
- WebRTC Meetup Tokyo 主催
- WebRTC Beginners Tokyo 主催

この資料は何？

サポート等で問い合わせが多いSkyWayのティップスを厳選して紹介します

達成したいゴール

SkyWayを利用するエンジニアの困ったを、1つでも多く解決し ハッピー になってもらう
SkyWay初心者からSkyWay中級者へステップアップしてもらう

今日お話する内容

SkyWaySDKの通信モデル
SkyWayの通信要件
SkyWayを利用したWebRTC通信のコネクティビティ（メディアコネクションの場合）を確認する
SkyWayを利用する際の通信帯域
SkyWayの動作確認済みブラウザとOS
SkyWayを配信に利用する場合のティップス

本題に入る前に…お知らせ

ダッシュボードで利用量の閲覧ができるようになりました

APIキー毎に直近2ヶ月分閲覧可能
更新頻度は1日に数回程度
利用量は1MB単位で切り上げ
Enterprise Edition利用のお客様は今まで通り「料金・請求」の明細画面からも確認可能

Enterprise EditonへのAPIキー移行ができるようになりました

Community EditionからEnterprise Editionへ移行可能
- 逆はできない
サービス停止無しで移行可能
利用量表示のデータはCommunity Editionでの実績が反映されますが、課金は移行完了した時点から開始

SkyWaySDKの通信モデル

SkyWayを利用するにあたり、知っておくべき概念です。

Peer

SkyWayを利用して何らかのサービスを作る場合、最初にPeer(ピア)というインスタンスを作成する
Peerは、SkyWayのシグナリングサーバや、他のクライアントとの接続を管理するエージェント

PeerID

Peerを作成(new Peer)すると、作成したPeerがシグナリングサーバへ接続する
接続が成功すると、Peer.openイベントの発火と共に、SkyWayサーバ側がランダムに作成するPeer IDという値を取得できる
Peer IDはPeerを一意に識別するためのID
接続が失敗した場合はPeer.errorイベントが発火する

通信モデルその１「電話モデル」

電話で通話する場合と同様に1:1で通信するモデル
通信を開始する場合には、相手のPeerIDを何らかの手段で知る必要がある

音声・映像（メディアチャンネル）

相PeerIDを指定して相手に発信（peer.call）
callイベントが着信側で発火
そのcall要求に対してanswer()を呼ぶことで通信確立
音声・映像はStreamイベントの発火とともに取得できる

データの場合（データチャンネル）

peer.connect()で相手に接続要求
接続が確立するとconnectionイベントが発火

メディアチャンネルと異なりanswer()を明示的に呼ぶ必要がない

通信モデルその２「ルームモデル」

同一ルームに存在するすべてのPeerで会話するモデル
ルームの名前空間はAPIキー毎に独立している
APIキーが違う場合は同一ルーム名でも別ルームと扱われて相互通信は出来ない
ルームの実現方式にはフルメッシュとSFUの2種類がある
- 両者の違いはの詳細はこちら
- 同一APIキー上にフルメッシュとSFUで方式で同時に同一ルーム名のルームを作ることは出来ない

ルーム名を指定してルームに参加（peer.joinRoom）
他の参加者からメディアを受信した場合はRoom.streamイベントが発火する
Room.Close()でルームからの退出する

ルームの削除は参加者が全員退出したら行われる
- 明示的に消す方法はなし

メディアストリームの扱い

SkyWayのSDKではメディアストリームは入力時に渡して出力時に取得するのみが原則となる
- iOS/Android SDKはメディア作成APIを搭載しているが入力はプログラム側から行う

SkyWayの通信要件

その１（管理系）

ディスパッチャ
- TCP443(HTTPS Protocol)
- dispatcher.webrtc.ecl.ntt.com
シグナリングサーバ
- TCP443（プロトコルはSocket.io依存）
- *.webrtc.ecl.ntt.com
- シグナリングサーバは複数台構成のためワイルドカードで記載

その２（WebRTC関連）

P2P通信
- ポート番号はUDPハイポートレンジを利用し毎回ランダムに決定
- IPアドレスもクライアントアドレスは環境に合わせて変わる
STUN通信
- UDP3478(STUN Protocol)
- stun.webrtc.ecl.ntt.com
- 役割
  - 自分自身のIPアドレスとポート番号を取得
  - STUNサーバへアクセスが出来ずP2P通信も出来ない場合は、TURNサーバで代用

TURN通信
- TCP443,UDP443（低コストでつながる方を勝手に選択）
- turn.webrtc.ecl.ntt.com
- 役割
  - P2P通信できない場合の代替手段

TURN通信は3パターン

AさんのみTURN（プロトコル）を利用する場合

AさんとBさん両方が同一のTURN（プロトコル）を利用する場合

AさんとBさん両方が別々のTURN（プロトコル）を利用する場合

TURNサーバは極力使わないようにネットワーク設計する

UDPによるハイポートの通信を規制しない
STUNサーバへのアクセスを許可する
エンタープライズユースの場合はNATタイプに気を使う

絶対TURNサーバが必要な場合

UDP通信が禁止
- TURNプロトコル（TCP）を利用した通信をするしかない
通信相手をACL等で制限する必要がある
- 通信相手を固定する場合はTURNサーバのアドレスで固定するしかない
IPv6アドレスを持ったPeerがSFUやIPv４アドレスのPeerと通信する場合
- NAT64/DNS64環境でTURNにアクセスできる場合
- 詳しくは SkyWayのIPv6環境での動作について

SkyWayを利用したWebRTC通信のコネクティビティ（メディアコネクションの場合）を確認する

予備知識〜SkyWay SDKのオブジェクト構造〜

全SDK共通

Peer Class/Object
- シグナリングサーバとの接続を管理する
MediaConnection Class/Object
- メディアコネクション（映像・音声のP2P通信）を管理する
DataConnection Class/Object
- データコネクション（データのP2P通信）を管理する
SFURoom Class/Object
- SFUのRoom接続を管理する
MeshRoom Class/Object
- MeshのRoom接続を管理する

iOS/Android SDKのみ

iOS
- SKWNavigator
  - ブラウザのgetUserMedia APIに相当
- SKWMediaStream
  - メディアストリーム
- SKWVideo
  - 映像を表示するレンダラービューオブジェクト
Android
- Navigator
  - ブラウザのgetUserMedia APIに相当
- MediaStream
  - メディアストリーム
- Canvas
  - 映像を表示するレンダラービューオブジェクト

シグナリングサーバとの接続が確立できたことを把握

全SDK共通
- new Peer実行
- Peer Class/Objectのopenイベントが発火する
- 以降の処理はすべてこのイベントが発火してから実施する

（参考）new Peerを実行すると内部的には何が行われるのか？

ディスパッチャーサーバから接続対象のシグナリングサーバを取得
- シグナリングサーバは複数台で冗長構成を取っているため接続対象のサーバをディスパッチャーサーバに毎回問い合わせる
- signaling-xxxxxxx.webrtc.ecl.ntt.com 等のURLを取得
シグナリングサーバへの接続
- 認証サーバ連携している場合は認証情報の検証
- PeerIDの生成
- TURNサーバ接続用の認証情報取得
シグナリングサーバとは常時接続された状態を維持
- 定期的にping/pongを実施
openイベントが発火

メディア通信が開始されたことを把握

JS SDK
- MediaConnectionオブジェクトまたはRoomオブジェクトのstreamイベント
iOS/Android SDK
- P2Pの場合
  - SKWMediaConnection on:SKW_MEDIACONNECTION_EVENT_STREAM
  - MediaConnection.MediaEventEnum.STREAM
- Roomの場合
  - SKWRoom on:SKW_ROOM_EVENT_STREAM
  - Room.RoomEventEnum.STEAM

これらのイベントが発火すると実際にメディアデータが送受信される

通信状況をモニターする

iOS/Android SDK
- 機能としては用意されてないが、Webアプリと相互接続する場合、ブラウザ側で確認可能
JS SDK
- ChromeまたはFirefoxのWebRTC開発者向けツールでモニタリング
- 詳しくは次のページで

Chrome WebRTC Internalsの使い方

情報量が多いのでChromeがオススメ
WebRTCで通話中に別のタブで開発者向けツールにアクセス
- chrome://webrtc-internals/

WebRTC Internals　その1

WebRTC通信を行っているブラウザのタブ毎にタブが作られるので、該当部分を選択
- TimeとEventはWebRTCの接続シーケンスがログとして出ている
- リアルタイムで更新される

ICE Connection Stateをチェック

ICEとはInteractive Connectivity Establishmentの略で、WebRTCによる通信経路定めるためのプロトコル

ICEのステータス遷移

ステータス	内容
connnected	通信可能な接続を発見したでもまだ他の経路情報も探索中
completed	すべての経路を探査し終わり通信に利用する経路が確定した

completed以外のステータスで止まっている場合は通信経路に問題がある
ICE Stateの詳細は WebRTC 1.0: Real-time Communication Between Browsers を確認

WebRTC Internals　その2

メディアの通信が行われている場合は、必ず一つだけ太字になっている部分がある
- 無ければ接続がうまく行っていない

チェックする箇所は以下の通り

項目	意味
bytesReceived	受信バイト数カウンタがリアルタイムに更新される
bytesSent	送信バイト数カウンタがリアルタイムに更新される
googLocalAddress	自分自身の通信に利用しているIPアドレスとポート番号 TURNサーバを利用している場合はTURNサーバのアドレスとなる
googLocalCandidateType	通信経路の種類を識別 `relay`はTURNサーバ利用
googRemoteAddress	相手の通信に利用しているIPアドレスとポート番号 TURNサーバを利用している場合はTURNサーバのアドレスとなる
googRemoteCandidateType	通信経路の種類を識別 `relay`はTURNサーバ利用

WebRTC Internals　その3

通信するメディアのAnalyticsが表示される
- 大まかな帯域等を把握することが出来る
- 受信側、送信側でそれぞれ確認できる

SkyWayを利用する際の通信帯域

通信帯域はあくまで目安です

用途	帯域
1:1音声通話	40kbps
1:1ビデオ通話（SD）	500kbps
1:1ビデオ通話（HD）	1.5Mbps
4人ビデオ会議（SD）	1.5Mbps

出展: SkyWay利用モデル

　実際どうなの？

計測条件
- Chrome M66
- コーデック：VP8
- フレームレート：指定なし
- MacBookPro 13inch 2016モデル
- Logicool BRIO
計測方法
- カメラの前に座って会議をやっている前提（動き少なめ）
- 同一PC内でP2Pビデオチャットを実施しwebrtc-internalsで確認

条件	帯域
320x240(QVGA)	450kbps前後
640x480(VGA)	1.6Mbps前後
720x480(SD)	1.6Mbps前後
1024x768(XGA)	1.6Mbps前後
1280x720(HD)	1.6Mbps前後
1920x1080(フルHD)	1.6Mbps前後
3840x2160(4K UHDTV)	2Mbps前後

4Kについてはマシンの性能の問題も有り安定していない可能性がある
解像度参考: モニタ解像度図解チャート＆一覧

帯域を考える上でのポイント
- アプリの作りである程度コントロール可能
- 利用シーンによって変動幅が異なる
  - Web会議用は比較的変動が少ない
  - スマホやスマートグラス等動きがある場合はかなり変動幅が大きい

SkyWayの動作確認済みブラウザとOS

ChromeとFirefoxに正式対応
- 安定版の最新2バージョンに対応
  - 例： 2018.04.19現在最新の安定版は Version66　なので、動作確認済みブラウザは66と65
- ブラウザは約6週間でアップデートされるため、JS SDKのアップデートへの追従はお早めに
Edge（一部機能のみ対応）
- P2PとRoom（Meshモード）のみ利用可能
- Room（SFUモード）への対応予定：無し
  - EdgeがMultiStream機能に対応していないから
Safari（一部機能のみ対応）
- P2PとRoom（Meshモード）のみ利用可能
- Room（SFUモード）への対応予定：有り
  - 現在のSFUはビデオコーデックがVP8固定のため利用不可
  - 今後コーデックの切り替え機能をリリース予定

iOS
- iOS 8+
Android
- Android 4.2+ (API Level 17+)
EPSON MOVERIO BT-300/350
- Android SDKで動作

SkyWayを配信に利用する場合のティップス

配信に利用できる機能

受信のみモード

自身のMediaStreamをオプションに渡さずに、Roomへjoinすることで受信のみモードになる

// 例
const room = peer.joinRoom("roomName", {
  mode: 'mesh'
});

この時、MediaStreamをオプションに渡して参加したメンバがいる場合、そのメンバから受信のみモードメンバへ片方向通信が実現できる

videoReceiveEnabled/audiReceiveEnabled

映像と音声を単独で受信のみにすることが出来る

// 例：音声だけ受信したいしたい
const room = peer.joinRoom("roomName", {
  mode: 'mesh',
  audioReceiveEnabled: true
});

映像と音声を単独で受信のみにすることが出来る

// 例：音声は送受信、映像は受信だけしたい
const room = peer.joinRoom("roomName", {
  mode: 'mesh',
  stream: audioOnlyStream,
  videoReceiveEnabled: true
});

おことわり…

Room機能のSFUモードで受信のみモードを利用する場合はワークアラウンドが必要（2018.04.19現在）
参考: SkyWayサポートコミュニティ:受信のみモードを併用した多人数でのSFUの利用
SFUの不具合が解消されたため、このワークアラウンドは不要となりました(2019.04.09追記)

replaceStreamで、受信のみモードから通常モード（MediaStreamを送信するモード）への切り替えは動作保障対象外（2018.04.19現在）
- 送信していたMediaStreamを単純に差し替える用途では問題なく利用可能

それぞれの機能の利用可否まとめ

機能	JS SDK	iOS SDK	Android SDK
受信のみモード
videoReceiveEnabled/audiReceiveEnabled

機能	meshモード	sfuモード
受信のみモード		^※1
videoReceiveEnabled/audiReceiveEnabled

※1:~~ワークアラウンドが必要~~(不要になりました)

配信等のユースケースで活用する場合、SFUモードが必要になることが多いと思います。以後、受信のみモード☓SFUモード、replaceStream☓SFUモードの組み合わせで利用する際のワークアラウンドにフォーカスします。

受信のみモード☓SFUモードのワークアラウンド

2019.04.09 追記
SFUの不具合が解消されたため、このワークアラウンドは不要となりました。

受信のみモードをSFUモードで利用する場合、送信される映像が受信のみモードのユーザ上で再生されない問題がある。この問題は、SkyWayのSFUサーバから映像の再生に必要なキーフレーム^{※参考情報（外部サイト）}が、受信のみモードのユーザに届かないため発生している。

次に示す方法で回避可能。また、送信されるのが音声のみの場合は問題なく利用できる。

SkyWayサポートコミュニティ:受信のみモードを併用した多人数でのSFUの利用で開発者の方が記載していただいている、ダミーのjoinRoomを実行する方法が一番良い。

const skyway = new Peer({key:'APIKEY'});
const room = skyway.joinRoom('roomName',{mode: 'sfu'});
room.on('open',async (peerId) => {
    try {
        await dummyRoomJoin();
    } catch (err){
        console.error(err);
    }
});

function dummyRoomJoin(){
    return new Promise((resolve, reject) => {
        const dummyPeer = new Peer({key:'APIKEY'});
        dummyPeer.on('open',() => {
            const dummyRoom = dummyPeer.joinRoom('roomName',{mode: 'sfu'});
            dummyRoom.on('open',() => {
                dummyRoom.close();
            });
            dummyRoom.on('close',() => {
                dummyPeer.destroy();
                resolve();
            });
            dummyRoom.on('error',(err) => {
                reject(err);
            });
        });
    });
};

この他に、canvasで作成した1px X 1pxのダミーストリームを送信する方法もあるが、受信のみモードのユーザからSFUへのUpstreamのメディアコネクションが生成されるため、Roomに参加するユーザ全体の負荷が高くなる。おすすめしない。

replaceStream☓SFUモード

SFUモードでreplaceStreamを利用し、受信のみモードから通常モードへの切り替えを行うのは動作対象外。つまり、以下のようなユースケースについては、現状正常に動作しない。

全員が受信のみモードでRoom参加
あるユーザがreplaceStreamを利用して映像・音声の送信者になる
他の参加者は受信のみモードで視聴する

この場合、3のタイミングで、他の参加者に対してstreamイベントが発火しない
JS SDKに関しては、誰かが一人でも通常モードで参加していれば、受信のみモードから通常モードへの切替時は可能

まとめ

SkyWaySDKの通信モデル
SkyWayの通信要件
SkyWayを利用したWebRTC通信のコネクティビティ（メディアコネクションの場合）を確認する
SkyWayを利用する際の通信帯域
SkyWayの動作確認済みブラウザとOS
SkyWayを配信に利用する場合のティップス

SkyWay初心者からステップアップしよう

はじめに

自己紹介

この資料は何？

達成したいゴール

今日お話する内容

本題に入る前に…お知らせ

ダッシュボードで利用量の閲覧ができるようになりました

Enterprise EditonへのAPIキー移行ができるようになりました

SkyWaySDKの通信モデル

Peer

PeerID

通信モデルその１「電話モデル」

音声・映像（メディアチャンネル）

データの場合（データチャンネル）

通信モデルその２「ルームモデル」

メディアストリームの扱い

SkyWayの通信要件

その１（管理系）

その２（WebRTC関連）

TURN通信は3パターン

TURNサーバは極力使わないようにネットワーク設計する

絶対TURNサーバが必要な場合

SkyWayを利用したWebRTC通信のコネクティビティ（メディアコネクションの場合）を確認する

予備知識〜SkyWay SDKのオブジェクト構造〜

全SDK共通

iOS/Android SDKのみ

シグナリングサーバとの接続が確立できたことを把握

（参考）new Peerを実行すると内部的には何が行われるのか？

メディア通信が開始されたことを把握

通信状況をモニターする

Chrome WebRTC Internalsの使い方

WebRTC Internals その1

WebRTC Internals その2

WebRTC Internals その3

SkyWayを利用する際の通信帯域

通信帯域はあくまで目安です

実際どうなの？

SkyWayの動作確認済みブラウザとOS

SkyWayを配信に利用する場合のティップス

配信に利用できる機能

受信のみモード

videoReceiveEnabled/audiReceiveEnabled

おことわり…

それぞれの機能の利用可否まとめ

受信のみモード☓SFUモードのワークアラウンド

replaceStream☓SFUモード

まとめ

WebRTC Internals　その1

WebRTC Internals　その2

WebRTC Internals　その3

　実際どうなの？