はじめに

当調査にはアウトバウンドウィスパーで実際に挙動を確認した証跡並びに、調査結果を記載しています。

調査内容

実際に発信されるタイミング、エージェントと通話が確立するタイミングや挙動時の各ブロックの処理時間の目安を調査

前提条件

ルーティングに設定されたアウトバウンドキューにアウトバウンドウィスパーの設定をしていること
下図の簡易的なフローを実施した計測時間で調査
実際に発信をし、CloudWatchLogsに記録されるログをベースとする
用語が変わったり表記統一のため下記としています
- アウトバウンドウィスパー : 発信ウィスパー
- 発信先 : 顧客でありAmazon Connectからの電話を着信する番号
- 発信元 : エージェントでありAmazon ConnecのCCP

調査結果

結論から記載すると、実際に発信され発信先と通電するタイミング、発信元との通話が確立するタイミングでは差がある

作成したアウトバウンドウィスパーの開始～終了までの時間

13:56:27.432 - 13:56:42.163

14.731 秒

調査ログ

※一部マスキングするためXXXXとしています。

設置した各ブロックのログは下記の通りとなります。

ログ記録動作の設定
 音声の設定
 電話番号を呼び出す
 プロンプトの再生
 メディアストリーミングの開始
 終了フロー/再開

ログ記録動作の設定

2024-04-03T13:56:27.432+09:00

{
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "SetLoggingBehavior",
    "Identifier": "8661b594-c6ea-4187-b1c4-9a9558ec07d3",
    "Timestamp": "2024-04-03T04:56:27.432Z",
    "Parameters": {
        "LoggingBehavior": "Enable"
    }
}

"ContactFlowModuleType": "SetLoggingBehavior" となっているので「ログ記録動作の設定」ブロックとなる

音声の設定

2024-04-03T13:56:27.443+09:00

{
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "SetVoice",
    "Identifier": "88a46365-67b5-4463-9555-f22e29d788ed",
    "Timestamp": "2024-04-03T04:56:27.443Z",
    "Parameters": {
        "SpeakingStyle": "None",
        "GlobalEngine": "Neural",
        "GlobalVoice": "Kazuha"
    }
}

"ContactFlowModuleType": "SetVoice" となっているので「音声の設定」ブロックとなる

直前のログの時間との差を計算する

13:56:27.443 - 13:56:27.432

0.011 秒

電話番号を呼び出す

2024-04-03T13:56:27.444+09:00

{
    "Results": "Success",
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "Dial",
    "Identifier": "835689fd-32d8-426c-81a3-efcf3583d925",
    "Timestamp": "2024-04-03T04:56:27.444Z",
    "Parameters": {
        "CallerId": "+815000000000"
    }
}

"ContactFlowModuleType": "Dial"となっているので「電話番号を呼び出す」ブロックとなる
"CallerId": "+815000000000" の部分が発信先へ通知する際の電話番号です
※実際の電話番号のため0表記としています。

直前のログの時間との差を計算する

13:56:27.444 - 13:56:27.443

0.001 秒

2024-04-03T13:56:36.512+09:00

{
    "Results": "Success",
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "Dial",
    "Identifier": "835689fd-32d8-426c-81a3-efcf3583d925",
    "Timestamp": "2024-04-03T04:56:36.512Z"
}

なぜか、ここで"ContactFlowModuleType": "Dial"のログとして2つ出力され、両方とも"Results": "Success"となっています。

重要

どうやらここの挙動として以下のようです

1つめのログで発信している
2つめのログで発信先が応答している

直前のログの時間との差を計算する

13:56:36.512 - 13:56:27.444

9.068 秒

発信先が通話を受け入れるまでにかかっている時間もあるため時間がかかっている

実際にAmazon Connectから発信し、発信先で通話を開始することなく電話を切ると2つめのログは出力されません
※なるほどな。と後述の音声プロンプトのところで明確になります。

プロンプトの再生

2024-04-03T13:56:36.526+09:00

{
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "PlayPrompt",
    "Identifier": "42f84b7d-cbc9-4d2b-a907-e5a8ffdcf189",
    "Timestamp": "2024-04-03T04:56:36.526Z",
    "Parameters": {
        "TextToSpeechType": "text",
        "Text": "電話番号を呼び出す後に設置されたプロンプトの再生ブロック",
        "Voice": "Kazuha"
    }
}

