自己紹介

AIテクノロジー推進室仙台に所属しております櫻井と申します。

2013年に入社、学生時代にアプリ開発を行っていた経験を買われ、エンジニアとしての第一歩はAndroidアプリ開発からスタートしました。それからJavaを用いた業務システム開発や、親会社のクルマ・ポータルサイト「グーネット」でのAPIプラットフォームの新規開発業務など様々な分野の案件を経て、現在は当社が展開しておりますSaaS「受付クラウドシステムラクネコ」のプロジェクトで開発セクションリーダーを担当しています。

ラクネコでは先日インターホン機能という、来訪者が受付端末を介して担当者と通話できる機能をリリースしました。

こちらのインターホン機能はWebRTCという技術を用いて実装しておりまして、来訪者が受付操作を行った際に担当者のモバイルアプリケーションに電話発信を行い通話を行うことができます。

本記事ではWebRTC技術についての説明と、どのような構成によって通話機能を実現させたかをご紹介したいと思います。

WebRTCとは？

Web Real-Time Communicationの略で、ウェブブラウザやモバイルアプリケーションが音声や動画などのデータをリアルタイムに通信するための技術です。

端的に説明すると上記のようになりますが、正確には映像の圧縮技術や画面共有で使われるスクリーンキャプチャ技術なども含まれており、さまざまな技術の集合体とも言えます。

従来にもオンライン会議アプリケーションは存在しておりましたが、それらは専用のプラグインやクライアントアプリケーションのインストールが必要で、また開発コストも高いものでした。

しかし現在にいたってはモダンウェブブラウザがWebRTCを標準でサポートしており、誰でも簡単にリアルタイムなコミュニケーションに参加することが可能になりました。

コロナ禍で世界中の人々にオンラインでコミュニケーションを行う文化が普及した今、WebRTCは無くてはならない技術になりつつあると思います。

WebRTCの仕組み

次にWebRTCがどのような仕組みでリアルタイム通信を実現しているかを説明します。

まず大事なキーワードとしてP2P（Peer to Peer）を理解する必要があります。P2Pはネットワーク上で端末同士がサーバを介さずにデータをやりとりする通信方式で、中央サーバを用意するクライアントサーバ方式と比較するとサービス提供者が低コストで運用でき、耐障害性も高いなどのメリットがあります。

WebRTCは基本的にP2Pで映像や音声といったデータをリアルタイムで送受信するようになっています。ただ、P2P通信を確立させるにはお互いに通信相手の情報が必要なわけで、事前にいくつかのサーバ通信が発生します。

まずはWebサーバ・シグナリングサーバに接続し、SDPと呼ばれる通信確立に必要な自身のIPアドレス・ポートなどが含まれた情報をシグナリングサーバ経由で相手に送信します。相手は受け取ったSDPを登録します。この処理をお互いに行います。

ここで通信経路上にNATの存在することによる問題があり、その対処が必要です。

NATはネットワークアドレスを変換する役割を持ち、プライベートIPアドレスをポートに割り当てることにより、ひとつのグローバルIPアドレスで複数端末の通信を可能にします。この変換処理の存在によって、SDPに含まれたIPアドレスでは相手と通信できない状態となってしまうため、それを対処するためSTUNサーバを利用します。

STUNサーバは外部ネットワークから見た時のIPアドレス情報を返してくれます。そのIPアドレスと自身のIPアドレスを比べることで、NAT越えの処理が必要かを判断します。

NAT越えでの接続が必要な場合、外部ネットワークから見た時のIPアドレス・ポートでの通信をしたいことをシグナリングサーバ経由で相手に通知し、その情報を受け取ってもらいます。これによりP2Pが確立します。

ただ、このSTUNでの対処は確実なものではなく、NATやファイアウォールの設定によっては通信を遮断されてしまうことがあります。その時の最後の手段として、TURNという仕組みが用意されています。P2Pによる通信は不可能と諦め、TURNサーバを中継させることにより、データを受け渡せるようにします。

通話アプリケーションを構成するまで

ここまででWebRTCの仕組みを簡単に解説しましたが、シグナリングサーバなどを自前で用意するとなると流石に面倒です。現在はそれらを提供してくれるWebRTCプラットフォームを利用することで、リアルタイム通信アプリケーションを少ない開発量で構築することができます。

有名どころのサービスとしてTwilioやSkywayの他、多くのサービスが提供されています。それぞれクライアントライブラリや料金（無料のものもある）、導入実績などに違いがありますので、利用する際は比較検討をするのがおすすめです。ラクネコでは国内にサーバがあり、低コストで運用できるSkywayを採用してアプリケーション開発を行いました。

設計について

さて、WebRTCを使って通話アプリケーションを作るとなった場合、オンライン会議アプリケーションとは違う点について考慮が必要となります。一般的なオンライン会議アプリケーションでは、時間や会議URLを示し合わせて、各々が自ら通話に参加する形かと思います。しかし通話アプリケーションの場合は、一方が通話発信を行った後に相手に通話のリクエストが来ている事、つまり着信通知の仕組みが必要となります。

iOSでの開発を例にあげますが、着信通知を実現させるためにはPushKit、そしてVoIP Pushを使うことができます。VoIP Pushは標準のPush通知とは異なり、受信時にアプリが動作していなくてもバックグラウンド処理を確実に行え、また遅延が少なく安定性が高いといわれています。まさに通話リクエストのようなリアルタイム処理のためにある仕組みです。またPushKitはVoIP Pushを受け取るためのフレームワークとして用意されています。

次にVoIP Pushの配信に使うサービスですが、もしAWSでシステムを構築しているならAmazon SNSの採用が良いと思います。他のAWSサービスとの連携ができ便利です。

使用する技術・サービスの紹介は以上で、ここからはラクネコで実装した通話を成り立たせるための処理フローをご紹介します。

まずは事前準備として、VoIP Pushを受け取られるようにするために端末の登録が必要となります。デバイストークンと呼ばれる情報が取得できますので、それを自前のAPIを経由させてAmazon SNSに登録します。するとPush通知をパブリッシュ（配信）する際に必要なtarget ARNが返されますので、ユーザに紐づける形でデータベースに保存しておきます。これを通話の発信側、受信側の端末それぞれで行います。

次がいよいよ通話を確立させるまでのフローです。始めにSkywayにPeer作成のリクエストを行います。PeerはSkywayにおける概念のひとつで、Skywayのシグナリングサーバや他の端末との接続を管理するエージェントです。1:1通話においては発信側、着信側の2つのエージェントが存在することになります。

Peer IDを受け取った後は発信したい相手の情報をパラメータに、自前の通話発信APIをリクエストします。すると、DBに保存されているtarget ARNをもとにVoIP Pushが配信されます。VoIP Pushには通話発信側のPeer IDを含めており、着信側は通知受信後にそのPeer IDとの接続をSkywayに要求します。これでP2P通信が確立され、インターネット回線を使った通話が行われます。

今回ラクネコでの構成を紹介させていただきましたが、こちらは実装の一例ですので実現したいシステムイメージにあわせて設計を検討されることが望ましいかと思います。