Guide de transition vidéo de Vonage pour Ruby

Transition de OpenTok-Ruby-SDK à vonage-ruby-sdk

Introduction

Objectif

L'objectif de ce document est de fournir un point de départ pour passer du SDK Ruby Server d'OpenTok au SDK Ruby Server de Vonage.

Champ d'application

Ce document suppose que vous utilisez au moins la version 4.9.0 ou une version ultérieure de l'application OpenTok Ruby SDK. Une première implémentation de l'API Video a été ajoutée au SDK Ruby Server en version 7.19.0avec des fonctionnalités supplémentaires mises en œuvre dans version 7.24.0. Cependant, pour votre migration, nous vous recommandons d'utiliser la fonction actuel dernier du SDK Ruby de Vonage, qui peut être trouvé sur le site GitHub ou RubyGems.

Hypothèses

Ce guide est destiné à être suivi par un ingénieur logiciel professionnel. Il suppose au moins un niveau de compétence de base avec Ruby, les outils de développement Ruby courants et Git (ou un autre système de contrôle de version). Vous devez être à l'aise avec la lecture et l'écriture de code Ruby, la gestion des dépendances d'un projet, le déploiement et l'exécution d'un projet Ruby. Une introduction au langage Ruby, à la plateforme et aux outils associés dépasse largement le cadre de ce document.

Ressources

Les liens suivants sont utiles pour compléter le présent document et pour se référer à tout ce qui n'est pas couvert dans le présent document :

Vonage

• Documentation vidéo de Vonage
• Spécification de l'API Video de Vonage
• SDK Ruby Server de Vonage Guide d'utilisation vidéo
• Vonage Ruby Server SDK Rubydocs
• Code source vidéo du SDK Ruby Server de Vonage
• SDK Ruby Server de Vonage GitHub repo
• Artéfacts publiés par Vonage Ruby Server SDK sur RubyGems

TokBox

• Référence REST de l'API OpenTok
• Documentation d'OpenTok Ruby Server SDK
• Code source d'OpenTok Ruby Server SDK
• OpenTok Ruby Server SDK GitHub repo
• Artéfacts publiés par OpenTok Ruby Server SDK sur RubyGems

Planifier votre migration

Avant de passer d'OpenTok à Vonage Video, vous devez prendre en compte l'ampleur de la tâche afin de fixer des attentes réalistes.

Évaluer l'impact

Afin d'évaluer l'impact de la migration sur votre application, vous devrez vous poser certaines questions.

1. Combien du code de votre application dépend du SDK OpenTok ? Dressez une liste de tous les fichiers dans lesquels le SDK est directement utilisé. Une façon de le déterminer pourrait être d'identifier tous les fichiers .rb qui contient un fichier require 'opentok' référence. Par exemple, vous pouvez rechercher la déclaration suivante dans les fichiers de votre projet require 'opentok' en utilisant un éditeur de code, un IDE ou un outil de ligne de commande pour identifier les fichiers concernés.

2. Combien de des fonctionnalités du SDK OpenTok votre application utilise-t-elle ? Par exemple, une application qui utilise le SDK uniquement pour créer des sessions vidéo et générer des jetons clients sera probablement plus simple à migrer qu'une application qui utilise également des fonctions d'archivage, de diffusion, de modération et autres.

3. Qui des fonctionnalités du SDK OpenTok sont-elles utilisées par votre application ? La migration de certaines fonctionnalités peut nécessiter plus d'efforts que d'autres. Voir la section Section "Principaux changements et considérations pour plus de détails sur les modifications apportées à la mise en œuvre des deux SDK.

4. Comment étroitement couplé Le code de votre application est-il compatible avec le SDK OpenTok ? Dans le contexte d'une application Ruby on Rails, par exemple, invoquez-vous les méthodes du SDK directement dans les actions de votre contrôleur, ou avez-vous abstrait ces appels de méthode d'une manière ou d'une autre (par exemple, via l'utilisation du modèle de passerelle ou du modèle d'adaptateur) ?

Il peut y avoir d'autres considérations pour votre projet spécifique qui ne sont pas énumérées ci-dessus.

Chronologie

