こんにちは、@24guchiaです。

以前の記事で、日本国内でTaskRouterを使う場合、
Conferenceを使いましょうとの結論を付け、
実際に運用をはじめたので、TaskRouterとConferenceを組み合わせる方法について書きます。

この記事を読むとTaskRouterを使わない場合でも、Conferenceを使って、
通話のモニタリング機能を拡張できるようにしておくか、
それとも通常のDialで済ませるかの判断基準になると思います。

日本国内でTaskRouterを使う場合、Conferenceを使う理由って？

端的に言うと、TaskRouterで割り振った受電の通話音声が
必ず遅れやすい環境での通話を強いられます。
詳細は過去記事を参照してください。
https://harinoma.info/caution-taskrouter-in-japan/

TaskRouterのみの影響ということは受電だけ直せばよいか？

これはケースバイケースですが、基本的には架電もConferenceに置き換えたほうが良いです。
理由はConferenceとDialが混合するため、コードが読みづらくなり、
拡張性や保守性が下がります。
また、保留を提供している場合、受電と架電で処理を分ける必要があります。
日本国内でTaskRouterを使う場合、
Conferenceでの受電架電の機能提供はセットで必須になると思います。

TaskRouterは使いたいけど、Conferenceは使いたくない場合は？

下記選択肢から選んでください。

受電は通話が遅れるものとして受け入れる
一旦受けて、必ず即時折り返す
TaskRouterの日本サーバができるのを待つ

3以外はあんまり現実的な選択肢はないですね。ただ、3はいつになるか不明です。今日時点（2018年5月27日）では、諦めてConferenceを使いましょう。

そもそもConferenceとは

250人まで同時通話できる機能です。Dialは1対1の通話に対し、250人まで同時に話せます。グループ通話機能を作ったりするのが一般的なユースケースです。

AgentConferenceとは

Conferenceの拡張機能です。Conferenceとの決定的な違いは、
coachプロパティにより、話した音声を特定の相手に届けられる点です。

この機能は何に使うかというと、新人営業と顧客の通話を先輩営業が聞きながら、話し相手には聞かれずに、先輩が新人に口頭で直接指示を出すといった場合に使います。
リアルタイムで指示が出せ、さらにソフトフォンを使えるため、
場所を問わず、コーチングが出来ます。
声が荒ぶっても、話し相手には音声が聞こえないので、
近くの新人をコーチングする場合でも、この機能を使うと安全です。

一般的なビジネスフォンでもウィスパリングやら、
モニタリングやらといった名称で提供されていることもあります。

Conferenceのハマりどころ

概念が違う

先にも書いた通り、Dialは1対1の通話に対し、Conferenceは1人以上250人までの通話という点が違います。
二人以上ではなく、1人以上のため、
普通の通話では考えなくても良いことを考える必要があります。

誰かが通話を終了した時、Conferenceを終了させるかどうか考える必要がある

Conferenceは1人以上でも、通話が可能です。
そのため、二人で話していて、相手が電話を切っても、
残された方は自動で電話が切れません。

例えば、endConferenceOnExitというプロパティがあり、
このプロパティをtrueにすることで、
このプロパティがtrueの人が通話を終了したら、
自動でConferenceを終わらせる機能があります。

じゃあ、これを一律でtrueにすればよいかというと、基本的にはダメです。
その理由は保留があるからです。
保留する場合、その人はConference上の通話を終了するため、
このプロパティがtrueだとConferenceが終了してしまいます。

一律ではなく、顧客の通話のみ、このプロパティをtrueにします。
また、このプロパティがfalseの側が通話を終了した場合、
API経由で必ずConferenceを終了させましょう。
終了させないと、通話相手は自動で電話が切れないので、
気付かずずっと通話状態になっているとクレームにつながります。

Twilio ClientでConferenceSidが取れない

ConferenceSidは通話を終了させたり、
参加者に対して更新処理をかけるのに必要な情報です。

先に挙げたように、必ずAPI経由でConferenceを終了させる必要がありますが、ClientにはなぜかConferenceSidを受け渡されません。
じゃあ、CallSidから参照しようという手も無理です。
CallSidからConferenceに関する情報は取れません。

解決方法としては、架電と受電で異なる方法を用いました。

架電の場合

ConferenceにStatusCallbackイベントが設定できるので、
イベント時にSyncでClientに通知しました。

かなりトリッキーな方法で一刻も早く別の方法で直したいのですが、
現時点ではこういう方法以外は見つけられませんでした。

