Aperçu de la création d'une session

Lorsque vous vous connectez à une session OpenTok depuis une application, vous indiquez la session à laquelle vous souhaitez vous connecter à l'aide d'un identifiant de session OpenTok. Chaque identifiant de session identifie une session OpenTok unique. Vous pouvez considérer une session comme une salle dans laquelle les participants se retrouvent et discutent.

Le nombre de sessions que vous créez et la manière dont les clients s'y connectent dépendent des besoins de votre application. Si votre application met en relation des utilisateurs pour une réunion ponctuelle, créez une session unique pour cette réunion. En revanche, si votre application met en relation des utilisateurs pendant plusieurs jours dans la même « salle », vous pouvez créer une seule session et la réutiliser. Si un groupe d'utilisateurs se réunit entre eux tandis que d'autres groupes se réunissent indépendamment, créez des sessions uniques pour chaque groupe.

Les sessions OpenTok n'ont pas de date d'expiration. En revanche, les jetons d'authentification ont une durée de validité limitée. Notez également qu'il n'est pas possible de mettre fin explicitement à une session.

Lorsque vous créez une session, vous pouvez spécifier les options suivantes, qui sont décrites dans les sections suivantes :

  • Le mode multimédia (utilisation ou non du routeur multimédia OpenTok)
  • Le paramètre d'archivage (qui permet de choisir d'archiver automatiquement la session)
  • Une indication de localisation (pour préciser la géolocalisation de la session)

Le routeur multimédia OpenTok et les modes multimédias

Lorsque vous créez une session, vous définissez la manière dont les clients participant à cette session enverront leurs flux audio-vidéo, appelés mode média. Il existe deux options :

  • Relayé — Dans une session relayée, les clients tentent d’échanger des flux audio-vidéo directement entre eux (peer-to-peer). Toutefois, si les clients ne parviennent pas à se connecter en raison de restrictions de pare-feu, la session utilise le serveur TURN d’OpenTok pour relayer les flux audio-vidéo. (Avant la version 2.2, les SDK du serveur OpenTok désignaient ces sessions comme des sessions peer-to-peer. Cependant, même en utilisant ces SDK, les sessions continueront d’utiliser le serveur TURN d’OpenTok pour relayer les flux si des restrictions de pare-feu bloquent la diffusion peer-to-peer). Le protocole TLS 1.3 et un certificat sécurisé d’au moins 3 072 bits sont utilisés pour la négociation de session.

  • Acheminé — La session utilise OpenTok Media Router pour acheminer les flux audio-vidéo entre les clients. Le Routeur multimédia OpenTok offre les avantages suivants :

    • Le protocole TLS 1.3 et un certificat sécurisé d'au moins 3 072 bits sont utilisés pour la négociation de session.

    • Le routeur multimédia OpenTok permet de réduire la consommation de bande passante lors des sessions multipartites. (Lorsque la propriété « media mode » est définie sur « relayed », chaque client publiant un flux doit l'envoyer séparément à chaque client qui s'y abonne. Avec le routeur multimédia OpenTok, un éditeur envoie un seul flux une seule fois au routeur, qui le transmet ensuite à chaque client abonné.)

    • Le routeur multimédia OpenTok permet d'améliorer la qualité de l'expérience utilisateur grâce à solution de secours audio et récupération vidéo pour les abonnés. Grâce à ces fonctionnalités, si la connexion d'un client se détériore au point de ne plus permettre la lecture de la vidéo d'un flux auquel il est abonné, la vidéo est interrompue pour ce client (sans affecter les autres clients), et celui-ci ne reçoit alors que le son. Si la connexion du client s'améliore, la vidéo reprend.

    • Le routeur multimédia OpenTok prend en charge le Fonctionnalité d'archivage d'OpenTok, qui vous permet d'enregistrer, de sauvegarder et de consulter des sessions OpenTok.

    • Le routeur multimédia OpenTok prend en charge diffusions en direct.

    • Le routeur multimédia OpenTok prend en charge Compositeur d'expérience.

    • Dans les sessions utilisant OpenTok Media Router, la réduction de la fréquence d'images d'une vidéo publiée entraîne une réduction proportionnelle de la bande passante utilisée par le flux.

    • Le routeur multimédia OpenTok prend en charge le fonctionnalité vidéo adaptative. La vidéo adaptative peut considérablement améliorer la qualité vidéo lors de sessions à plusieurs participants.

    • Dans les clients utilisant les SDK OpenTok pour iOS et Android, les sessions relayées ne prennent en charge que deux clients connectés à la session. Le routeur multimédia OpenTok prend en charge des clients supplémentaires pour les sessions multipartites sur les appareils mobiles.

    • Le routeur multimédia OpenTok prend en charge le Fonctionnalité d'interconnexion SIP, qui vous permet de connecter des sessions OpenTok à des passerelles SIP.

    • Le routeur multimédia OpenTok prend en charge le Fonctionnalité « Connecteur audio », qui vous permet d'envoyer le flux audio d'une session OpenTok vers un WebSocket.

