Format SDP du plan unifié - Plan de transition

Google prévoit de passer de l'implémentation WebRTC de Chrome du format SDP actuel (appelé "Plan B") à un format conforme aux normes (appelé "Unified Plan", draft-ietf-rtcweb-jsep) au cours des prochains trimestres.

Le plan comprend cinq phases et une fonctionnalité d'API temporaire.

Entité concernée

Les utilisateurs qui utilisent plusieurs pistes audio ou plusieurs pistes vidéo sur un seul PeerConnection devront tester leur produit avec le forfait unifié et s'adapter en conséquence. Si un appel est lancé à partir d'un point de terminaison autre que Chrome et que Chrome y répond, la forme de l'offre peut devoir changer. Les personnes qui effectuent une analyse détaillée du fichier SDP et qui s'intéressent aux attributs msid devront vérifier que leur code d'analyse détecte le nouveau format (a=msid). Les détails sur la nécessité de modifier les applications et la manière dont elles doivent être modifiées dépendront de l'application. Nous pensons que presque toutes les applications qui n'utilisent qu'une seule piste audio et une seule piste vidéo par RTCPeerConnection ne seront pas affectées 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;
}

La RTCConfiguration peut être transmise au constructeur d'un RTCPeerConnection, et toutes les offres et réponses créées seront au format Unified Plan. Les appels à setLocalDescription et setRemoteDescription s'attendent également à ce que l'SDP soit au format Unified Plan. S'il est au format Chrome précédent, tous les canaux audio et vidéo, à l'exception du premier, seront ignorés.

Il existe également un indicateur de ligne de commande (–enable-features=RTCUnifiedPlanByDefault dans Chrome M71 et versions ultérieures, –enable-blink-features=RTCUnifiedPlanByDefault dans les versions antérieures) qui permet de définir la valeur par défaut de cet indicateur sur "unified-plan".

Les phases

Phase 1: Implémenter le plan unifié

Au cours de cette phase, le plan unifié était en cours de développement derrière un indicateur de test disponible depuis la version M65. Jusqu'à la phase 2, il était préférable de tester avec Chrome Canary en utilisant "–enable-blink-features=RTCUnifiedPlan".

Phase 2: Rendre la fonctionnalité de l'API disponible pour tous les utilisateurs

Disponible dans M69 (bêta en août 2018, version stable en septembre 2018)

Au cours de cette phase, la valeur par défaut de l'indicateur sdpSemantics était "plan-b". Au cours de la phase 2, les personnes qui avaient des implémentations dépendant du format SDP devaient exécuter des tests pour voir si leurs applications fonctionnaient lorsque Unified Plan était utilisé. Pour les applications compatibles avec Firefox, cet exercice devrait être très simple: faites comme vous le feriez pour Firefox.

La valeur par défaut de l'indicateur sdpSemantics peut être modifiée dans "chrome://flags". Recherchez la fonctionnalité "WebRTC: utiliser les sémantiques SDP Unified Plan par défaut".

Phase 3: Définir la valeur par défaut

La date de passage était M72 (bêta en décembre 2018, version stable en janvier 2019).

Au cours de cette phase, nous avons modifié la valeur par défaut de l'indicateur sdpSemantics pour qu'elle soit "unified-plan". Les applications qui ont découvert qu'elles avaient besoin de plus de temps pour effectuer la conversion ont défini explicitement l'indicateur sdpSemantics sur "plan-b" afin de récupérer le comportement précédent.

Phase 4: Effectuer le lancer de secours

Dans cette phase, définir l'indicateur sdpSemantics sur "plan-b" entraîne l'émission d'une exception. Il a été lancé dans Canary à partir de la version M93. À partir de la version M96, l'exception était générée dans tous les canaux, y compris la version stable.

Au cours de cette phase, un essai de dépréciation était disponible, qui permettait d'utiliser le plan B sans exception, mais l'essai a cessé de fonctionner le 25 mai 2022.

Phase 5: Supprimer le "Plan B" de Chromium

À la fin de l'essai, Plan B sera supprimé de Chrome. À ce stade, l'indicateur sdpSemantics est supprimé. Si vous essayez de le définir sur "plan-b", aucune exception ne sera générée, mais il n'aura plus aucun effet.

Le plan B est toujours disponible derrière des indicateurs ou des builds spéciaux, mais la suppression complète du code aura lieu au second semestre 2022.

Phase 6: Abandon et suppression du "Plan B" de WebRTC

Le plan B est déjà marqué comme obsolète dans WebRTC, mais il est toujours disponible. La suppression devrait intervenir en 2023.

Préparer votre application pour le forfait unifié

Pour en savoir plus sur les différences entre le plan B et le plan unifié, et sur la façon dont votre application peut devoir être mise à jour en vue du plan unifié, consultez le 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é".