Serveurs TURN configurables

Vue d'ensemble

Cette fonction est disponible en tant que fonction complémentaire.

Client SDK : Veuillez noter que votre ID de l'application est votre Clé API.

Vous pouvez personnaliser l'utilisation du serveur TURN pour chaque client de la session de la manière suivante :

Vous pouvez ajouter une liste de vos propres serveurs TURN que le client utilisera.
Vous pouvez décider si le client doit utiliser exclusivement vos serveurs TURN ou les utiliser en plus des serveurs TURN de Vonage. en plus des serveurs TURN de Vonage

L'ajout de vos propres serveurs TURN peut aider les utilisateurs à se connecter dans des environnements réseau restrictifs où les serveurs TURN de Vonage peuvent être bloqués. les serveurs TURN de Vonage pourraient être bloqués.

Si vous choisissez d'ignorer les serveurs TURN de Vonage et de n'utiliser que vos propres serveurs TURN, vous pouvez vous assurer que les flux de médias ne quittent jamais votre réseau.

Vous pouvez ajouter vos propres serveurs TURN pour chaque client se connectant à la session, en utilisant OpenTok.js (pour les clients web), le SDK iOS ou le SDK Android. L'API de serveur TURN personnalisé personnalisée a été ajoutée dans la version 2.13.0 de ces SDK clients.

Il existe également un Proxy IP qui vous permet d'utiliser votre propre d'utiliser votre propre serveur proxy pour acheminer les hors média le trafic, tel que les appels à l'API Video, les connexions WebSocket et le trafic de journal, les connexions WebSocket et le trafic des journaux.

OpenTok.js (v2.13.0+)

Les options du paramètre OT.initSession() comprend une méthode non documentée iceConfig propriété. Ce bien comprend les propriétés suivantes :

includeServers (Chaîne) - Définir ceci à 'custom' et le client n'utiliseront que les serveurs TURN personnalisés que vous fournissez dans le customServers réseau. La valeur de ce tableau est 'all' (par défaut) et le client utilisera à la fois les serveurs TURN personnalisés que vous fournissez et les serveurs TURN de Vonage.
transportPolicy (Chaîne) - Définir ceci à 'all' (par défaut) et le client utilisera tous les types de transport ICE (tels que host, srflx et TURN) pour établir la connectivité média. Définir à 'relay' pour forcer la connectivité via TURN toujours et ignorer tous les autres candidats ICE .
customServers (Array) - Définit un tableau d'objets définissant vos serveurs TURN personnalisés. Chaque objet correspond à un serveur TURN personnalisé et comprend les propriétés suivantes :
- urls (String or Array of Strings) - Une chaîne ou un tableau de chaînes, où chaque chaîne est une URL supportée par le serveur TURN (il ne peut s'agir que d'une seule URL).
- username (Chaîne) - Le nom d'utilisateur du serveur TURN défini dans cet objet.
- credential (Chaîne) - La chaîne d'authentification du serveur TURN définie dans cet objet. objet.

Remarque : Pour que le client n'utilise que les serveurs TURN que vous avez spécifiés (et n'utilise pas les serveurs TURN de Vonage) les serveurs TURN de Vonage) : définissez l'option includeServers à la propriété 'custom', fixer le transportPolicy à la propriété 'relay'et définir le customServers pour répertorier vos serveurs serveurs TURN.

Pour mettre à jour dynamiquement les informations d'identification personnalisées de TURN, utilisez l'option Session.setIceConfig() méthode.

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

const session = OT.initSession(projectId, sessionId, {
  iceConfig: {
    includeServers: 'custom',
    transportPolicy: 'relay',
    customServers: [
      {
        urls: [
          'turn:123.124.125.126:3478?transport=udp',
          'turn:123.124.125.126:3478?transport=tcp'
        ],
        username: 'webrtc',
        credential: 'foO0Bar1'
      },
      {
          urls: [
            'turns:turntls.example.com:3478?transport=tcp'
          ],
          username: 'webrtc',
          credential: 'foO0Bar2',
      },
    ],
  },
});

SDK Android

Les Session.Builder comprend deux méthodes pour configurer l'utilisation du serveur TURN pour le client :

