Interconnexion SIP

Vous pouvez utiliser l'API REST OpenTok pour connecter votre plateforme SIP aux sessions OpenTok. Cela vous permet d' ajouter le flux audio (et, éventuellement, le flux vidéo) d'un appel SIP à la session OpenTok. Le flux audio provenant des autres flux de la session OpenTok est mixé avec les autres et envoyé vers votre terminal SIP. Si vous incluez de la vidéo dans l'appel SIP, les flux vidéo des autres participants (jusqu'à 9) sont disposés en grille et envoyés sous la forme d'un seul flux vidéo vers votre terminal SIP.

La fonctionnalité d'interconnexion SIP n'est prise en charge que dans les sessions routées (sessions qui utilisent le Routeur multimédia OpenTok).

Cette page comprend les sections suivantes :

Introduction au protocole SIP

OpenTok SIP Interconnect assure l'interopérabilité entre les terminaux WebRTC et les systèmes de téléphonie existants, permettant ainsi aux utilisateurs de passer des appels SIP en contexte, tout en naviguant sur le site Web ou dans l'application mobile.

Cas d'utilisation cibles

Cas d'utilisation d'un centre de contact

  • Dans le cadre de leur stratégie de communication omnicanale, les entreprises s'intéressent à WebRTC pour que les utilisateurs finaux puissent.. :

    • Utiliser les navigateurs ou les applications mobiles pour se connecter aux centres de contact, plutôt que d'utiliser uniquement les téléphones, afin d'offrir une expérience plus omniprésente et contextuelle.

    • Utiliser la vidéo/collaboration en plus de l'audio pour améliorer l'efficacité et accroître la satisfaction et la fidélisation des clients.

RTPC Fallback

  • Dans certains cas, il n'est pas possible de se connecter à l'aide des clients OpenTok classiques :

    • Si l'un des participants dispose d'un navigateur qui ne prend pas en charge WebRTC ou
    • Si le pare-feu est trop restrictif

  • Si la connexion via IP/OpenTok échoue pour les raisons mentionnées ci-dessus, les clients auront besoin d'un mécanisme de secours. La fonctionnalité « OpenTok SIP Interconnect » permet aux clients de passer un appel téléphonique classique au cours d'une session OpenTok. Pour cela, les clients doivent configurer une passerelle SIP-PSTN.

Lancer un appel SIP

Pour lancer l'appel SIP, utilisez l'API REST OpenTok. Envoyez une requête POST HTTPS à l'URL suivante :

https://api.opentok.com/v2/project/:apiKey/dial

Remplacer apiKey avec votre clé API OpenTok.

Régler le Content-Type à l'en-tête application/json. Définir une valeur personnalisée X-OPENTOK-AUTH en-tête vers un jeton Web JSON valide pour les appels à l'API REST d'OpenTok. Consultez la section consacrée à Authentification des appels à l'API REST d'OpenTok.

Définir le corps de la demande en données JSON au format suivant :

{
  "sessionId": "OpenTok session ID",
  "token": "A valid OpenTok token",
  "sip": {
    "uri": "sip:user@sip.partner.com;transport=tls",
    "from": "from@example.com",
    "headers": {
      "headerKey": "headerValue"
    },
    "auth": {
      "username": "username",
      "password": "password"
    },
    "secure": true|false,
    "video": true|false,
    "observeForceMute": true|false,
    "streams": ["stream-id-1", "stream-id-2"]
  }
}

L'objet JSON comprend les propriétés suivantes :

  • sessionId​ (obligatoire) — L'identifiant de session OpenTok correspondant à l'appel SIP auquel vous souhaitez vous joindre.

  • token​ (obligatoire) — Le jeton OpenTok à utiliser pour le participant appelé. Vous pouvez ajouter un jeton data pour déterminer si le participant est un terminal SIP ou pour obtenir d’autres données d’identification, telles que des numéros de téléphone. (Les bibliothèques client OpenTok comprennent des propriétés permettant d’examiner les données de connexion d’un client connecté à une session.) Voir la Création de jetons guide du développeur.

  • SIP uri ​(obligatoire) : l'URI SIP à utiliser comme destination de l'appel SIP lancé depuis OpenTok vers votre plateforme SIP.

    Si le SIP uri contient un transport=tls en-tête, la négociation entre Vonage et le terminal SIP s'effectuera de manière sécurisée. Notez que cela ne s'applique qu'à la négociation elle-même, et non à la transmission audio. Si vous souhaitez également que la transmission multimédia audio (et vidéo, le cas échéant) soit chiffrée, configurez le secure à la propriété true.

    Il s'agit d'un exemple de négociation d'appel sécurisée :

    "sip:user@sip.partner.com;transport=tls"

    Il s'agit d'un exemple de négociation d'appel non sécurisée :

    "sip:user@sip.partner.com"

    Vous pouvez également régler la transport à l'en-tête transport=tcp ou transport=udp. Le transport par défaut est udp.

  • SIP from (facultatif) : Le numéro ou la chaîne de caractères qui sera envoyé au numéro SIP final en tant que l'appelant. Il doit s'agir d'une chaîne de caractères de la forme from@example.comoù from peut être une chaîne de caractères ou un nombre.

    Si from est fixé à un nombre (par exemple, "14155550101@example.com"), il s'affichera s'affichera comme numéro entrant sur les téléphones RTC. Si le from est indéfini ou correspond à une chaîne de caractères (par exemple, "joe@example.com"), +00000000 s'affichera comme numéro entrant sur les téléphones RTC.

    Si from est indéfini, ou défini comme une chaîne de caractères (par exemple, "joe@example.com"), c'est-à-dire un numéro non reconnu ou non autorisé, qui, dans la plupart des cas, sera converti en "Unknown" avant que la demande ne soit transmise à un opérateur pour la terminaison RTPC par les fournisseurs SIP. En fonction du fournisseur, "Unknown" apparaîtra comme le numéro entrant sur les téléphones RTPC. Dans certains cas, les fournisseurs peuvent rejeter ces appels pour des raisons de sécurité, afin d'éviter des problèmes tels que l'usurpation de numéro. d'éviter des problèmes tels que l'usurpation de numéro. Si l'appel n'est pas rejeté par le fournisseur, + s'affichera comme numéro entrant sur les téléphones RTC, +00000000 apparaîtra comme le numéro entrant sur les téléphones RTC.

    Un numéro est considéré comme non reconnu lorsqu'il n'est pas E.164 ou qu'il n'est pas un Numéro virtuel Vonage si l'on se connecte à le Vonage Voice API, par exemple.

  • SIP headers​ (facultatif) - Cet objet définit les en-têtes personnalisés à ajouter au message SIP INVITE initiée par OpenTok vers votre plateforme SIP.

  • SIP auth (facultatif) - Cet objet contient le username et password à utiliser dans le le SIP INVITE pour l'authentification HTTP digest, si elle est requise par votre plateforme SIP.

  • secure (facultatif) - Indicateur booléen indiquant si le média doit être transmis crypté (true) ou non (false(par défaut).

  • video (facultatif) — Un indicateur booléen précisant si l'appel SIP inclura la vidéo (true) ou non (false, valeur par défaut). Lorsque la vidéo est activée, la vidéo du client SIP est intégrée au flux OpenTok envoyé à la session OpenTok. La vidéo SIP est limitée à 480p à 800 kbps. Le client SIP recevra un flux vidéo composite dynamique issu des flux publiés dans la session OpenTok.

  • observeForceMute (facultatif) — Un indicateur booléen indiquant si le point d'extrémité SIP respecte force mute moderation (true) ou non (false, valeur par défaut). De plus, avec observeForceMute fixé à true, l'appelant peut appuyer sur « *6 » pour activer ou désactiver le son de l'audio diffusé. Pour que la commande « *6 » de mise en sourdine fonctionne, l'appelant SIP DOIT négocier les signaux DTMF conformes à la norme RFC 2833 (chiffres RFC 2833/RFC 4733). La fonction de mise en sourdine n’est pas prise en charge avec les DTMF SIP INFO ou en bande. Un message (en anglais) est diffusé à l’ appelant lorsqu’il active ou désactive la sourdine, ou lorsque le client SIP est mis en sourdine par une action de mise en sourdine forcée.

  • streams (facultatif) - Un tableau d'identifiants de flux à inclure dans l'appel SIP. l'appel SIP. Si vous ne définissez pas cette propriété, tous les flux de la session sont inclus dans l'appel. sont inclus dans l'appel.

Un appel réussi génère une réponse HTTP 200, dans laquelle l'identifiant de connexion et l'identifiant de flux sont inclus dans les données de réponse JSON :

{
  "id": "b0a5a8c7-dc38-459f-a48d-a7f2008da853",
  "connectionId": "e9f8c166-6c67-440d-994a-04fb6dfed007",
  "streamId": "482bce73-f882-40fd-8ca5-cb74ff416036",
}

L'objet JSON comprend les propriétés suivantes :

  • id - Un identifiant unique pour l'appel SIP.

  • connectionId — L'identifiant de connexion OpenTok correspondant à la connexion de l'appel SIP dans la session OpenTok. Vous pouvez utiliser cet identifiant de connexion pour mettre fin à l'appel SIP à l'aide de l'API REST d'OpenTok. Voir la section suivante.

  • streamId — L'identifiant de flux OpenTok correspondant au flux de l'appel SIP dans la session OpenTok.

La passerelle SIP OpenTok envoie un message SIP standard INVITE à l'adresse que vous indiquez dans l'appel REST. Lorsque votre terminal SIP se connecte, il est ajouté en tant que nouvelle connexion à la session OpenTok, et son flux audio (et vidéo, le cas échéant) est ajouté à un nouveau flux dans la session OpenTok. La nouvelle connexion est immédiatement ajoutée à la session OpenTok sans attendre que le terminal SIP reçoive ou accepte l’appel. Dans les clients connectés à la session, le Client SDK OpenTok diffuse des événements indiquant la nouvelle connexion et le nouveau flux (tout comme il le ferait pour d’autres connexions et flux OpenTok). Les clients peuvent s’abonner au flux, tout comme ils s’abonneraient à n’importe quel autre flux de la session.

Terminer un appel SIP

L'appel prend fin lorsque votre serveur SIP envoie un BYE message (pour mettre fin à l'appel). Vous pouvez également mettre fin à un appel à l'aide de la méthode de l'API REST OpenTok permettant de déconnecter un client d'une session. Utilisez l'identifiant de connexion de l'appel SIP lorsque vous appelez cette méthode. (La méthode REST pour lancer l'appel SIP renvoie l'identifiant de connexion dans les données de réponse.)

Lorsque l'appel SIP prend fin, la connexion OpenTok et le flux associés à cet appel SIP prennent également fin. Sur chaque client connecté à la session, le SDK côté client OpenTok déclenche des événements indiquant que la connexion et le flux ont pris fin (tout comme il le ferait lorsque d'autres clients se déconnectent de la session).

