CML を使用したアウトバウンド コールの作成
CMLによるアウトバウンドコールを開始するには、コールの詳細と通話中にNTT CPaaSが使用するURLを/markuplanguage/1/createエンドポイントにリクエストを送信します。
要求本文には、次のフィールドが含まれます。
callback.url: 通話に応答したときにマークアップ言語の指示の最初のセットを提供する Webhook の URL。callback.errorUrl:urlに到達できない場合に呼び出される URL。それに応じてフェールオーバー アクションが想定されます。callback.method: Webhook と通信するための HTTP メソッド (GETまたはPOST)。notifyUrl: NTT CPaaS が通話の概要を含む通話後通知を送信する Webhook の URL。
リクエストを送信した後、次の操作を行います。
- NTT CPaaSは、定義したエンドポイントを呼び出します。
- 宛先エンドポイントがコールに応答すると、NTT CPaaS はコールバック
urlにアウトバウンドコールのコンテキストを通知し、一連の CML アクションを期待します。
コールバックurlに到達できない場合、または不正な形式のCMLアクションが返された場合、NTT CPaaSプラットフォームはエラー通知をerrorUrlに送信し、エラーUrlは新しいCMLアクションセットで応答できます。
同期機械検出
通話マークアップ言語を使用して発信通話を開始する場合、同期モードでマシン検出(ボイスメール検出)を有効にすることができます。このモードでは、通話に応答した後、NTT CPaaS プラットフォームが最初にマシン検出を実行し、コールバック url に 検出完了後 のアクションを照会します。メッセージの終了検出を有効にすると、コールバック URL はメッセージの終了検出が完了した後にのみ呼び出されます。たとえば、マシン検出を 3 秒間、メッセージの終了検出を 30 秒間持続するように設定した場合、コールバック URL が最初のリクエストを受信するまでに、コールに応答してから最大 33 秒かかることがあります。
同期マシン検出は、次のシナリオに最適です。
- コンプライアンス主導のフロー: 債権回収、法的、または規制上の通知で、ボイスメールに特定のメッセージを再生するか、ボイスメールを完全に回避する必要があります。ボイスメールのグリーティングが終了した直後にメッセージを開始する必要がある場合は、メッセージ終了検出の同期モードがそのタイミングを直接提供します。
- 分岐フロー: 機械への応答が人間への応答とは異なるフローを必要とする場合。たとえば、マシンが応答した場合は、ボイスメールメッセージをドロップして電話を切ります。人間が応答した場合は、完全な IVR （自動音声応答）を起動します。
- 少量で遅延耐性のあるコール: 最初のプロンプトの前の遅延がエンゲージメントに影響を与えない企業間コールバック。
- 機密性の高いワンタイム コード: OTP（ワンタイムパスワード） または認証コールバックで、コードをボイスメールに読み上げてはなりません。マシンが応答した場合は、再生をスキップして、別のチャネルで再試行します。同期モードでは、オーディオが再生される前にこの決定が行われます。
非同期マシン検出
通話マークアップ言語を使用して発信通話を開始する場合、非同期モードでマシン検出(ボイスメール検出)を有効にすることができます。このモードでは、コールに応答した後、NTT CPaaS プラットフォームはコールバックのurlにコールの詳細を直接照会し、Webhook が CML アクションで応答することを期待します。並行してプラットフォームはマシン検出を開始し、その結果を定義された asyncUrl に送信します。asyncUrl は 200 OK ステータスコードで応答するだけでよく、CML アクションは返されません。メッセージの終わりの検出が有効になっている場合、プラットフォームはメッセージの終わりの結果も asyncUrl に送信します。
非同期マシン検出は、次のシナリオに最適です。
- アウトバウンド ダイヤラーとコンタクト センターのシナリオ: すぐに接続して、発信先に無音が聞こえて電話を切らないようにします。後でマシン検出結果を使用して、エージェントに通知するか、結果をログに記録します。
- 大量の自動キャンペーン: 予約のリマインダー、配信通知、または情報ブロードキャストで、検出結果に基づいて開始メッセージが変更されません。メッセージは関係なく再生し、非同期結果を使用して次のステップ (再試行、ログ記録、またはエスカレーション) を推進します。
- レイテンシーの影響を受けやすいフロー: メッセージの終了検出によって、フローが許容できる時間よりも長い間、最初の Webhook 応答がブロックされるケース。