Session.Builder.setCustomIceServers() - Appeler cette méthode pour ajouter une liste de serveurs TURN personnalisés pour le client.
Session.Builder.setIceRouting() - Appeler cette méthode pour ajouter la limitation des options ICE pour le client.

En plus des deux nouvelles méthodes, deux nouveaux enums définissent les options du serveur TURN :

IncludeServers - Inclut des options pour utiliser uniquement les serveurs personnalisés ou à la fois les serveurs de Vonage et les serveurs personnalisés. les serveurs Vonage et les serveurs personnalisés.
TransportPolicy - Décrit la méthode de routage à utiliser.

Remarque : Pour que le client n'utilise que les serveurs TURN que vous avez spécifiés (et non les serveurs TURN de Vonage), appelez les méthodes suivantes de Session.Builder. les serveurs TURN de Vonage), appelez les méthodes suivantes de l'objet Session.Builder que vous utilisez pour créer l'objet Session :

setCustomIceServers() - Passer une liste d'objets IceServer (correspondant à vos serveurs TURN personnalisés) en tant qu'objet serverList et passer en IncludeServers.TURN en tant que config paramètre.
setIceRouting() - Entrer TransportPolicy.Relay.

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

List<IceServer> serverList = new IceServer(
  'turn:123.124.125.126:3478?transport=udp', // TURN server URL
  'webrtc', // Username
  'foO0Bar1' // Credential
);
mSession = new Session.Builder(this, apiKey, sessionId)
  .setCustomIceServers(serverList, IncludeServers.Custom)
  .setIceRouting(TransportPolicy.TURN)
  .build();
mSession.setSessionListener(this);
mSession.connect(token);

SDK iOS

Lors de l'initialisation d'un objet OTSession, vous devez définir l'attribut OTSessionSettings.iceConfig pour définir la configuration personnalisée du serveur TURN pour le client. La classe OTSessionICEConfig définit la propriété OTSessionSettings.iceConfig propriété.

Remarque : Pour que le client n'utilise que les serveurs TURN que vous avez spécifiés (et non les serveurs TURN de Vonage). les serveurs TURN de Vonage), appelez l'option [OTSessionSettings addICEServerWithURL:] de l'objet de l'objet OTSessionSettings que vous utilisez pour créer l'objet OTSession. Définissez ensuite les propriétés suivantes de l'objet OTSessionSettings propriétés suivantes de l'objet OTSessionSettings :

includeServers - Définissez ce paramètre sur OTSessionICEIncludeServersCustom.
transportPolicy - Réglez ce paramètre sur OTSessionICETransportRelay.

Vous pouvez régler la OTSessionICEConfig.filterOutLanCandidates pour d'empêcher la souscription à des clients sur le même réseau local dans les sessions relayées, ce qui fait que l'application demande la permission à l'utilisateur dans iOS 14+. Notez que cette fonctionnalité n'est pas nécessitent le module complémentaire configurable TURN. Pour plus d'informations, voir ce sujet.

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

OTSessionICEConfig *myICEServerConfiguration = [[OTSessionICEConfig alloc] init];
myICEServerConfiguration.includeServers = OTSessionICEIncludeServersCustom;
myICEServerConfiguration.transportPolicy = OTSessionICETransportForceTurn

NSError *error = nil;
[myICEServerConfiguration addICEServerWithURL:@"turn:123.124.125.126:3478?transport=udp"
                                     userName:@"webrtc"
                                   credential:@"foO0Bar1"
                                        error:&error];

OTSessionSettings *settings = [[OTSessionSettings alloc] init];
settings.iceConfig = myICEServerConfiguration;

_session = [[OTSession alloc] initWithApiKey:kApiKey
                                   sessionId:kSessionId
                                    delegate:self
                                    settings:settings];

SDK Windows

Utilisez la classe IceConfig pour définir la configuration personnalisée de l'ICE à utiliser par le client.

Les IceConfig() comprend les paramètres suivants :

