SDK と API の既知の問題

これらの記事では、Azure Communication Services Calling SDK と Communication Services Call Automation API に関連する制限事項と既知の問題について説明します。

重要

通話エクスペリエンスの品質に影響する可能性のある要因が複数あります。 Communication Services のネットワーク構成とテストのベスト プラクティスの詳細については、「ネットワークの推奨事項」を参照してください。

Calling Web SDK

次のセクションでは、Azure Communication Services JavaScript 音声およびビデオ通話 SDK に関連する既知の問題について説明します。

Chrome M115 - 回帰

Android 用 Chrome バージョン 115 では、ビデオ通話を行うときに回帰が発生しました。このバグの結果、このバージョンの Chrome を使用して Azure Communication Services で通話を行うユーザーは、グループ通話や Azure Communication Services-Microsoft Teams 通話でビデオを送信できなくなります。

• この回帰は、Chromium で発生した既知の問題です
• 短期的な軽減策として、Android で Microsoft Edge または Firefox を使用するか、Android で Google Chrome 115/116 を使用しないようにユーザーに指示します

Firefox に関する既知の問題

Firefox デスクトップ ブラウザーのサポートがパブリック プレビューで利用できるようになりました。 既知の問題を次に示します。

• スピーカーの列挙が利用できない: Firefox を使用している場合、Communication Services デバイス マネージャーを使用してアプリでスピーカーを列挙または選択することはできません。 このシナリオでは、オペレーティング システムを介してデバイスを選択する必要があります。
• 現在、Firefox デスクトップの音声/ビデオ通話を行う場合、仮想カメラはサポートされていません。

iOS Chrome の既知の問題

iOS Chrome ブラウザーのサポートがパブリック プレビューで利用できるようになりました。 既知の問題を次に示します。

• ブラウザーをバックグラウンドに切り替えたり、デバイスをロックしたりすると、音声の発着信が利用できなくなります。 この問題は、iOS バージョン 16.4 以降で修正されました。
• Bluetooth ヘッドセットからの音声の着信/発信が利用できません。 ユーザーが Azure Communication Services 通話の途中で Bluetooth ヘッドセットを接続すると、ユーザーが電話をいったんロックしてロック解除するまで、スピーカーから引き続き音声が出力されます。 この問題は以前の iOS バージョン (15.6、15.7) で発生しており、iOS 16 では再現できません。

iOS Safari でカメラ プレビューの解像度サイズが正しく表示されない

このバグは、iOS 16.7 または 17.4 より前の iOS 17 バージョンで、ユーザーが通話中に携帯電話を回転させたり、ビデオを有効/無効にしたりすると発生します。 カメラ プレビューには、通常に戻る前に誤った解像度サイズが一時的に表示されます。 この問題は、iOS 17.4 ベータ版では再現できません。 関連する WebKit のバグはこちらをご覧ください。

iOS 16 で、通話中にブラウザーをバックグラウンドに配置するときにバグが発生しました

iOS 16 リリースで、Safari モバイル ブラウザーを使っているときに Azure Communication Services の音声/ビデオ通話が停止する可能性があるバグが発生しました。 Apple はこの問題を認識していて、修正策を検討しています。 影響として、通話中に Azure Communication Services 通話が機能しなくなる可能性があり、再度機能させるための唯一の解決策は、エンド カスタマーに電話を再起動してもらうことです。

このバグを再現するには次のようにします。

• ユーザーに iOS 16 を実行している iPhone を使用してもらいます
• Safari iOS モバイル ブラウザーを使って Azure Communication Services 通話 (オーディオのみ、またはオーディオとビデオを使用) に参加します
• 通話中に誰かが Safari ブラウザーをバックグラウンドに配置して、YouTube を表示したり、Bluetooth デバイス経由で接続中に FaceTime や電話の通話を受信したりします

結果:

• この状況の数分後に、受信と送信ビデオが停止する可能性があります。
• Azure Communication Services 通話を再度機能させる唯一の方法は、エンド ユーザーに電話を再起動してもらうことです。

Chrome M98 - 回帰

Chrome バージョン 98 で、ビデオ キーフレームが異常に生成される回帰が導入され、大半 (70% 以上) のユーザーで、送信されたビデオ ストリームの解像度に悪影響が生じています。

• この回帰は、Chromium で発生した既知の問題です