受電の場合

TaskRouterを使う場合、TaskSidがConferenceのFriendlyNameに設定されるため、
Taskを受領する際、FriendlyNameで検索することで
ConferenceSidが取得できます。
TaskSidはTwilioが付与する一意なIDなので、1件のみ取れます。

一個余計なAPIを投げる必要があり、余計なコストだと考えています。
まあ、架電に比べたらかなりマシです。

この解決方法の問題点

Syncにしても、API経由にしても、時差があります。
Webページなら気にならない誤差ですが、電話ではけっこう致命的な時差です。

一番の問題として、ConferenceSid取得前に電話を切ろうとすると
Conferenceを終了させるAPIに失敗します。
そのため、この方法で解決する場合、ConferenceSidが取得できているか、
できていない場合、再度時間を置いてAPIを呼び出すよう待つ必要があります。

架電時、架電先がビジー応答返却すると、Conferenceが重複した

なんだそれ、という感じですが架電時の処理を下記の通りに組むと重複します。

Twilioの番号と架電先の番号の通話をConferenceに参加させるAPIを実行する
1で作られたConferenceにdialするTwimlを返却する

これは普通に待受状態の電話機に通話する場合は問題ありません。
問題が発生するのは、ビジー応答を返却する電話機の場合のみです。
ちなみにビジー応答は、通話中かつ留守電設定がない電話機の場合、
ビジー応答が返却されるようです（観測範囲内）。

なぜ重複するかというと、1でConferenceに入る前に、
ビジー応答が返却され、通話中の参加者がConferenceからいなくなり
1のAPIで作成されたConferenceが即時終了します。
そして、2ではすでに終了したConferenceに架電しようとしますが、
存在していないため、同名の別のConferenceが作成され、そこに1人で参加します。

これにはけっこうハマりました。
Conferenceは1人以上で成立するという仕様のため、
電話を切る必要があるが、上でも挙げている通り、
ConfereceSidがClientに渡されない。
さらに重複したConferenceにはStatusCalllbackのイベントを設定できず、ConfereceSidをSyncで渡すという実装をしていたので、
電話を切るために行った対策がすべて通用しませんでした。

これの対策は1と2の間で少し待ち、
1で生成されたConferenceが生きているか確認したり、
StatusCallbackで対策したりと方法があります。
私は1秒待ち、Conferenceのstatusを確認する方法で対応するつもりです。

StatusCallbackの数が普通の通話より増える

イベントの数が増えます。https://www.twilio.com/docs/voice/twiml/conference#attributes-statusCallbackEvent

サーバへのアクセスが増えるので、注意してください。
うちのサーバはちょいちょい限界を迎えてます。

ConferenceSidが渡されないために、必要以上にStatusCallback設定しています。

まとめ

ちょっとこれは理不尽では？

理不尽だと感じる理由は下記の通り。

TaskRouterはGAなのに、日本国内では通話に遅延が発生しやすいまま放置されている
1のアナウンスが私のブログにしか情報がない（観測範囲内）
ConferenceSidをClientに受け渡す方法がなく、かなりトリッキーな実装を強いられる

これからTaskRouterを受電で使う場合はよく考えて採用してください。TaskRouterと同様の仕組みは時間かかりますが、作れると思います。
受電はTaskRouterを使うとTwilioで完結し、良いと思うのですが、
いかんせん日本国内での使用には問題が多いです。

AgentConferenceも実装しづらいなぁという感じなので、
急いで導入する必要はあまりないかもしれません。
下記記事によると、通常のコールからシームレスにConferenceに変更できる機能が実装予定らしいので、モニタリング・ウィスパリングしたい場合でも、
それまで待ったほうが無難かと思います。
https://www.twilio.com/blog/2017/12/agent-conference-generally-available.html

モニタリングの下地ができたのはよしとよう

1ヶ月の実装とテスト2週間ほど（バグがめっちゃ出た）かけ、
とりあえずConferenceが導入できました。

モニタリング・ウィスパリングは元から要望が合ったのですが、
どうにもリリースに間に合わず、置いておいた要望です。
ウィスパリングのアドバイス機能はバグが発生すると、
即クレームに繋がるので、まずはモニタリングで聞くだけの機能を提供し、
その後、ウィスパリングを導入する予定です。
また、リアルタイムでの通話一覧機能を実装し、
どの通話を聞くか、アドバイスするかを選択できるようにする予定です。

これらの機能が実装でき次第、
記事を上げていく予定ですのでそれまで乞うご期待。