はじめに：導入事例のご紹介

2023年5月18日、株式会社コムテック様のドライブレコーダーと通信可能な次世代 IoT スマホアプリ「Comtec IoT」開発の導入事例が公開されております。

本事例ではお客様から下記3機能に関してご要望があり、それらを踏まえた開発をKDDI様と連携して進めました。
①ドライブレコーダーのイベント録画を自動的にクラウドに保存し、スマートフォンへ通知を飛ばしたり、スマートフォンアプリにて確認できる機能
②離れた場所からでも位置情報や車両の状況を確認できる機能
③スマートフォンアプリとドライブレコーダーで通話ができる機能

本記事では、「③スマートフォンアプリとドライブレコーダーで通話ができる機能」に関して、解説いたします。

音声通話を支える技術「WebRTC」について解説

事例記事にも記載がありますが、ドライブレコーダー・スマートフォンアプリ間での通話を実現するにあたっては、「Amazon Kinesis Video Streams」（通称:KVS）を使用しております。本記事ではその中の一機能であるAmazon Kinesis Video Streams WebRTCを使用した音声通話の仕組みについて解説します。

根底にある仕組み〜WebRTC〜

KVSを使用した音声通話の仕組みの説明の前に、
前提として、使用されているWebRTCという技術について触れたいと思います。
「Amazon Kinesis Video Streams WebRTC」を使用した音声通話については、名前にもあるとおり、WebRTCと呼ばれる技術が使用されています。

MDNによるWebRTCの定義は下記です。

WebRTC (Web Real-Time Communication、ウェブリアルタイムコミュニケーション) は、ウェブアプリケーションやウェブサイトにて、仲介を必要とせずにブラウザー間で直接、任意のデータの交換や、キャプチャした音声／映像ストリームの送受信を可能にする技術です

以下では、WebRTCを理解する上で重要な概念をご紹介していきます。

Peer（ピア）

WebRTCの通信を行う当事者のことで、ブラウザやアプリケーションのことを指します。
今回の事例においては、ドライブレコーダーと、スマホアプリがそれぞれPeerとなります。

シグナリングサーバー

Peer同士の通信の仲介役となるサーバーのことです。
WebRTCにおいては、Peer同士が直接通信を行いますが、通信を行うためにはまずお互いの存在を知り、通信に際して必要な情報を交換する必要があります。
その際、シグナリングサーバーが仲介役となって、情報交換の支援を行います。

NAT Traversal（NATトラバーサル）

NATで発生する通信上の制約を解消するための技術です。
NAT（NetWork Address Translation）は、プライベートネットワークのIPアドレスを、インターネットに接続する際に、外部から見えないようにパブリックIPに変換する技術です。NATを使うと、プライベートネットワーク内のデバイスは外部のサーバーと通信できますが、デバイス同士が直接通信することは困難です。（相手のプライベートIPアドレスやポート番号が分からないため）

この問題を解消するためにNAT Traversalが使われます。
NAT Traversalには、STUN（Session Traversal Utilities for NAT）, TURN（Traversal Using Relays around NAT）, ICE（Interactive Connectivity Establishment）など様々な方法があります。

STUNサーバー

NAT Traversalをサポートするために使用するサーバーのことです。STUNサーバーはNAT外部に配置されており、以下のように機能します。

①Peerが自分のパブリックIPアドレスとポート番号を知るためにSTUNサーバーにリクエストを送る
②STUNサーバーがリクエストを受信し、そのPeerのパブリックIPアドレスとポート番号を確認し、レスポンスとして返却する
③Peerは受け取った情報をもとに、NATのタイプを確認し、Peer同士が直接通信を確立できるかどうかを判断する
TURNサーバー

STUNサーバーを介した通信がうまくいかない場合に、その通信を中継してくれるサーバーのことです。
例えば、シンメトリックNATと呼ばれるタイプのNATの場合は、STUNサーバーだけでは、NAT Traversalが実現できないようです。
(詳細はここでは省略します。)

SDP（Session Description Protocol）

事前にPeer同士で情報をやり取りする際の取り決めのことです。
シグナリングサーバーの説明の部分でPeer間の通信では事前に「通信に際して必要な情報を交換する必要がある」と説明しましたが、その「必要な情報」のことがSession Descriptionと呼ばれています。
そこでは通信に関する条件が交換されます。
SDP Offerと、SDP Answerと呼ばれるものがあり、Peerの片方がSDP Offerを送り、もう片方がSDP Answerを返す仕組みになっています。両者共通して通信できる条件があればPeer間の通信経路が確保されます。
この、Peer間で確保できた通信経路のことは、ICE Candidateと呼ばれます。

ICE