Tenez compte du temps nécessaire pour mener à bien la transition. Cela dépendra d'un certain nombre de facteurs tels que votre familiarité avec le projet et l'impact de la migration du projet (tel que décrit ci-dessus). Il est essentiel de disposer d'une bonne suite de tests afin de pouvoir vérifier l'équivalence entre les implémentations d'OpenTok et de Vonage Video. Le temps nécessaire pour achever la transition est de grossièrement proportionnelle au nombre d'endroits où le SDK OpenTok est utilisé dans votre code, ainsi qu'à la variété des fonctionnalités utilisées, mais, comme mentionné précédemment, certains appels d'API seront plus simples à remplacer que d'autres.

Versionnement

OpenTok et Vonage Video sont deux produits différents. Cela rend impossible une migration progressive.

Vous devriez créer une branche temporaire sur votre système de contrôle de version pour la transition, afin de pouvoir apporter des changements progressivement et fréquemment sans casser le projet existant. Vous pouvez également utiliser les tests du projet existant en tant qu'oracle pour vérifier l'exactitude des données. Idéalement, vous ne devriez fusionner la branche de transition avec la branche principale qu'une fois la conversion terminée.

Principaux changements et considérations

L'API Video de Vonage présente les mêmes caractéristiques qu'OpenTok, et le SDK Ruby est activement mis à jour pour être conforme à la spécification de l'API. Il existe cependant quelques différences entre les deux SDK que vous devez connaître.

Nouvelles caractéristiques et normes

Structure du paquet

Le SDK Ruby d'OpenTok et le SDK Ruby de Vonage respectent tous deux la norme approche de structuration des gems Ruby recommandée par Bundleret sont donc, à un niveau élevé, similaires dans leur structure. Il existe toutefois quelques différences essentielles :

1. Le SDK Ruby de Vonage utilise l'option zeitwerk pour l'autochargement du code et suit donc les conventions de zeitwerk pour la structure et le nommage des fichiers et des répertoires. Si vous savez comment les applications Ruby on Rails sont structurées, vous connaissez déjà ces conventions. Si ce n'est pas le cas, il peut être utile de consacrer quelques minutes à la mise en place d'un système de gestion des fichiers et des répertoires. se familiariser avec eux. Si l'on considère cette structure en termes d'implémentation de l'API vidéo :

• Le principal Video est définie dans ce dossier
• Toutes les classes nommées sous le nom de Video (par exemple Video::Broadcasts et Video::Archives) sont définis sous ce répertoire.

2. Le SDK Ruby de Vonage met en œuvre d'autres API de Vonage en plus de l'API Video. Le SDK met en œuvre des classes qui représentent chacun de ces produits API, et la classe Client fournit des accesseurs pour les objets de ces classes.

En gardant à l'esprit les points 1 et 2 ci-dessus, en partant de l'exemple de Vonage Client une ou plusieurs invocations de méthodes supplémentaires peuvent être nécessaires avant d'atteindre la méthode représentant le point de terminaison spécifique de l'API vidéo que vous souhaitez appeler.

Exemple 1 : Création d'une session

L'utilisation du SDK Ruby d'OpenTok pourrait ressembler à ceci :

# 1: instantiate an `OpenTok` object (assuming credentials stored as environment variables)
opentok = OpenTok::OpenTok.new(
  ENV['OPENTOK_API_KEY'],
  ENV['OPENTOK_API_SECRET']
)

# 2: invoke the `create_session` method on the `OpenTok` object
session = opentok.create_session

Alors que l'utilisation du SDK Ruby de Vonage pourrait ressembler à ceci :

# 1: instantiate a Vonage `Client` object (assuming credentials stored as environment variables)
client = Vonage::Client.new(
  application_id: ENV['VONAGE_APPLICATION_ID'],
  private_key: ENV['VONAGE_PRIVATE_KEY']
)

# 2: access the `Video` object
video = client.video

# 3: invoke the `create_session` method on the `Video` object
session = video.create_session

Comme on peut s'y attendre avec Ruby, il est possible de combiner les étapes 2 et 3 par le biais d'un chaînage de méthodes :

session = client.video.create_session

Exemple 2 : Obtenir une liste d'enregistrements d'archives

L'utilisation du SDK Ruby d'OpenTok pourrait ressembler à ceci :

# 1: instantiate an `OpenTok` object
opentok = OpenTok::OpenTok.new(
  ENV['OPENTOK_API_KEY'],
  ENV['OPENTOK_API_SECRET']
)

# 2: access the `Archives` object
archives = opentok.archives

# 3: invoke the `all` method on the `Archives` object
archive_list = archives.all

