こんにちは。テクニカルサポート2課 の めぐろ です。
前回の申込編では、NTTコミュニケーションズのフリーダイヤルに Amazon Connect の 050番号を着信番号として追加出来たところまで確認しました。
今回は実際に発着信させて挙動を確認してみたいと思います。
はじめに
本記事は主に以下の挙動について確認した結果を記載しています。
- フリーダイヤルからの着信
- 話中時迂回の挙動確認
- 発信時による特定番号通知確認
なお、本記事に登場する番号は以下の通りです。
- 0120xxx353 : NTTコミュニケーションズで直接契約したフリーダイヤル番号
- 05033xxxx21 : Amazon Connect (東京リージョン) で払い出された 050番号
- 以下 3番号は、本記事に直接影響を与える番号ではありません。
- 0xxxxxxx64 : フリーダイヤルの接続先番号として登録した固定電話(0ABJ)番号
- 0120xxx912 : 着信確認に使った Amazon Connect (東京リージョン) 払い出しの 0120番号
- 07084xxxx55 : 着信確認に使った携帯電話番号
フリーダイヤルからの着信
カスタマコントロールからフリーダイヤルの着信先を Amazon Connect の 050番号になるように設定します。
設定後、携帯電話からフリーダイヤルに発信し、無事着信することが確認出来ました。
フリーダイヤルと Amazon Connect の記録を見てみましょう。
着信電話番号となっている Amazon Connect の 050番号で完了呼数 1 が計上されました。
フリーダイヤル から Amazon Connect への着信は問題無さそうです。
話中時迂回の挙動確認
話中時迂回とは
着信先の回線が塞がり新たな着信を受けることが出来ない場合、指定した着信先へ転送 する機能です。
着信先（着信先電話番号またはACDグループ）の回線がすべてお話し中の場合、あらかじめ指定したほかの着信先へ接続します。
この機能が使えると、フリーダイヤル上で以下のようなフローが実現出来そうです。
- オンプレミス PBX の収容回線が埋まった場合、次の着信先に設定した Amazon Connect で受ける
- Amazon Connect で受けられない (Available なエージェントがいない / クォータ値に達している) 場合、別の着信先に迂回させる
1 の場合、Amazon Connect は受け手側なので懸念はありませんが、2 の場合、Amazon Connect の挙動によっては機能しない可能性があります。
実際、NTTコミュニケーションズへの追加番号申込時、Amazon Connect では話中時迂回が機能しない可能性がある旨の案内がありました。
NTTコミュニケーションズのフリーダイヤルのページには以下の記載があります。
※LS話中：フリーダイヤル交換機上の設定回線数としては空きであるため、着信先への接続処理を行ったが、着信交換機側で空き回線がなく、話中になる場合
詳細な説明をしだすと終わらないため簡単にまとめますと、着信側から特定の信号が返され LS話中と判断される必要がある ということになります。
上記を踏まえて確認をしていきましょう。
LS話中になるのか
LS話中にならないと話中時迂回が発動しないため、話中時迂回が無しの Amazon Connect だけに着信する状態で試して LS話中 と判断されるか確認してみます。
- 050番号に対し、インスタンスあたりのアクティブな同時呼び出しの数 (Concurrent active calls per instance) を超え、次の着信が話中になる状況にする
- 0120番号にかけ、Amazon Connect への着信が話中になることを確認する
- フリーダイヤルのトラヒックレポートでどのように判断されたか確認する
12:27 - 12:30 の間で次の着信が話中になることを確認し、0120番号に 2度かけてみたところいずれも話中となりました。
12:20台のレポートで 着LS話中 と判定されました。
話中時迂回の確認
LS話中になることを確認出来たため、話中時迂回を設定し、迂回されるかを確認します。
Amazon Connect (050番号) の迂回先として、固定電話番号(0ABJ番号) を設定しました。
12:37 - 12:39 の間で次の着信が話中になることを確認し、0120番号にかけてみたところ、固定電話番号(0ABJ番号) への着信を確認しました。
トラヒックレポートでも、12:30台のレポートで固定電話番号に対し呼が計上されていました。
(不完了呼なのは、鳴動のみ確認し受話せず放棄呼としたため。)
話中時迂回が発動する条件
あくまで話中信号が返されないと発動しないため、Amazon Connect 側のフロー作成は注意が必要です。
発信者と Amazon Connect 間で音声パスが通ってしまうと、その呼は話中呼では無く接続呼となってしまいます。
迂回が機能する例
- インスタンスあたりのアクティブな同時呼び出しの数 を超えた場合
- 音声パスの接続無しに「切断」とした場合
- 「人員の確認」ブロックでエージェントがいない場合に「切断」繋げた場合
- 「AWS Lambda 関数を呼び出す」ブロックで処理した後に「切断」繋げた場合
発信時による特定番号通知確認
特定番号通知機能は、発信先の相手にフリーダイヤル番号を通知することが出来る機能 です。
フリーダイヤルへ 050番号を紐付ける際に申し込みをしていましたので、早速確認してみます。
Amazon Connect より 050番号を アウトバウンド発信者 ID 番号 としたキューから、同一インスタンスの番号に対して発信し、別端末の CCP で受信をして確認をしました。
上が発信呼、下が着信呼のコンタクト詳細画面です。
システムの電話番号 +815033xxxx21 (050-33xx-xx21) から発信 をしていますが、着信時の 顧客の電話番号 は +81120xxx353 (0120-xxx353) となり着信 をしています。
0120-xxx353 は Amazon Connect の払い出し番号では無く、NTTコミュニケーションズ 直接契約の番号であり、特定番号通知が正常に機能していることが確認出来ました。
工事タイミングについて
フリーダイヤルの工事と特定番号通知の工事は別で行われます。
特定番号通知の工事は、月 2 回しか行われないようですので、実際に検討される際にはご注意ください。
注意事項
Amazon Connect 側から特定の信号 (LS話中) が返される点について、AWS ドキュメント上での公開情報ありません。
そのため、検討の際は以下について予めご認識いただくようお願いいたします。
- 特定の信号 (LS話中) が変更になる可能性
- NTTコミュニケーションズ以外のトールフリー番号サービスでは仕様が異なる可能性
- 東京リージョン以外では同様の挙動にならない可能性
まとめ
今回は以下について確認が出来ました。
- NTTコミュニケーションズと契約したフリーダイヤルの接続先に Amazon Connect の 050番号を設定し、着信させることが出来ることが確認出来ました。
- Amazon Connect 側から特定の信号 (LS話中) が返されることにより、フリーダイヤル上で迂回設定が利用できることが確認出来ました。
- フリーダイヤルの接続先に設定した Amazon Connect の 050番号で、発信時にフリーダイヤル番号が通知できることが確認出来ました。
キャリアサービスと Amazon Connect のハイブリッド構成を上手く利用することにより、他社との協業や DR対策に活用できるかもしれません。
このブログが皆様のお役に立てば幸いです。