STUNサーバ、TURNサーバーを使い分けながらPeer同士の接続を確立するための仕組みのことです。
STUNサーバー、TURNサーバーをまとめてICEサーバーと呼ぶこともあるようです。

以上がWebRTCを実現する上で重要な概念となります。

Amazon Kinesis Video Streams について解説

AWS公式によれば、Amazon Kinesis Video Streamsは、
分析、機械学習 (ML)、再生、およびその他の処理のために、接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングできるようにするサービスです。

Amazon Kinesis Video Streamsにおいては、StreamsとWebRTCという二つの形式でストリーミングを実現できるのですが、本記事ではWebRTCの方に焦点を当てます。
Amazon Kinesis Video Streams WebRTCとは、Amazon Kinesis Video Streams の一機能で、WebRTCの実現にあたって必要なシグナリングサーバー、STUNサーバー、TURNサーバーといったサーバーのリソースがマネージドで提供されているため、ブラウザ、モバイルデバイス、IoTデバイス間でのリアルタイムのビデオ配信やオーディオのストリーミングを容易に実装することができるような仕組みになっています。

以下では、Kinesis Video Streams WebRTCの理解において重要な概念を整理しておきます。

シグナリングチャネル

Peer同士が接続するための場所のようなものです。
Management Consoleから簡単に作成することができます。

Master

データを送信する側のことです。1シグナリングチャネルにつき設定できるMasterは1つのみです。

Viewer

Masterから送信されたデータ（映像/音声など）を受信して表示する側のことです。
一つのMasterに対して10のViewerを紐づけることができます。
つまり、一つのデバイスから送信されるデータを最大10のデバイスから閲覧できる、ということです。

Kinesis Video Streams WebRTCを使った双方向通信を図にしてみる

Kinesis Video Streams WebRTCを使った双方向通信を図にしてみます。
①Master, Viewer間で、「この条件だったら通信できる」条件をシグナリングサーバーを介して交換した上で、
②STUNサーバーを介して自分の通信対象のデバイスのIPアドレスやポート番号を取得し、相手と通信できるかを判断する
③その後、問題なく通信ができると判断された場合に、Master, Viewer間で交換されたICE Candidate（通信経路の候補）から順に接続を試行し、成功すれば双方向通信が確立したことになる
がポイントです。
※厳密にはもっと複雑なやりとりがされているのですが、単純化のために省略している箇所があることはご了承ください。

Kinesis Video Streams WebRTCを使用した音声通話のテスト

ではここから実際に、音声通話のテストを行ってみます。
AWS側で用意されている、テストページ（KVS WebRTC Test Page）があるため、今回はそれを使用します。初期画面は以下のようになっています。

裏側では、KVS WebRTC SDKが使用されています。サンプルコードはこちらで公開されています。
C言語, Javascript, iOS, Androidの向けのSDKが用意されており、これにより組み込み機器、Webアプリ、スマホアプリなど多様なデバイスでの接続がSDKを使って簡単に実現できます。
今回のテストにあたってはJavascript版のSDKを使用しました。

ローカル開発用にサンプルアプリを編集することもできるようなので、試してみます。
手順としては、事前にテスト用のディレクトリを作成したうえで、その後はターミナルで下記コマンドを叩くだけです。

# 手順
$ git clone https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-js.git
↓
$ cd amazon-kinesis-video-streams-webrtc-sdk-js/
↓
$ npm install
↓
$ npm run develop

そうすると、localhost:3001でテストページを閲覧することができます。

※ローカル起動の手順についてはこちらにも記載があるのでご覧ください。

音声通話にあたり入力が最低限必要なのは下記の情報です。

  • KVSのエンドポイントのリージョン
  • シグナリングチャンネルの名前（Kinesis Video Streamsのコンソールから作成/テストページからも作成可能）
  • Access Key ID/Secret Access Key

Tracksの部分では、送信するメディアの種類を選択します。音声通話の場合はSend Audioにチェックを入れる必要があります。
必要な情報を記載したのち、片方の端末でStart Masterを押下します。別の端末から、同じように情報を入力し、Start Viewerを押下します。
今回は一つの端末でMaster/Viewerのテストをしているため、別タブでページを開き、Viewerとしてアクセスするという形で実施しました。

その後は、Master, Viewerそれぞれの情報を閲覧することができます。
画像からは伝わりづらいですが、下記のようにMaster側、Viewer側で、Connection to peer successful!
というログの表示がされているので、Master, Viewer相互で音声通話が成功しているようです。

最後に

最後までご覧いただきましてありがとうございました。
今回は、音声通話を支える技術である、Amazon Kinesis Video Streams WebRTCをご紹介させていただきました。
WebRTCの概念の理解はある程度必要ですが、比較的簡単に音声通話（やビデオ通話など）を実現できるサービスになっています。
本記事が理解の一助となれば幸いです。

参照サイト