Alors que l'utilisation du SDK Ruby de Vonage pourrait ressembler à ceci :

# 1: instantiate a Vonage `Client` object
client = Vonage::Client.new(
  application_id: ENV['VONAGE_APPLICATION_ID'],
  private_key: ENV['VONAGE_PRIVATE_KEY']
)

# 2: access the `Video` object
video = client.video

# 3: access the `Archives` object
archives = video.archives

# 4: invoke the `list` method on the `Archives` object
archive_list = archives.list

Là encore, les étapes peuvent être combinées par le biais d'un enchaînement de méthodes :

archive_list = client.video.archives.list

Note sur la dactylographie

Le SDK Ruby de Vonage utilise Sorbet pour la vérification statique des types. Pour simplifier la migration du SDK Ruby OpenTok vers le SDK Ruby Vonage, les signatures de type n'ont pas encore été définies pour les méthodes de l'implémentation de l'API Video. Les signatures de type seront définies pour ces méthodes dans le cadre d'une prochaine version.

Note sur les changements au niveau du front-end

Les bibliothèques frontales utilisées pour votre application seront les mêmes que celles d'OpenTok. Il y a cependant un changement mineur en ce qui concerne leur utilisation.

L'interaction entre le back-end et le front-end sera la même : le SDK créera des sessions et générera également des jetons permettant aux bibliothèques clientes front-end d'accéder à ces sessions. Comme dans le cas d'une implémentation OpenTok, les bibliothèques clientes frontales s'attendent à ce que le serveur back-end fournisse un jeton ID de la session et un jeton. Toutefois, dans le cas d'une mise en œuvre par Vonage, le serveur devra également fournir un numéro d'identification de l'utilisateur. ID de l'application. Ce numéro d'identification de l'application remplace en fait le numéro d'identification de l'utilisateur. Clé API qui serait utilisé dans une implémentation OpenTok, bien que les bibliothèques client frontales soient toujours utilisées. étiquette en tant que clé API. Pour plus d'informations sur les ID d'applications, voir la section sur les Modifications de l'authentification.

Ce petit changement dans l'interaction entre le front-end et le back-end peut nécessiter quelques mises à jour mineures de votre implémentation, par exemple dans vos modèles de vue ou dans la logique qui transmet les données à ces modèles de vue.

Mise à jour du paquet

Pour utiliser le SDK Ruby de Vonage, vous devrez mettre à jour les dépendances de votre projet afin d'utiliser le fichier vonage au lieu de la gemme Ruby opentok Ruby gem. Vous pouvez le faire en mettant à jour votre Gemfile pour inclure le vonage gemme :

gem "vonage"

puis en exécutant bundle install.

Modifications de l'authentification

Considérant que le opentok La gemme utilise un api_key et api_secret pour l'autorisation, la mise en œuvre de l'API Video dans l'application vonage utilise un JWT. Le SDK gère la génération de JWT en arrière-plan pour vous, mais il vous faudra un fichier application_id et private_key en tant qu'informations d'identification afin de générer le jeton. Vous pouvez les obtenir en configurant une Application Vonage, et en générant un ID d'application et une clé privée pour cette application. L'Application Vonage est également l'endroit où vous pouvez définir d'autres paramètres tels que les produits API pour lesquels l'application est activée, les URL de rappel, les préférences de stockage, etc.

Vous pouvez créer une application Vonage de plusieurs façons :

• Par l'intermédiaire de la Tableau de bord du développeur
• Par l'intermédiaire de la Application API
• En utilisant le CLI Vonage

Votre application_id et private_key sont ensuite transmises lors de l'instanciation d'un fichier Client (l'exemple ci-dessous suppose que ces éléments sont des variables d'environnement) :

client = Vonage::Client.new(
	application_id: ENV['VONAGE_APPLICATION_ID'],
	private_key: ENV['VONAGE_PRIVATE_KEY']
)

Si vos variables d'environnement sont nommées comme dans l'exemple ci-dessus, vous pouvez en fait omettre les arguments de la commande new invocation de la méthode. Le SDK recherchera automatiquement le ENV à la recherche de variables portant ces noms et utilise leurs valeurs s'il les trouve. Dans ce cas, l'exemple suivant d'instanciation d'une variable Vonage::Client est fonctionnellement équivalent au précédent :

client = Vonage::Client.new

