コールルーティング

インバウンドコールの転送方法は、コールルーティング で管理できます。コールルーティングは、事前に定義されたルーティングと設定可能なフェイルオーバー戦略を活用して、高い信頼性と柔軟性を確保するとともに、発信者にとって最適な体験を提供できるようにします。

コールルーティングは、事前に定義されたルートに基づいて動作します。各ルートには最大10件の呼び出し先を含めることができ、コールが正常に接続されるまで、これらの呼び出し先への呼び出しが順番に試行されます。

コールルーティングでは、実行するルートを選択するための2つの方法がサポートされています：

静的ルーティング：固定ルートは、各インバウンド番号または発信元に割り当てられます。その番号で受信されたすべてのコールは、常に同じ事前定義された呼び出し先のシーケンスに従います。
動的ルーティング：ルートは、発信元の位置情報やその他のコール属性など、構成可能なフィルターに基づいて決定されます。コールを受信すると、システムはフィルターを評価し、定義されている基準に最も合致するルートを選択します。

コールルーティングは、以下を経由して入ってくるインバウンドトラフィックでトリガーできます：

ルート内の呼び出し先には、以下の種類があります：

エントリーの種類	定義
SIP	お使いのアカウントで既に作成している、定義済みのいずれかのSIPトランク
PHONE	NTT CPaaSのグローバルネットワークを介して到達できる固定電話番号または携帯電話番号
WEBRTC	WebRTCアプリケーションに紐づいているユーザーID
WEBSOCKET	WebSocketメディアストリーミング構成
WHATSAPP	WhatsApp Business Callingで呼び出す、WhatsAppを利用しているエンドユーザーのMSISDN (電話番号)
VIBER	Viber Business Callsで呼び出す、Viberを利用しているエンドユーザーのMSISDN (電話番号)
URL	バックエンドアプリケーションによって公開されている、動的なルーティングシナリオに対応するウェブフック

ルートの作成

ルートは、NTT CPaaSのWebインターフェイスからVoiceチャネルアプリケーションのコールルーティングを使用するか、コールルーティングAPI (opens in a new tab)を使って作成できます。

ルート定義には、次のものが含まれます：

1から10件の呼び出し先、それぞれの優先度、およびオプションの重み付けと呼び出し先パラメーター。
(任意) インバウンドトラフィックのフィルター基準。

ルートが作成されると、ルートの優先度が割り当てられます。作成された最初のルートには1の優先度が与えられ、後続の各ルートには1ずつ増加する優先度が与えられます。ルートの優先度は、コールルーティングのユーザーインターフェイスまたはコールルーティングAPIを通じて変更できます。

フィルター基準とルートの優先度の詳細については、「フィルターベースのルート選択」と題したセクションをご参照ください。

呼び出し先の優先度と重み

ルート上の各エントリーまたは呼び出し先には、1 (最高) から 100 (最低) までの値で 優先度 を割り当てる必要があります。実装に最も適した方法で優先度を設定できます。ルートが実行されると、エントリーは優先度に応じて評価されます。

同じ 優先度 を持つルート内のエントリーには、重みを割り当てる必要があります。

重みは、同じ優先度を持つ各ルートエントリーへの負荷の配分を決めるために使用されます。
優先度 は、ハントシーケンスを定義するために使用されます。

呼び出し先の詳細

ルート内の呼び出し先の種類ごとに、異なる結果を生成するオプションの要素を定義できます。次の表に、結果に影響を与えるパラメーター設定を示します。

