複数の架電リクエスト発生時のPigeonの挙動について
回答済み
お世話になっております。
Pigeon仕様情報によりますと
「同時架電可能件数（最大）」は20件
「架電リクエスト上限」は30件
ライトプラスの「同時架電数」は５
スタンダードの「同時架電数」は１ とあります。
■もし同じコールフロー宛ての架電リクエストが例えば10件発生した場合のPigeonの
挙動を教えてください。
例：コールフローA：
連絡先１:080-1xxx-xxxx
連絡先２:080-2xxx-xxxx
連絡先３:080-3xxx-xxxx
1回目のリクエストで架電先の電話が鳴るまで10秒、さらに呼び出し（最大）30秒なので、2回目のアラートによる架電がされるときは、
連絡先１は話し中だと思います。
その時Pigeon は連絡先２に先に架電しますか？
それとも待ちますか？
同様のことが10件立て続けに発生したとして、Pigeonの架電は
1-2-3-1-2-3-1-2-3-1 の待ち行列ができるのでしょうか？
またこの行列はタイムアウトしてしまう場合（条件）はあるのでしょうか？
などなどを
ライトプラスの場合とスタンダードの場合で、ご教示ください。
よろしくお願いします。
-
正式なコメント
ご質問ありがとうございます。回答させていただきます。
例：コールフローA：
連絡先１:080-1xxx-xxxx
連絡先２:080-2xxx-xxxx
連絡先３:080-3xxx-xxxxいただいた上記の例にならって、上記のコールフローを用いた連絡を10回連続でリクエストしたケースを考えてみることにいたしましょう。このとき、1回目に行われたリクエストにより連絡先1に対して行われる電話発信を「1-1」、連絡先2に対して行われる電話発信を「1-2」・・・と順番に置き、「1-1」から「10-3」までがどのような流れで発信されるかを解説いたします。
スタンダードプラン（同時架電数1）の場合
10回のリクエストのうち、1回目のリクエスト分は即座に処理が開始し、2回目以降のリクエストは待ち状態に入ります。そのため連絡の流れとしては
1-1 → 1-2 → 1-3 → 2-1 → 2-2 → ・・・ → 9-3 → 10-1 → 10-2 → 10-3
と、順番に1つずつ発信が行われます。
ライトプラスプラン（同時架電数5）の場合
10回のリクエストのうち、5回目までのリクエスト分は即座に処理が開始し、6回目以降のリクエストは待ち状態に入ります。そのため連絡の流れとしては、例えば
- 1-1・2-1・3-1・4-1・5-1が同時に発信される
- いずれか1つは電話が繋がり、残り4件は失敗する（以降、仮に1-1が繋がったとする）
- 2-2・3-2・4-2・5-2が発信される
- いずれか1つは電話が繋がり、残り3件は失敗する（以降、仮に2-2が繋がったとする）
- 3-3・4-3・5-3が発信される
- いずれか1つは電話が繋がり、残り2件は失敗する（以降、仮に3-3が繋がったとする）
- 4回目・5回目のリクエスト全体が失敗と判断され、6回目・7回目の処理が開始する
といった流れとなることが考えられます。（実際にはリクエスト毎の処理は並列で行われるため、失敗判断や連絡開始のタイミングが揃わないことで微妙に異なる流れになる可能性があります）
その他の点に関するご回答
Pigeon仕様情報によりますと
「同時架電可能件数（最大）」は20件
「架電リクエスト上限」は30件
ライトプラスの「同時架電数」は５
スタンダードの「同時架電数」は１ とあります。こちらの情報について補足しておきますと、Pigeonの「同時架電数」は先にご説明した通り、「同時処理可能な連絡の件数」を指しております。
また、追加料金をいただくことでこの「同時架電数」を増やしていただくことが可能ですが、その理論上の最大値が「同時架電可能件数（最大）」となります。
「架電リクエスト上限」は例えば先の例では10件のリクエストを行いましたが、これが30件を超える場合には31件目以降のリクエスト受付に失敗します。より正確な説明としては「実行中の連絡と実行待ちの連絡の合計」が30件を超えることができず、これを「架電リクエスト上限」と呼んでおります。この数字は「同時架電数」の大小にかかわらず、スペース毎に30件と決めております。
またこの行列はタイムアウトしてしまう場合（条件）はあるのでしょうか？
連絡の開始待ち自体がタイムアウトしてしまうことは原則ございません。
なお、1回の通話が10分を超える場合、Pigeonはその通話の終了待ちを止め、次の電話発信を開始します。そのため、処理開始した連絡に関しては「コールフローに設定した連絡先の件数 × コールフローに設定したループ回数 × 10分」が実質的なタイムアウト時間となります。
コメントアクション -
お世話になっております。丁寧なご説明、ありがとうございました。
弊社内でこの挙動について話し合ってみて、いくつか質問がありましたので追加でご回答をお願いします。
＞＞7．4回目・5回目のリクエスト全体が失敗と判断され、6回目・7回目の処理が開始する
この説明に関して、4回目・5回目のリクエスト全体が失敗と判断されるのは、
「失敗（ボタン返答による明確な終了ではなく、ループ回数超過により終了した）」
ルールによるものだと理解して間違いないでしょうか？
平たく言ってしまうと、3人の受電担当者が１０件のリクエストに対して、
それぞれのループ回数を超過するまでに、ボタン返答による終了をできればアラートにはならず、
できない場合に「結果ID＝失敗」となる。
そして5回線への第1リクエストは全部080-1xxx-xxxx にかけてしまいますが、話し中と判断すれば 080-2xxx へ架電開始する。
この想像が正しい場合、話し中と判断するまで何秒程度要するものでしょうか？また、
＞＞1回の通話が10分を超える場合、Pigeonはその通話の終了待ちを止め、次の電話発信を開始します。
とありますが、この「10分」はガイダンスメッセージの読み上げ繰り返し時間でしょうか？
-
4回目・5回目のリクエスト全体が失敗と判断されるのは、
「失敗（ボタン返答による明確な終了ではなく、ループ回数超過により終了した）」
ルールによるものだと理解して間違いないでしょうか？この理解で相違ございません。
平たく言ってしまうと、3人の受電担当者が１０件のリクエストに対して、
それぞれのループ回数を超過するまでに、ボタン返答による終了をできればアラートにはならず、
できない場合に「結果ID＝失敗」となる。
そして5回線への第1リクエストは全部080-1xxx-xxxx にかけてしまいますが、話し中と判断すれば 080-2xxx へ架電開始する。
この想像が正しい場合、話し中と判断するまで何秒程度要するものでしょうか？架電先が話し中であることは即座に判断がつきますが、Pigeonでは架電のリクエストを行ってからその結果を10秒に1回のペースで確認しており、基本的にどのようなケースでも架電〜結果記録には10秒以上の時間を要します。
そのため、基本的には10秒程度で話し中と判断され、次の架電が行われることになります。
この「10分」はガイダンスメッセージの読み上げ繰り返し時間でしょうか？
「10分」は読み上げの繰り返し時間とは別の制限となります。
Pigeonのガイダンスは1回読み上げが行われた後5秒間の入力待ちを挟み、再度の読み上げ・入力待ちを経てもなお入力がない場合、入力エラーを知らせる旨のメッセージが流れた上で自動的に電話が切れます。つまり「ガイダンスの読み上げ2回にかかる時間」「入力エラーメッセージの読み上げ時間」「入力待ちの時間（計10秒）」が最大のガイダンス読み上げ時間となります。
これは大概の場合10分を下回りますが、Pigeonのガイダンスでは最大800文字までの読み上げを可能としており、特にAPIリクエスト時に受け取った情報（ガイダンスのテンプレートへ展開される情報）が非常に長いケースなど、読み上げ時間が非常に長くなるケースが考えられます。
読み上げが続いている間は次の架電が出来ないため、このようなケースで想定を大きく超えた待ち時間が発生しないよう、「10分」というタイムアウトを同時に設けております。
-
別々の質問となって申し訳ありません。
更にご質問いたしますが、長くなってしまいましたので、勝手ながら付番いたします。
社内用ですので気になさらないでください。質問【20210708_2】
＞＞「実行中の連絡と実行待ちの連絡の合計」が30件を超えることができず、これを「架電リクエスト上限」と呼んでおります。この数字は「同時架電数」の大小にかかわらず、スペース毎に30件と決めております。
この「架電リクエスト上限」に達してしまった場合、Kompira cloud ではどのような事象が生じますか？
【目視】
・スペース内に何らかの警告が表示されるか
・エラーメッセージは出るか
【システムとしての保守】
・この事象に影響を受けたリクエストを見分けられるか
・リクエストを一時的に止めるなど何らかの対処法はあるか
など、ご教示ください。 -
お世話になっております。早速のご返答ありがとうございました。
まず
質問【20210708_1】（勝手に付番いたしました）
"架電結果の確認間隔" についてですが、
＞＞1分に1回と記載いただいたことから、話し中だった場合になるべく架電し続けたいという意図かと推察いたしました。
仰る通りです。複数の架電リクエストが1コールフローに集中してしまう場合を懸念いたしました。
＞＞同一の連絡先に連続して複数回架電するコールフローとするなどの対処が考えられます
こちらは連絡先登録時に
例：
１．Aさん
２．Aさん
３．Aさん
４～６．Bさん
といった具合に登録するという意味ですね。
おおよそですが、1コール（１．Aさんへのコール） は４コール後切電し、次の架電リクエスト実施といった具合であってますでしょうか？質問【20210708_2】について
＞＞・HTTPステータスはリクエスト成功時と同様に「201」
・status の値が rejected となる
・架電リクエスト上限に達したことでリクエストが拒否された旨のメッセージが含まれる
こちらは APIコマンド POST/api/apps/pigeon/chain/invoke [連絡処理の実行]
の実行結果が"201""status" が "requested" の場合は、正常にスケジュールされたことを意味する。"status" が "rejected" の場合は、スケジュールが拒否されたことを意味する。
についての記載ということで間違いないでしょうか？
このレスポンスはどこに表記されますか？
・連絡履歴の理由欄ですか？そこから更にリンクしたループ詳細画面のステータス行の動作のところですか？また、少々蛇足になりますが、連絡履歴の理由欄のとなりの入力キーには何が入りますか？
＞＞・リクエストを一時的に止めるなど何らかの対処法はあるか
については、履歴で確認できるため、システム的な対応はないという理解で合ってますでしょうか？
-
お世話になっております。
上記ご回答いただいた内容についてもう少し確認をさせてください。
質問【20210708_3】
「話し中」「通話中」に対するPigeo挙動について【整理】
架電リクエストからみて
・回線が第3者と「話し中」の場合、基本的には10秒程度で話し中と判断され、次の架電が行われる。架電リクエストからみて
・相手がPigeonと「通話中」の場合、ガイダンスタイムアウトロジックによって10分を超えたPigeon制御はその「通話」の終了待ちを終了し切電。次の架電リクエストを発信する
色々とご教示いただいたのでこんがらがってしまいましたので、主語と「話し中」「通話中」の補足を加えて整理してみました。
この理解であってますでしょうか？ -
質問【20210708_1】について
お伝えしたコールフローについては以下のイメージの通りとなります。
> 例：
> １．Aさん
> ２．Aさん
> ３．Aさん
> ４～６．Bさん上記のコールフローの場合、仮にAさんがずっと話し中のままであった場合は、
1. でAさんにコールして話し中、10秒後に結果確認し次のコールへ
2. でAさんにコールして話し中、10秒後に結果確認し次のコールへ
、、、と繰り返し都合30秒程度はAさんにコールされる、ということとなります。
質問【20210708_2】について> こちらは APIコマンド POST/api/apps/pigeon/chain/invoke [連絡処理の実行]
> の実行結果が"201"
> "status" が "requested" の場合は、正常にスケジュールされたことを意味する。"status" が "rejected" の場合は、スケジュールが拒否されたことを意味する。
>
> についての記載ということで間違いないでしょうか？
間違いありません。> このレスポンスはどこに表記されますか？
レスポンスの内容は Pigeon の画面上には表出しないものとなります。
連絡履歴は、架電リクエストに成功したものがどういった架電結果になっているか、という情報ですので、
架電リクエストが拒否された場合は、連絡履歴に含まれず、表示する画面は設けておりません。ただし、こちらは Pigeon 単体の場合の話であり、
AlertHub のアクションにおいて Pigeon での架電を行った場合については、
その架電リクエストの結果としてレスポンスを AlertHub のアクション履歴から確認することができます。仮に Pigeon の 連絡処理の実行API への架電リクエストを他の機構で行った場合は、
レスポンスはその機構で受け取ることになりますので、
そちらで確認することとなります。> 連絡履歴の理由欄のとなりの入力キーには何が入りますか？
連絡履歴の「入力キー」には押下されたプッシュボタンが表示されます。> リクエストを一時的に止めるなど何らかの対処法はあるか
Pigeon への架電リクエストを行う手段次第となります。
AlertHub については返却されたレスポンスの内容から次の挙動を変化させることはできませんが、
Enterprise や他の独自実装した機構からのリクエストであれば、
対処法はあるものと考えられます。
質問【20210708_3】についてご認識の通りとなります。
-
質問【20210708_3】について
気になるところがあったので、少し質問させてもらってもいいですか？
＞架電リクエストからみて
＞・相手がPigeonと「通話中」の場合、ガイダンスタイムアウトロジックによって10分を超えたPigeon制＞御はその「通話」の終了待ちを終了し切電。次の架電リクエストを発信する上記の部分なのですが、この状況の中に通話中のPigeonと架電中のPigeonの2つのPigeonが登場
しています。
この場合、通話中のPigeonは入力がない場合はタイムアウトが10分で発生し、その後次の架電を開始する。架電中のPigeonは相手が話し中だったので10秒後に次の架電を開始する。
架電中のPigeonは対象の電話がPigeonと通話しているかどうかまでは判断はできないため、架電の対象が通話中であれば10秒後に次の架電。
で間違いないでしょうか？
-
上記の部分なのですが、この状況の中に通話中のPigeonと架電中のPigeonの2つのPigeonが登場しています。
あらためての確認となりますが、
- Pigeonに対して連絡リクエストを行い、だれかが通話に応答する
- 通話が続いている最中に次の連絡リクエストが行われる
という状況との理解で相違ないでしょうか？
このとき、最初にリクエストされた連絡を「連絡1」、連絡1での通話中に新たにリクエストされた連絡を「連絡2」とおき、それぞれがどういった動きをするかご説明します
「連絡1」の動き
連絡1にて行われている通話に対して応答がない場合、本質問における2回目の回答にて触れております通り、「1回読み上げが行われた後5秒間の入力待ちを挟み、再度の読み上げ・入力待ちを経てもなお入力がない」場合には自動的に電話が切れ、（10分のタイムアウトを待たずに）次の連絡先への架電が行われます。
また設定されたガイダンスが極端に長い場合など、自動的に電話が切れるよりも前に10分が経過したケースに関しては通話の終了を待たずに次の連絡先への架電が行われます。
「連絡2」の動き
これはプランによって動きが異なります
スタンダード（同時架電数1）の場合はすでに連絡1により同時架電数の枠が埋まっており、後からリクエストされた連絡2は連絡1の終了を待ってから実行されることになります。
ライトプラス（同時架電数5）の場合は連絡2が即座に開始しします。このときすでに連絡1にて通話中の連絡先に対して架電が行われた場合、普通は約10秒後に「話し中」と判断され、次の連絡先への架電が行われます。
ここで「普通は」といたしましたのは、法人の電話番号など、1つの電話番号で複数の通話を受けられるケースがあり、この場合は「話し中」にならずに新たな通話が発生いたします。
こういったケースを考慮して、Pigeonでは発信先の電話番号に対してPigeonによる通話が発生しているかどうかにかかわらず、必ず発信を試行するようにしております。
サインインしてコメントを残してください。
コメント
14件のコメント