Il convient de noter que la valeur de l'élément VONAGE_PRIVATE_KEY peut être le chemin d'accès à l'emplacement de votre private.key fichier. La manière dont vous déterminez la valeur de ce chemin dépend de la façon dont vous déployez votre application. Si vous déployez votre application localement, vous pouvez stocker votre fichier private.key à la racine de votre projet et définissez le chemin d'accès comme suit private.key. Par exemple, si l'on utilise dotenv pour gérer vos variables d'environnement, votre VONAGE_PRIVATE_KEY définition dans votre .env se présenterait comme suit :

VONAGE_PRIVATE_KEY=private.key

Si le déploiement en production se fait à l'aide d'un service tel que RenduEn général, ces types de services permettent de stocker en toute sécurité des fichiers tels que des clés privées. La méthode exacte pour ce faire dépend du service utilisé et dépasse le cadre du présent document.

Changements de méthode

Certaines méthodes ont été modifiées entre le SDK Ruby d'OpenTok et la mise en œuvre de l'API Video dans le SDK Ruby de Vonage.

Paramètres de la méthode

Tous les paramètres positionnels dans les signatures de méthodes ont été remplacés par des paramètres de mots-clés dans le SDK de Vonage.

Changement de nom de la méthode

Certaines méthodes ont été renommées et/ou déplacées, par souci de clarté et/ou pour mieux refléter ce qu'elles font. Elles sont énumérées ci-dessous :

Objets de réponse

Contrairement au SDK Ruby OpenTok, le SDK Ruby Vonage n'utilise pas de classes d'objets spécifiques lors de la désérialisation de la charge utile JSON d'une réponse HTTP, mais désérialise les réponses dans des objets de réponse génériques.

Objets de réponse à une ressource unique

Les réponses dont la charge utile JSON représente une seule ressource sont désérialisées par le SDK Ruby de Vonage dans un fichier générique de type Vonage::Response objet.

D'une manière générale, vous pouvez utiliser ce qui suit Vonage::Response de la même manière que vous le feriez avec l'objet OpenTok::Archive, OpenTok::Broadcast, OpenTok::Streametc., en ce sens que vous pouvez accéder aux propriétés de la réponse en appelant les méthodes de l'objet dont le nom équivaut à celui de la propriété. Par exemple, si vous souhaitez lancer un nouvel enregistrement d'archive et obtenir son identifiant à partir de la réponse, l'approche à adopter serait largement similaire pour les deux SDK.

Exemple : OpenTok Ruby SDK

opentok = OpenTok::OpenTok.new(
  ENV['OPENTOK_API_KEY'],
  ENV['OPENTOK_API_SECRET']
)
session = opentok.create_session
archive = opentok.archives.create(session.session_id) # => returns a OpenTok::Archive object

# calling the `id` method on the object returns the value of the `id` property in the JSON payload
archive.id

Exemple : SDK Ruby de Vonage

client = Vonage::Client.new.new(
  application_id: ENV['VONAGE_APPLICATION_ID'],
  private_key: ENV['VONAGE_PRIVATE_KEY']
)
session = client.video.create_session
archive = client.video.archives.start(session_id: session.session_id) # => returns a Vonage::Response object

# calling the `id` method on the object returns the value of the `id` property in the JSON payload
archive.id

L'une des principales différences dans la mise en œuvre des objets de réponse entre les deux SDK réside dans l'utilisation du modèle de façade dans les objets de réponse du SDK Ruby OpenTok. Les objets réponse du SDK OpenTok sont initialisés avec une référence à l'objet qui a invoqué la méthode qui les a créés. Cet objet porte à son tour une référence à un objet OpenTok::Client objet. Cela signifie que vous pouvez invoquer des méthodes qui interagissent avec certains points d'extrémité de l'API Video directement sur ces objets. Les objets de réponse dans le SDK Ruby de Vonage ne fournissent pas de moyen direct d'appeler des méthodes qui enveloppent les points de terminaison de l'API Video, de sorte que vous devrez utiliser des objets représentant la classe de fonctionnalité spécifique en tant qu'appelant de la méthode.

Supposons, par exemple, que vous souhaitiez arrêter un enregistrement d'archives en cours.

Exemple : OpenTok Ruby SDK

Dans le SDK OpenTok, vous pouvez appeler la fonction stop directement sur la méthode Archive renvoyé par l'objet Archives#create l'invocation de la méthode.