Les sessions acheminées (c'est-à-dire celles qui utilisent OpenTok Media Router) bénéficient également des optimisations suivantes :

  • Connexion à un seul homologue. À partir de la version 2.28.0 des SDK clients pour iOS, Android, Windows, macOS et Linux, les sessions acheminées prendront en charge les éléments suivants connexion unique entre pairs. Lorsque la connexion à un seul pair est activée, tous les flux d'abonnés destinés à un client sont transmis via une seule connexion au routeur multimédia OpenTok (même s'ils sont publiés par différents clients). L'activation de la connexion à un seul pair présente plusieurs avantages, notamment une réduction de la consommation de ressources du client, un meilleur contrôle du débit et, dans le cas des appareils mobiles natifs, la prise en charge de sessions plus volumineuses. Lorsque la connexion à un seul pair est désactivée (configuration par défaut), le client utilise une connexion distincte vers l'OpenTok Media Router pour chaque ensemble audio/vidéo.

    La connexion à un seul pair n'est disponible que dans les sessions acheminées (sessions qui utilisent le routeur média de Video API de Vonage). Pour un guide complet comprenant des cas d'utilisation, des détails de configuration, des exemples de code et l'interaction avec d'autres fonctions, consultez le site Web de l'API vidéo de Vonage. Guide du développeur Single Peer Connection.

    Pour activer la connexion à un seul homologue, utilisez les API suivantes du Client SDK :

    • SDK Web (OpenTok.js) — Consultez la singlePeerConnection des options que vous passez dans OT.initSession()
    • SDK Android - Session.Builder.setSinglePeerConnection()
    • SDK iOS - OTSessionSettings.singlePeerConnection
    • SDK Linux - otc_session_settings_set_single_peer_connection()
    • macOS SDK - otc_session_settings_set_single_peer_connection()
    • SDK Windows - SinglePeerConnection de la propriété Session.Builder classe
    • SDK React Native — Le enableSinglePeerConnection de la propriété options prop du composant OTSession

  • Optimisation de Media Mesh. La plateforme utilise Media Mesh pour optimiser automatiquement les sessions acheminées en connectant chaque participant au routeur multimédia situé dans le centre de données régional le plus proche. Cela permet de réduire la latence et d'améliorer la qualité, en particulier pour les sessions impliquant des participants répartis géographiquement.

    Media Mesh est activé par défaut et ne nécessite aucune configuration. Pour désactiver cette optimisation et limiter la diffusion des contenus multimédias à une région spécifique, consultez Zones médiatiques régionales.

  • Routage adaptatif des médias. À partir de la version 2.24.7 d'OpenTok.js et des versions 2.27.0 des autres SDK clients (pour Android, iOS, Windows, macOS, Linux et React), les sessions acheminées sont optimisées pour utiliser routage adaptatif des médias, si possible. Le routage adaptatif des flux multimédias détermine si ceux-ci peuvent être acheminés sans passer par l’OpenTok Media Router pour les sessions vidéo en tête-à-tête, afin d’optimiser les performances multimédias entre deux participants. La session acheminée adapte automatiquement le routage multimédia pour utiliser l’OpenTok Media Router lorsque cela est nécessaire — pour les sessions comptant trois participants ou plus, l’archivage, les diffusions en direct, l’interconnexion SIP, Experience Composer, les sous-titres en direct et Audio Connector.

    Avec l'ajout du routage adaptatif des médias, il existe également un scalableVideo option dans OpenTok.js OT.initPublisher() pour remplacer la valeur par défaut et désactiver la vidéo évolutive pour l'éditeur dans une session acheminée.

