セッション

セッションに接続するには、セッションIDを使って接続したいセッションを指定する必要がある。

各セッションIDは、一意のセッションを識別します。セッションは、参加者が集まってチャットをする部屋のようなものだと考えることができます。

作成するセッションの数やクライアントがセッションに接続する方法は、アプリの要件によって異なります。

もし、あなたのアプリがユーザー同士を1回きりのミーティングのためにつなぐのであれば、そのミーティング用にユニークなセッションを作成しましょう。

しかし、もしあなたのアプリが、同じ「部屋」で何日もユーザーをつなげるのであれば、1つのセッションを作成し、それを再利用することができます。あるグループのユーザー同士が集まり、他のグループは独立して集まる場合は、グループごとに固有のセッションを作成します。

セッションには有効期限はありません。ただし、認証トークンには有効期限があります。トークンの最大TTLは 24時間. トークンの生成や長時間継続するセッションの処理に関する詳細については、以下を参照してください。 トークンの作成. また、セッションは明示的に破棄することはできない点にも注意してください。

セッションを作成する際、以下のオプションを指定することができます：

• メディアモード（メディアルーターを使用するかどうか）。
• アーカイブの優先順位（セッションを自動的にアーカイブするかどうか）。
• ロケーションヒント（セッションのジオロケーションを指定する）。

メディア・ルーターとメディア・モード

セッションを作成するときに、セッション内のクライアントがどのようにオーディオビデオストリームを送信するかを指定します（メディアモードとして知られています）。オプションは2つあります：