La passerelle SIP OpenTok met automatiquement fin à un appel après 5 minutes d'inactivité (5 minutes sans réception de données multimédia). De plus, par mesure de sécurité, la passerelle SIP OpenTok met fin à tout appel SIP qui dure plus de 6 heures.

Envoi de signaux DTMF

Vous pouvez envoyer des signaux DTMF (Dual-tone multi-frequency) à des terminaux SIP à l'aide de l'API REST. Voir Envoi de chiffres DTMF aux clients SIP.

Les événements de téléphonie sont négociés via le protocole SDP et transmis sous forme de chiffres conformes aux normes RFC 4733/RFC 2833 au terminal distant.

Suivi de la progression de l'appel

Enregistrez-vous pour recevoir des rappels d'événements en temps réel pour votre appel SIP sur votre serveur d'application.

Les développeurs peuvent utiliser l'API REST d'OpenTok pour connecter leur plateforme SIP aux sessions OpenTok. Cela vous permet d'ajouter le flux audio (et vidéo, le cas échéant) d'un appel SIP en tant que flux dans la session OpenTok. Grâce à la surveillance des appels SIP, les développeurs peuvent suivre la progression de l'appel SIP depuis leur serveur d'applications. En vous inscrivant aux rappels, votre URL de rappel recevra des requêtes HTTP POST contenant des informations sur la progression de l'appel SIP.