Routage adaptatif des médias

L'acheminement adaptatif des médias (AMR) est une optimisation des performances pour les services de téléphonie mobile. sessions acheminées. L'AMR évalue individuellement le nombre d'abonnés de chaque éditeur. Lorsqu'un éditeur n'a qu'un seul abonné et qu'aucune fonction nécessitant le Media Router n'est utilisée (par exemple, archivage, streaming en direct, SIP, etc.), la plateforme relaie les médias de cet éditeur en peer-to-peer vers l'abonné au lieu de les acheminer via le Media Router. Cela permet de réduire la latence et d'améliorer la qualité audio et vidéo.

La session reste toujours une session acheminée. L'AMR ne modifie pas le mode média de la session - elle modifie uniquement le mode de transmission des données. chemin des médias utilisé sous le capot. Le code de votre application, les jetons et la configuration de la session côté serveur restent exactement les mêmes. Le passage du relais pair-à-pair au relais Media Router est géré de manière transparente par les SDK clients.

Lorsque l'AMR utilise le relais peer-to-peer

L'AMR relaiera les médias directement entre un éditeur et son abonné (en contournant le routeur de médias sur le chemin des médias) dans les cas suivants tous des éléments suivants sont vrais :

  • L'éditeur a exactement un abonné.
  • Aucune des fonctions énumérées dans la section suivante n'est active.

Par exemple, une session avec quatre éditeurs et quatre abonnés peut rester entièrement en relais peer-to-peer tant que chaque éditeur n'a qu'un seul abonné et qu'aucune fonction Media Router n'est utilisée.

Lorsque l'AMR passe au routeur de média

La plateforme fait transiter les médias d'un éditeur par le routeur de médias lorsque tous des conditions suivantes s'appliquent :

Dès qu'un déclencheur est activé, tous les médias des éditeurs sont acheminés de manière transparente via le routeur média.

Support SDK

La fonctionnalité AMR a été introduite dans OpenTok.js v2.24.7 ainsi que dans les versions 2.27.0 des Client SDK pour Android, iOS, Windows, macOS, Linux et React. Les clients utilisant des versions plus anciennes des Client SDK dans le cadre d'une session routée utiliseront toujours le Media Router.

Implications pour le débogage et le développement