PSTN 通話中でも、ユーザーが ACS 通話からの音声を聞くことができる

この問題は、Android Chrome ユーザーに PSTN 通話の着信があったときに発生します。PSTN 通話に応答すると、ACS 通話のマイクがミュートされます。 ACS 通話の発信音声はミュートされているため、PSTN 通話を行っているユーザーの音声は他の参加者には聞こえません。 そのユーザーの着信音声はミュートされておらず、この動作はブラウザーに固有のものであることに注意してください。

通話中に音声が着信しない

Azure Communication Services で通話中のユーザーがリモート参加者の音声が聞こえない場合があります。 この問題の原因に関連する Chromium バグがあり、PeerConnection を再接続すると問題を軽減できます。 SDK 1.9.1 (安定版) と SDK 1.10.0 (ベータ版) 以降に、この回避策を追加しました。

Android Chrome では、ユーザーが Azure Communication Services 通話に複数回参加すると、着信音声も消える場合があります。 ユーザーは、ページが更新されるまで、他の参加者からの音声を聞くことができません。 SDK 1.10.1-beta.1 でこの問題を修正し、音声リソースの使用を改善しました。

一部の Android デバイスでは、グループ呼び出しを除き、シナリオの呼び出しに失敗します。

特定の Android デバイスの多くが、起動、通話を受ける、会議の参加に失敗します。 この問題が発生したデバイスは復旧できず、すべての試行で失敗します。 これらは主に Samsung のモデル A デバイスです。具体的には、A326U、A125U、A215U の各モデルが該当します。

• この回帰は、Chromium で発生した既知の問題です。

ブラウザーがバックグラウンドに 1 分間移動した後、Android Chrome によって通話がミュートされる

Android Chrome では、ユーザーが Azure Communication Services の通話中で、ブラウザーを 1 分間バックグラウンドにある状態した場合。 マイクにアクセスできなくなり、通話の他の参加者にはそのユーザーの音声が聞こえなくなります。 ユーザーがブラウザーをフォアグラウンドに戻すと、マイクが再び使用可能になります。 関連する Chromium のバグはこちらとこちらをご覧ください

モバイル (iOS および Android) ユーザーが通話を切断しても、参加者リストに引き続き表示される。

この問題は、モバイル ユーザーが Call.hangUp() API を使用せずに Azure Communication Services グループ通話を終了した場合に発生することがあります。 モバイル ユーザーが電話を切らずにブラウザーを閉じるか、Web ページを更新した場合、グループ通話の他の参加者には、このモバイル ユーザーが参加者リストに約 60 秒間引き続き表示されることがあります。

ユーザーが別のアプリに移動し、ブラウザーに戻った場合、iOS Safari によってページが更新される

この問題は、iOS Safari を使用した Azure Communication Services 通話のユーザーがしばらくの間、他のアプリに切り替えた場合に発生する可能性があります。 ユーザーがブラウザーに戻ると、ブラウザー ページが更新される場合があります。 これは、OS がブラウザーを強制終了するためです。 この問題を軽減する 1 つの方法は、いくつかの状態を保持し、ページの更新後に回復させることです。

グループ通話や Microsoft Teams 会議に参加する iOS 15.1 ユーザー。

• PSTN の着信を受信すると、通話または会議のタブがハングする場合があります。 関連する WebKit のバグはこちらとこちらをご覧ください。

iOS の Safari や Android の Chrome で一定の中断が発生するとローカル マイクまたはカメラがミュート状態になる

この問題は、別のアプリケーションまたはオペレーティング システムによってマイクまたはカメラの制御が引き継がれる場合に発生する可能性があります。 ユーザーが通話中に発生する可能性があるいくつかの例を次に示します。

• PSTN (公衆交換電話網) を介して着信通話があると、マイク デバイスへのアクセスがキャプチャされます。
• たとえば、ユーザーが YouTube 動画を再生するか、FaceTime 通話を開始します。 別のネイティブ アプリケーションに切り替えると、マイクまたはカメラへのアクセスがキャプチャされる可能性があります。
• ユーザーが Siri を有効にして、Siri がマイクへのアクセスを取得します。

