4.1.1. Constructor (Constructeur)
4.1.1. Constructor (Constructeur)
Le constructeur PeerConnection permet à l'application de spécifier des paramètres globaux pour la session multimédia, tels que les serveurs STUN/TURN et les informations d'identification à utiliser lors de la collecte des candidats, ainsi que la politique initiale des candidats ICE et la taille du pool, ainsi que la politique de bundle à utiliser.
Si une politique de candidats ICE est spécifiée, elle fonctionne comme décrit dans la Section 3.5.3, obligeant l'implémentation JSEP à ne présenter que les candidats autorisés (y compris tout filtrage interne à l'implémentation) à l'application et à n'utiliser que ces candidats pour les vérifications de connectivité. L'ensemble des politiques disponibles est le suivant:
all: Tous les candidats autorisés par la politique d'implémentation seront collectés et utilisés.
relay: Tous les candidats sauf les candidats relais seront filtrés. Cela masque les informations de localisation qui pourraient être déterminées par le pair distant à partir des candidats reçus. Selon la façon dont l'application déploie et choisit les serveurs relais, cela pourrait masquer la localisation au niveau métropolitain ou même mondial.
La politique par défaut des candidats ICE DOIT être définie sur "all", car il s'agit généralement de la politique souhaitée et cela réduit également généralement l'utilisation des ressources du serveur TURN de l'application de manière significative.
Si une taille est spécifiée pour le pool de candidats ICE, cela indique le nombre de composants ICE pour lesquels pré-collecter des candidats. Étant donné que la pré-collecte entraîne l'utilisation des ressources du serveur STUN/TURN pendant des périodes potentiellement longues, cela NE DOIT se produire que sur demande de l'application, et par conséquent la taille par défaut du pool de candidats DOIT être zéro.
L'application peut spécifier sa politique préférée concernant l'utilisation du bundle, le mécanisme de multiplexage défini dans [RFC8843]. Quelle que soit la politique, l'application essaiera toujours de négocier le bundle sur un seul transport et offrira un seul groupe de bundle sur toutes les sections "m="; l'utilisation de ce transport unique dépend de l'acceptation du bundle par le répondeur. Cependant, en spécifiant une politique de la liste ci-dessous, l'application peut contrôler exactement à quel point elle essaiera de regrouper les flux multimédias, ce qui affecte la façon dont elle interagira avec un point de terminaison non conscient du bundle. Lors de la négociation avec un point de terminaison non conscient du bundle, seuls les flux non marqués comme flux bundle uniquement seront établis.
L'ensemble des politiques disponibles est le suivant:
balanced: La première section "m=" de chaque type (audio, vidéo ou application) contiendra des paramètres de transport, ce qui permettra à un répondeur de débundler cette section. La deuxième et toutes les sections "m=" suivantes de chaque type seront marquées comme bundle uniquement. Le résultat est que s'il y a N types de médias distincts, alors les candidats seront collectés pour N flux multimédias. Cette politique équilibre le désir de multiplexer avec la nécessité de s'assurer que l'audio et la vidéo de base peuvent encore être négociés dans les cas hérités. Lorsqu'il agit en tant que répondeur, s'il n'y a pas de groupe de bundle dans l'offre, l'implémentation rejettera toutes les sections "m=" sauf la première de chaque type.
max-compat: Toutes les sections "m=" contiendront des paramètres de transport; aucune ne sera marquée comme bundle uniquement. Cette politique permettra à tous les flux d'être reçus par des points de terminaison non conscients du bundle, mais nécessitera la collecte de candidats séparés pour chaque flux multimédia.
max-bundle: Seule la première section "m=" contiendra des paramètres de transport; tous les flux autres que le premier seront marqués comme bundle uniquement. Cette politique vise à minimiser la collecte de candidats et à maximiser le multiplexage, au prix d'une moindre compatibilité avec les points de terminaison hérités. Lorsqu'il agit en tant que répondeur, l'implémentation rejettera toutes les sections "m=" autres que la première section "m=", à moins qu'elles ne soient dans le même groupe de bundle que cette section "m=".
Comme elle offre le meilleur compromis entre performance et compatibilité avec les points de terminaison hérités, la politique de bundle par défaut DOIT être définie sur "balanced".
L'application peut spécifier sa politique préférée concernant l'utilisation du multiplexage RTP/RTCP [RFC5761] en utilisant l'une des politiques suivantes:
negotiate: L'implémentation JSEP collectera à la fois des candidats RTP et RTCP mais offrira également "a=rtcp-mux", permettant ainsi la compatibilité avec des points de terminaison multiplexés ou non multiplexés.
require: L'implémentation JSEP ne collectera que des candidats RTP et insérera une indication "a=rtcp-mux-only" dans toutes les nouvelles sections "m=" des offres qu'elle génère. Cela réduit de moitié le nombre de candidats que l'offrant doit collecter. L'application d'une description avec une section "m=" qui ne contient pas d'attribut "a=rtcp-mux" provoquera le renvoi d'une erreur.
La politique de multiplexage par défaut DOIT être définie sur "require". Les implémentations PEUVENT choisir de rejeter les tentatives de l'application de définir la politique de multiplexage sur "negotiate".