customIceServers -- Fixe ceci à Une liste d'objets IceServer, représentant les serveurs des serveurs TURN personnalisés à utiliser par le client. Pour chaque IceServer, vous définissez l'URL, le nom d'utilisateur et la chaîne d'authentification du serveur TURN personnalisé
transportPolicy -- Fixer une valeur dans le ICETransport enum :
- All -- Le client utilisera tous les types de candidats ICE (tels que host, srflx et relay) pour établir la connectivité média.
- Relayed -- Le client forcera toujours la connectivité par TURN et ignorera tous les autres candidats ICE. et ignorera tous les autres candidats ICE.
includeServers -- Fixer une valeur dans le IncludeServers enum :
- All -- Le client utilisera les serveurs TURN de Vonage en plus des serveurs TURN personnalisés que vous fournirez. les serveurs TURN personnalisés que vous fournissez.
- Custom -- Le client n'utilisera que les serveurs TURN personnalisés que vous lui fournirez.

La classe Session.Builder comprend une fonction IceConfig propriété. Définissez cette propriété à un objet IceConfig lors de la construction de l'objet Session. L'exemple suivant montre comment configurer les serveurs TURN pour le client :

SDK macOS

Le type otc_custom_ice_config définit une structure qui comprend les membres suivants :

num_ice_servers -- Le nombre de serveurs ICE
ice_url -- Un tableau de chaînes de caractères spécifiant les URL de votre serveur ICE.
ice_user -- Un tableau de chaînes de caractères spécifiant les noms d'utilisateurs des serveurs TURN.
ice_credential -- Un tableau de chaînes de caractères spécifiant les chaînes d'authentification pour les serveurs TURN. Appeler le otc_session_settings_set_custom_ice_config() et de passer dans la fonction le otc_custom_ice_config instance :

otc_session_settings_set_custom_ice_config(session_settings,
                                           &ice_config);

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

// Provide the ICE configuration here.
struct otc_custom_ice_config ice_config;
ice_config.num_ice_servers = 1;
ice_config.ice_url = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_url[0] = strdup("turn:123.124.125.126:3478?transport=udp");
ice_config.ice_user = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_user[0] = strdup("webrtc");
ice_config.ice_credential = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_credential[0] = strdup("foO0Bar1");
ice_config.force_turn = OTC_TRUE;
ice_config.use_custom_turn_only = OTC_FALSE;
otc_session_settings *session_settings = otc_session_settings_new();
if (session_settings != NULL) {
  otc_session_settings_set_custom_ice_config(session_settings,
                                             &ice_config);
}
otc_session *session = NULL;
session = otc_session_new_with_settings(API_KEY,
                                        SESSION_ID,
                                        &session_callbacks,
                                        session_settings);
if (session == NULL) {
  printf("Could not create session successfully");
  return EXIT_FAILURE;
}
otc_session_connect(session, TOKEN);

SDK Linux

Le type otc_custom_ice_config définit une structure qui comprend les membres suivants :

num_ice_servers -- Le nombre de serveurs ICE
ice_url -- Un tableau de chaînes de caractères spécifiant les URL de votre serveur ICE.
ice_user -- Un tableau de chaînes de caractères spécifiant les noms d'utilisateurs des serveurs TURN.
ice_credential -- Un tableau de chaînes de caractères spécifiant les chaînes d'authentification pour pour les serveurs TURN.

Appeler le otc_session_settings_set_custom_ice_config() et de passer dans la fonction le otc_custom_ice_config instance :

otc_session_settings_set_custom_ice_config(session_settings,
                                           &ice_config);

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

// Provide the ICE configuration here.
struct otc_custom_ice_config ice_config;
ice_config.num_ice_servers = 1;
ice_config.ice_url = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_url[0] = strdup("turn:123.124.125.126:3478?transport=udp");
ice_config.ice_user = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_user[0] = strdup("webrtc");
ice_config.ice_credential = (char **)malloc(sizeof(char *) * ice_config.num_ice_servers);
ice_config.ice_credential[0] = strdup("foO0Bar1");
ice_config.force_turn = OTC_TRUE;
ice_config.use_custom_turn_only = OTC_FALSE;

otc_session_settings *session_settings = otc_session_settings_new();
if (session_settings != NULL) {
  otc_session_settings_set_custom_ice_config(session_settings,
                                             &ice_config);
}

otc_session *session = NULL;

session = otc_session_new_with_settings(API_KEY,
                                        SESSION_ID,
                                        &session_callbacks,
                                        session_settings);

if (session == NULL) {
  printf("Could not create session successfully");
  return EXIT_FAILURE;
}

