ども、@kimihom です。
Twilio の最新を追いかけ続けてる身として、今年の Twilio Programmable Voice で注目したリリースについて紹介してみる。基本的に、最新の情報は Twilio Changelog で参照できる。本記事で紹介しているのは一部だけであるため、より詳細が気になる場合はぜひ Twilio 本家のページを参照してほしい。
Voice Insights API
Voice Insights API は最近も更新されている API だ。通話一つ一つに、誰と誰の通話で、通話がどんな状態なのか。通話は Twilio Client や SIP, 外線(キャリア)など、どんなタイプか。その通話のネットワーク通信状況はどうだったのか。これらの情報を API で取得できる。
とりわけその通話で問題が起きた時の原因として Tag をみることで API から原因を見つけられる。
- silence: 話のない時間の検知。オーディオ周りの問題の可能性
- high_jitter: 高いジッタ が現地された。
- high_packet_loss: >5% パケット損失
- high_pdd: ダイヤルの遅れ
- high_latency: Twilio 内部の RTP 時間の遅れ
- low_mos: MOS(Mean Opinion Scor) が低い
- ice_failure: ICE 接続の失敗
その通話の何が原因で通話がうまくいかなかったのかを Twilio が返してくれる。Twilio Client を利用している場合、ほとんどは インターネット接続の遅さが原因だ。基本的に 10MBps が上下共にないと、乱れが発生してしまう。もし2人が同時に通話していた場合は、20MBps は欲しいという形となる。 とりわけ会社内で同じネットワークを30名以上で使っている場合、たまに(or しょっちゅう) 音質が乱れるという状態となってしまう。ネットワークを改善してもらうようお願いするしかないのが難しいところだが、そうするしか改善の方法はない。
Twilio Client を利用して不満足となる理由のダントツが、この音質問題となる。
SubAccounts ダッシュボード
上記は電話一つ一つのログを取得できるものだった。ただ実際は、一つ一つの通話を見るよりアカウントごとの全体の通話傾向を見たいというケースの方が多いかと思う。そんな時に便利なサブアカウント ダッシュボードが登場した。Subaccount Dashboard | Twilio である。
ほとんどの場合、通話のグループごとに、Twilio の サブアカウントを使って開発していることだろう。そのサブアカウントごとで、どのサブアカウントが一番問題が起きているのかをパッと確認することができる。"このサブアカウントはネットワーク原因で通話品質に問題が起きている" ことがわかれば、こちらからネットワーク状況の改善を依頼することができる。
Twilio 発信コール TwiML
今まで、Twilio API で発信したあと、どこに繋げるかという実装には、
- Twilio API で発信リクエストを送る
- 繋がったら、Twilio からリクエストが飛んでくる
- そのリクエストに対して TwiML を返す
という流れが必要があった。それがようやく、Twilio にリクエストを送る時に一緒に、繋がった時の TwiML を指定できるようになった。
call = @client.calls.create( twiml: '<Response><Say>Ahoy, World!</Say></Response>', to: '+14155551212', from: '+15017122661' )
calls.create の引数に twiml を指定できるようになった。余計なサーバーリクエストが1つなくなったという意味で、個人的に大きな改善だった。
ちなみに Twilio Ruby の場合、Twiml を Ruby コードで書ける。
Twilio::TwiML::VoiceResponse.new do |r| r.say message: "こんにちは。", language: "ja-jp" end.to_s
Media Stream の GA
去年(2019年) の SIGNAL で一番注目された 新機能である Media Stream が GA となった。
通話しているリアルタイムの音声を取ってこれるため、Google Speech-to-Text でリアルタイムに文字に起こしたり、Amazon Lex でリアルタイムに会話をする Bot を作ったりできるようになった。ただ、このリアルタイム処理のサーバーは自分たちで用意する必要がある。個人的には、そのサーバーでどれだけ処理できるのか不安があるので、Media Stream での実装は様子見している。そもそも、リアルタイムで通話した内容を文字化するのではなく、通話が終わった後に音声を分析して一括で文字化をして 振り返られる。
今後の Media Stream の有効活用について、引き続き研究していきたいし、話し合ってみたいところではある。
Conference での新設定
ログイン後の https://jp.twilio.com/console/voice/conferences/settings にて、カンファレンスの設定項目として "Background Noise Passthrough" が登場した。カンファレンス通話の場合、会話してない人の音声はシャットアウトされるが、例えば2~3人で通話している場合、そのシャットアウトが発生すると相手がいないように発話者は思えてしまう。そこでこのモードを ON にすれば、雑音も聞こえるので相手がいると判断したまま話者は会話を続けられる。
割と大規模なコールセンターだと、この機能は ON にして、Conference でモニタリング、ウィスパリングをできるようにするといいんじゃないだろうか。
Voice Diagnostics SDK のリリース
実際に通話をする時には、ネットワークやデバイス、利用ブラウザなど様々な条件が整わないと通話がうまくできない。そこで 12/3 に Voice Diagnostics SDK が正式リリースとなったようだ。
これが存在しない以前までは、自分で通話が正しくできる環境かをチェックできるツールを用意する必要があった。私自身、そのテストツールを自分で実装していた。 もちろんこのツールを導入しただけでは全部英語なのでカスタマイズなど色々必要だろうが、全て自分で実装する必要もなくなる。私自身、このコードの詳細まで確認できていないので、時間がある時に見てみるかもしれない。
Single Party Call Recordings
最近、興味深いリリースが発表されている。通話の録音で、話者だけの録音が可能になった Single Party Call Recordings だ。
セキュリティの厳しい会社では、相手の言ったことが勝手に録音されることに問題があるケースがある。例えばお客さんが秘密情報を電話内で発言してしまうと、それが録音として残り続けてしまったりするためである。
そこで 運営側の発言だけを録音できれば、それはオペレーターの教育として役立つ。何を言ったのかを自動でテキスト化し、問題のある発言があった時に管理者へ通知を送るようなことも可能だろう。オペレーターごとの口癖をまとめたり、スピードなどを計算することで、良いオペレーターの特徴を把握することができる。 より良いコールセンターにするための機能として、注目していきたい。
終わりに
Twilio 自体とても大きなシステムになってきたけど、引き続きアップデートが繰り返されている。とりわけ Twilio Flex には引き続き力を入れている形に見える。Twilio Flex 側で必要になってくる Twilio Voice の機能が新しく追加され、Developer にも公開されているようだ。
より大規模なコールセンターでも便利に使えるような Twilio Programmable Voice の進化にこれからも注目していきたい。
