Google planea migrar la implementación de WebRTC de Chrome del formato SDP actual (llamado “Plan B”) a un formato que cumpla con los estándares (“Plan unificado”, draft-ietf-rtcweb-jsep) en los próximos trimestres.
El plan incluye 5 fases y una función de API transitoria.
¿A quiénes afecta el cambio?
Las personas que usen varias pistas de audio o varias pistas de video en una sola PeerConnection deberán probar su producto en el Plan unificado y adaptarse según corresponda. En el caso de que se inicie una llamada desde un extremo que no sea de Chrome y Chrome responda, es posible que deba cambiar el formato de la oferta. Las personas que hacen un análisis detallado de SDP y se preocupan por los atributos msid deberán verificar que su código de análisis detecte el nuevo formato (a=msid). Los detalles sobre si se necesitarán cambios y cómo deben cambiar las apps dependerán de la aplicación. Creemos que casi todas las aplicaciones que usan solo una pista de audio y una de video por RTCPeerConnection no se verán afectadas por el cambio.
La función de la API
Agregaremos una función nueva a RTCConfiguration de RTCPeerConnection:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
RTCConfiguration se puede pasar al constructor de un RTCPeerConnection, y todas las ofertas y respuestas que se construyan estarán en el formato de Unified Plan. Las llamadas a setLocalDescription y setRemoteDescription también esperarán que el SDP esté en el formato de Unified Plan. Si está en el formato heredado de Chrome, se ignorarán todos, 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 que el valor predeterminado de esta marca se establezca en “unified-plan”.
Las fases
Fase 1: Implementa el plan unificado
En esta fase, Unified Plan se estaba desarrollando detrás de una marca de experimentación disponible desde la M65. Hasta la fase 2, lo más conveniente era realizar pruebas con Chrome Canary con el parámetro “–enable-blink-features=RTCUnifiedPlan”.
Fase 2: Disponibilidad general de la función de la API
Se lanzó en M69 (beta en agosto de 2018, estable en septiembre de 2018)
En esta fase, el valor predeterminado de la marca sdpSemantics era "plan-b". En la fase 2, se esperaba que las personas que tenían implementaciones que dependían del formato SDP ejecutaran pruebas para ver si sus aplicaciones funcionaban cuando se usaba el plan unificado. Para las aplicaciones que admiten Firefox, esperamos que este sea un ejercicio muy simple: haz lo mismo que harías para Firefox.
El valor predeterminado de la marca sdpSemantics se puede cambiar en “chrome://flags”. Busca la función “WebRTC: Use Unified Plan SDP Semantics by default”.
Fase 3: Cambia la configuración predeterminada
La fecha del cambio fue la M72 (beta en diciembre de 2018, estable en enero de 2019).
En esta fase, cambiamos el valor predeterminado de la marca sdpSemantics a "unified-plan". Las aplicaciones que descubrieron que necesitaban más tiempo para realizar la conversión establecieron la marca sdpSemantics explícitamente en "plan-b" para recuperar el comportamiento anterior.
Fase 4: Lanza el “Plan B”
En esta fase, si configuras la marca sdpSemantics en "plan-b", se arroja una excepción. Se produce en Canary desde la versión M93. A partir de M96, la excepción se arrojaba en todos los canales, incluido el estable.
Durante esta fase, estaba disponible una prueba de baja que permitía usar el plan B sin generar excepciones, pero la prueba dejó de funcionar el 25 de mayo de 2022.
Fase 5: Quita el "Plan B" de Chromium
Una vez que finalice la prueba, se quitará el Plan B de Chrome. En este punto, se quitará la marca sdpSemantics. Si intentas establecerlo en "plan-b", no se mostrará una excepción, pero ya no tendrá ningún efecto.
El plan B aún está disponible detrás de marcas especiales o compilaciones especiales, pero la eliminación completa del código se realizará en el segundo semestre de 2022.
Fase 6: Se dará de baja y se quitará el "Plan B" de WebRTC
El plan B ya está marcado como obsoleto en WebRTC, pero aún está disponible. La eliminación debería ocurrir en 2023.
Prepara tu aplicación para el plan unificado
Para obtener información detallada sobre las diferencias entre el Plan B y el Plan unificado, y cómo es posible que debas actualizar tu aplicación para prepararte para el Plan unificado, consulta la Guía de transición al "Plan unificado" (JavaScript).
Para aplicaciones nativas (C++), consulta el documento "Cómo migrar tu aplicación nativa o para dispositivos móviles al plan unificado".