ベスト プラクティス: Azure Communication Services の通話 SDK
この記事では、Azure Communication Services の Calling SDK に関連するベスト プラクティスについて説明します。
Azure Communication Services Calling Web SDK のベスト プラクティス
このセクションでは、Azure Communication Services の音声およびビデオ通話用の Calling Web (JavaScript) SDK に関連するベスト プラクティスについて説明します。
通話中はマイクを接続するか、デバイス マネージャーからマイクを有効にする
Azure Communication Services 通話の開始時にはマイクが使用できず、その後マイクが使用可能になると、その変更によって noMicrophoneDevicesEnumerated 診断イベントが発生します。 このイベントが発生した場合、デバイスを列挙するためのユーザーの同意を得るために、アプリケーションで askDevicePermission を呼び出す必要があります。 その後、ユーザーはマイクをミュートまたはミュート解除できます。
VideoStreamRendererView を破棄する
Communication Services アプリケーションは、VideoStreamRendererView またはその親 VideoStreamRenderer インスタンスが不要になったら破棄する必要があります。
onbeforeunload イベントの発生時は通話を切る
アプリケーションは、onbeforeunload イベントが生成されたら call.hangup を呼び出す必要があります。
複数タブにおける複数の通話への対処
アプリケーションは、モバイル デバイス上の複数のブラウザー タブからの通話に同時に接続すべきではありません。 この状況では、デバイスのマイクとカメラのリソース割り当てにより、定義されていない動作が生じる可能性があります。 開発の際は、バックグラウンドで通話が完了したら、新しい通話を開始する前にその通話を必ず切ることを推奨します。
電話着信時の OS による通話ミュートを処理する
Azure Communication Services の通話中 (iOS と Android のどちらの場合も)、電話がかかってきたり、音声アシスタントが起動したりすると、OS によってユーザーのマイクとカメラが自動的にミュートにされます。 Android の場合、通話が終了すると、自動的にミュートが解除され、ビデオが再開されます。 iOS では、ビデオのミュートを解除して再開するには、ユーザーの操作が必要です。
microphoneMuteUnexpectedly の品質イベントを使用して、マイクが予期せずミュートされたという通知をリッスンできます。 通話を正しく再開するには、SDK 1.2.3-beta.1 以降を使用する必要があることに注意してください。
const latestMediaDiagnostic = call.api(SDK.Features.Diagnostics).media.getLatest();
const isIosSafari = (getOS() === OSName.ios) && (getPlatformName() === BrowserName.safari);
if (isIosSafari && latestMediaDiagnostic.microphoneMuteUnexpectedly && latestMediaDiagnostic.microphoneMuteUnexpectedly.value) {
// received a QualityEvent on iOS that the microphone was unexpectedly muted - notify user to unmute their microphone and to start their video stream
}
ビデオ ストリームを開始するには、アプリケーションで call.startVideo(localVideoStream); を呼び出す必要があります。また、オーディオのミュートを解除するには、this.currentCall.unmute(); を使用する必要があります。
デバイスの管理
Azure Communication Services SDK を使用して、デバイスとメディア操作を管理できます。
アプリケーションでは、getUserMedia や getDisplayMedia などのネイティブ ブラウザー API を使用して SDK の外部でストリームを取得すべきではありません。 その場合は、Communication Services SDK を介して DeviceManager または他のデバイス管理 API を使用する前に、メディア ストリームを手動で破棄する必要があります。
デバイスのアクセス許可を要求する
SDK を使用してデバイスのアクセス許可を要求できます。 アプリケーションでは、DeviceManager.askDevicePermission を使用して、オーディオ デバイスやビデオ デバイスへのアクセスを要求する必要があります。
ユーザーがアクセスを拒否した場合、ページが更新された後でも、DeviceManager.askDevicePermission は、後続の通話で特定のデバイスの種類 (オーディオまたはビデオ) に対して false を返します。 このシナリオでは、アプリケーションで以下を行う必要があります。
- ユーザーが以前にアクセスを拒否したことを検出する。
- 特定のデバイスの種類へのアクセスを手動でリセットするか、明示的に許可するようユーザーに指示する。
別のプロセスで使用されているカメラの動作を管理する
Windows Chrome と Windows Microsoft Edge の場合: ビデオをオンにして通話を開始、参加、承諾した際に別のプロセス (Web SDK が実行されているブラウザー以外) でカメラ デバイスが使用されている場合、通話は音声のみで開始され、ビデオは表示されません。 カメラの起動に失敗したため、
cameraStartFailedユーザー向け診断フラグが発生します。通話中にビデオをオンにした場合も、同様になります。 他のプロセスでカメラをオフにし、そのプロセスでカメラ デバイスを解放してから、通話のビデオを再度オンにします。 その後、通話のビデオがオンになり、リモート参加者にビデオが表示されるようになります。
macOS Chrome と macOS Safari では、OS によってプロセスやスレッドでカメラ デバイスを共有できるので、この問題は発生しません。
モバイル デバイスの場合: カメラ デバイスが ProcessB によって使用されている時に ProcessA によって使用が要求された場合、ProcessA による使用が優先されて、ProcessB によるカメラ デバイスの使用は停止します。
iOS Safari の場合: 同じタブ内またはタブをまたがる複数の通話クライアントでカメラをオンにすることはできません。 任意の呼び出しクライアントでカメラが使用されると、その前にカメラを使用していた呼び出しクライアントからカメラの使用が優先されます。 前の通話クライアントで、
cameraStoppedUnexpectedlyユーザー向け診断フラグが発生します。
画面共有を管理する
アプリケーションを終了しても共有は停止しない
たとえば、Chromium から Microsoft Teams アプリケーションを画面共有するとします。 その後、Teams アプリケーションの [X] ボタンを選択して閉じたとします。 この際、ウィンドウは閉じられていますが、Teams アプリケーションはバックグラウンドで実行され続けています。 アイコンは、デスクトップのタスク バーに表示されたままです。 Teams アプリケーションはまだ実行されているため、リモート参加者と画面共有されています。
アプリケーションの画面共有を停止するには、次のいずれかの操作を実行する必要があります。
- デスクトップのタスク バーでアプリケーションのアイコンを右クリックし、[終了] を選択します。
- ブラウザーで [共有停止] ボタンを選択します。
- SDK の
Call.stopScreenSharing()API 操作を呼び出します。
Safari では全画面表示の共有のみ可能
Safari では、全画面でのみ画面共有ができます。 この動作は、全画面表示、特定のデスクトップ アプリ、または特定のブラウザ タブを画面共有できる Chromium とは異なります。
macOS では画面共有アクセス許可を付与可能
macOS Safari または macOS Chrome で画面共有するには、OS メニューの [システム環境設定]>[セキュリティとプライバシー]>[画面収録] で、ブラウザーに必要な権限を付与します。
Azure Communication Services Calling Native SDK のベスト プラクティス
このセクションでは、Azure Communication Services の音声およびビデオ通話の Azure Communication Services Calling Native SDK に関連するベスト プラクティスについて説明します。
サポートされているプラットフォーム
Calling Native SDK の最適な機能を確保するための最小 OS プラットフォーム要件は次のとおりです。
アプリ要求に対するデバイスのアクセス許可を確認する
Calling Native SDK を通話の発信または受信に使用するには、プラットフォームがデバイス リソースにアクセスすることをコンシューマー側でプラットフォームごとに承認する必要があります。 開発者は、ユーザーにアクセスを求め、アクセス許可が有効になっていることを確認する必要があります。 これらのアクセス許可はコンシューマー側で承認するため、コンシューマーが現在必要なアクセス許可を持っていることを確認してください。
ログを構成する
ログ ファイルの取得に関するチュートリアルの説明にあるようにログ記録を実装することは、これまで以上に重要です。 詳細なログは、最小 SDK 条件を満たすデバイス モデルまたは OS バージョンに固有の問題を診断するのに役立ちます。 開発時には、Logs API を使用してログを構成することをお勧めします。 ログがなければ、Microsoft サポート チームは通話のデバッグとトラブルシューティングを支援できません。
CallID の追跡
CallID は通話の一意の ID です。 これは、1 回の通話中に接続するすべての参加者とエンドポイントからの相関イベントを識別します。 ほとんどの場合、これはログを確認するために使用します。 Microsoft サポート チームは、通話のトラブルシューティングを支援するために、この ID を要求します。
CallID 値は、アプリで構成するテレメトリで追跡する必要があります。 各プラットフォームの値を取得する方法を理解するには、トラブルシューティング ガイドのガイドラインに従ってください。
ユーザー向け診断とメディア品質の統計情報にサブスクライブする
次の Azure Communication Services 機能を使用して、ユーザー エクスペリエンスの向上に役立てることができます。
- ユーザー向け診断: 通話のプロパティを調べて、顧客に影響を与える問題の原因を特定します。
- メディア品質の統計情報: 受信と送信の通話メトリックについて、低次の音声、ビデオ、画面共有の品質メトリックを調べます。 データを収集し、通話の終了後にパイプライン インジェストに送ることをお勧めします。
エラー処理の管理
通話または実装中にエラーが発生する場合、メソッドはエラー コードを含むエラー オブジェクトを返します。 これらのエラー オブジェクトを適切なエラー処理に使用し、アラートを表示することが重要です。 通話状態では、通話エラーの背後にある理由を特定するのに役立つエラー コードも返されます。 問題を解決するには、トラブルシューティング ガイドを参照してください。
ビデオ ストリームを管理する
UI にビデオが表示されなくなった場合は、必ず VideoStreamRendererView を破棄してください。 VideoStreamType を使用して、ストリームの種類を判別します。
一般的なメモリ管理を行う
リソースを事前に割り当てましょう。 オンデマンドではなく、アプリの起動フェーズ中に、呼び出し元のクライアントと必要なリソースを初期化します。 この方法により、通話開始時の待機時間が短縮されます。
適切に破棄しましょう。 システム リソースを解放し、メモリ リークを回避するために、使用後はすべての呼び出しオブジェクトを破棄します。 メモリ リークの原因となる可能性がある "イベント" からは、必ずサブスクライブ解除してください。
プロセスがカメラまたはマイクにアクセスする方法を検討する
モバイル デバイスでは、複数のプロセスが同時にカメラまたはマイクにアクセスしようとすると、アクセスを要求する 1 番目のプロセスによってデバイスが制御されます。 その結果、2 番目のプロセスは即座にアクセスを失います。
ライブラリ のサイズを最適化する
ソフトウェア開発でライブラリのサイズを最適化することは、特にアプリケーションがますます複雑になり、リソースを大量に消費するようになるにつれて、以下の理由から非常に重要です。
アプリケーションのパフォーマンス: ライブラリを小さくすることで、アプリケーションが読み込み、解析、実行しなければならないコードの量を減らすことができます。 この削減により、特にリソースが限られているデバイスで、アプリケーションの起動時間と全体的なパフォーマンスが大幅に向上する可能性があります。
メモリ使用量: ライブラリのサイズを最小限に抑えることで、アプリケーションのランタイム メモリ占有領域を減らすことができます。 この削減は、メモリが制限されていることが多いモバイル デバイスにとって重要です。 メモリ使用量が少ないほど、システムのクラッシュが減り、マルチタスクのパフォーマンスが向上する可能性があります。
詳細については、以下を参照してください: