コールルーティング
コールルーティングは、NTT CPaaS ダイヤルイン方式 (DID) 番号へのインバウンドコールの処理方法を決定できるルート管理システムであり、強力な復元性を実現するのに役立ちます。
コールルーティングでは、必要な数のルートを定義でき、それぞれに最大 10 個のエントリーがあります。ルートのエントリーには、次の種類があります：
エントリーの種類 | 定義 |
|---|---|
| SIP | お使いのアカウントで既に作成している事前定義されたSIPトランク |
| PHONE | NTT CPaaSのグローバルネットワークを介して到達できる固定電話番号または携帯電話番号 |
| WEBRTC | WebRTCアプリケーションからのユーザー ID |
| WEBSOCKET | Websocketのメディアストリーミング構成 |
| WhatsApp Business Calling で呼び出される WhatsApp エンドユーザーの MSISDN (電話番号) | |
| VIBER | Viber Business Callsで呼び出されるViberエンドユーザーのMSISDN (電話番号) |
| URL | お使いのバックエンドアプリケーションによって公開されているウェブフック |
特定のルートを使用するように設定された DID 番号にコールが到達すると、そのルートの各エントリーが次の順序で評価されます：
- 定義されたエントリーに正常に到達できる場合、インバウンドコールはその送信先に接続されます
- 定義されたエントリーに到達できない場合は、ルートリスト内の次のエントリーが評価されます
以下のスキーマ図は、コールルーティングを使用して、指定した送信先にコールを転送する方法を示しています。
ルートの作成
ルートは、音声チャネルアプリケーションのコールルーティングを使用して NTT CPaaSのWebインターフェイスから作成するか、API を使用して作成できます。
優先度と重み
ルート上の各エントリーまたは送信先には、1から100の範囲の優先度 を割り当てる必要があります (1が最も優先度が高い)。優先度は、実装に必要かつ重要度の順に自由に設定できます。ルート内の各送信先には、1から100の範囲のプライオリティ値を設定できます。ルートが実行されると、エントリーは優先度に従って評価されます。
同じ優先度 を共有するルート内のエントリーには、重み を割り当てる必要があります。重みは、同じ優先度を持つ各ルートエントリーへの負荷の割合を決定するために使用されます。
優先度は、基本的にハントシーケンスを定義します。
送信先の詳細
ルートの送信先タイプごとに、異なる結果を生成するオプションの要素を定義できます。次の表に、結果に影響するパラメーター設定を示します。
| 送信先の種類 | パラメーター | 影響 |
|---|---|---|
| SIP | username (ユーザー名) | 定義すると、コールの元の送信先 ( to ) は、コールが SIPトランクでトリガーされた時にこの値で上書きされます。定義されていない場合、コールの元の送信先は上書きされず、SIP トランクでコールがトリガーされた時に保持されます。 |
timeOut (タイムアウト) | 必要に応じて、SIP トランクでコールがトリガーされた時にコールが確立されるまで待機する時間を定義します。timeOut は、SIPトランクの可用性などの他の内部基準の次に、ルートを失敗させる最初の理由である場合、ルートの前進 (つまり、送信先リストの次のエントリーに移動する)をトリガーする可能性があります。 | |
| PHONE | phoneNumber (電話番号) | E.164 形式の電話番号のことで、指定しない場合、このデフォルト値は、インバウンドコールで使用される to 値になります。 |
timeOut (タイムアウト) | 必要に応じて、この送信先がトリガーされた時にコールが確立されるまで待機する時間を定義します。timeOut は、ルートを失敗させる最初の理由である場合、送信先の電話交換手の空き状況などの他の内部基準の次に、ルートの前進 (つまり、送信先リストの次のエントリに移動する)をトリガーする可能性があります。 | |
| WEBRTC | identity (ID) | このコールの転送先となる webRTC ユーザーのIDです。指定しない場合、デフォルト値は、インバウンドコールで使用されるto 値になります。 |
displayName (表示名) | 必要に応じて、接続された webRTC パーティに表示される webRTC ユーザーの名前を上書きします。 | |
| WEBSOCKET | endpoint configuration (エンドポイント構成) | 以前に定義された Websocket メディアストリーミング構成のことです。 |
phoneNumber (電話番号) | E.164 形式の電話番号のことで、指定しない場合、このデフォルト値は、インバウンドコールで使用される to 値になります。 | |
from (送信元) | このWhatsApp Businessのアウトバウンドコールに使用する必要がある WhatsApp送信者のことです。 | |
| VIBER | phoneNumber (電話番号) | E.164 形式の電話番号のことで、指定しない場合、このデフォルト値は、インバウンドコールで使用される to 値になります。 |
from (送信元) | このViberのアウトバウンドコールのcallerId として使用する番号のことで、指定する場合は、Viber Business Callの番号を反映する必要があります。 | |
| URL | url | 公開されているURLは常に指定する必要があります。 |
securityConfig (セキュリティ構成) | 必要に応じて、公開されているウェブフックに対する認証を行う任意のセキュリティメソッドです。 |
レコーディングの有効化
ルートのエントリーごとに、その結果として生まれる会話の音声を録音することを選択できます。
レコーディングは次のいずれかになります：
- 構成版 (全参加者の音声をミックスした1つのオーディオファイル)、または
- 非構成版 (コールの参加者ごとに 1つのオーディオファイル)
レコーディングにクラウドストレージを使用せず、SFTPサーバーに転送することを選択した場合は、filePrefixにオプションのテキスト文字列を指定できます。このテキスト文字列は、サーバーにプッシュされる zip ファイル名に使用されます。
許可された時間枠
Allowed Time Window (許可された時間枠) では、ルートの送信先がコールルーティングの対象となる特定の時間枠を定義できます。コールフローをきめ細かく制御し、曜日と特定の時間の両方に基づいてコールがルーティングされるようにします。この機能の使用例は次のとおりです：
- 営業時間ルーティング：コールが営業時間内にのみオフィス番号にルーティングされ、営業時間外にボイスメールまたは代替送信先にリダイレクトされるようにします。
- 特別なイベント処理：イベント時間中にのみ特別なイベントホットラインにコールをルーティングします。
- グローバルオペレーション：統一性を維持するために、UTC時間を使用して、異なるタイムゾーンのグローバルオフィスのコールルーティングを管理します。
ルート内の送信先ごとに、管理者は 1つ以上の [Allowed Time Windows (許可された時間枠)] を設定できます。これらの時間枠は、送信先がコールルーティングに有効な時期を決定します。複数の時間枠を 1つの送信先に割り当てることができます。例えば、送信先の可用性を下記のように構成できます：
- 月曜日から金曜日の午前8時から午後5時
- 金曜日の午前8時から午後6時
- 土曜日の午前9時から午後1時
1つの送信先に複数の時間枠が定義されている場合、システムはこれらの時間枠の一貫性を自動的にチェックして、競合や重複を回避します。
コールによってルート実行がトリガーされると、システムは、ルート内の各送信先に対して定義した [Allowed Time Windows (許可された時間枠)] に対して現在の時刻を評価します。現在の時刻が送信先に対して定義した [Allowed Time Windows (許可された時間枠)] の範囲外の場合、その送信先はスキップされ、コールは次の利用可能な送信先にルーティングされます。
DID番号へのルートのアサイン
NTT CPaaSのWebインターフェイスまたは API を使用して、NTT CPaaS DID 番号にルートをアサインすることができます。
Webインターフェイス経由のDID番号へのルートのアサイン
アカウントにログインし、Channels and Numbers (チャネルと番号) > Voice and WebRTC (VoiceとWebRTC) に移動してから、次の操作を行います：
- 取得した音声番号のいずれかをクリックします。すると、新しいタブが開き、その番号の音声構成設定が表示されます。
- インバウンド構成の編集：Forward to Call Routing (コールルーティングへの転送) というアクションを選択し、(必要に応じて)ドロップダウンリストからこの番号に割り当てるルートを選択します。
- アクションでルートを指定すると、音声番号へのインバウンドコールがある度にこのルートが体系的に実行されます。
- アクションでルートを指定しない場合は、フィルタリング基準に一致するルートが少なくとも 1つあることを確認する必要があります。詳しくは、フィルタリング基準によるルートの照合セクションをご参照ください。なお、フィルタリング基準に一致するルートが複数ある場合は、最初に見つかったルートが使用されますので、ご注意ください。
API 経由で DID 番号へのルートのアサイン
API 経由のインバウンドコール用のルーティングアクションをセットアップするには、番号管理 (opens in a new tab) メソッドを使用します。
一般的なフローは次のとおりです：
- 購入した番号の
numberKeyを取得します。このリファレンスは、購入番号の一覧表示 (opens in a new tab) メソッドを使って取得できます。 - 音声セットアップ (opens in a new tab)を作成します。その際、以下を指定します：
- 取得した
numberKey - アクション
タイプFORWARD_TO_CALL_ROUTING - この番号にアサインするルートの
routeId
- 取得した
フィルタリング基準によるルートの照合
フィルターを使用すると、これらの基準に一致するコールのみを評価することで、割り当てられたルートをさらに詳細にすることができます。フィルタリング基準は、ルートの作成時にオプションで定義します。
特定のフィルターを使って様々な種類のインバウンドトラフィックを管理することができます。同じルートに複数のフィルターを定義すると、それらは OR 演算によってリンクされ、フィルターの条件のいずれかが満たされた場合にルートがトリガーされます。
PHONEフィルター
フィルターは、from または toのいずれか、または両方を使って指定できます。from と to の両方の番号が指定されている場合、それらは AND 演算によって結合されます。
from と to に指定する値は、完全に定義された番号でも正規表現でも構いません。例えば：
- PHONEフィルターのfrom値が
13124567890のルートは、この番号からコールを受信した場合にのみトリガーされます。 - from 値が
^1(312|773|872)\d{5}90$の PHONE フィルターを持つルートは、シカゴのプレフィックスを持ち、数字 90 で終わる米国の番号からのインバウンドコールに対してのみトリガーされます。
コールルーティングでフィルターを使用する場合、NTT CPaaS DID に特定のルートを割り当てる必要がなくなりました。番号で Forward to Call Routing (コールルーティングへの転送) を選択すると、システムはすべてのルート定義を評価します。一致するフィルターを持つ最初のルートがトリガーされます。例えば、NTT CPaaSを通じて登録した番号が13124567890で、シカゴの市外局番 (312、773、872) からのコールを 1つの宛先にルーティングし、ネーパービルの市外局番 (630) からのコールを別の宛先にルーティングする場合は、次のようにします：
- From フィルター
^1(312|773|872).*を使用してルートを作成し、ルート内の目的地を設定します。 - From フィルター
^1(630).*を使用して 2 番目のルートを作成し、ルート内の目的地を設定します。 - ルートを指定せずに、Forward to Call Routing (コールルーティングへの転送) を
13124567890に割り当てます。
インバウンドコールが着信すると、コール ルーティングは発信者の番号に一致する最初のルートフィルターを自動的に適用します。
次の表に、正規表現を使って PHONE フィルターを定義した例をいくつか示します：
| 目的 | 正規表現 | 正規表現の説明 |
|---|---|---|
| 英国の番号から発信されるすべてのコールに対してルートをトリガーしたい場合 | From番号に次の正規表現を設定します：^44\d10$ |
|
| シカゴの発信者からのインバウンドコールに対してこのルートをトリガーしたい場合 | From番号に次の正規表現を設定します：^1(312|773|872)\d7$ |
|
| NTT CPaaSを通じて登録した米国のフリーダイヤル番号に着信するインバウンドコールに対して、このルートをトリガーしたい場合 | To 番号に次の正規表現を設定します：^1(800|888|877|866|855|844|833)\d{7}$ | 上記と同じ構造の説明を使用します。 |
| このルートを、どこから発信されたかを問わず、番号「1234」のシーケンスを含むすべてのインバウンドコールに対してトリガーしたい場合 | From番号に次の正規表現を設定します： ^\d1234\d$ |
|
SIPフィルター
このフィルターを使えば、インバウンドのSession Initiation Protocol (SIP)トラフィックに基づいてルートをアクティブ化できます。SIPフィルターは、以下に基づいて定義できます：
- トラフィックの送信元のトランクの参照：指定されたトランクから来るすべてのトラフィックで、この正確なルートをトリガーする必要があります。
- Fromフィールドの値
- Toフィールドの値
- 指定されたカスタムヘッダーの値 - ヘッダー名は完全に指定する必要がありますが、ヘッダー値には正規表現を含めることができます。
次の表に、正規表現を使用した SIP フィルタの例をいくつか示します。
| 目的 | 正規表現 | 正規表現の説明 |
|---|---|---|
| To / From のフィルタリング基準 | 上記のPHONEフィルターの例と同様 - これらの値の一部は、oliverjones のような文字列で構成する特定の「ユーザー名」など、数値以外の場合があることにご注意ください。 | |
| ヘッダー値 - ヘッダー X-IB-AGENTCONTEXT に「sales」が含まれている場合に、このルートをアクティブ化したいとします。 | ヘッダー値フィルターを .*sales.* に設定します。 | 左の.* は、部分文字列「sales」の前にある任意の数の任意の文字（文字がない場合も含む）の一致、salesは、 部分文字列「sales」との完全な一致、そして右の .* は、部分文字列「sales」の後にある任意の数の任意の文字（文字がない場合も含む）の一致をそれぞれ意味します。 |
ヘッダー値 - ヘッダー X-IB-WHATEVER が「xyz」で始まり「001」 で終わる場合、このルートをアクティブ化したいとします。 | ヘッダー値を ^xyz.*001$ に設定します。 | ^ は、一致する位置のアンカーを文字列の先頭に置きます。xyz は、先頭の部分文字列「xyz」との完全な一致を意味します。.* は、任意の数の任意の文字（文字がない場合も含む）の一致を意味します。001 は、末尾の部分文字列「001」との完全な一致を意味します。$ は、一致する位置のアンカーを文字列の末尾に置きます。 |
WEBRTCフィルター
WEBRTCフィルターは、Web リアルタイム通信 (WebRTC) から発信されたトラフィックのルート実行をトリガーします。WebRTCクライアントアプリケーションで、CALL_ROUTING アプリケーションに対してapplicationCall を行います。オプションとして、from パラメーター (コールルーティングAPIを使用している場合は identity) の値 (完全または正規表現) を設定でき、これは、その特定の WebRTC IDからのコールに対してのみルートがトリガーされることを意味します。
ルート実行
ルート内の送信先は、そこに正常に接続できるようになるまで、または送信先リストの末尾に達するまで、優先度と重みに基づいて順番に試行されます。
ルートの実行は、エラー状態とタイムアウトに基づいて、ある送信先から次の送信先に進みます。
SIPトランクの送信先
次の表は、UDPとTLS 両方のSIPトランクでルートの進行がどのように処理されるかをまとめたものです。
SIPトランクの送信先が Administrative Downstatus にある場合、またはサービス停止状態だと見なされた場合 (トランクが 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秒後に進みます。
コールステータス
上記の大まかなスキーマ図では、シナリオの一部であるコールレッグごとにコールログが作成されています。スキーマでは、これは次のことを意味します：
- 外部電話ユーザーからNTT CPaaS DID番号へのインバウンドコールのコールログ
- 最初の送信先エントリー (SIPトランク Aへ)のコールログ (このトランクが管理上無効に設定されている場合を除く)。この例では、このエントリーは失敗したコールを暫定的に反映します。
- 2 番目の送信先エントリー (SIPトランク Bへ)のコール ログ (このトランクが管理上無効に設定されている場合を除く)。この例では、このエントリーは失敗したコールを暫定的に反映します。
- 3 番目の送信先エントリー (SIPトランク Cへ)のコールログ (このトランクが管理上無効に設定されている場合を除く)。この例では、このエントリーは失敗したコールを暫定的に反映します。
- 最終送信先エントリー (外線電話機へ)のコールログ。この例では、このエントリーは正常に応答されたコールを反映します。
正常に接続されたコールレッグのログには、同じコミュニケーションに参加した接続コールレッグと一致する相関参照 dialogId が含まれます。
コール履歴の取得
お使いのアカウントにログイン (opens in a new tab) し、Analyze> L (opens in a new tab)ogs (ログの分析) (opens in a new tab)に移動します。
ログは、次の条件でフィルタリングできます：
- data range (日付範囲)
- 発信元 (From) と送信先 (To)
- SIPトランク名
詳細レポートの取得
お使いのアカウントにログイン (opens in a new tab)し、Analyze > Reports (レポートの分析) (opens in a new tab) に移動します。
NTT CPaaS では、コールの方向、通話時間、課金時間、通話料など、コールに関するすべての詳細を含む新しい詳細 レポートをリクエストすることをお勧めします。詳細レポートには、SIPトランク名、SIPトランク ID、相関識別子および dialogId も含まれます。
NTT CPaaS レポートの使用方法の詳細については、Analyze Reports (レポートの分析) セクションをご参照ください。
コールルーティングの録音へのアクセス
コールルーティングによって実行される録音には、API または NTT CPaaSのWebインターフェイスからアクセスできます。
NTT CPaaSのWebインターフェイスからコールルーティングの録音を検索してダウンロードするには、次の手順を実行します：
- Voiceチャネルアプリケーションの下の録音タブに移動します。
- サブナビゲーションバーで Call Routing (コールルーティング) を選択します。
- 特定の録音エントリーを展開すると、作成済みまたは未作成かにかかわらず、関連ファイルのリストが表示されます。クラウドストレージに保存されているファイルと、関連するメタデータjsonファイルをダウンロードできます。
また、ルート、参加者タイプ、ID (ユーザー名、電話番号など)でコールルーティングの録音を検索することもできます。