Enregistrement des rappels

Les informations relatives aux événements liés aux appels SIP peuvent être transmises à des points de terminaison HTTP au sein de votre serveur. Chaque fois qu'une activité enregistrée se produit, une requête HTTP est envoyée depuis l'infrastructure OpenTok vers votre point de terminaison.

Pour enregistrer une URL de rappel :

  1. Visitez votre Page de compte de l'API Video de Vonage.

  2. Sélectionnez le projet OpenTok pour lequel vous souhaitez enregistrer un callback.

  3. Définissez l'URL de rappel dans la section Surveillance SIP.

    Sécuriser les rappels : Vous pouvez sécuriser les demandes de rappel de webhook avec des rappels signés, à l'aide d'un secret de signature. Voir Rappels sécurisés.

Surveillance de l'activité des appels SIP

Une fois correctement enregistrée, l'infrastructure OpenTok envoie des requêtes HTTP pour tous les appels SIP d'un projet spécifique. Cela permet de suivre l'évolution des appels SIP et d'intervenir en cas d'erreur. Vous pouvez vous attendre à :

  • Au moins un callCreated événement par appel

  • Au moins un callDestroyed événement par appel

  • Un nombre indéfini de callUpdated événements par appel

  • Un nombre indéfini de muteForced événements par appel

