背景事情

iOSはすべてのアプリでマルチタスクをサポートしていますが、Vonage Video iOS SDKをさまざまなアプリの状態でうまく動作させるには、開発者がいくつかのステップを踏む必要があります。このドキュメントでは、ほとんどのVonage Videoアプリでうまく機能することが分かっている一連の方法を説明します。しかし、これはアップルのドキュメント特に、「アプリの状態遷移を処理するための戦略」、「バックグラウンド実行」、「VoIPアプリを開発するためのヒント」のセクションを参照してください。Appleは、ほとんどのVonage VideoアプリをVoIPアプリとはみなしていませんが、オーディオセッションの設定やソケットの設定に関する内容は、このドキュメントを理解する上で関連性があり、役に立ちます。

クイックスタート - アプリのアクセス許可を設定する

アプリがバックグラウンドでオーディオを録音し続けるようにするには、Xcodeでアプリのターゲットを選択し Signing & Capabilities タブをクリックします。次に、+ Capabilityボタンをクリックし、Background Modesケイパビリティをプロジェクトに追加します。次に Audio, Airplay, and Picture in Picture オプションで設定できます。この設定により、バックグラウンドでのオーディオ再生・録音中にアプリがサスペンド状態に移行するのを防ぐこともできます。

電話アプリのネイティブUIを使用して、着信時にアプリを起動させたり、保留イベントを通知したりする優先度の高いプッシュ通知が必要な場合は、以下を選択します。 Voice over IP XCodeの機能です。

Vonage Videoがバックグラウンドでできること（できないこと

SDKを使用して、アプリ缶バックグラウンドの状態で、以下のことを行う：

セッションをアクティブに保つ。
オーディオのみのセッションを持続する。
パブリッシャーと購読者にオーディオ/ビデオフラグを設定する。例えば OTPublisher.publishAudio プロパティ YES が許される。
カメラを取得しないカスタムビデオキャプチャ実装でパブリッシュする（たとえば、ファイルまたは合成されたビデオソースからパブリッシュする）。

アプリがアクティブ状態に戻り次第、カメラの使用を再開できます。

しかし、アプリ できない バックグラウンドの状態で次のことを行う：

カメラを出版社のビデオソースとして使用する。
ストリームからのビデオで新しいビューを設定します。
電話やFaceTimeの着信があっても、アクティブなオーディオセッションを維持します。
他のアプリがシステムオーディオリソースを取得するのを防ぎます。
アクティブなパブリッシャーやサブスクライバーのいないセッションへの接続を維持する。

バックグラウンドでアクティブなセッション

エンドユーザーがホームボタンを押したり、画面をロックしたり、別のプロセスでURLコンテンツを開いたりした結果だと思われる。このような場合 audio パーミッションは、オーディオセッションがアクティブな場合、バックグラウンドでアプリプロセスがサスペンドされないようにします。つまり、他のプロセスがオーディオリソースを要求しない限り、オーディオキャプチャとレンダリングをセッション内で継続することができます。

iOSが正しく設定されている場合、アプリがバックグラウンドでアクティブなオーディオセッションを実行していることを示すインジケータが表示されます。これは、ステータスバーの背景が赤くなり、アクティブなオーディオセッションを保持しているアプリの名前（この場合はあなたのアプリ）を示す追加のバーが表示されます。

について Voice over IP 機能は、アプリケーション・サーバーとの長期間のシグナリング接続を維持するためのものである。

を選択した場合 Voice over IP XCodeのCapabilitiesセクションのオプションで、アプリはその機能を正当化する機能を実装する必要があります。このケイパビリティは、オーディオまたはビデオ通信に関連しないその他の理由でアプリをバックグラウンドで実行し続けるために使用すべきではありません。

アプリケーションのイベント通知を受ける必要がある場合は、次のようにすることをお勧めします。 Appleプッシュ通知を使用してアプリを起動し、ワークフローを実行します。アプリが着信コールを実装している場合は VoIPプッシュ通知.

コントロールを失う

電話やFaceTimeの着信は、アプリケーションを完全に中断させる最初のイベントです。このような場合、アクティブなオーディオセッションの有無に関わらず、アプリは中断されます。

オーディオセッションが他のプロセスに移ったためにアプリが中断された場合、これを処理するための追加ロジックは必要ありません。アプリが長時間サスペンドされた場合、セッションへの接続は終了します。セッションに接続している他のクライアントは connectionDestroyed イベントが発生し、アプリが中断されなくなると、最終的なクリーンアップが必要になります。コントローラがセッションのエラーと切断のデリゲートイベントを処理する限り、これは自発的な切断ワークフローと変わりません。切断のクリーンアップが処理されると、クライアントは再接続できる。