Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Format SDP du plan unifié - plan de transition

Google prévoit de faire passer la mise en œuvre WebRTC de Chrome du format SDP actuel (appelé «Plan B») à un format conforme aux normes («Unified Plan», draft-ietf-rtcweb-jsep) au cours des deux prochains trimestres.

Le plan comprend 4 phases et une fonctionnalité API transitoire.

Qui sera affecté

Les personnes qui utilisent plusieurs pistes audio ou plusieurs pistes vidéo sur un même PeerConnection devront tester leur produit sous un plan unifié et s'adapter en conséquence. Dans le cas où un appel est lancé à partir d'un point de terminaison non Chrome et auquel Chrome répond, la forme de l'offre peut devoir changer. Les personnes qui effectuent une analyse SDP détaillée et se soucient des attributs msid devront vérifier que leur code d'analyse prend le nouveau format (a = msid). Les détails indiquant si des modifications seront nécessaires et comment les applications doivent changer 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 le changement.

La fonctionnalité API

Nous ajoutons une nouvelle fonctionnalité à la configuration RTCC de RTCPeerConnection:

 enum SdpSemantics {
  "plan-b",
  "unified-plan"
};


partial dictionary RTCConfiguration {
   SdpSemantics sdpSemantics;
}
 

La configuration RTCC peut être transmise au constructeur d'un RTCPeerConnection, et toutes les offres et réponses construites seront au format de plan unifié. Les appels à setLocalDescription et setRemoteDescription s'attendront également à ce que le SDP soit au format Unified Plan; s'il s'agit de l'ancien format Chrome, toutes les pistes audio et vidéo sauf la première seront ignorées.

Il existe également un indicateur de ligne de commande (–enable-features = RTCUnifiedPlanByDefault dans Chrome M71 et supérieur, –enable-blink-features = RTCUnifiedPlanByDefault dans les versions antérieures) qui permet à la valeur par défaut de cet indicateur d'être définie sur «unified-plan».

Les phases

Phase 1: mise en œuvre du plan unifié

Unified Plan est actuellement développé et le drapeau pour l'expérimentation est disponible sur M65. Jusqu'à la phase 2, il est plus sage de tester avec Canary. Si vous exécutez Chrome avec «–enable-blink-features = RTCUnifiedPlan», vous aurez accès à la fonctionnalité «sdpSemantics» décrite ci-dessus et pourrez commencer les tests avec Unified Plan.

Phase 2: rendre la fonctionnalité API généralement disponible

Sorti en M69 (bêta août 2018, stable septembre 2018)

Dans cette phase, la valeur par défaut de l'indicateur sdpSemantics est «plan-b». Dans la phase 2, nous attendons des personnes qui ont des implémentations qui dépendent du format SDP d'exécuter des tests pour voir si leurs applications fonctionnent lorsque Unified Plan est en cours d'utilisation. Pour les applications prenant en charge Firefox, nous nous attendons à ce que ce soit un exercice 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 la sémantique Unified Plan SDP par défaut».

Phase 3: changer la valeur par défaut

La date du changement sera fixée en consultation avec les utilisateurs, après des tests approfondis. Notre plan actuel est M72 (bêta décembre 2018, stable janvier 2019).

Dans cette phase, nous changerons la valeur par défaut de l'indicateur sdpSemantics en «unified-plan». Les applications qui découvrent qu'elles ont besoin de plus de temps pour se convertir peuvent définir explicitement l'indicateur sdpSemantics sur «plan-b» afin de récupérer le comportement précédent.

Dans le cadre des tests, nous prévoyons d'essayer de modifier la valeur par défaut de l'indicateur dans Canary plusieurs fois au cours du cycle de développement de M71 et M72.

Nous surveillerons l'utilisation de l'indicateur et la quantité de SDP reçue avec la sémantique «Plan B», afin de fixer la date de la phase 4.

Phase 4: supprimer le «plan B»

Dans cette phase, l'indicateur sdpSemantics et tout le code de prise en charge du plan B seront supprimés de Chrome. La définition de l'indicateur sdpSemantics ne sera pas une erreur, mais n'aura aucun effet.

Préparation de votre demande pour un plan unifié

Pour obtenir des informations détaillées sur les différences entre le plan B et le plan unifié et sur la manière dont votre application peut avoir besoin d'être mise à jour en vue du plan unifié, consultez le guide de transition «Plan unifié» (JavaScript)

Pour les applications natives (C ++), consultez le document «Migration de votre application native / mobile vers Unified Plan»