呼び出し先の種類	パラメーター	影響
SIP	`username`	定義されている場合、SIPトランク上でコールがトリガーされると、 `to` コールの元々の呼び出し先はこの値で上書きされます。定義されていない場合、SIPトランク上でコールがトリガーされると、コールの元々の呼び出し先が保持されます。
SIP	`timeOut`	(任意)SIPトランク上でコールがトリガーされる時に、コールが確立されるまで待機する時間を定義します。 `timeOut`は、SIPトランクの可用性といった他の内部基準に加え、ルート失敗の最初の原因である場合には、ルートの前進または呼び出し先リストの次のエントリーへの移行をトリガーする可能性があります。
電話	`phoneNumber`	E.164形式の電話番号。指定しない場合、この値はデフォルトでインバウンドコールで使用される`to` 値になります。
電話	`timeOut`	(任意) この呼び出し先がトリガーされた時にコールが確立されるまで待機する時間を定義します。 `timeOut`は、呼び出し先の通信事業者の接続状況といった他の内部基準に加え、ルート失敗の最初の原因である場合には、ルートの前進または呼び出し先リストの次のエントリーへの移行をトリガーする可能性があります。
WEBRTC	`identity`	このコールの転送先となるWebRTCユーザーのID。指定しない場合、この値はデフォルトでインバウンドコールで使用される`to` 値になります。
WEBRTC	`displayName`	(任意) 接続されたWebRTCパーティに表示される WebRTCユーザーの名前を上書きします。
WEBSOCKET	`endpoint configuration`	以前に定義したWebSocketメディアストリーミング構成。
WHATSAPP	`phoneNumber`	E.164形式の電話番号。指定しない場合、この値はデフォルトでインバウンドコールで使用される`to` 値になります。
WHATSAPP	`from`	WhatsApp Business Callingを通じてアウトバウンドコールを発信する際に必要になるWhatsAppの発信元情報。
VIBER	`phoneNumber`	E.164形式の電話番号。指定しない場合、この値はデフォルトでインバウンドコールで使用される`to` 値になります。
VIBER	`from`	このアウトバウンドViberコールの`callerId`として使用する必要がある番号。指定すると、お使いのViber Business Call番号が反映されるはずです。
URL	`url`	公開されているURLを常に指定する必要があります。
URL	`securityConfig`	(任意) 公開されているウェブフックへの認証を行うセキュリティ方法。

レコーディングの有効化

ルートのエントリーごとに、その結果として生まれる会話の音声を録音することを選択できます。

レコーディングは次のどちらかになります：

結合 (すべての参加者のオーディオをまとめた1つのオーディオファイル)、または
非結合 (コールの参加者ごとに作成される1つのオーディオファイル)。

録音データを当社のクラウドストレージではなく、独自にお使いSFTPサーバーに保存したい場合は、filePrefixに任意のテキスト文字列を指定できます。このテキスト文字列は、サーバーに転送されるZIPファイルの名前に使用されます。

Allowed Time Window (許可された時間枠)

ルートの呼び出し先がコールルーティングの対象となるタイミングを制御したい時は、Allowed Time Window (許可された時間枠) を使用します。この機能を使うと、コールのフローを正確に制御し、コールが曜日と特定の時間帯の両方に基づいてルーティングされるようになります。この機能の使用例は次のとおりです：

Business Hour Routing (営業時間ルーティング)：コールが営業時間内にのみオフィス番号にルーティングされ、営業時間外にボイスメールまたは代替呼び出し先にリダイレクトされるようにします。
Special Event Handling (特別イベント処理)：イベント期間中は特別なイベント専用ホットラインにのみコールをルーティングします。
Global Operations (グローバル運用)：統一性を維持するために、UTC 時間を使用して、異なるタイムゾーンにある世界各地のオフィスへのコールルーティングを管理します。

管理者は、ルート内の呼び出し先ごとに1つ以上のAllowed Time Windows (許可された時間枠) を構成できます。これらの時間枠は、呼び出し先がコールルーティングに有効な時期を決定します。複数の時間枠を1つの呼び出し先に割り当てることができます。例えば、呼び出し先の可用性を下記のように構成できます：

月曜日から金曜日の午前8時から午後5時まで。
金曜日の午前8時から午後6時まで。
土曜日の午前9時から午後1時まで。

1つの呼び出し先に複数の時間枠が定義されている場合、システムはこれらの時間枠の整合性を自動的にチェックして、競合や重複を回避します。

コールによってルートの実行がトリガーされると、システムは現在の時刻を、そのルート内の各呼び出し先に対して定義された Allowed Time Windows (許可された時間枠) と照合します。

現在の時刻が特定の呼び出し先に対して定義されたAllowed Time Windows (許可された時間枠)の範囲外の場合、その呼び出し先はスキップされ、コールは次の適格な呼び出し先にルーティングされます。

インバウンドトラフィック用のルート選択

コールルーティングは、インバウンドトラフィックに適用するルートを次の2つの方法のいずれかで決定します。

静的ダイヤルイン方式 (DID) ルート選択：コールルーティングは、指定されたNTT CPaaSのDID番号のインバウンドトラフィックに常に同じ指定ルートを適用します。
フィルターベースのルート選択：コールルーティングは、フィルター基準に基づいてインバウンドトラフィックに適用されるルートを選択します。