Appel créé

Votre terminal recevra le JSON suivant pour chaque appel SIP créé :

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "projectId":  "123456", 
  "event":  "callCreated",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Voir Propriétés JSON ci-dessous pour les descriptions.

Appel mis à jour

Votre terminal recevra le JSON suivant lorsque l'état de chaque appel SIP sera mis à jour :

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "projectId":  "123456",
  "event":  "callUpdated",
  "state":  "HANGUP",
  "timestamp":  1470257688309,
  "call": {
     "id":  "<conference-id>",
     "connectionId":  "<sip-ot-connection-id>",
     "createdAt":  1470257688143
  }
}

Voir Propriétés JSON ci-dessous pour les descriptions.

Appel détruit

Votre terminal recevra le JSON suivant à la fin de chaque appel SIP :

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "projectId":  "123456",
  "event":  "callDestroyed",
  "reason_code":  "400",
  "reason_message":  "Bad Request",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Voir Propriétés JSON ci-dessous pour les descriptions.

Sourdine forcée

Votre terminal recevra le JSON suivant lorsqu'un appel SIP sera mis en sourdine en raison d' un Forcer la mise en sourdine d'un événement de modération:

{
  "sessionId":  "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
  "projectId":  "123456",
  "event":  "muteForced",
  "timestamp":  1470257688309,
  "call": {
    "id":  "<conference-id>",
    "connectionId":  "<sip-ot-connection-id>",
    "createdAt":  1470257688143
  }
}

Voir Propriétés JSON ci-dessous pour les descriptions.

Notez que vous devez définir l'option observeForceMute (pour true) lors de l'établissement de la connexion SIP afin qu'elle prenne en compte un événement de modération par mise en sourdine forcée.

Propriétés JSON des événements de surveillance SIP

L'objet JSON comprend les propriétés suivantes :

  • sessionId -- L'identifiant de session associé à cet événement

  • projectId -- L'identifiant du projet associé à cet événement

  • event -- callCreated | callUpdated | callDestroyed | muteForced

  • reason_code -- Pour un callDestroyed événement, reason_code est réglé sur l'une des valeurs suivantes :

    • A code de réponse standard SIP pour détecter les erreurs lors de la négociation SIP

    • 700 -- « Fin normale de l'appel » -- Ce code indique que l'appel est en cours de clôture car l'un des utilisateurs participant à l'appel a demandé que celui-ci soit clôturé.

    • 703 -- "Effacement inattendu" -- Cette cause indique que l'appel est effacé de façon inattendue.

    • 704 — « Media Timeout » — Ce code indique que notre passerelle SIP n'a pas pu recevoir de trafic RTP provenant de l'autre terminal SIP.

    • 705 -- "Max Duration" -- L'appel a atteint la durée maximale.

    • 706 -- "Max Inactive" -- L'appel a atteint la durée maximale d'inactivité.

  • reason_message -- Pour un callDestroyed événement, reason_message est une chaîne de caractères décrivant la raison pour laquelle l'appel a été annulé.

  • state -- Pour un callUpdated événement, state est réglé sur l'une des valeurs suivantes :

    • DIALING -- Un appel SIP a été lancé

    • RINGING -- L'appel SIP est en train de sonner

    • ON_HOLD -- L'appel SIP est en attente

    • ACTIVE -- Un appel SIP a été pris et est en cours.

    • HANGUP -- Un appel SIP terminé

  • timestamp -- L'horodatage de l'événement, en millisecondes depuis l'époque Unix.

  • call -- Un objet définissant la connexion, contenant les propriétés suivantes :

    • id -- L'identifiant de la conférence

    • connectionId -- L'identifiant de connexion du client SIP

    • createdAt —- La valeur de l'horodatage, en millisecondes depuis l'époque Unix, correspondant au moment où l'appel a été créé

