Google prévoit de faire passer l'implémentation WebRTC de Chrome du format SDP actuel (appelé « Plan B ») à un format conforme aux normes ("plan unifié", brouillon-ietf-rtcweb-jsep) au cours des deux prochains trimestres.
Le plan comprend cinq phases et une fonctionnalité d'API temporaire.
Qui sera concerné ?
Personnes qui utilisent plusieurs pistes audio ou vidéo au même titre PeerConnection devra tester son produit dans le cadre du plan unifié et l'adapter en conséquence. Lorsqu'un appel est initié depuis un point de terminaison autre que Chrome et auquel une réponse a été envoyée par Chrome, vous devrez peut-être modifier la forme de l'offre. Personnes qui effectuer une analyse SDP détaillée et vous occuper des attributs msid devront vérifier que son code d'analyse utilise le nouveau format (a=msid). Les détails sur si si des modifications sont nécessaires, et la façon dont les applications doivent changer dépendante. Nous pensons que presque toutes les applications qui n'utilisent qu'un seul fichier audio et une seule piste vidéo par RTCPeerConnection ne sera pas affectée par ce changement.
Fonctionnalité de l'API
Nous ajoutons une nouvelle fonctionnalité à la RTCConfiguration de RTCPeerConnection:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
Le RTCConfiguration peut être transmis au constructeur d'un RTCPeerConnection, Toutes les offres et réponses créées seront au format "Plan unifié". Les appels à setLocalDescription et setRemoteDescription attendent également le SDP au format "Forfait unifié" si elle est dans l'ancien format Chrome, toutes, sauf la première piste audio et la première vidéo, sont ignorées.
Il existe aussi un indicateur de ligne de commande (–enable-features=RTCUnifiedPlanByDefault dans Chrome M71 et versions ultérieures, –enable-blink-features=RTCUnifiedPlanByDefault dans versions antérieures) qui permet de définir la valeur par défaut de cet indicateur sur "unified-plan".
Phases
Phase 1: Mise en œuvre du plan unifié
Au cours de cette phase, le plan unifié a été développé en mode expérimentation disponible depuis M65. Avant la phase 2, il était plus sage de tester avec Chrome Canary à l'aide de "–enable-blink-features=RTCUnifiedPlan".
Phase 2: Disponibilité générale de la fonctionnalité de l'API
Publication dans M69 (version bêta d'août 2018, version stable en septembre 2018)
Dans cette phase, la valeur par défaut de l'indicateur sdpSemantics était "plan-b". Dans Phase 2 : les personnes dont les implémentations dépendaient du format SDP ont été exécuter des tests pour vérifier le fonctionnement de leurs applications lorsque le plan unifié est utiliser. Pour les applications compatibles avec Firefox, exercice: faites comme pour Firefox.
La valeur par défaut de l'indicateur sdpSemantics peut être modifiée dans "chrome://flags". recherchez la fonctionnalité "WebRTC: Use Unified Plan SDP Semantics by default".
Phase 3: Changer la valeur par défaut
La date de transition était M72 (version bêta de décembre 2018, version stable en janvier 2019).
Au cours de cette phase, nous avons remplacé la valeur par défaut de l'indicateur sdpSemantics par "unified-plan". Les applications qui ont découvert qu'elles avaient besoin de plus de temps pour Convertissez et définissez explicitement l'indicateur sdpSemantics sur "plan-b" afin de récupérer le comportement antérieur.
Phase 4: Préparez le "Plan B"
Dans cette phase, définir l'indicateur sdpSemantics sur "plan-b" génère une exception. généré. Il a été intégré dans Canary à partir de M93. Depuis M96, l'exception était inclus dans toutes les versions, y compris la version stable.
Au cours de cette phase, un essai avant arrêt permettaient d'utiliser le forfait B sans générer d'exception, mais a cessé de fonctionner le 25 mai 2022.
Phase 5: Supprimer le "plan B" de Chromium
À la fin de l'essai, le forfait B sera supprimé de Chrome. À ce stade, l'indicateur sdpSemantics est supprimé. Tentative de définition sur "plan-b"... ne se produira pas génère une exception, qui n'aura plus aucun effet.
Le plan B est toujours disponible derrière des indicateurs spéciaux ou des builds spéciaux, mais le plan complet la suppression du code aura lieu au 2e semestre 2022.
Phase 6: Arrêt du plan B et suppression de WebRTC
Le plan B est déjà marqué comme obsolète dans WebRTC, mais il est toujours disponible. Cette suppression devrait avoir lieu en 2023.
Préparation de votre application pour le forfait unifié
Pour en savoir plus sur les différences entre le forfait B et le forfait unifié, et comment l'application peut avoir besoin d'être mise à jour en prévision du plan unifié, consultez la Guide de transition vers le plan unifié (JavaScript)
Pour les applications natives (C++), consultez le document Migrer votre application native/mobile vers le plan unifié.