En los próximos trimestres, Google planea hacer la transición de 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"), borrador-ietf-rtcweb-jsep.
El plan implica 5 fases y una característica transitoria de la API.
¿A quiénes afectará el cambio?
Las personas que usan varias pistas de audio o video en una sola PeerConnection deberán probar su producto en el plan unificado y adaptarse en consecuencia. Si una llamada se inicia desde un extremo que no es Chrome y la responde Chrome, es posible que el formato de la oferta deba cambiar. Las personas que analizan el SDP en detalle y se preocupan por los atributos msid tendrán que verificar que su código de análisis recoja el nuevo formato (a=msid). Los detalles sobre si se necesitarán cambios y cómo las apps deberán modificarse dependerán de la aplicación. Creemos que el cambio no afectará a casi todas las aplicaciones que usan un solo audio y una única pista de video por RTCPeerConnection.
La función de la API
Agregaremos una función nueva a la RTCConfiguration de RTCPeerConnection:
enum SdpSemantics {
"plan-b",
"unified-plan"
};
partial dictionary RTCConfiguration {
SdpSemantics sdpSemantics;
}
La RTCConfiguration se puede pasar al constructor de una RTCPeerConnection y todas las ofertas y respuestas construidas estarán en el formato de Plan unificado. Para las llamadas a setLocalDescription y setRemoteDescription, también se espera que el SDP tenga el formato de Plan unificado. Si se utiliza en el formato de Chrome heredado, se ignorarán todos los componentes, 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 configurar el valor predeterminado de esta marca como “unified-plan”.
Las fases
Fase 1: Implementa un plan unificado
En esta fase, se desarrolló el plan unificado detrás de una marca de experimentación disponible desde M65. Hasta la fase 2, fue mejor realizar pruebas con Chrome Canary usando "–enable-blink-features=RTCUnifiedPlan".
Fase 2: Ofrece la disponibilidad general de la función de la API
Se lanzó en la versión 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. En el caso de las aplicaciones compatibles con Firefox, se espera que este sea un ejercicio muy simple, como se haría con Firefox.
El valor predeterminado de la marca sdpSemantics se puede cambiar en "chrome://flags"; busca la función "WebRTC: Usar la semántica del SDP del plan unificado de forma predeterminada".
Fase 3: Cambie la configuración predeterminada
La fecha de cambio era M72 (beta, diciembre de 2018, estable en enero de 2019).
En esta fase, cambiamos el valor predeterminado de la marca sdpSemantics a "unify-plan". Las aplicaciones que descubrían que necesitaban más tiempo para convertir la marca de sdpSemantics explícitamente a "plan-b" a fin de recuperar el comportamiento anterior.
Fase 4: Haga que el "Plan B" aparezca
En esta fase, si estableces la marca sdpSemantics como "plan-b", se generará una excepción. Se lanzó en Canary desde M93. A partir de M96, se lanzó la excepción en todos los canales, incluido el canal estable.
Durante esta fase, había una prueba de baja disponible que permitía usar el plan B sin que se generara ninguna excepción, 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. Intentar establecerlo en "plan-b" no se generará una excepción, pero ya no tendrá ningún efecto.
El plan B todavía está disponible detrás de marcas especiales o compilaciones especiales, pero la eliminación completa del código se realizará en la segunda mitad de 2022.
Fase 6: Baja el "Plan B" de WebRTC
El plan B ya está marcado como obsoleto en WebRTC, pero aún está disponible. Debería quitarse en 2023.
Cómo preparar su solicitud para un plan unificado
Para obtener información detallada sobre las diferencias del plan B y el plan unificado, y cómo tu aplicación puede actualizarse en la preparación del plan unificado, consulta la guía de transición del "plan unificado" (JavaScript).
En el caso de las aplicaciones nativas (C++), consulta el documento "Migra tu aplicación nativa/móvil al plan unificado".