静的DIDルート選択

ルートは、NTT CPaaS DIDルートに静的に割り当てられます。このDIDに到達するすべてのコールには、常に同じ指定ルートが選択されます。

サポートされているDIDまたは番号の種類は次のとおりです：

音声対応のNTT CPaaS VLNまたはTFN。
WhatsApp Business Calling機能が有効になっているWhatsApp送信者。
Viberの音声番号。

この構成は、 Webインターフェイス (opens in a new tab)または音声番号セットアップAPI (opens in a new tab) を使って完了できます。

Webインターフェイス (opens in a new tab)を通じてDIDをセットアップするには：

アカウントにログインします。
Channels and Numbers (チャネルと番号) > Channels (チャネル) > Voice and WebRTC (VoiceとWebRTC) に移動します。
取得した音声番号のいずれかをクリックします。新しいタブが開き、その番号の音声構成の設定内容が表示されます。

インバウンド構成を次のように編集します：

アクションタイプForward to Call Routingを選択します。
ドロップダウンリストから、この番号に割り当てるルートを選択します。

API 経由のインバウンドコールのルーティングアクションをセットアップするには、下記のAPIメソッドに使用します：

購入した番号のnumberKeyを取得します。これはリストの一覧表示 (opens in a new tab)メソッドを使ってアクセスする参照先から取得できます。

備考

NUMBERタイプのリソースを一覧表示し、その表示結果からnumberKeyを取得する必要があります。

以下を指定して、音声セットアップを作成します：
- 取得した numberKey。
- アクションタイプFORWARD_TO_CALL_ROUTING。
- この番号に割り当てたいルートのrouteId。

備考

APIメソッドは、Viberの音声番号やWhatsApp Business Calling機能が有効になっている送信者には対応していません。

フィルタベースのルート選択

フィルターを使用すると、定義された基準と合致するコールのみを評価することで、ルートの細分化をさらに進めることができます。フィルター基準は、ルート作成時に任意で定義できます。

特定のフィルターを使用することで、様々な種類のインバウンドトラフィックを管理できます。同じルートに複数のフィルターを定義すると、それらは論理的なOR 演算によって連結され、フィルター基準のいずれかが満たされれば、そのルートがトリガーされます。

PHONEフィルター

フィルターは、 from または to 番号のいずれか、または両方を使って指定できます。fromとto 番号の両方が指定されている場合、それらは論理AND演算を使って結合されます。

from と to番号の両方に指定する値は、完全に定義された数値または正規表現にすることができます。例えば：

from 値が 13124567890の PHONE フィルターを持つルートは、この正確な番号からコールを受信した場合にのみトリガーされます。
from 値が ^1(312|773|872)\d{5}90$ の PHONE フィルターを持つルートは、シカゴのプレフィックスを持ち、数字90で終わる米国の番号からのインバウンドコールに対してのみトリガーされます。

コールルーティングでフィルターを使用する場合、NTT CPaaS DIDに特定のルートを割り当てる必要がなくなりました。番号に Forward to Call Routing (コールルーティングへの転送) アクションを割り当てると、システムはすべてのルートの呼び出し先を評価します。一致するフィルターを持つ最初のルートがトリガーされます。

例えば、NTT CPaaS番号 ‪1312456789‬0 があるとします。もしシカゴの市外局番 (312、773、872) からその番号に着信するコールを1つの呼び出し先にルーティングし、ネーパービルの市外局番 (630) からのコールを別の呼び出し先にルーティングしたい場合は、以下の方法で振り分けることができます：

From フィルター ^1(312|773|872).* を使ってルートを作成し、そのルート内で目的の呼び出し先を設定します。
From フィルター ^1(630).* を使って2つ目のルートを作成し、そのルート内で目的の呼び出し先を設定します。
ルートを指定せずに、Forward to Call Routing (コールルーティングへの転送) を 13124567890 に割り当てます。

インバウンドコールが着信すると、コールルーティングは発信者の番号に合致する最初のルートフィルターを自動的に適用します。

次の表は、正規表現を使用したPHONEフィルター定義の例を幾つか示しています。