• 中継 - 中継セッションにおいて、クライアントはオーディオ-ビデオストリームを互いの間で直接送信しようとします（ピアツーピア）。しかし、ファイアウォールの制限によりクライアントが接続できない場合、セッションはTURNサーバーを使用してオーディオビデオストリームを中継します。(バージョン2.2以前では、サーバーSDKはこれらのセッションをピアツーピアセッションと呼んでいました。ただし、これらのSDKを使用している場合でも、ファイアウォールの制限によりピアツーピア・ストリーミングがブロックされている場合、セッションはストリームを中継するためにTURNサーバーを使用します）。セッションネゴシエーションには、TLS 1.3と少なくとも3072ビットの強力な証明書が使用される。

• ルーティング - セッションはメディアルーターを使用して、クライアント間でオーディオビデオストリームをルーティングします。メディア・ルーターには次のような利点がある：

  • TLS 1.3と少なくとも3072ビットの強力な証明書がすべてのシグナリングに使用される。

  • メディアルーターは、マルチパーティセッションの帯域幅使用量を減らすことができる。(メディアモードプロパティが relayedに設定されている場合、ストリームを公開する各クライアントは、そのストリームをサブスクライブする各クライアントに個別に送信する必要がある。メディアルーターでは、パブリッシャーは1つのストリームをルーターに1度送信し、ルーターはそれを各サブスクライブクライアントに転送する)。

  • メディア・ルーターは、オーディオ・フォールバックとビデオ・リカバリによって、ユーザー・エクスペリエンスの質を向上させることができます。これらの機能により、あるクライアントの接続性が低下し、サブスクライブしているストリームのビデオをサポートできなくなった場合、そのクライアントのビデオは（他のクライアントに影響を与えることなく）ドロップされ、クライアントはオーディオのみを受信します。クライアントの接続性が改善されれば、ビデオは戻ります。

  • メディアルーターはアーカイブ機能をサポートしており、セッションを記録、保存、検索することができます。

  • メディアルーターを使用するセッションでは、公開ビデオのフレームレートを下げると、それに比例してストリームが使用する帯域幅が減少します。

  • メディアルーターはスケーラブル・ビデオ機能をサポートしています。スケーラブルビデオは、マルチパーティセッションのビデオ品質を大幅に向上させます。

  • iOSおよびAndroid SDKを使用するクライアントの場合、中継セッションはセッションに接続する2つのクライアントのみをサポートします。メディア・ルーターは、モバイル・デバイスのマルチパーティ・セッション用に追加のクライアントをサポートします。

  • メディアルーターは、SIPゲートウェイにセッションを接続できるSIP相互接続機能をサポートしています。

• シングルピア接続。 iOS、Android、Windows、macOS、Linux用クライアントSDKのバージョン2.28.0から、ルーティングされたセッションは以下をサポートします。 シングルピア接続.シングルピア接続を有効にすると、クライアントのすべてのサブスクライバーストリームが、メディアルーターへの単一の接続で配信されます（それらが異なるクライアントによって公開されている場合でも）。シングルピア接続を有効にする利点には、クライアントのリソース消費の削減、レート制御の改善、およびモバイルネイティブデバイスの場合、大規模なセッションのサポートなどがあります。シングルピア接続が無効（デフォルト）の場合、クライアントはオーディオ/ビデオバンドルごとにメディアルーターへの個別の接続を使用します。

  シングルピア接続は、ルーティングされたセッション（Vonage Video API メディアルータを使用するセッション）でのみ使用できます。使用例、設定の詳細、コードサンプル、および他の機能との相互作用を含む完全なガイドについては シングルピア接続開発者ガイド.

  シングルピア接続を有効にするには、以下の Client SDK API を使用します：

  • Web SDK singlePeerConnection に渡すオプションの OT.initSession()
  • アンドロイドSDK Session.Builder.setSinglePeerConnection()
  • iOS SDK OTSessionSettings.singlePeerConnection
  • Linux SDK otc_session_settings_set_single_peer_connection()
  • macOS SDK otc_session_settings_set_single_peer_connection()
  • Windows SDK SinglePeerConnection プロパティの Session.Builder クラス
  • リアクト・ネイティブSDK enableSinglePeerConnection プロパティの options OTSessionコンポーネントのプロップ

• メディアメッシュの最適化： このプラットフォームは、メディア・メッシュを使用して、各参加者を最寄りの地域データセンターのメディア・ルーターに接続することで、ルーティングされたセッションを自動的に最適化します。 これにより、遅延が短縮され、品質が向上します。これにより、待ち時間が短縮され、品質が向上します、 特に地理的に分散したセッションの場合

  メディアメッシュはデフォルトで有効になっており、設定の必要はない。この最適化を無効にし、メディアを を参照してください。 地域メディアゾーン.

アダプティブ・メディア・ルーティング

アダプティブ・メディア・ルーティング（AMR）は、以下のようなパフォーマンスの最適化である。 ルーティングセッション.AMRは各パブリッシャーの加入者数を個別に評価する。パブリッシャーに加入者が1人しかおらず、メディアルーターを必要とする機能（アーカイブ、ライブストリーミング、SIPなど）が使用されていない場合、プラットフォームはそのパブリッシャーのメディアをメディアルーター経由でルーティングする代わりに、加入者にピアツーピアでリレーします。これにより、待ち時間が短縮され、オーディオとビデオの品質が向上します。

セッションは常にルーティングされたセッションのままである。 AMRはセッションのメディアモードを変更しない。 メディアパス を使用します。アプリケーション・コード、トークン、サーバー側のセッション構成はまったく同じです。ピアツーピア中継とメディア・ルーター中継の切り替えは、クライアントSDKによって透過的に処理されます。

AMRがピアツーピア中継を使用する場合

AMRは、次のような場合、パブリッシャーとその加入者間でメディアを直接リレーする（メディアパスでメディアルーターをバイパスする）。 すべて 次のうちどれかが当てはまる：

• 出版社はまさに 一加入者.
• 次のセクションに記載されている機能はいずれもアクティブではない。

例えば、4つのパブリッシャーと4つのサブスクライバーを持つセッションは、各 パブリッシャーにサブスクライバーが1人しかおらず、メディアルーター機能が使 用されていない限り、完全にピアツーピア中継のままであることができる。

AMRがメディア・ルーターに切り替わるとき

プラットフォームは、以下の場合にパブリッシャーのメディアをメディアルーターを経由するように移行します。 いずれも 以下の条件のいずれかが適用される：

• 出版社は 複数の加入者 (たとえば、2番目のクライアントが同じ公開ストリームを購読する)。
• アーカイブ が開始される（自動アーカイブが有効になっているセッションを含む）。
• ライブストリーミング放送 が始まる。
• SIP相互接続 が使われている。
• エクスペリエンス・コンポーザー がセッションをレンダリングしている。
• オーディオ・コネクター がアクティブである。
• ライブ・キャプション が有効になっている。

いずれかのトリガーがアクティブになると、すべてのパブリッシャーのメディアはメディアルーターを通じてシームレスにルーティングされます。

SDKサポート

AMRが導入されたのは OpenTok.js v2.24.7 そして バージョン2.27.0 Android、iOS、Windows、macOS、Linux、およびReact NativeクライアントSDKの。ルーティングされたセッションの古いSDKバージョンのクライアントは、常にメディア・ルーターを使用します。

デバッグと開発への影響

AMRはアプリケーション・ロジックに対して透過的ですが、開発やトラブルシューティングの際に注意すべき点がいくつかあります：

• インスペクター 誤って表示される可能性がある clientDisconnection イベント パブリッシャーのメディアがピアツーピアの中継からメディアルーターに移行 するとき(例えば、2番目のクライアントがストリームを購読するとき)。これらのイベントは実際の切断を表すものではなく、移行中も参加者は接続されたままです。これは、Inspectorの既知の問題です。

• MediaStreamオブジェクトは、トランジション中に変更される可能性がある。 AMRがピア・ツー・ピア・リレーとメディア・ルーターの間で切り替わるとき、基礎となる MediaStream を置き換えます。アプリケーションから MediaStream オブジェクトを直接レンダリングします。 <video> 要素)を変更する場合は、以下のいずれかでこの変更を処理しなければならない：

  • おすすめだ： を使用する。 メディアストリーム利用可能API (OpenTok.js v2.27.7+ で利用可能)。その mediaStreamAvailable パブリッシャーおよびサブスクライバー・オブジェクトのイベントは、AMRによって引き起こされた変更を自動的にアカウントし、正しい MediaStream トランジションが起こるたびに。

  • レガシーアプローチ（v2.27.7以前）： を聴く。 play イベントがサブスクライバのvideoエレメントに発生したことを検出する。 MediaStream を置き換え、それに応じてカスタムレンダリングを更新してください。カスタムレンダリングを更新するには サブスクライバのMediaStreamオブジェクトへのアクセス を案内する。