otc_session_connect(session, TOKEN);

SDK React Native

Les options prop de la OTSession comprend un iceConfig propriété. Cet objet comprend les propriétés suivantes :

includeServers (Chaîne) - Définir ceci à 'custom' et le client n'utiliseront que les serveurs TURN personnalisés que vous fournissez dans le customServers réseau. La valeur de ce tableau est 'all' (par défaut) et le client utilisera à la fois les serveurs TURN personnalisés que vous fournissez et les serveurs TURN OpenTok.
transportPolicy (Chaîne) - Définir ceci à 'all' (par défaut) et le client utilisera tous les types de transport ICE (tels que host, srflx et TURN) pour établir la connectivité média. Définir à 'relay' pour forcer la connectivité via TURN toujours et ignorer tous les autres candidats ICE .
customServers (Array) - Définit un tableau d'objets définissant vos serveurs TURN personnalisés. Chaque objet correspond à un serveur TURN personnalisé et comprend les propriétés suivantes :
- urls (String or Array of Strings) - Une chaîne ou un tableau de chaînes, où chaque chaîne est une URL supportée par le serveur TURN (il ne peut s'agir que d'une seule URL).
- username (Chaîne) - Le nom d'utilisateur du serveur TURN défini dans cet objet.
- credential (Chaîne) - La chaîne d'authentification du serveur TURN définie dans cet objet. objet.

Remarque : Pour que le client n'utilise que les serveurs TURN que vous avez spécifiés (et n'utilise pas les serveurs TURN d'OpenTok) les serveurs TURN d'OpenTok) : mettre l'option includeServers à la propriété 'custom', fixer le transportPolicy à la propriété 'relay'et définir le customServers pour répertorier vos serveurs serveurs TURN.

L'exemple suivant montre comment configurer les serveurs TURN pour le client :

<OTSession
  applicationId="your-application-id"
  sessionId="your-session-id"
  token="your-session-token"
  options={{
    iceConfig:{
      transportPolicy: 'all',
      includeServers: 'all',
      customServers: [
        {
        urls: [
          'turn:123.124.125.126:3478?transport=udp',
          'turn:123.124.125.126:3478?transport=tcp'
        ],
        username: 'webrtc',
        credential: 'foO0Bar1'
        },
      ],
    }
  }}
>
  <OTPublisher style={{ width: 600, height: 400 }}/>
  <OTSubscriber style={{ width: 600, height: 400 }} />
</OTSession>

Problème connu