目的	正規表現	正規表現の説明
英国の番号から着信するすべてのコールに対してルートをトリガーさせたい。	from番号に次の正規表現を設定します：`^44\d{10}$`	`^`：行頭の位置を表します。 `44`：文字列`44`と文字通り一致します。 `\d`：桁と一致します ([0-9]と同等)。 `$`：行末の位置を表します。
シカゴの発信者からのインバウンドコールに対してこのルートをトリガーしたい場合	from番号に次の正規表現を設定します：`^1(312\|773\|872)\d{7}$`	`^`：行頭の位置を表します。 `1`：数字の1と文字通り一致します。第1キャプチャー群 (312\|773\|872)：第1代替数字312：文字通り`312`と一致します。第2代替数字773：文字通り`773`と一致します。第3代替数字872：文字通り`872`と一致します。 `\d`：桁と一致します ([0-9]と同等)。 `{7}`：前のトークンと完全に7回一致します。 `$`：行末の位置を表します。
NTT CPaaSを通じて登録した米国のフリーダイヤル番号に着信するインバウンドコールに対して、このルートをトリガーしたい場合	to番号に次の正規表現を設定します：`^1(800\|888\|877\|866\|855\|844\|833)\d{7}$`	上記と同じ構造の説明をここでも用います。
このルートを、どこから発信されたかを問わず、番号シーケンス"1234"を含むすべてのインバウンドコールに対してトリガーしたい場合	from番号に次の正規表現を設定します：`^\d1234\d$`	`^`：行頭の位置を表します。 `\d`：シーケンス"1234"より前の任意の桁数 (0の桁を含む) と一致します。 `1234`：特定のシーケンス"1234"と一致します。 `\d`：シーケンス"1234"より後の任意の桁数 (0の桁を含む) と一致します。 `$`：一致を文字列の末尾に固定します。

SIPフィルター

このフィルターを使えば、インバウンドのSession Initiation Protocol (SIP)トラフィックに基づいてルートをアクティブ化できます。SIPフィルターは、以下に基づいて定義できます：

トラフィックの発信元のトランクの参照：指定されたトランクから発信したすべてのトラフィックで、この正確なルートをトリガーする必要があります。特定のSIPトランクが指定されていない場合、アクティブなSIPトランクからのインバウンドSIPトラフィックに対してフィルターが有効になります。
fromフィールドの値。
toフィールドの値。
指定されたカスタムヘッダーの値。

備考

ヘッダー名は完全に指定する必要があり、ヘッダー値には正規表現を含めることができます。

次の表は、正規表現を使用したSIPフィルターの例を示しています：

正規表現	目的	正規表現の説明
`To` / `From` フィルター基準	上記の電話フィルターの例と同様です。 NOTE これらの値の一部は、特定のユーザー名 (例えば、`oliverjones` のような文字列) など、数値ではありません。
`Header value` - ヘッダー X-IB-AGENTCONTEXT に `sales` が含まれている場合に、このルートをアクティブにしたいとします。その場合：	ヘッダー値フィルターを `.sales.` に設定します。	`.`：部分文字列 `sales` の前のいずれかの文字と幾つか (なしを含む) 一致します。 `sales`：部分文字列 `sales` と完全に一致します。 `.`：部分文字列 `sales` の後のいずれかの文字と幾つか (なしを含む) 一致します。
`Header value` - ヘッダー `X-IB-WHATEVER` が `xyz` で始まり `001` で終わる場合、このルートをアクティブにしたいとします。その場合：	ヘッダー値を `^xyz.*001$` に設定します。	`^`：一致範囲の始まりを文字列の先頭に固定します。 `xyz`：先頭の部分文字列 `xyz` と完全に一致します。 `.*`：その間のいずれかの文字と幾つか (なしを含む) 一致します。 `001`：末尾の部分文字列 `001` と完全に一致します。 `$`：一致範囲の終わりを文字列の末尾に固定します。

WEBRTCフィルター

このフィルターは、WebRTC から発信されたトラフィックのルート実行をトリガーします。お使いのWebRTCクライアントアプリケーションから、CALL_ROUTINGアプリケーションに対してapplicationCallを行う必要があります。あるいは、コールルーティング API (opens in a new tab)を使用している場合、fromパラメーターに値 (完全表現または正規表現) を設定することも可能です。その場合、ルートはその特定のWebRTC IDからのコールに対してのみトリガーされます。

重要

ルート優先度の影響

複数のルートにインバウンドトラフィックと合致するフィルターがある場合、コールルーティングは優先度番号が最も小さいルートを選択します (1 が選択優先度が高い)。

ルート実行

