ベスト プラクティス: Azure Communication Services の通話 SDK
この記事では、Azure Communication Services の Calling SDK に関連するベスト プラクティスについて説明します。
Azure Communication Services Web JavaScript SDK のベスト プラクティス
このセクションでは、Azure Communication Services の JavaScript 音声およびビデオ通話 SDK に関連するベスト プラクティスについて説明します。
JavaScript 音声およびビデオ通話 SDK
Azure Communication Services 通話の進行中にマイクを接続するかマイクをデバイス マネージャーから有効にする
通話の開始時に使用可能なマイクがなく、その後マイクが使用可能になった場合、"noMicrophoneDevicesEnumerated" 通話診断イベントが発生します。
この場合、アプリケーションは askDevicePermission を呼び出して、デバイスを列挙することについてユーザーの同意を取得する必要があります。 その後、ユーザーはマイクをミュートまたはミュート解除できるようになります。
ビデオ ストリーム レンダラー ビューを破棄する
Communication Services アプリケーションは、VideoStreamRendererView またはその親 VideoStreamRenderer インスタンスが不要になったら破棄する必要があります。
onbeforeunload イベントで通話を切る
アプリケーションは、onbeforeunload イベントが生成されたら call.hangup を呼び出す必要があります。
モバイルにおける複数タブでの複数の呼び出しへの対処
アプリケーションは、複数のブラウザー タブからの呼び出しに同時に接続することはできません。これが行われると、デバイス上のマイクとカメラのリソース割り当てに起因する未定義の動作が発生する可能性があるためです。 開発者は、新しい通話を開始する前に、バックグラウンドで完了した通話を必ず切るようにしてください。
電話がかかってきたときに OS の通話ミュートを処理する。
(iOS と Android のどちらの場合も) Azure Communication Services の通話中に、電話がかかってきた場合、または音声アシスタントがアクティブになっている場合は、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 UFD が発生します。 通話中にビデオをオンにした場合も同様です。 他のプロセスでカメラをオフにし、そのプロセスでカメラ デバイスが解放された後、通話からビデオをもう一度開始すると、通話に対してビデオがオンにされ、リモート参加者にビデオが表示されます。
- macOS Chrome と macOS Safari では、プロセスやスレッドでカメラ デバイスを共有できるので、これは問題ではありません。
- モバイル デバイスでは、ProcessA によってカメラ デバイスが要求され、それが ProcessB で使用されている場合、ProcessA によるカメラ デバイスの使用が優先されて、ProcessB によるカメラ デバイスの使用は停止します
- iOS Safari では、同じタブ内またはタブ間で複数の呼び出しクライアントのカメラをオンにすることはできません。 任意の呼び出しクライアントでカメラが使用されると、その前にカメラを使用していた呼び出しクライアントからカメラの使用が優先されます。 以前の呼び出しクライアントは、cameraStoppedUnexpectedly UFD を取得します。
画面共有
アプリケーションを終了しても共有が停止しない
たとえば、Chromium から Microsoft Teams アプリケーションを画面共有するとします。 次に、Teams アプリケーションの [X] ボタンを選択して閉じます。 Teams アプリケーションは、閉じることなく、バックグラウンドで引き続き実行されます。 デスクトップ バーの右下には、アイコンが表示されたままです。 Teams アプリケーションは引き続き実行されているため、まだ画面共有中であり、通話のリモート参加者は Teams アプリケーションが画面共有されていることを引き続き把握できることを意味します。 アプリケーションが画面共有されないようにするには、デスクトップ バーのアイコンを右クリックし、[終了] をクリックする必要があります。 または、ブラウザーの [共有を停止する] ボタンをクリックする必要があります。 または、SDK の Call.stopScreenSharing() API を呼び出します。
Safari では全画面表示の共有のみが可能
Safari を使用すると、画面全体の共有のみ行うことができます。 Chromium とは異なり、全画面表示、特定のデスクトップ アプリ、または特定のブラウザー タブを画面共有できます。
macOS での画面共有のアクセス許可
macOS Safari または macOS Chrome で画面共有を行うには、ブラウザーに画面記録のアクセス許可を付与する必要があります。OS メニューで、[システム環境設定] -> [セキュリティとプライバシー] -> [画面記録] の順に移動します。
Azure Communication Services ネイティブ SDK のベスト プラクティス
このセクションでは、Azure Communication Services の音声およびビデオの Calling Native SDK に関連するベスト プラクティスについて説明します。
サポートされているプラットフォーム
Calling Native SDK の最適な機能を確保するための最小 OS プラットフォーム要件を次に示します。
アプリのデバイス アクセス許可の要求
Calling Native SDK を通話の発信または受信に使用するには、各プラットフォームがデバイス リソースにアクセスすることを承認する必要があります。 開発者は、ユーザーにアクセスを求め、有効になっていることを確認する必要があります。 コンシューマーはこれらのアクセス権を承認するので、以前にアクセス許可が付与されていることを確認してください。
- マイクへのアクセスの場合は
NSMicrophoneUsageDescription。 - カメラへのアクセスの場合は
NSCameraUsageDescription。
ログを構成する
ログ ファイルの取得に関するチュートリアルに従ってログ記録を実装することが、これまでよりも重要になります。 詳細なログは、最小 SDK 条件を満たすデバイス モデルまたは OS バージョンに固有の問題の診断に役立ちます。 開発者はログなしで Logs API の構成を開始することをお勧めします。Microsoft サポート チームは通話のデバッグとトラブルシューティングを支援することはできません。
通話 ID を追跡する
CallID は通話の一意の ID です。 これは、1 回の通話中に接続するすべての参加者とエンドポイントから相関イベントを識別します。ほとんどの場合、それを使用してログを確認し、Microsoft サポート チームは通話のトラブルシューティングに役立てるために要求します。 アプリで構成するテレメトリで CallID を追跡する必要があります。トラブルシューティング ガイドのガイドラインに従って、プラットフォームごとに取得する方法を理解できます。
UFD (User Facing Diagnostics) とメディア品質の統計にサブスクライブする
- 通話のさまざまなプロパティを調べて、顧客に影響を与える通話時の問題を探るのに使用できる User Facing Diagnostics (UFD)。
- メディア品質の統計では、低次のオーディオ、ビデオ、画面共有の品質メトリックを調べ、通話の受信と送信のメトリックを取得します。 データを収集し、通話の終了後にパイプライン インジェストに送ることをお勧めします。
エラー処理
通話または実装中にエラーがある場合、メソッドはエラー コードを含むエラー オブジェクトを返します。 これらのエラー オブジェクトを適切なエラー処理に使用し、アラートを表示することが重要です。 通話状態では、呼び出しエラーの背後にある理由を特定するのに役立つエラー コードも返されます。 問題を解決するには、トラブルシューティング ガイドを参照できます。
ビデオ ストリームの管理
ビデオが UI に表示されなくなった場合は、必ず VideoStreamRendererView を破棄してください。 VideoStreamType を使用して、ストリームの種類を判別します。
一般的なメモリの管理
リソースを事前に割り当てます。 オンデマンドではなく、アプリの起動フェーズ中に、呼び出し元のクライアントと必要なリソースを初期化します。 この方法では、通話を開始するときの待機時間が短縮されます。
適切に破棄します。 システム リソースを解放し、メモリ リークを回避するために、使用後にすべての通話オブジェクトが正しく破棄されていることを確認します。 メモリ リークを防ぐイベントのサブスクライブを解除してください。
カメラまたはマイクが別のプロセスで使用されている
モバイル デバイスでは、複数のプロセスが同時にカメラまたはマイクにアクセスしようとすると、アクセスを要求する最初のプロセスによってデバイスが制御されることに注意してください。 その結果、2 番目のプロセスはすぐにアクセスできなくなります。
UI ライブラリを使用して APP サイズを最適化する
特にアプリケーションがますます複雑になり、リソースを大量に消費するため、ソフトウェア開発でライブラリのサイズを最適化することが、いくつかの理由で非常に重要です。
アプリケーションのパフォーマンス: ライブラリが小さくなると、アプリケーションによる読み込み、解析、実行が必要なコードの量が減ります。 これにより、特にリソースが限られているデバイスで、アプリケーションの起動時間と全体的なパフォーマンスが大幅に向上する可能性があります。
メモリ使用量: ライブラリ サイズを最小限に抑えることで、アプリケーションのランタイム メモリ占有領域を減らすことができます。 これは、メモリが制約されることが多いモバイル デバイスにとって重要です。 メモリ使用量が少ないほど、システムのクラッシュが減り、マルチタスクのパフォーマンスが向上する可能性があります。
次のステップ
詳細については、次の記事を参照してください。