opentok = OpenTok::OpenTok.new(
  ENV['OPENTOK_API_KEY'],
  ENV['OPENTOK_API_SECRET']
)
session = opentok.create_session
archives = opentok.archives
archive_1 = archives.create(session.session_id) # => returns a OpenTok::Archive object

# calling the `stop` method directly on the returned OpenTok::Archive object stops the archive recording
archive_1.stop

Exemple : SDK Ruby de Vonage

Dans le SDK de Vonage, vous devez appeler la fonction stop sur un Video::Archives et transmet l'objet archive_id comme argument.

client = Vonage::Client.new.new(
  application_id: ENV['VONAGE_APPLICATION_ID'],
  private_key: ENV['VONAGE_PRIVATE_KEY']
)
session = client.video.create_session
archives = client.video.archives
archive_1 = archives.start(session_id: session.session_id) # => returns a Vonage::Response object

# calling the `stop` method on a Video::Archives object, passing in the `id` of the archive you want to stop
archives.stop(archive_id: archive_1.id)

Objets de réponse à ressources multiples

Les réponses dont la charge utile JSON représente une collection d'une ou plusieurs ressources sont désérialisées par le SDK Ruby de Vonage dans un fichier ListResponse sous le nom de produit, puis le type d'objet à l'origine de la demande, par exemple Vonage::Video::Broadcasts::ListResponse.

Essentiellement, ils fournissent la même fonctionnalité que les types d'objets de réponse de liste du SDK Ruby OpenTok, dans la mesure où ce sont des collections itérables d'objets de ressources individuels. L'implémentation diffère légèrement entre les SDK, mais en général, cela ne devrait pas avoir d'impact sur la façon dont vous pouvez interagir avec ces objets, et est décrit ci-dessous par souci d'exhaustivité :

• Les ListResponse dans le SDK Ruby de Vonage mettent en œuvre un objet each et inclure la méthode Ruby Enumerable module.
• Les réponses de type liste dans le SDK Ruby d'OpenTok (par ex. ArchiveList, BroadcastListetc.) de la sous-classe Ruby Array classe.

Objets de réponse aux erreurs

Les deux SDK définissent une classe d'erreur générique qui est une sous-classe de la classe d'erreur Ruby StandardError avec des classes d'erreurs plus spécifiques qui sont des sous-classes de cette classe générique.

Le SDK Ruby d'OpenTok définit une fonction OpenTok::OpenTokError puis des classes d'erreurs spécifiques par type d'élément qui sous-classe la classe OpenTokError, tels que OpenTokArchiveError, OpenTokBroadcastError, OpenTokAuthenticationErroretc. Aucun de ces types d'erreur n'implémente de fonctionnalité supplémentaire par rapport à ce qui est prévu par la norme StandardError fournit.

Le SDK Ruby de Vonage définit une fonction générique de Vonage::Error ainsi qu'une classe Vonage::APIError qui sous-classe les classes de Vonage::Error. Les APIError représente les erreurs qui résultent d'une requête HTTP vers un point de terminaison de l'API de Vonage. Le SDK définit ensuite un certain nombre de classes d'erreurs plus spécifiques, en fonction de la nature de la réponse reçue, qui sous-classent les classes de APIError. Ces classes comprennent Vonage::ClientError (pour 4xx réponses), Vonage::ServerError (pour 5xx réponses), et Vonage::AuthenticationError (qui est une sous-classe de Vonage::ClientErroret est spécifiquement utilisé pour 401 réponses).

Les APIError met en œuvre une logique supplémentaire qui fournit des méthodes d'obtention pour la classe Net:HTTPResponse ainsi que le code de réponse, les en-têtes et le corps du message. Vous pouvez sauver l'exception pour accéder à ces propriétés.

Exemple

client = Vonage::Client.new.new(
  application_id: ENV['VONAGE_APPLICATION_ID'],
  private_key: ENV['VONAGE_PRIVATE_KEY']
)

begin
  session = client.video.create_session
rescue Vonage::APIError => error
  if error.http_response
    error.http_response # => #<Net::HTTPUnauthorized 401 Unauthorized readbody=true>
    error.http_response_code # => "401"
    error.http_response_headers # => {"date"=>["Sun, 24 Sep 2023 11:08:47 GMT"], ...rest of headers}
    error.http_response_body # => {"title"=>"Unauthorized", ...rest of body}
  end
end

Stratégies de migration

Migration incrémentale

