ボクココ

サービス開発を成功させるまでの歩み

2019年の Twilio Client の振り返り

ども、@kimihom です。

f:id:cevid_cpp:20190825134809p:plain

コールコネクト のメイン技術である Twilio Client は、今年も頻繁にアップデートが行われ、新しい機能が多く追加された。最新を追い続けている身として、今年の Twilio Client を振り返っていこう。

今年一年の印象

まず、今年一年で Twilio Client は バージョン 1.6.5 から、1.9.7 までアップデートされている。なかなかの高頻度な更新だ。個別の変更点は後でまとめるとして、全体的にはバグ修正による安定したバージョンがリリースされていっている印象である。

去年、一昨年あたりの Twilio Client では深刻なバグのアップデートがあったりした。アップデートしたらいつの間にか ~ が動かないということが頻繁に起こっていたため、バージョンをあげたら全ての通話のテストケースを念入りに試していく必要があった(今もだけど)。

最近は深刻なバグは見つからなくなって安定している。アップデートで新しい機能が追加されたとしても、大抵は Device.setup のパラメータで有効にするかしないかを指定する形となっている。これはこれで ファットな setup となっていってしまっているが、バグが頻発するよりはマシであろう。

new Twilio.Device(YOUR_TOKEN, {
  forceAggressiveIceNomination: true
});

では今年の大きめのアップデートを振り返っていこう。

通話保留の実装改善

Twilio エンジニアな方と話をしていると、通話の保留で私の書いた以下の記事などを参考にされた方が多いようだ。

Twilio で保留機能を実現 詳細 ver | selfree

今まで、Twilio で保留を実現するには、以下のような手順が必要だった。

  1. アップデート対象の Call を取得
  2. URL を指定して Call を Update
  3. Twilio が 指定した URL にリクエスト
  4. TwiML を返す (音楽を流す)

この手順は、対象のコールの取得が手間という点と、2回 Twilio とリクエストのやりとりをする必要のある無駄 があり、手間のかかる作業であった。この2つの課題を解決する、「カスタムパラメータの指定」と 「アップデート時の TwiML の指定」が今年から可能になった。

以下がイマドキの Twilio 保留の実装方法である。

1. 着信時の TwiML にカスタムパラメータで CallSID を指定

まず、 <Dial><Client> で対象のクライアント名を指定するのに追加して、カスタムパラメータを指定することができる。着信を受けたら、その着信 CallSid を指定しておく。

Twilio::TwiML::VoiceResponse.new do |r|
   dial.client do |clt|
    clt.identity name
    clt.parameter name: "call_sid", value: params[:CallSid]
  end
end

すると、通話時の connection で、カスタムパラメータの値を取ってこれる。

twilioDevice.on('incoming', function (conn) {
  connection.customParameters.get('call_sid');  // => CA1111111
});

この Call を サーバー側で Twilio API を通じてアップデートすれば良くなるだけとなる。先ほどの手順にあった "1. アップデート対象の Call を取得" の手順が不要になったわけだ!

2. Call を TwiML 指定でアップデート

Twilio の Call のアップデート時に、アクションURL ではなく、TwiML を直接指定できるようになった。このおかげで、先ほどの3 の手順が不要となった。

client = Twilio::REST::Client.new(twilio_api_key, twilio_api_secret, twilio_account_sid)
call = client.api.calls(call_sid).fetch
call.update(twiml: Twilio::TwiML::VoiceResponse.new do |r|
  r.enqueue name: "pause", action: action_url
end.to_s)

通話の保留はこれだけで実装できる。この1年で大きく変わって点として、まず最初に通話の保留方法について取り上げた。

OPUS コーデックの正式リリース

OPUS という WebRTC のコーデックがある。従来は PCMU というコーデックのみのサポートであったが、どちらか使いたいコーデックをセットアップ時に指定ができるようになった。複数指定も可能で、使えなかった場合は2つ目に指定したコーデックを使うといったことも可能だ。基本的には OPUS を第一指定で問題ないはずだ。

new Twilio.Device(YOUR_TOKEN, {
    codecPreferences: ['opus', 'pcmu']
});

OPUS をサポートしたことによって、ついに iOS Safari で Twilio Client Web が使えるようになった。引き続き Twilio としては iOS/Android ネイティブの SDK を使うことを推奨しているが、iOS Safari の Web上から Twilio Client で発信できるようになったという点はひとつ大きな進歩だと言えるだろう。ちなみに iOS Safari の Twilio Client で着信の実装はオススメしない。Safari が最小化されてしばらくすると、着信通知が発生しなくなる。

Twilio Call Insights の無料化

実際に Twilio Client を使った運用を始めると必ず課題となってくるのが「音質」だ。 Twilio 側では Insights として各通話のネットワークやデバイスの接続状況を細かくレポートしてくれる機能が存在する。今まで、これを使うには1通話あたり~円と有料であった。今年の SIGNAL の発表で、めでたいことに Insights の利用が無料となったのである。(感謝)

てことで「なんか音質が悪い」って報告が来た時には、Programmable Voice の Insights をチェックするようにしよう。大抵はネットワークアラートが出ているけども、何にも出てなかった場合には PC が重すぎるとかそういう要因もあるため、Insights で全ての原因がわかるとはいえないという点だけ注意してほしい。ちょっと古いけど Voice Insights の各項目の簡単な説明を以下の記事に記してある。

Twilio で新しく登場した Voice Insight | selfree

Unified Plan のサポート

WebRTC における Unified Plan のサポートが v1.7.1 からサポートされた。来年のQ1 までにはこのバージョン以上にしないと、動かなくなるリスクがあるため、1.7.1 以上のアップデートはマストな状態となっている。

ice の再起動

Twilio Client のセットアップ時に enableIceRestart を指定できるようになった。これは、ice の接続が切れた時に自動で再接続を試みてくれるようになった機能である。そのステータスを取ってくるために 再接続時にConnection.on('reconnecting', handler(error))、再接続完了時に Connection.on('reconnected', handler()) という新しいイベントが定義された。

切断されるケースはそこまで多くないけども、より確実に通話を続けるという点でより安定した Twilio Client になったと言えよう。

終わりに

今年の Twilio Client アップデートの中で主要なものを取り上げてみた。

公式からは以下よりアップデートを確認できる。

Twilio 全体としては、より安定して確実に安心して使えるようにっていう部分にフォーカスが当たった1年だったと言えよう。その点はどの Twilio ユーザーとしても望んでいる改善だと思うので、ありがたい限りである。

来年はどんな Twilio アップデートがあるのか。引き続き Twilio の最先端を追い続けてプロダクトに反映していく次第である。