Google planea hacer la transición de la implementación de WebRTC de Chrome del formato SDP actual (llamado “Plan B”) según un formato conforme a los estándares (“Plan unificado”, borrador-ietf-rtcweb-jsep) durante los trimestres siguientes.
El plan involucra 5 fases y una función de API transitoria.
Quiénes se verán afectados
Personas que utilizan varias pistas de audio o de video en un solo video PeerConnection tendrá que probar su producto en el plan unificado y adaptarse según corresponda. Cuando se inicia una llamada desde un extremo que no es de Chrome y Chrome respondió, es posible que la forma de la oferta deba cambiar. Personas que hacer un análisis detallado del SDP y prestarle atención a los atributos msid su código de análisis recoge el nuevo formato (a=msid). Los detalles sobre si cambios serán necesarios y cómo deberán cambiarse las aplicaciones dependiente. Creemos que casi todas las aplicaciones que usan solo un audio y una sola pista de video por RTCPeerConnection no se verá afectada por el cambio.
La función de la API
Agregamos una función nueva a la RTCConfiguration de RTCPeerConnection:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
RTCConfiguration puede pasarse al constructor de una RTCPeerConnection y todas las ofertas y respuestas formuladas tendrán el formato de Plan unificado. Las llamadas a setLocalDescription y setRemoteDescription también esperan el SDP. estén en el formato del Plan unificado. si está en el formato heredado de Chrome, Se ignorarán todas excepto la primera pista de audio y la primera pista de video.
También hay una marca de línea de comandos (–enable-features=RTCUnifiedPlanByDefault en Chrome M71 y versiones posteriores, –enable-blink-features=RTCUnifiedPlanByDefault en versiones anteriores) que permite establecer el valor predeterminado de esta marca como “plan unificado”.
Las fases
Fase 1: Implementación del plan unificado
En esta fase, el plan unificado se desarrolló con un parámetro de experimentación disponibles a partir de M65. Hasta la fase 2, lo más acertado fue hacer las pruebas con Chrome Canary con “–enable-blink-features=RTCUnifiedPlan”.
Fase 2: Disponibilidad general de la función de la API
Lanzamiento en M69 (versión beta de agosto de 2018, estable en septiembre de 2018)
En esta fase, el valor predeterminado de la marca de sdpSemantics era “plan-b”. En En la fase 2, a las personas que tenían implementaciones que dependían del formato SDP se les se espera que ejecuten pruebas para ver si sus aplicaciones funcionan cuando el Plan unificado está en usar. En el caso de las aplicaciones compatibles con Firefox, esperamos que se trate de un proceso : haz lo que harías con Firefox.
El valor predeterminado de la marca sdpSemantics se puede cambiar en “chrome://flags”. busca la función “WebRTC: Usa Semantics de SDP del plan unificado de forma predeterminada”.
Fase 3: Cambiar la configuración predeterminada
La fecha del cambio fue M72 (versión beta de diciembre de 2018, estable en enero de 2019).
En esta fase, cambiamos el valor predeterminado de la marca sdpSemantics a “plan unificado”. Las aplicaciones que descubrieron que necesitaban más tiempo para convierte la marca de sdpSemantics de forma explícita en “plan-b” para recuperarla comportamiento anterior.
Fase 4: Lanzamiento del "Plan B"
En esta fase, estableceremos la marca sdpSemantics en “plan-b” da como resultado una excepción que se lanza. Se lanzó en Canary desde M93. A partir de la versión M96, la excepción está lanzando en todos los canales, incluido el estable.
Durante esta fase, se realizará una prueba de baja que permitía usar el Plan B sin la excepción, pero el de prueba dejó de funcionar el 25 de mayo de 2022.
Fase 5: Quita el "Plan B" de Chromium
Una vez finalizada la prueba, se quitará el plan B de Chrome. En este punto, se quitará la marca sdpSemantics. Intentando establecerlo en "plan-b" no arroja una excepción, pero ya no tendrá ningún efecto.
El plan B sigue estando disponible detrás de marcas o compilaciones especiales, pero la versión la eliminación del código se realizará en el segundo semestre de 2022.
Fase 6: Dar de baja el "Plan B" de WebRTC y quitarlo
El plan B ya está marcado como obsoleto en WebRTC, pero sigue estando disponible. La eliminación debería ocurrir en 2023.
Cómo preparar tu postulación para el plan unificado
Para obtener información detallada sobre las diferencias entre los planes B y los planes unificados, y cómo cómo se deban actualizar las aplicaciones y, así, prepararse para el plan unificado, consulta el Guía de transición al "plan unificado" (JavaScript)
Para aplicaciones nativas (C++), consulta el documento “Migra tu aplicación nativa o para dispositivos móviles al plan unificado”.