L'AMR est transparent pour la logique de votre application, mais il y a quelques points à prendre en compte lors du développement et du dépannage :

  • Inspecteur peut être erronée clientDisconnection événements survenant lorsqu'un média d'un éditeur passe d'un relais peer-to-peer au Media Router (par exemple, lorsqu'un deuxième client s'abonne à un flux). Ces événements ne correspondent pas à de véritables déconnexions : les participants restent connectés tout au long de la transition. Il s'agit d'un problème connu dans Inspector.
  • Les objets MediaStream peuvent évoluer au cours des transitions. Lorsque l'AMR bascule entre le relais peer-to-peer et le routeur multimédia, le sous-jacent MediaStream d'un abonné est remplacé. Si votre application accède à la fonction MediaStream directement (par exemple, pour rendre une vidéo dans des objets <video> ), vous devez traiter cette modification de l'une des manières suivantes :
    • Recommandation : utilisez le Flux de médias disponibles API (disponible dans OpenTok.js v2.27.7+). Les mediaStreamAvailable sur les objets de l'éditeur et de l'abonné tient automatiquement compte de tout changement causé par l'AMR, en fournissant les informations correctes sur les objets de l'éditeur et de l'abonné, en tenant compte de tout changement causé par l'AMR. MediaStream chaque fois qu'une transition se produit.
    • Ancienne méthode (avant la version 2.27.7) : surveiller le play sur l'élément vidéo de l'abonné pour détecter le moment où l'événement MediaStream a été remplacé, et mettez à jour votre rendu personnalisé en conséquence. Voir la page Accès aux objets MediaStream pour les abonnés guide.
  • Les événements de connexion et de flux continuent de se déclencher normalement. Vous n'avez pas besoin de gérer les transitions AMR dans vos écouteurs d'événements de session. Le streamCreated, streamDestroyed, connectionCreatedet connectionDestroyed reflètent l'état réel des participants, et non le chemin médiatique sous-jacent.

Interaction avec d'autres fonctionnalités

  • Connexion à un seul pair (SPC): La fonction SPC n'est active que lorsque le flux multimédia transite par le routeur multimédia. Tant que l'AMR relaie le flux multimédia d'un éditeur en peer-to-peer, la fonction SPC ne s'applique pas à ce flux. Dès que le flux passe par le routeur multimédia, la fonction SPC prend effet si elle est activée.
  • Cryptage de bout en bout: Le chiffrement de bout en bout fonctionne avec AMR. Les flux multimédias sont chiffrés, qu'ils transitent en peer-to-peer ou via le routeur multimédia.
  • Solution de secours pour l'audio : Repli audio de l'abonné est une fonction du routeur média qui s'applique normalement une fois qu'un flux est acheminé par le routeur média. Cependant, pendant que l'AMR relaie le média d'un éditeur en peer-to-peer, Repli audio de l'éditeur désactiver automatiquement la vidéo pour sauvegarder le flux audio, si nécessaire. Une fois que le flux est transféré au routeur multimédia, le repli audio de l'éditeur et de l'abonné s'applique normalement.
  • Simulcast et évolutivité: Lorsque l'AMR assure la transmission de médias en peer-to-peer, la vidéo évolutive est automatiquement désactivée, quel que soit le codec utilisé. Lorsque le flux passe par le Media Router, le comportement de la vidéo évolutive dépend du codec et du paramètre de vidéo évolutive de l'application défini dans le tableau de bord :
    • VP8 : Si la vidéo évolutive est réglée sur Sur ou Auto dans le tableau de bord, la diffusion simultanée est automatiquement activée sur le tronçon acheminé une fois la transition vers le routeur média effectuée.
    • VP9 : La vidéo évolutive est activée par défaut lorsqu'elle est acheminée par le routeur multimédia.
    • H.264 : La vidéo évolutive n'est pas prise en charge et reste désactivée par défaut dans tous les cas.

Mode archive

Lorsque vous créez une session, vous pouvez activer le mode d'archivage afin que celle-ci soit archivée automatiquement. Cela ne s'applique qu'aux sessions acheminées (c'est-à-dire celles qui utilisent OpenTok Media Router). Par défaut, les sessions ne sont pas archivées automatiquement.

Indices de localisation

Lorsque vous créez une session, vous pouvez définir l'adresse IP que la plateforme vidéo Vonage utilisera pour sélectionner le meilleur serveur chargé de gérer la session au sein de son réseau mondial. Si aucune indication de localisation n'est définie lors de la création de la session (ce qui est recommandé), le serveur de gestion de la session est sélectionné en fonction de la localisation du premier client se connectant à la session. Ne définissez une indication de localisation que si vous connaissez la région géographique générale (et une adresse IP représentative) et que vous pensez que le premier client à se connecter pourrait ne pas se trouver dans cette région. Indiquez une adresse IP représentative de la localisation géographique de la session.