Considérations relatives à la sécurité

Vonage recommande certaines bonnes pratiques lors de l'utilisation de l'interface SIP avec vos serveurs SIP. Ces pratiques visent à limiter les risques d'attaques en mettant en place des mécanismes permettant de vérifier l'authenticité et la légitimité des appels SIP reçus par votre serveur, ainsi que de chiffrer l'ensemble des données de signalisation et multimédia :

  • Utilisez le protocole TLS et activez les appels sécurisés (SRTP) pour la signalisation afin d'éviter tout risque d' interception des communications.

  • Activez l'authentification SIP sur votre serveur. Sinon, toute personne connaissant votre URI SIP pourrait envoyer des appels vers votre serveur.

Contactez nous si vous avez des questions supplémentaires.

Détails techniques

Prise en charge de la norme RFC3550 (RTP/RTCP) : Le trafic multimédia peut être chiffré (SRTP) ou non chiffré (RTP en clair). En cas de chiffrement, les protocoles DTLS et SDES sont tous deux pris en charge.

Prise en charge des codecs : La passerelle SIP OpenTok prend en charge les codecs audio OPUS, G.711 et G.722, ainsi que les codecs vidéo H.264 et VP8. La vidéo SIP est limitée à une résolution de 480p à un débit de 800 kbps.

Signalisation : La passerelle SIP OpenTok prend en charge la norme RFC 3261 (SIP) sur UDP, TCP et TLS. Contactez Vonage si vous avez besoin d'informations ou d'assistance concernant une extension spécifique.

La passerelle SIP OpenTok rejettera tout message SIP provenant d'une plateforme SIP tierce, à moins qu'il ne s'inscrive dans le cadre d'un dialogue SIP lancé par la passerelle SIP OpenTok. Les appels lancés via la passerelle SIP OpenTok peuvent être mis en attente à l'aide soit d'un re-­INVITE avec le sendonly/inactive dans le SDP ou un re-­INVITE avec le port 0 dans le SDP.

Autres considérations : Les médias précoces sont désactivés.

Exemples d'applications

Les SDK serveur OpenTok pour Node et PHP proposent des exemples d'appels à l'API OpenTok Dial utilisant la fonctionnalité d'interconnexion SIP d'OpenTok. Consultez les exemples à l'adresse suivante :

Vous trouverez ci-dessous des exemples d'intégrations SIP utilisant OpenTok SIP Interconnect avec Nexmo :

FAQ

Qu'est-ce que le SIP ? Pourquoi le SIP est-il important ?

Le protocole d'initiation de session (SIP) est un protocole de communication permettant de signaler et de contrôler les sessions de communication multimédia. Les Applications les plus courantes du SIP sont la téléphonie sur Internet pour les appels vocaux et vidéo, ainsi que la messagerie instantanée, sur les réseaux IP (Internet Protocol).

Dans notre cas, il sert à établir un appel depuis les sessions OpenTok vers un serveur SIP tiers. Une fois l'appel établi, le flux audio (et vidéo, le cas échéant) est transmis via le protocole RTP.

Quelle est la différence entre le protocole SIP et le réseau PSTN ? OpenTok propose-t-il une passerelle PSTN ?

Le RTC est le réseau téléphonique traditionnel. Le RTC n'est pas un réseau IP et n'utilise pas le protocole SIP, mais de nombreux fournisseurs, comme Nexmo, disposent de passerelles pour convertir les protocoles SIP en protocoles RTC. De cette manière, un appel SIP sur IP est converti en appel téléphonique.

Concrètement, même si la Video API de Vonage ne prend pas en charge les appels vers le réseau PSTN, nous parvenons à les réaliser en utilisant les appels SIP. Il suffit ensuite de trouver un fournisseur capable de convertir ces appels SIP en appels vers le réseau PSTN.

