WebSocket ストリーミングを使用する

WebSocket オーディオ ストリーミングは、WebSocket プロトコルを使用して、インターネット経由でリアルタイムのオーディオ データを送信します。クライアントとサーバーの間に永続的な双方向接続を確立し、ライブボイスチャット、自動音声応答システム、リアルタイムオーディオモニタリングなどのアプリケーションとの継続的なオーディオ交換を可能にします。この接続と効率的なデータ転送により、従来の方法と比較してレイテンシーが短縮され、パフォーマンスが向上します。

ストリーミングオプション

NTT CPaaS Calls APIは、WebSocketストリーミングによる外部メディア処理サービスとの連携に対応しています。ユースケースに応じて 2 つの異なるオプションが提供されます。

ストリーミング メディア アクション

• 特定のコール レッグで開始および停止します。
• そのコール レッグから外部サービスにオーディオ ストリームを複製し、メディア置換を実行するオプションを使用します。
• メディアの置換がアクティブな場合、そのコール レッグの元の音声は外部サービスからの音声に置き換えられるため、会議またはダイアログの他の参加者には、元のストリームではなく置き換えられた音声が聞こえます。
• 一般的な使用例:
  • 指定されたコール レッグの音声を外部の音声文字起こしまたは感情分析サービスにストリーミングします。
  • 外部 AI サービスを使用して、指定されたコール レッグの音声を変更し、置き換えます。*例:*冒涜的な言葉のフィルタリングまたは音声強化。

WebSocket エンドポイント

• 外部メディア処理サービスを会議またはダイアログの個別の参加者として追加します。
• ミュートされていないすべての参加者から音声を受信します。
• 外部サービスによって生成された音声は、その会議またはダイアログのすべての参加者に聞こえます。
• 一般的な使用例:
  • 会話型 AI サービス (ボイスボット) を会議やダイアログに統合する。
  • すべての参加者の音声を、話者のダイアライゼーションをサポートする外部文字起こしサービスにストリーミングします。
  • すべての参加者の音声を外部録音サービスにストリーミングします。
  • すべての参加者の音声を外部ブロードキャストサービスにストリーミングします。

これらの統合方法を使用して、リアルタイム オーディオ処理やその他の高度なメディア機能を NTT CPaaS Calls アプリケーションに組み込むことができます。

ストリーミング メディア アクション

呼び出し API を使用すると、WebSocket を使用してアプリケーションから任意のホストにアウトバウンド呼び出しメディアをストリーミングできます。オーディオストリーミングのみがサポートされています。

音声ストリーミングは、コール レッグごとに設定されます。ストリームを開始する前に、少なくとも 1 つの新しいメディアストリーム設定を作成する必要があります。次に、呼び出し内の構成 ID を使用して、ストリーミング メディアを開始または停止します。メディアは、一連の生バイトとしてストリーミングされます。

メディア置換無しのストリーミング

次の図は、メディアを置き換えないストリーミングを示しています。2 人の参加者が会議ブリッジ上で互いに話し合い、参加者 A の音声は外部文字起こしサービスにルーティングする必要がありますが、参加者 B は 参加者 A をそのまま聞く必要があるとします。メディアを置き換えずにストリーミングすると、送信メディアが別のリスナーにストリーミング (フォーク) されるだけです。

メディア置換によるストリーミング

上記と同じ例を使用すると、外部ホストの役割は、オーディオ フィルタリング (ボイス チェンジャー、不適切な表現フィルタなど) などのサービスを提供することです。この場合、変更された音声が会議に挿入され、これはこの会議のすべての参加者が聞く音声です。

メディア ストリーミング構成を作成する

まず、メディア ストリーム構成オブジェクトを作成します。このオブジェクト内で、WebSocket ホストの URL と、それにアクセスするために必要な承認 (存在する場合) を指定します。

wsと wssの両方がサポートされています。応答には、新しく作成された MediaStreamConfigオブジェクトの ID が含まれます。

通話中にメディアのストリーミングを開始するには、start-media-stream リクエストを作成します。要求内で、以前に作成した構成の ID を指定し、ホストがメディアを置き換えるかどうかを指定します。

すべてが成功した場合、ホストが受信する最初のメッセージは次のとおりです。

このメッセージには、次のフィールドが含まれています。

• callId: 対応するcallId。ホストが複数の通話を処理している場合に役立ちます。
• sampleRate: ストリーミングされるオーディオのサンプリングレート。キロヘルツ (kHz) の単位で表されます。デフォルトは 48kHz です。
• packetizationTime: ホストに送信される 2 つの連続したパッケージ間の経過時間。ミリ秒 (ms) 単位で表されます。デフォルトは 20 ミリ秒です。
• customData: 開発中 (完全にはサポートされていません)。

受信オーディオ ストリームの解析