• 接続とストリームのイベントは通常通り発生する。 セッションイベントリスナーでAMRのトランジションを処理する必要はありません。セッションの streamCreated, streamDestroyed, connectionCreatedそして connectionDestroyed イベントは参加者の実際の状態を反映するものであり、根本的なメディア経路を反映するものではない。

他の機能との相互作用

• シングルピア接続（SPC）: SPCは、メディアがメディアルーターを流れるときのみ有効である。AMRがパブリッシャーのメディアをピアツーピアで中継している間は、SPCはそのストリームには適用されない。ストリームがメディア・ルーターに移行すると、SPCが有効になっていれば、SPCが有効になる。

• エンド・ツー・エンドの暗号化: エンドツーエンドの暗号化は AMR で機能します。メディアはピアツーピアでもメディアルーター経由でも暗号化されます。

• オーディオのフォールバック： 加入者音声フォールバック はメディア・ルーターの機能であり、ストリームがメディア・ルーター を経由すると、通常は適用される。ただし、AMRがパブリッシャーのメディアをピア・ツー・ピアで中継している間は、この機能は適用されない、 パブリッシャー・オーディオのフォールバック は、必要に応じて、オーディオストリームを保護するためにビデオを自動的に無効にする。ストリームがメディア・ルーターに移行すると、パブリッシャーとサブスクライバーの両方の音声フォールバックが通常通り適用されます。

• サイマルキャストとスケーラビリティ: AMR がメディアをピアツーピアで中継している間は、使用中のコーデックに関係なく、スケーラブル・ビ デオは自動的に無効になります。ストリームがメディア・ルーターに遷移すると、スケーラブル・ビデオの動作は、コーデックとダッシュボードのアプリケーションのスケーラブル・ビデオ設定に依存します：

  • VP8である： スケーラブル・ビデオが オン または オート ダッシュボードに表示されるサイマルキャストは、メディア・ルーターへの移行が発生すると、ルーティングされたレグで自動的に有効になります。
  • VP9： スケーラブルビデオは、メディアルーターを経由する場合、デフォルトで有効になります。
  • H.264: スケーラブルビデオはサポートされておらず、デフォルトではすべてのケースでオフのままです。

  スケーラブルなビデオ設定とコーデックサポートの詳細については スケーラブルなビデオガイド.

アーカイブ・モード

セッションを作成するときに、アーカイブモードを設定して、セッションが自動的にアーカイブされるようにすることができます。

これは、ルーティングされたセッション（メディアルーターを使用するセッション）にのみ適用されます。

デフォルトでは、セッションは自動的にアーカイブされません。

場所のヒント

セッションを作成する際、Vonageビデオプラットフォームがグローバルネットワーク内でセッションを制御する最適なサーバーを選択するために使用するIPアドレスを設定することができます。

セッションの作成時にロケーションヒントが設定されていない場合（これを推奨）、セッションに最初に接続したクライアントのロケーションに基づいて、セッションコントロールサーバーが選択される。

一般的な地理的地域（および代表的なIPアドレス）を知っていて、最初に接続するクライアントがその地域にいないと思われる場合にのみ、ロケーションヒントを設定します。