Pour le streaming multimédia, le système utilisera toujours l'indice de localisation pour se connecter au serveur multimédia le plus proche (SFU), garantissant ainsi que le trafic multimédia est acheminé via le serveur le plus optimal en fonction de la situation géographique du client.

Bonnes pratiques lors de la création de sessions

Réutilisation de l'identifiant de session

Dans la mesure du possible, ne réutilisez pas les identifiants de session entre différentes conversations par chat vidéo. Générez plutôt de nouveaux identifiants de session pour chaque conversation par chat vidéo distincte sur votre application.

C'est important, surtout lorsque l'on utilise OpenTok Inspecteur. Dans Inspector, les scores de qualité des sessions et les données associées sont indexés par identifiant de session. Un identifiant de session réutilisé pour plusieurs conversations est plus difficile à analyser à l'aide d'Inspector, et les sessions dont l'identifiant est réutilisé ont tendance à afficher des scores de qualité globaux inférieurs à la qualité réelle de l'appel.

Activer la migration des sessions ou limiter les sessions à 8 heures

La mise à l'échelle automatique des nuages modernes rend nécessaire l'établissement d'une durée de rotation minimale pour les services. Les sessions qui durent plus de 8 heures risquent d'être déconnectées, car elles peuvent résider dans des services qui sont en train de s'éteindre ou de se rallonger.

Les versions 2.30.0 et ultérieures des SDK clients de Vonage Video API comprennent une fonction de migration de session qui transfère de manière transparente tous les participants d'une session vers un nouveau serveur pendant la rotation des serveurs. Cette fonction assure la continuité de la session avec un minimum de perturbations pour les participants. Voir Rotation des serveurs et migration des sessions.

Note pour les clients utilisant des versions du SDK client inférieures à 2.30.0 : Pour les sessions prévues pour durer plus de 8 heures, nous vous recommandons de migrer les utilisateurs connectés vers une nouvelle session avant tout événement potentiel de dépassement de délai/reconnexion. Cela garantira une expérience optimale pour l'utilisateur.

Les clients sont également déconnectés d'une session s'ils ne publient pas de flux ou ne s'y abonnent pas dans les 4 heures suivant leur connexion.

Vous pouvez utiliser suivi de la session pour recevoir des notifications lorsque les sessions s'arrêtent ou se terminent et lorsqu'un groupe de serveurs Video API pour une session est programmé pour une rotation.

Pour plus d'informations, voir Rotation des serveurs.

Choisir le type de session Relayed vs. Routed

Privilégiez une session relayée plutôt qu'une session routée si vous n'avez que deux participants (voire trois) et que vous n'utilisez pas l'archivage. L'utilisation de sessions relayées réduit la latence entre les participants, diminue les points de défaillance et permet, dans la plupart des cas, d'obtenir une meilleure qualité vidéo et audio.

Les sessions acheminées sont obligatoires si vous souhaitez archiver votre session. Elles sont recommandées si votre session compte plus de deux ou trois participants.

Pour plus d'informations, voir Le routeur multimédia OpenTok et les modes multimédias.

Création de sessions

Lorsque vous travaillez sur une version de test de votre application, vous pouvez obtenir un identifiant de session de test via la page du projet de votre Video API Account.

Vous pouvez également utiliser l'une des bibliothèques côté serveur d'OpenTok ou l'API REST d'OpenTok pour créer une session :

Vous pouvez également utiliser la fonction API REST d'OpenTok pour créer une session.

Si vous devez générer dynamiquement plusieurs identifiants de session, utilisez l'une des bibliothèques côté serveur d'OpenTok ou l'API REST d'OpenTok — et non la page du projet.