接続の確立時に最初のメッセージを送信した後、NTT CPaaSプラットフォームは引き続きホストに音声パケットを送信します。パケットはpacketizationTime秒(このフィールドに入力した値)ごとに送信されます。パケットには純粋な音声のみが含まれます。

48kHz のサンプリング オーディオの場合、20 ミリ秒のオーディオには次のものが含まれます。

• number_of_samples = 48kHz x 20ms = 960サンプル

オーディオは生でストリーミングされるため、各オーディオ サンプルは 16 ビットの符号付き整数としてエンコードされ、2 バイトの値として表されます。つまり、すべての受信メッセージには、理想的には 1920 バイト (960x2) が含まれている必要があります。ただし、ネットワークに問題がある場合は、メッセージ内で複数のパケットが送信される可能性があります。これらのパケットは、1920 バイトの倍数(3840、5760、7680 など)であることが保証されています。

メディアの交換

メディア ストリーム要求がメディアを置き換えるように設定されている場合、NTT CPaaS プラットフォームは 1920 バイトのパケットを送り返すことを想定しています。ネットワークエラーが発生し、複数のパケットが1つのクラスタとして送信された場合でも、ホストは常に1920バイトのパケットを送り返す必要があります。これらのパケットはコールに挿入され、他の参加者に配布されます。したがって、メディア交換がアクティブな場合は、メディアの 1 つのストリームを送り返すだけでよく、NTT CPaaS プラットフォームが通話の他の参加者に配信します。

メディア置換が設定されていない場合、NTT CPaaS プラットフォームはホストからの着信メッセージを無視します。

WebSocket エンドポイント

WEBSOCKETエンドポイントを使用して、WebSocket 経由で外部メディア サービスへのアウトバウンド コール レッグを作成できます。コール レッグとして、次のものに参加できます。

• 複数の参加者が参加する会議。
• 参加者が 1 人いるダイアログ。

これは、参加者のそれぞれのエンドポイントタイプ(PHONE、SIP、WEBRTC、VIBER、WHATSAPP)に関係なく可能です。

WebSocket エンドポイント構成の作成

WebSocket ストリーミングを有効にするには、 WebSocket ストリーミング構成オブジェクトを作成します。このオブジェクト内で、WebSocketホストのURLを指定し、構成タイプをWEBSOCKET_ENDPOINTに設定します。

WebSocketエンドポイントで認証が必要な場合、NTT CPaaSはcustomDataキーと値のペアを使用して認証をサポートしていることに注意してください。WebSocket エンドポイントは、customData を含む websocket:connected イベントを送信できるように、接続を許可する必要があります。

WebSocket エンドポイントを接続する

WEBSOCKET 呼び出しレッグは、 呼び出しの作成、 新しい呼び出しとの接続、 新しい呼び出しの追加、 ダイアログの作成などのメソッドで開始できます。タイプ WEBSOCKET のアウトバウンド コールを作成する場合は、WebSocket 構成 ID を指定します。

タイプWEBSOCKETのコールレッグを作成すると、customDataで定義されたキーと値のペアがwebsocket:connectedイベントの一部としてWebSocketサーバーに送信されます。customData の最大長は 512 バイトです。

WebSocket メッセージ

WebSocket メッセージは、SIP シグナリングや RTP パケットと機能的に同等であり、シグナリングを処理するテキスト メッセージと、メディア データを伝送するバイナリ メッセージがあります。

確立された WebSocket 接続で送信される最初のメッセージはテキストベースで、JSON ペイロードが含まれています。

最初のテキストメッセージの後、後続のメッセージはテキスト(DTMF数字)またはバイナリにすることができます。

WebSocket インターフェイスでサポートされているオーディオ コーデックはリニア PCM 16 ビットで、サンプル レートは 8kHz、16kHz、24kHz、または 32kHz、フレーム サイズは 20 ミリ秒です。

WebSocket に接続されている通話のパーティが DTMF トーンを送信すると、WebSocket でイベントがトリガーされます。このイベントは、オーディオフレーム間でインターリーブされた JSON ペイロードを含むテキストメッセージで、次の形式です。

WebSocket にオーディオを書き込む

音声を通話に送り直すには、WebSocket を介してバイナリ メッセージを送信します。オーディオ形式は、前のセクションで説明した仕様と一致する必要があります。各メッセージは、サンプル レートに応じて正確に 320、640、960、または 1280 バイト である必要があり、オーディオの 20 ミリ秒のセグメントを表す必要があります。

メッセージは、再生前にプラットフォームがバッファに保存するため、リアルタイム再生を超える速度で送信できます。これにより、メッセージサイズの要件(320、640、960、または1280バイト)を遵守していれば、1回の操作でオーディオファイル全体を転送できます。ただし、バッファ容量は 1024 メッセージに制限されており、これは約 20 秒の音声に相当します。ファイルがこの期間を超える場合は、データの損失を防ぐために、各メッセージの間に約 18 から 19 ミリ秒の遅延を設けてください。