ルート内の呼び出し先への呼び出しは、そこに正常に接続できるようになるまで、または呼び出し先リストの末尾に達するまで、優先度と重みに基づいて順番に試行されます。

ルートの実行は、エラー条件とタイムアウトに基づいて、ある呼び出し先から次の呼び出し先に進みます。

Note

新しく追加または変更されたルートが有効になり、その定義がシステムキャッシュに伝播されるまでに最大5分かかる場合があります。

SIPトランクの呼び出し先

次の表は、UDPとTLS両方のSIPトランクでルートの進行がどのように処理されるかをまとめたものです。

SIPトランクの呼び出し先がAdministrative Downステータスの場合、または使用停止中と見なされる場合 (トランクがSIP OPTIONSを使用するように設定され、SIP OPTIONSのポーリングによってトランクが使用停止中であると判断された場合)は、直ちにスキップされます。

トランスポートの種類	エンドユーザーの状態	SIP OPTIONSが有効	再ルーティング遅延	トランクがサービス停止状態にあると見なす期間
UDP	SIPトランクが到達可能	偽	N/A	N/A
UDP	SIPトランクが到達不能	偽	コールごとに4秒	一度もない
UDP	SIPトランクが到達不能	真	コールごとに4秒	最短：32秒 (SIPタイマー) 最長：32秒 + SIP OPTIONSのping間隔 (60秒)
UDP	SIPトランクが到達不能	真	0秒	N/A
TLS	SIPトランクが到達不能	偽	N/A	N/A
TLS	SIPトランクが到達不能	偽	コールごとに4秒	一度もない
TLS	SIPトランクが到達不能	真	コールごとに4秒	最短：28秒 (TCPタイマー) 最長：28秒 + ping間隔 (30秒) のSA構成
TLS	SIPトランクが到達不能	真	0秒	N/A

呼び出し先のタイムアウト

呼び出し先をSIPトランク、PHONE番号、または WebRTCユーザーに設定する場合、その呼び出し先でのタイムアウトを定義できます。このパラメーターは、到達可能な呼び出し先に対してのみ作動するため、タイムアウトを接続タイムアウト ではなく、応答タイムアウト として理解する必要があります。

例として、タイムアウトが15秒に設定されたSIPトランクの呼び出し先について考えてみます：

トランクに到達できない場合(詳細はSIP トランクの呼び出し先と題したセクションを参照)、タイムアウトは効果がなく、ルートが実行され、優先度と重みに基づいて次の呼び出し先に進みます。
トランクに到達でき、SIP INVITEに応答する場合、コールに応答しない場合、ルートの実行は15秒後に進みます。

SIP REFERによる再ルーティング

コールルーティングは、SIP REFER メソッドを使用したアクティブな接続コールの動的再ルーティングをサポートします。この機能は、最初の発信者を切断せずに新しい呼び出し先にコールを転送する必要がある場合に便利です。

典型的なフローは次のとおりです：

NTT CPaaS番号 (パーティA) でインバウンドコールが受信され、コールルーティングで事前定義されたルートがトリガーされます。
このルートは、ルートの呼び出し先リスト (パーティB) で指定されたSIPトランクを介して、インバウンドコールをアウトバウンドコールに接続します。
通話中の任意の時点で、セッションを終了する代わりに、リモートSIPユーザーエージェント (パーティB) は、新しい呼び出し先 (パーティC) を指定して、NTT CPaaSへのSIP REFERのリクエストを開始することができます。
コールルーティングは、元のインバウンドコールを維持し、新しくリクエストされた呼び出し先 (パーティC) にシームレスにブリッジして、通信が中断されないようにします。

この再ルーティング機能は、元のコールレッグをアクティブに保ちながら、発信者を別の部門、エージェント、または外線番号に転送するなど、柔軟なコール処理シナリオへの対応を可能にします。

重要

SIP REFERのリクエストは、パーティBから発信され、パーティBがSIPトランキングを介して接続されている場合にのみ受け入れられ、処理されます。
パーティBがSIP REFERを開始してコールをパーティCに転送すると、パーティCが接続された後も、パーティBのコールレッグはアクティブなままになります。必要に応じて、お使いのSIPユーザーエージェントがパーティBのコールレッグを終了するようにしたい場合は、お客様の責任でそのように設定してください。
パーティCがコールを拒否するか、到達できない場合、すべてのコールレッグ(A、B、C) は終了し、元のパーティAとパーティBは接続されたままになりません。