たとえば iOS では、Azure Communication Services 通話中に PSTN 通話が着信すると、microphoneMutedUnexepectedly bad UFD が発生し、Azure Communication Services 通話の音声の流れが停止し、通話はミュート状態としてマークされます。 PSTN 通話が終了したら、ユーザーは Azure Communication Services 通話のミュートを解除して、Azure Communication Services 通話で音声が再び流れるようにする必要があります。 Android Chrome の場合、PSTN 通話が着信すると、Azure Communication Services 通話での音声の流れが停止し、Azure Communication Services 通話はミュート状態としてマークされません。 この場合、microphoneMutedUnexepectedly UFD イベントはありません。 PSTN 通話が終了すると、Android Chrome によって音声が自動的に再開され、Azure Communication Services 通話で音声が再び正常に流れ始めます。

カメラがオンの状態で中断が発生した場合、Azure Communication Services 通話でカメラが使用できない場合と使用できる場合があります。 カメラが失われた場合、カメラはオフとしてマークされます。カメラの中断が終了したら、ユーザーはカメラをオンに戻す必要があります。

場合によっては、マイクやカメラ デバイスが予定どおりに解放されず、これにより元の通話に問題が発生する可能性があります。 たとえば、YouTube 動画の視聴中にミュートを解除しようとする場合や、PSTN 通話が同時にアクティブな場合などです。

ユーザーが iOS 15.2 以降で SDK バージョン 1.4.1-beta.1 以降を使用している場合、受信ビデオ ストリームのレンダリングは停止しません。音声とビデオの送信を再開するには、ビデオのミュート解除と開始の手順が引き続き必要になります。

iOS 15.4 以降では、ほとんどの場合、オーディオとビデオを自動復旧できる必要があります。 一部のエッジ ケースでは、ミュートを解除するには、アプリケーションが "ミュート解除" する API を呼び出して (ユーザー アクションの結果として可能)、送信音声を復旧する必要があります。

ユーザーが前面カメラから背面カメラに切り替えようとすると、Safari を使用した iOS がクラッシュし、ページが更新される

Azure Communication Services Calling SDK バージョン 1.2.3-beta.1 が原因で、iOS Safari からのすべての通話に影響するバグが発生しました。 この問題は、ユーザーがカメラのビデオ ストリームを前面から背面に切り替えようとしたときに発生します。 カメラを切り替えると、Safari ブラウザーがクラッシュし、ページが再度読み込まれます。

この問題は、Azure Communication Services Calling SDK バージョン 1.3.1-beta.1 以降で解決されます

• iOS Safari バージョン: 15.1

macOS Ventura Safari (v16.3 以下) での画面共有

macOS Ventura Safari (v16.3 以下) では画面共有が機能しません。 Safari からの既知の問題であり、v16.4 以降で修正される予定です。

ページを更新してもユーザーが通話からすぐに削除されない

ユーザーが通話中にページを更新することにした場合、Communication Services メディア サービスはこのユーザーを通話から直ちに削除しません。 ユーザーが再び参加するのを待機します。 メディア サービスがタイムアウトになると、ユーザーは通話から削除されます。

エンド ユーザーが通話中にアプリケーションのページを更新する必要がないユーザー エクスペリエンスを構築することをお勧めします。 ユーザーがページを更新した場合、そのユーザーがアプリケーションに戻った後、Communication Services の同じユーザー ID を再使用します。 ユーザーは、同じユーザー ID で再度参加することにより、remoteParticipants コレクション内の同じ既存のオブジェクトとして表されます。 他の通話参加者から見ると、ユーザーは、ページの更新にかかる時間の間 (最大 1 分から 2 分)、通話中のままになります。

更新の前にユーザーがビデオを送信していた場合、サービスがタイムアウトになって以前のストリーム情報が削除されるまで、videoStreams コレクションにはこの情報が保持されます。 このシナリオの場合、アプリケーションでは、コレクションに追加された新しいストリームを確認し、id が最も高いものをレンダリングする場合があります。

Web 上の複数のデバイスから複数のプレビューをレンダリングできない

この問題は、既知の制限です。 詳細については、「通話 SDK の概要」を参照してください。

アプリケーションが iOS または iPadOS で実行されている場合、Safari でデバイスを列挙できない

Safari iOS または iPadOS では、アプリケーションでスピーカー デバイス (Bluetooth など) を列挙したり選択したりすることはできません。 この問題は、これらのオペレーティング システムの既知の制限事項です。