Si vous paramétrez un client pour qu'il utilise toujours les serveurs TURN dans une zone session relayéeil ne pourra pas s'abonner à ses propres flux (flux qu'il publie). s'abonner à ses propres flux (flux qu'il publie).

FAQ

L'API configurable de TURN résout-elle le problème pour le trafic HTTP ?

Non. Le TURN configurable répond aux préoccupations des clients concernant la connexion à des points d'extrémité de confiance pour le trafic média uniquement. pour le trafic média uniquement.

Pour le trafic HTTP, les clients devront effectuer l'une des opérations suivantes :

Liste blanche des noms de domaine vonage et opentok :
- *.opentok.com
- *.tokbox.com
- *.vonage.com
Liste blanche des blocs d'adresses IP fournis pour l'API Video de Vonage.
Utilisez les paramètres de proxy web sur les clients pour acheminer tout le trafic HTTPS de Vonage à travers vos propres cibles. par l'intermédiaire de vos propres cibles. Voir la section Exigences en matière de proxy ici.

Comment le chemin média est-il sélectionné entre les cibles TURN disponibles. Tient-il compte de la latence aller-retour, ou est-il influencé par l'ordre dans lequel nous listons les cibles, ou encore est-il aléatoire ?

L'ordre des serveurs TURN n'est pas garanti sur la base de la liste fournie. Au lieu de cela, lorsque le média commence à l'implémentation de l'ICE sélectionne le candidat/serveur qui a la meilleure connectivité et qui a négocié avec succès en premier. négocié avec succès en premier.

Si l'URL du serveur TURN correspond à plusieurs adresses IP, comment le serveur TURN spécifique est-il sélectionné pour la session ? Est-ce aléatoire ?

La plupart des implémentations, y compris celles utilisées dans Chrome et Firefox, prennent la première IP renvoyée par la recherche DNS. Il en résulte généralement une sélection aléatoire de type round-robin.

Si des serveurs TURN TCP et UDP sont fournis et joignables, est-il possible de donner la priorité aux cibles UDP et de ne revenir au TCP qu'en cas de besoin ?

Les candidats au relais UDP seront préférés aux candidats au relais TCP car ces candidats ont une préférence de type local plus faible et donc une priorité plus faible. préférence de type local plus faible et donc une priorité plus faible. Se référer à RFC 8445 pour plus de détails. L'ordre des serveurs ICE transmis n'a pas d'influence.

Un même client peut-il utiliser différents chemins médiatiques pour différents flux ?

Oui, il s'agit d'un comportement attendu car Vonage traite chaque flux média séparément.

Quel est le degré de contrôle de l'API TURN configurable sur la sélection du chemin d'accès au média ?

La sélection du chemin média est gérée par ICE (Interactive Connectivity Establishment) au sein de WebRTC, et nous n'avons aucun moyen de modifier ce comportement. nous n'avons aucun moyen de modifier ce comportement. L'API TURN configurable permet uniquement de modifier la liste des serveurs ICE fournie par le client à WebRTC et n'influence pas le processus de sélection. liste des serveurs ICE fournie par le client à WebRTC et n'influence pas le processus de sélection.

Est-ce que la connexion directe au serveur média de Vonage par UDP est toujours préférable ?

Oui, la connexion directe à Vonage Media Server est toujours préférable. Elle passe à l'utilisation de TURN si la connexion à Vonage Media Server échoue ou si l'option "Force TURN" est utilisée dans l'API configurable. dans l'API configurable de TURN.

Puis-je utiliser plusieurs serveurs TURN du même type pour la répartition de charge ?

Cela n'est pas recommandé car le client choisit un serveur au hasard et ce serveur peut changer pendant la durée de la connexion.

Comment équilibrer la charge de mon déploiement de serveurs TURN personnalisés ?

Veuillez nous contacter pour plus d'informations.

Le serveur TURN peut-il décrypter les médias ?

Non, le serveur TURN n'a pas accès aux clés SRTP qui sont échangées avec DTLS-SRTP et uniquement disponibles pour les endpoints de la connexion.

Que se passe-t-il si un serveur TURN tombe en panne pendant une session et comment le récupérer ?

Si un serveur TURN tombe en panne alors qu'il est en cours d'utilisation, la connexion du client sera interrompue. Le client essaiera de rétablir la connexion en utilisant un redémarrage ICE.

Comment tester un serveur TURN ?

Vous pouvez tester votre serveur TURN soit en utilisant Page de test de la glace en filet ou coturn turnutils_uclient.

Navigation

Serveurs TURN configurables

Vue d'ensemble

OpenTok.js (v2.13.0+)

SDK Android

SDK iOS

SDK Windows

SDK macOS

SDK Linux

SDK React Native

Problème connu

FAQ

L'API configurable de TURN résout-elle le problème pour le trafic HTTP ?

Comment le chemin média est-il sélectionné entre les cibles TURN disponibles. Tient-il compte de la latence aller-retour, ou est-il influencé par l'ordre dans lequel nous listons les cibles, ou encore est-il aléatoire ?

Si l'URL du serveur TURN correspond à plusieurs adresses IP, comment le serveur TURN spécifique est-il sélectionné pour la session ? Est-ce aléatoire ?

Si des serveurs TURN TCP et UDP sont fournis et joignables, est-il possible de donner la priorité aux cibles UDP et de ne revenir au TCP qu'en cas de besoin ?

Un même client peut-il utiliser différents chemins médiatiques pour différents flux ?

Quel est le degré de contrôle de l'API TURN configurable sur la sélection du chemin d'accès au média ?

Est-ce que la connexion directe au serveur média de Vonage par UDP est toujours préférable ?

Puis-je utiliser plusieurs serveurs TURN du même type pour la répartition de charge ?

Comment équilibrer la charge de mon déploiement de serveurs TURN personnalisés ?

Le serveur TURN peut-il décrypter les médias ?

Que se passe-t-il si un serveur TURN tombe en panne pendant une session et comment le récupérer ?

Comment tester un serveur TURN ?