コールルーティングは、SIP REFERメッセージを受信すると、基準タイプがSIPに設定されたフィルターを持つルートのみを考慮します。このフィルターで指定されるTo値は、SIP REFERでリクエストされた新しい呼び出し先と一致する必要があります。

(任意) フィルター定義に特定のSIPトランクIDを設定して、実行ロジックをさらに絞り込むことができます。

Route Simulator (ルートシミュレーター)

コールルーティングのRoute Simulator (ルートシミュレーター) 機能を使用すると、どのルートが選択されて実行されるかを、ライブトラフィックを送信せずにテストできます。

ルートシミュレーター機能を使用すると、次の種類のインバウンドトラフィックのシミュレーションが可能になります：

電話
SIP
WEBRTC

シミュレーションの対象になる各トラフィックタイプには、fromおよびto値、ヘッダー、カスタムデータ値などの追加の適格データを含めることができます。また、無効なルートをシミュレーションに含めることも選択できるため、ライブトラフィックに影響を与えずにルート設定をテストできます。

Note

ルートを追加または変更すると、シミュレーションで変更が有効になるまでに最大5分かかる場合があります。

ルートシミュレーターは、 Webインターフェイス (opens in a new tab)ならびにAPI (opens in a new tab) を通じて使用できます。

NTT CPaaSのWebインターフェイスを通じて使用するルートシミュレーターの活用法：

コールルーティングのアプリケーションのメイン画面に移動します。
**Simulate Route (ルートのシミュレーション)**を選択します。
シミュレーションの対象にしたいトラフィックのタイプを選択します。

APIを通じて使用するルートシミュレーターの活用法：

API を使用してルート選択をシミュレートするには：

Simulate Route Selection (ルート選択シミュレーション) エンドポイントに POSTリクエストを送信します。
リクエスト本文に、次のような項目を含むインバウンドトラフィックの詳細を指定します：
- endpoint.type (PHONE、SIPまたはWEBRTC)。
- from と to の値 (該当する場合)。
- SIPトランク情報とカスタムヘッダー (SIPシミュレーション用)。
- useDisabledRoutes を使用して、無効なルートも評価対象に含めます。

シミュレーターは、実際のインバウンドコールであるかのようにリクエストを処理し、次のことを行います：

一致するすべてのルートを評価します。
選択するルートを決定します。
一致した基準と呼び出し先のリストを実行順に返します。

コールログの取得

コールログは、コールルーティングによって処理されたすべてのコールレッグに対して作成されます。

インバウンドコールレッグ。
コールルーティングがブリッジを試みる各アウトバウンドコールレッグ (呼び出し先が無効状態のSIPトランクの場合を除く)。

正常にブリッジされたコールレッグのログエントリーは、共通の同一 相関識別子 によって照合することができます。

詳細レポートの取得

コールルーティングの詳細レポートを取得するには、次の手順に従います：

アカウントにログイン (opens in a new tab)します。
Analyze (アナライズ) > Reports (レポート) (opens in a new tab) に移動します。

NTT CPaaSでは、通話方向、期間、請求期間、通話料金など、コールに関するあらゆる詳細情報を含む新しい 詳細レポート をリクエストすることをお勧めします。詳細レポートには、SIPトランク名、SIPトランクID、相関識別子、およびdialogIdも含まれます。

ダウンロードしたら、CALL_ROUTINGのFeature (機能) 列をフィルタリングします。

NTT CPaaS レポートの使用方法の詳細については、Analyze Reports (レポートの分析) セクションをご参照ください。

コールルーティングのレコーディングへのアクセス

コールルーティングによって実行されるレコーディングには、APIまたはNTT CPaaSのWebインターフェイス (opens in a new tab)からアクセスできます。

NTT CPaaSのWebインターフェイス (opens in a new tab)からコールルーティングのレコーディングを検索してダウンロードするには：

Voice チャネルアプリケーション内の[Recording (レコーディング)]タブに移動します。
サブナビゲーションバーで Call Routing (コールルーティング) を選択します。
レコーディングエントリーを展開し、関連ファイル (結合または非結合) のリストを確認します。
当社のクラウドストレージから利用可能なファイルならびに関連のメタデータJSONファイルをダウンロードします。

コールルーティングのレコーディングは、ルート、参加者タイプまたはID (ユーザー名や電話番号など) で検索できます。

Click-to-Call レポート