Nous recommandons une migration incrémentale, en passant d'un cas d'utilisation à un autre, en s'engageant à chaque fois que vous arrivez à un état "stable". Bien sûr, cela nécessiterait la coexistence temporaire d'OpenTok et de Vonage Video API.

Veuillez noter que, pendant ce processus incrémentiel, votre application dans son ensemble ne sera plus entièrement fonctionnelle, car OpenTok et Vonage Video API sont deux systèmes totalement différents.

Le plan exact d'une approche progressive dépendra du nombre et de la nature des fonctionnalités de l'API Video que vous utilisez et de la manière dont vous avez intégré ces fonctionnalités dans votre application. Bien qu'il ne soit pas possible de fournir des conseils spécifiques à la mise en œuvre dans ce domaine, en termes d'approche générale, un plan possible consiste à mettre à jour votre code fonctionnalité par fonctionnalité, et au sein de chaque fonctionnalité, méthode par méthode.

Un bon point de départ serait de commencer par tout code qui instancie un OpenTok::OpenTok et le remplacer par un code qui instancie un objet Vonage::Client à la suite de la comparaison entre les deux démontrée dans l'étude de cas. Structure du paquet section.

L'étape suivante pourrait consister à mettre à jour tout code traitant de la création de sessions, de la génération de jetons clients et de la transmission de données aux bibliothèques clientes frontales.

Vous pourriez ensuite mettre à jour à votre tour tout code qui met en œuvre des fonctionnalités spécifiques de l'API Video. Prenons l'exemple des archives :

• Identifier tout code où Archives sont créés ou font l'objet d'une interaction.
• Mettre à jour les invocations de méthodes de manière à ce que les méthodes soient appelées sur client.video au lieu de opentok objets.
• Mettre à jour les noms des méthodes qui ont changé.
• Si un appel de méthode transmet des arguments, mettez-le à jour afin d'utiliser les paramètres de mot-clé corrects.
• Identifier tout code dans lequel une méthode est appelée directement sur un Archive et le modifier comme indiqué dans l'annexe. Objets de réponse section.

Répétez ce processus pour chaque caractéristique et méthode.

Il se peut que vous deviez prendre d'autres mesures, telles que la mise à jour de tout code dans lequel vous erreurs spécifiques au sauvetage. La liste des étapes ci-dessus n'est pas exhaustive, mais devrait constituer un bon point de départ pour définir votre plan de migration.

Modèle de passerelle/adaptateur

Si vous n'utilisez pas encore une sorte de passerelle ou d'adaptateur dans le cadre de votre mise en œuvre, cette migration serait une bonne occasion de le faire. Non seulement cela facilitera la migration, mais cela signifiera également qu'en règle générale, le code de votre application sera moins étroitement couplé au code du SDK.

Il existe de nombreuses approches différentes pour mettre en œuvre ces modèles en fonction de la façon dont votre application est structurée et/ou du cadre de travail que vous utilisez. Le présent document n'a pas pour objet de fournir des conseils spécifiques dans ce domaine.

Recommandations pour les tests

Des tests approfondis sont essentiels pour assurer une transition en douceur, tant pendant qu'après la migration. Il s'agit non seulement de tests unitaires, mais aussi de tests d'intégration et de régression. Il est également utile de tester manuellement le flux de votre application au moins une fois avant et après la migration pour s'assurer que vos tests automatisés font ce que vous pensez qu'ils font, ou pour détecter tout problème que les tests n'auraient pas décelé. Vous pouvez même envisager de créer des tests d'équivalence. L'idée est de créer une suite qui affirme que les versions OpenTok et Vonage Video de votre application font la même chose. Ces tests peuvent ensuite être supprimés une fois que la transition est terminée et que la version OpenTok de votre application est supprimée.

Dépannage et assistance

Canaux de soutien

Pour obtenir de l'aide générale et discuter de la transition vers Vonage Video, consultez la section Canal #video-api sur notre communauté Slackoù vous pourrez obtenir des réponses du personnel de Vonage et d'autres utilisateurs. Vous pouvez également nous contacter sur X @VonageDev.

La personne à contacter en cas de problème avec l'API Video est la suivante support@api.vonage.com.

Si vous trouvez un bogue avec le SDK, veuillez déposer un problème, avec la marche à suivre pour le reproduire, sur GitHub.

Ressources complémentaires

Échantillons de code

• Appel vidéo multipartite de base avec Sinatra