セッションの地理的位置を代表するIPアドレスを指定する。

メディアストリーミングの場合、システムは常にロケーションヒントを使用して最も近いメディアサーバー（SFU）に接続し、メディアトラフィックがクライアントの地理的ロケーションに最適なサーバーを経由するようにします。

セッション作成時のベストプラクティス

セッションIDの再利用

可能な限り、異なるビデオチャットの会話間でセッションIDを再利用しないでください。

その代わりに、アプリケーション上で個別のビデオチャットごとに新しいセッション ID を生成してください。

これは、特に セッション検査官.

Inspectorでは、セッションIDによってセッションの品質スコアとデータがインデックス化される。

複数の会話で再使用されるセッションIDは、Inspectorを使用してデバッグするのがより困難であり、再使用されるセッションIDを持つセッションは、実際に体験される通話品質よりも低い集約品質スコアを報告する傾向がある。

セッションの移行を有効にするか、セッションを8時間に制限する

最新のクラウド自動スケーリングでは、サービスの最小回転時間を設定する必要がある。8時間以上続くセッションは、スケールアウトまたはスケールインするサービスに存在する可能性があるため、切断される可能性がある。

Vonage Video APIクライアントSDKのバージョン2.30.0以降には、サーバのローテーション中にセッションの参加者全員を新しいサーバにシームレスに転送するセッション移行機能が含まれています。この機能により、参加者の混乱を最小限に抑え、セッションの継続性が保証されます。参照 サーバーのローテーションとセッションの移行.

また、クライアントは、接続後4時間以内にストリームを公開または購読しない場合、セッションから切断される。

を使うことができる。 セッションモニタリング を使用して、セッションが停止したりタイムアウトしたりしたときや、セッション用の Video API サーバー群のローテーションが予定されているときに通知を受け取ることができます。

詳しくは サーバーのローテーション.

中継セッション・タイプとルーティング・セッション・タイプの選択

参加者が2人(あるいは3人)しかおらず、アーカイブを使用しない場合は、ルーティングされたセッションの代わりにリレーされたセッションを使用してください。

中継セッションを使用することで、参加者間のレイテンシーが減少し、障害ポイントが減少し、ほとんどの場合、より高品質のビデオとオーディオを得ることができます。

セッションをアーカイブしたい場合は、ルーティングされたセッションが必要です。

セッションに2、3人以上の参加者がいる場合にお勧めします。

詳しくは メディア・ルーターとメディア・モード.

セッションの作成

アプリのテストバージョンで作業している間に、テストセッションIDを 建設と管理 > Applications あなたの Vonageアカウント.

クレデンシャルはダッシュボードでも確認できます。 スタート のガイドを参照されたい。

独自の実装については サーバーサイドSDK.

複数のセッションIDを動的に生成する必要がある場合は サーバーサイドSDK プロジェクトページではありません。

セッションIDを Client SDK をクリックしてビデオセッションに接続します。

また、次のことも必要です。 トークンを生成する セッションに接続している各ユーザーの

について メディア・ルーター には次のようなメリットがある：

• メディアルーターは、マルチパーティセッションの帯域幅使用量を減らすことができる。(mediaModeプロパティが リレー各クライアントは、サブスクライブしている各クライアントに個別のオーディオ・ビデオストリームを送信しなければならない)。
• メディア・ルーターは、以下を通じてユーザー・エクスペリエンスの質を向上させることができる。 オーディオのフォールバックとビデオのリカバリー.これらの機能により、あるクライアントの接続性が低下して、そのクライアントが契約しているストリームのビデオをサポートできなくなった場合、そのクライアントのビデオは（他のクライアントに影響を与えることなく）停止され、そのクライアントはオーディオのみを受信します。クライアントの接続性が改善されると、ビデオストリームが復元されます。
• メディアルーターは アーカイブ機能セッションの記録、保存、検索ができます。

中継セッションの作成

中継セッションにおいて、クライアントは互いにストリームを直接送信し ようとする。

しかし、ファイアウォールの制限によりクライアントが接続できない場合、セッションはTURNサーバーを使用してオーディオビデオストリームを中継する。

フォローする ステップ・バイ・ステップ チュートリアルで中継セッションの生成方法を学ぶ

自動録画セッションの作成

自動的にアーカイブされるセッションを作成できます。

詳細は アーカイブ を案内する。

クライアントアプリケーションでセッションを使用する

のセッションIDを使用します。 Client SDK でセッションに接続する。

また、次のことも必要です。 トークンを生成する セッションに接続している各ユーザーの