Puis-je appeler des téléphones classiques grâce à la fonctionnalité d'interconnexion SIP d'OpenTok ?

La fonction d'interconnexion SIP d'OpenTok permet aux partenaires de lancer des appels vers n'importe quel terminal SIP. Pour passer ou recevoir des appels depuis ou vers un téléphone classique, les clients ont besoin d'une passerelle de leur côté afin de convertir l'appel SIP vers les protocoles utilisés dans les réseaux de téléphonie mobile ou fixe.

Existe-t-il un moyen de gérer les appels sortants ou entrants à partir d'un numéro de téléphone ordinaire (RTPC) ?

Grâce à OpenTok SIP Interconnect, les clients peuvent passer des appels sortants depuis une session OpenTok vers n'importe quelle destination SIP. De plus, ils peuvent configurer une passerelle SIP (la leur ou celle d'un tiers) pour passer des appels sortants vers un numéro de téléphone classique.

Bien que l'API d'interconnexion SIP ne prenne pas en charge les appels SIP entrants, les clients peuvent mettre en place la numérotation depuis un téléphone classique (PSTN) en utilisant une passerelle SIP (la leur ou celle d'un tiers) pour relier l'appel entrant reçu depuis des téléphones classiques à l'appel SIP sortant provenant d'OpenTok. Vous trouverez des exemples d'applications illustrant le cas d'utilisation des conférences ici.

L'interconnexion SIP d'OpenTok prend-elle en charge l'envoi de vidéos ?

Oui. video à true lors de l'établissement d'un appel SIP à l'aide de la Méthode de l'API REST. La vidéo SIP est limitée à une résolution de 480p à un débit de 800 kbps.

Y a-t-il une différence notable dans la qualité audio perçue sur le point d'extrémité WebRTC par rapport au point d'extrémité SIP ?

L'objectif est d'obtenir la même qualité, mais avec une latence supplémentaire au niveau du point d'extrémité SIP.

Comment fonctionne la fonctionnalité d'archivage avec OpenTok SIP Interconnect ?

La fonctionnalité d'archivage fonctionne exactement comme c'est le cas aujourd'hui pour une session WebRTC. Jusqu'à 16 flux vidéo et les 50 premiers flux audio, y compris les flux audio et vidéo SIP, feront partie de l'archive.

Comment l'utilisateur navigue-t-il dans le SVI ? Y aura-t-il un clavier de numérotation dans l'application web/mobile ?

Vous pouvez utiliser l'API REST pour envoyer des signaux DTMF à des clients SIP afin de prendre en charge les systèmes de réponse vocale interactive (IVR). Voir Envoi de signaux DTMF.

Avec quels serveurs SIP l'OpenTok SIP Interconnect est-il compatible ?

Nous avons testé l'interopérabilité avec certains des équipements de télécommunication les plus populaires (ACME packet, Broadsoft), certaines plateformes SIP populaires (Nexmo, et autres), et le serveur SIP open-source le plus populaire (freeswitch). Il est impossible de garantir l'interopérabilité avec chaque serveur SIP, mais nous essayons de limiter l'utilisation des extensions/fonctionnalités SIP afin de réduire les risques d'échec. Jusqu'à présent, nous n'avons jamais eu à modifier notre solution pour interopérer avec un nouveau serveur SIP.

Comment peut-on mettre fin à un appel vers un client SIP connecté à une session OpenTok ?

  • Utilisation de l'API client existante — Un client Web (JavaScript) connecté à une session OpenTok et disposant de privilèges de modérateur peut forcer d'autres clients, y compris les clients SIP, à se déconnecter d'une session.

  • L'utilisation de la API REST pour la modération côté serveur — Si les clients WebRTC se trouvent sur des appareils mobiles ou si le client ne souhaite pas accorder de droits de modérateur aux clients, les serveurs d'applications peuvent envoyer une requête HTTP DELETE à un client connecté afin de forcer la déconnexion depuis le serveur.

Problème connu

Lorsqu'un appel vidéo SIP est établi vers un client SIP Linphone et que cet appel est négocié avec le codec VP8, la vidéo entrante provenant de Linphone et destinée à la passerelle SIP OpenTok s'affiche sous forme d'images noires.