"ContactFlowModuleType": "PlayPrompt"となっているので「プロンプトの再生」ブロックとなる

直前のログの時間との差を計算する

13:56:36.526 - 13:56:36.512

0.014 秒

このブロックの経過時間から、ログの出力はブロック実行時に出力されていると推測

メディアストリーミングの開始

2024-04-03T13:56:41.447+09:00

{
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "Startmediatreaming",
    "Identifier": "7a3cde8c-2e32-498b-9880-9e8ada71e4a2",
    "Timestamp": "2024-04-03T04:56:41.447Z",
    "Parameters": {
        "mediatreamTypes": "Audio",
        "Track": [
            "ToCustomer",
            "FromCustomer"
        ]
    }
}

"ContactFlowModuleType": "Startmediatreaming"となっているので「メディアストリーミングの開始」ブロックとなる

直前のログの時間との差を計算する

13:56:41.447 - 13:56:36.526

4.921 秒

音声プロンプトで「電話番号を呼び出す後に設置されたプロンプトの再生ブロック」というアナウンスを流しているので4～5秒は納得

この音声は「発信先」に流れます。

「発信先」に流れるということは、このブロックへそもそも進むのは通話が確立した後ということですね。

2024-04-03T13:56:42.150+09:00

{
    "Results": "Success",
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "Startmediatreaming",
    "Identifier": "7a3cde8c-2e32-498b-9880-9e8ada71e4a2",
    "Timestamp": "2024-04-03T04:56:42.150Z"
}

なぜか、ここで"ContactFlowModuleType": "Startmediatreaming"のログとして2つ出力され、両方とも"Results": "Success"となっています。

どうやら、「メディアストリーミングの開始のブロック」も「電話番号を呼び出す」ブロックと似たような挙動の模様

直前のログの時間との差を計算する

13:56:42.150 - 13:56:41.447

0.703 秒

重要

メディアストリーミングの開始ブロックを利用するとこの部分だけで約1秒近くかかってしまう。

音声プロンプトでは「発信先」に音声が流れるのでこのタイミングで「発信先」に対して「無音」が発生します。

また、「メディアストリーミングの開始ブロック」は「電話番号を呼び出す」よりも前に設置することはできません。
※そりゃ、音声通話が発生しないとメディアストリーミングとして開始する必要ないからそうよね。。。

終了フロー/再開

2024-04-03T13:56:42.163+09:00

{
    "ContactId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "ContactFlowId": "arn:aws:connect:ap-northeast-1:XXXXXX:instance/XXXXXX/contact-flow/XXXXXX",
    "ContactFlowName": "XXXXXX",
    "ContactFlowModuleType": "Resume",
    "Identifier": "acea6e73-94fc-4e96-86f3-3268c20cd6c3",
    "Timestamp": "2024-04-03T04:56:42.163Z",
    "Parameters": {}
}

"ContactFlowModuleType": "Resume"となっているので「終了フロー/再開」ブロックとなる

直前のログの時間との差を計算する

13:56:42.163 - 13:56:42.150

0.013 秒

このブロックが完了すると「エージェント」側との通話が開始されます。

まとめ

アウトバウンドウィスパーフローを利用するときには「電話番号を呼び出す」ブロックよりも後ろに何かしらの処理をしたいときには、上記調査の通り場合によっては無音が発生するタイミング、時間が存在するため気をつけましょう

可能な限り「電話番号を呼び出す」ブロックよりも後ろには処理を置かないのが良さそう

通話が開始されたら何かの処理を実行したいときなどは、CCP側で実装するのが好ましいかも。。

今回の調査では発信先が体感する通話開始として発信先が応答し、プロンプトの再生が開始された時刻から最後のブロックまでの時間として

13:56:42.163 - 13:56:36.526

5.637秒

上記時間がかかっていることになります。
プロンプトの再生があるので実際の体感としては無応答というわけではないのですが、調査結果の通り「電話番号を呼び出す」ブロックの後では、発信元・先での体感が違うため、この差が生まれるような時には注意が必要となります。