macOS で Safari を使用している場合、お使いのアプリで Communication Services デバイス マネージャーを通じてスピーカーを列挙または選択することはできません。 このシナリオでは、オペレーティング システムを介してデバイスを選択する必要があります。 macOS 上で Chrome を使用している場合、アプリでは Communication Services のデバイス マネージャーを通じてデバイスを列挙したり選択したりすることができます。

• iOS Safari バージョン: 15.1

ビデオ デバイスを繰り返し切り替えると、ビデオ ストリーミングが一時的に停止する場合がある

ビデオ デバイスを切り替えると、選択したデバイスからストリームが取得される間、ビデオ ストリームが一時停止する場合があります。 デバイス間の切り替えを頻繁を行うと、パフォーマンスが低下する場合があります。 開発者は、1 つのデバイス ストリームを停止してから別のストリームを開始することをお勧めします。

iOS 上の Safari で通話しているときに、Bluetooth のヘッドセットのマイクが検出されない、または音声が聞こえない

Bluetooth のヘッドセットは、iOS の Safari ではサポートされていません。 お使いの Bluetooth デバイスは利用可能なマイクのオプションに一覧表示されていないため、Safari で Bluetooth を使用しようとしても他の参加者にはお客様の声は聞こえません。

この回帰は、オペレーティング システムの既知の制限事項です。 macOS および iOS/iPadOS の Safari では、Communication Services デバイス マネージャーを使用してスピーカー デバイスを列挙または選択することはできません。 これは、Safari ではスピーカーの列挙または選択がサポートされていないためです。 このシナリオでは、オペレーティング システムを使用してデバイスの選択を更新します。

デバイスのローテーションによってビデオ品質が低下することがある

ユーザーがデバイスを回転させると、ストリーミング中のビデオの品質が低下する可能性があります。

この問題は、次の環境で発生します。

• 影響を受けるデバイス: Google Pixel 5、Google Pixel 3a、Apple iPad 8、Apple iPad X
• クライアント ライブラリ: 通話 (JavaScript)
• ブラウザー: Safari、Chrome
• オペレーティング システム: iOS、Android

カメラを切り替えると画面がフリーズする

Communication Services ユーザーが JavaScript 通話 SDK を使用して通話に参加し、カメラのスイッチ ボタンを押すと、UI が応答しなくなることがあります。 ユーザーは、アプリケーションを更新するか、ブラウザーをバックグラウンドにプッシュする必要があります。

この問題は、次の環境で発生します。

• 影響を受けるデバイス: Google Pixel 4a
• クライアント ライブラリ: 通話 (JavaScript)
• ブラウザー: Chrome
• オペレーティング システム: iOS、Android

通話が接続中状態のときのビデオ信号の問題

通話が "接続中" 状態のときにユーザーがビデオのオン/オフをすばやく切り替えると、このアクションによって通話用に取得されたストリームに問題が発生する可能性があります。 開発者は、通話が "接続中" 状態のときにビデオをオンまたはオフにする必要がないような方法でアプリを構築することをお勧めします。 次のシナリオでは、ビデオのパフォーマンスが低下する可能性があります。

• 通話が "接続中" 状態のときに、ユーザーが音声から開始し、ビデオを開始して停止した場合。
• 通話が "ロビー" 状態のときに、ユーザーが音声から開始し、ビデオを開始して停止した場合。

macOS および iOS 上の Safari でのデバイスの列挙またはアクセス

特定の環境では、デバイスのアクセス許可が一定期間後にリセットされる場合があります。 macOS および iOS の Safari では、ストリームが取得されない限り、アクセス許可は長期間保持されません。 この制限を回避する最も簡単な方法は、デバイス マネージャーのデバイス列挙 API を呼び出す前に DeviceManager.askDevicePermission() API を呼び出すことです。 これらの列挙 API としては、DeviceManager.getCameras()、DeviceManager.getSpeakers()、DeviceManager.getMicrophones() があります。 アクセス許可がある場合、ユーザーには何も表示されません。 アクセス許可がない場合、ユーザーには再度アクセス許可の入力を求めるメッセージが表示されます。

この問題は、次の環境で発生します。

• 影響を受けるデバイス: iPhone
• クライアント ライブラリ: 通話 (JavaScript)
• ブラウザー: Safari
• オペレーティング システム: iOS

リモート参加者のビデオをレンダリングで遅延が生じる

グループ通話の進行中に、"ユーザー A" がビデオを送信し、次に "ユーザー B" が通話に参加するとします。 場合によって、ユーザー B にユーザー A からのビデオが表示されなかったり、長い遅延後にユーザー A のビデオのレンダリングが開始されたりすることがあります。 ネットワーク環境の構成の問題によってこの遅延が発生する可能性があります。 詳細については、「ネットワークの推奨事項」を参照してください。

通話中にサード パーティのライブラリを使用すると、オーディオが失われる可能性がある

アプリケーション内で getUserMedia を個別に使用すると、オーディオ ストリームが失われる場合があります。 音声ストリームが失われるのは、Azure Communication Services ライブラリからデバイス アクセスがサード パーティ製のライブラリによって引き継がれるためです。

• 通話中に内部で getUserMedia API を使用しているサード パーティ製のライブラリを使用しないでください。
• それでもサード パーティのライブラリを使用する必要がある場合、音声ストリームを復旧させる唯一の方法は、選択したデバイスを変更するか (ユーザーが複数のデバイスを持っている場合)、通話を再度開始することです。

この問題は、次の環境で発生します。

• ブラウザー: Safari
• オペレーティング システム: iOS

この問題の原因として考えられるのは、同じデバイスから独自のストリームを取得すると、競合状態になるという副作用が発生することです。 他のデバイスからストリームを取得すると、ユーザーの USB または IO 帯域幅が不足し、sourceUnavailableError 率が急上昇する可能性があります。

ミュートやミュート解除などの特定の API を過度に使うと、Azure Communication Services インフラストラクチャでスロットリングが発生する

ミュートやミュート解除 API 呼び出しの結果、Azure Communication Services インフラストラクチャによって、ミュートやミュート解除を起動したローカル参加者の音声の状態が通話の他の参加者に通知され、通話の参加者がミュートやミュート解除されたユーザーを認識できるようになります。 Azure Communication Services インフラストラクチャでは、ミュートやミュート解除の過剰な使用がブロックされます。 スロットリングは、参加者 (または参加者に代わるアプリケーション) がミュートとミュート解除を継続的に (毎秒、30 秒のローリング ウィンドウで 15 回以上) 試みた場合に発生します。

Call Automation API

次の制限事項は、Communication Services Call Automation API の既知の問題です。

• サーバー アプリケーションで現在サポートされている認証は、接続文字列の使用のみです。

• 通話は、同じ Communication Services リソースのエンティティ間でのみ行う必要があります。 リソース間通信はブロックされます。

• Microsoft Teams のテナント ユーザーと Communication Services ユーザー間、またはサーバー アプリケーション エンティティ間の通話は許可されません。

• アプリケーションで 2 つ以上の PSTN ID にダイヤル アウトした後、通話を中止した場合、他の PSTN エンティティとの間の通話が切断されます。

次のセクションでは、Azure Communication Services Calling Native および Native UI SDK に関連する既知の問題について説明します。

Android API エミュレーター

Android 5.0 (API レベル 21) と Android 5.1 (API レベル 22) で Android API エミュレーターを使うと、いくつかのクラッシュが発生することが予想されます。

Android Trouter モジュールの競合

同じアプリケーションに Android Chat と Calling SDK が一緒にある場合、Chat SDK のリアルタイム通知機能は機能しません。 依存関係の解決の問題が発生することがあります。

Microsoft がこの問題の解決に向けて取り組んでいる間、アプリの build.gradle ファイルに次の依存関係情報を追加し、代わりに GetMessages API をポーリングして受信メッセージをユーザーに表示することで、リアルタイム通知機能を無効にできます。

Java

 implementation ("com.azure.android:azure-communication-chat:1.0.0") {
     exclude group: 'com.microsoft', module: 'trouter-client-android'
 }
 implementation 'com.azure.android:azure-communication-calling:1.0.0'

注: アプリケーションが chatAsyncClient.startRealtimeNotifications() や chatAsyncClient.addEventHandler() のような通知 API にアクセスしようとすると、ランタイム エラーが発生します。

iOS の進行中のピクチャ イン ピクチャ (PiP)

アプリがバックグラウンドに移動すると、受信ビデオが停止します。 アプリケーションがフォアグラウンドにある場合、ビデオは正しくレンダリングされます。

UI ライブラリ

GitHub リポジトリの既知の問題に関する Wiki ページに従うことができます。

• Android
• iOS