SDP — qué es, formato de descripción de sesiones y rol en WebRTC

¿Qué es SDP (Session Description Protocol)?

SDP es un protocolo de capa de aplicación diseñado para describir parámetros de sesiones multimedia en formato de texto. Fue desarrollado dentro del grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) de IETF y estandarizado por primera vez en RFC 2327 en 1998. En 2021 se publicó la especificación actual RFC 8866, que reemplazó a la versión anterior RFC 4566.

La tarea principal de SDP es proporcionar a los participantes de la sesión toda la información necesaria para establecer una conexión: qué flujos multimedia se transmitirán, qué códecs son compatibles y a través de qué direcciones de red y puertos se realizará la transmisión. SDP no transmite los datos multimedia en sí, sino que solo describe cómo debe organizarse la conexión.

Según IETF RFC 8866, el formato SDP consiste en un conjunto de líneas, cada una comenzando con un tipo de una sola letra, seguido de un signo igual y un valor. Por ejemplo, la línea m=audio 5004 RTP/AVP 0 significa que la sesión incluye un flujo de audio en el puerto 5004 con protocolo de transporte RTP/AVP y códec PCMU (tipo 0).

Historia y estandarización de SDP

La primera versión de SDP se publicó en RFC 2327 en abril de 1998 como resultado del trabajo del grupo MMUSIC. El protocolo fue creado originalmente para anunciar sesiones multicast dentro de Mbone (Multicast Backbone). Con el desarrollo de VoIP y las videoconferencias, el ámbito de aplicación de SDP se expandió, y en 2006 se publicó la especificación actualizada RFC 4566.

Un verdadero avance en el uso de SDP se produjo con la llegada de WebRTC en 2011. Google integró SDP como el mecanismo principal para describir sesiones multimedia en su framework para comunicación en tiempo real basada en navegador. Desde entonces, SDP se ha convertido en un componente obligatorio de cualquier implementación de WebRTC, desde navegadores hasta aplicaciones móviles en iOS y Android.

En 2021, el grupo de trabajo de IETF publicó RFC 8866, la especificación actual de SDP, que reemplazó a RFC 4566. La versión actualizada aclaró el procesamiento de ICE (Interactive Connectivity Establishment), el soporte de DTLS (Datagram Transport Layer Security) y amplió las capacidades para describir sesiones grupales.

Diferencia entre SDP y los protocolos de transporte

SDP se diferencia fundamentalmente de los protocolos de transporte en que no participa en la transmisión de datos. Realiza una función puramente descriptiva, similar a los metadatos de un archivo multimedia. Mientras que RTP (Real-time Transport Protocol) transmite paquetes de audio y video, y RTCP controla la calidad de transmisión, SDP solo especifica qué códecs y puertos usar.

Una analogía del desarrollo web: SDP es como el marcado HTML que describe la estructura de la página, mientras que RTP son las imágenes y el texto reales. Sin SDP, los participantes de la sesión no saben cómo conectarse entre sí, incluso si la conexión de red ya está establecida. El mecanismo de NAT traversal (ICE) también se basa en SDP para transmitir información sobre los candidatos de red.

¿Cómo está estructurado SDP?

La estructura de SDP se organiza como una secuencia de líneas de texto, cada una siguiendo el formato type=value. El tipo de una letra define el propósito de la línea y el valor contiene el valor correspondiente. Todas las líneas están separadas por un carácter CRLF.

El estándar RFC 8866 define varios campos obligatorios y opcionales. Los campos obligatorios incluyen la versión del protocolo (v=), el nombre de la sesión (s=) y la hora de inicio y fin de la sesión (t=). Los campos restantes son opcionales, pero para sesiones WebRTC también son necesarias las descripciones de medios (m=), los atributos (a=) y la información de red (c=).

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

El ejemplo anterior muestra un segmento SDP típico para una sesión WebRTC. La línea v=0 indica la versión del protocolo. El campo o= contiene el identificador del propietario de la sesión y su versión. La línea s=- especifica el nombre de la sesión (un guión significa nombre vacío). El campo t=0 0 indica que la sesión no tiene límite de tiempo.

El campo a=group:BUNDLE audio video es un atributo que agrupa múltiples flujos multimedia en un solo canal de transporte. El mecanismo BUNDLE permite ahorrar recursos de red al transmitir audio y video a través de una sola conexión. Esto es especialmente importante para dispositivos móviles con ancho de banda limitado.

Campos obligatorios de SDP

La especificación RFC 8866 define un conjunto de campos obligatorios y opcionales. Los campos obligatorios incluyen v= (versión), s= (nombre de sesión) y t= (tiempo). El campo o= (propietario), aunque no es estrictamente obligatorio según RFC, está casi siempre presente en implementaciones reales.

El campo m= (media) es uno de los más importantes. Describe un flujo multimedia específico y contiene el tipo de medio (audio, video, text, application), puerto, protocolo de transporte y lista de códecs compatibles. En WebRTC, los tipos más utilizados son audio y video con protocolos de transporte RTP/SAVPF (Secure Audio/Video Profile with Feedback) o UDP/TLS/RTP/SAVPF.

El campo a= (attribute) es el más flexible y extensible. Puede contener rtpmap (mapeo del número de códec a nombre), fmtp (parámetros del códec), fingerprint (huella de la clave DTLS), ice-ufrag e ice-pwd (credenciales ICE) y muchos otros atributos. Es a través de los atributos que SDP soporta mecanismos modernos de seguridad y NAT traversal.

¿Cómo funciona SDP en WebRTC?

En la arquitectura WebRTC, SDP actúa como un protocolo de señalización para describir y negociar parámetros de sesión multimedia entre dos participantes. SDP en sí mismo no define el mecanismo para transmitir estas descripciones; esta tarea la maneja el canal de señalización, que el desarrollador implementa independientemente a través de WebSocket, HTTP u otro protocolo.

El proceso comienza cuando el iniciador (caller) crea una oferta SDP (Offer). Para ello, el navegador llama al método createOffer() en el objeto RTCPeerConnection. La descripción SDP generada contiene todos los parámetros de sesión del lado del iniciador: códecs compatibles, direcciones de red, candidatos ICE y requisitos de seguridad.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Add media tracks before createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Create SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Después de crear la Offer y establecer la descripción local mediante setLocalDescription(), el iniciador envía la cadena SDP al participante remoto a través del canal de señalización. El participante remoto, al recibir la SDP Offer, crea una respuesta SDP (Answer) y la devuelve. Este intercambio se llama intercambio de señalización y es un paso obligatorio antes de establecer una conexión peer-to-peer.

Según la especificación WebRTC de W3C, el intercambio SDP debe ocurrir antes de que comiencen los candidatos ICE. En la práctica, muchas implementaciones envían candidatos ICE en paralelo con SDP utilizando el mecanismo ICE trickle. Esto reduce el tiempo de establecimiento de conexión, especialmente para redes móviles con alta latencia.

El papel de ICE en SDP

ICE (Interactive Connectivity Establishment) es un mecanismo que utiliza atributos SDP para transmitir información sobre candidatos de red. Los candidatos ICE describen posibles rutas de conexión: host (dirección local), srflx (dirección después de NAT, obtenida a través de STUN) y relay (dirección del servidor TURN).

En SDP, los candidatos ICE se transmiten a través de atributos a=candidate:, así como a través de los campos ice-ufrag e ice-pwd para la autenticación del tráfico ICE. Cada candidato incluye el protocolo de transporte (UDP, TCP), dirección IP, puerto y prioridad. Una conexión exitosa se establece a través del primer candidato que pasa las pruebas de conectividad. El mecanismo ICE restart permite actualizar la conexión cuando cambia la red.

Para aplicaciones móviles, los candidatos ICE son especialmente importantes porque los dispositivos a menudo están detrás de NAT o firewalls corporativos. El mecanismo ICE permite encontrar una ruta funcional incluso en condiciones de red complejas, y SDP sirve como contenedor de transporte para esta información.

Seguridad de SDP en WebRTC

SDP en WebRTC incluye necesariamente atributos de seguridad, particularmente la huella DTLS y los parámetros SRTP. El campo a=fingerprint:sha-256 contiene la huella del certificado DTLS, utilizada para autenticación y cifrado del flujo multimedia. Sin este atributo, la conexión WebRTC no se establecerá.

Los mecanismos de seguridad adicionales incluyen el atributo a=setup:, que define el rol del handshake DTLS (active, passive, actpass), y a=ice-lite: para una implementación ICE simplificada en el lado del servidor. Todos estos parámetros se transmiten dentro de SDP y son verificados por ambas partes antes de que comience la transmisión de datos multimedia.

Tipos de SDP: Offer y Answer

En el modelo WebRTC, existen dos tipos de mensajes SDP: Offer (oferta) y Answer (respuesta). La Offer es creada por el iniciador de la conexión y contiene una descripción completa de la sesión multimedia deseada. La Answer es creada por el participante remoto en respuesta a la Offer y contiene sus capacidades teniendo en cuenta las limitaciones impuestas por la oferta.

La principal diferencia entre Offer y Answer radica en la semántica de los atributos. La Offer enumera todos los códecs, protocolos de transporte y direcciones de red compatibles que el iniciador puede proponer. La Answer selecciona un subconjunto de estas capacidades que la parte remota admite. Por ejemplo, si la Offer propone opus, ISAC y PCMU, la Answer puede seleccionar solo opus como el códec más preferido.

El proceso de intercambio está regulado por la especificación WebRTC de W3C e incluye varios estados de RTCPeerConnection. Después de crear la Offer mediante createOffer() y establecerla como descripción local, la conexión entra en el estado have-local-offer. Después de recibir la Answer y establecerla como descripción remota mediante setRemoteDescription(), la conexión entra en el estado stable, el estado final listo para la transmisión multimedia.

Uso de SDP en SDKs móviles

Los SDK móviles para WebRTC (Google WebRTC para Android y WebRTC.framework para iOS) soportan completamente el intercambio SDP a través de Offer y Answer. En Android, se utiliza la clase PeerConnection con el método createOffer(), similar a la API del navegador. La descripción SDP resultante se transmite como una cadena a través del canal de señalización.

En iOS, el trabajo con SDP se realiza a través de la clase RTCSessionDescription del framework WebRTC. Al inicializar, se especifican el tipo (RTCSdpTypeOffer o RTCSdpTypeAnswer) y la cadena SDP. La plataforma analiza automáticamente el SDP y configura la conexión según los parámetros transmitidos.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

La capacidad de trabajar directamente con la cadena SDP brinda flexibilidad a los desarrolladores: pueden modificar el SDP antes de enviarlo, agregando o eliminando códecs específicos, configurando parámetros ICE o agregando atributos personalizados. Para aplicaciones de Android, a menudo es necesario deshabilitar el video en SDP cuando el ancho de banda de la red es bajo; esto se hace eliminando las líneas m= correspondientes de la descripción SDP.

SDP en el desarrollo móvil

En el desarrollo móvil, SDP se utiliza principalmente en el contexto de WebRTC, para crear aplicaciones con videollamadas, chats de voz y streaming. Las aplicaciones móviles en Android e iOS pueden actuar tanto como iniciadores como receptores de mensajes SDP, lo que permite conexiones peer-to-peer simétricas.

Una característica de las aplicaciones móviles es la necesidad de trabajar con SDP en condiciones de calidad de red variable. Al cambiar entre Wi-Fi e internet móvil, así como cuando cambia el ancho de banda, puede ser necesaria la generación de una nueva descripción SDP. Esto se hace mediante el mecanismo de renegociación: un intercambio repetido de SDP a través de createOffer() y setLocalDescription().

Según el equipo de Google WebRTC (2023), la optimización del intercambio SDP para dispositivos móviles incluye el uso de ICE restart durante cambios de red, la priorización de códecs de baja tasa de bits (opus para audio, VP8 para video) y la minimización del tamaño de la cadena SDP excluyendo flujos multimedia innecesarios. La ventaja clave es la reducción de la latencia al establecer una conexión en condiciones de redes móviles.

Optimización de SDP para redes móviles

Una de las tareas clave al trabajar con SDP en dispositivos móviles es minimizar el tamaño de la descripción SDP. Un SDP completo para una sesión WebRTC típica con audio y video puede ocupar 2–5 KB, lo que es significativo para redes lentas. La optimización incluye el uso de BUNDLE (multiplexación de flujos), la eliminación de códecs no compatibles y la compresión de candidatos ICE.

Un problema adicional para los dispositivos móviles es la vida útil limitada del SDP. En condiciones de conexión inestable, el SDP puede quedar obsoleto antes de que el participante remoto pueda procesarlo. La solución es usar tiempos de espera cortos para recibir la Answer y reenviar el SDP si es necesario. El mecanismo ICE restart permite actualizar la conexión sin recrear completamente el RTCPeerConnection. El atributo a=ice-lite simplifica la implementación de ICE en el lado del servidor.

Bibliotecas populares para trabajar con SDP

Los desarrolladores de aplicaciones móviles tienen acceso a bibliotecas listas que simplifican el trabajo con SDP. libjingle_peerconnection (Google WebRTC) es la biblioteca principal para Android, que proporciona una API completa para gestionar SDP. Para iOS, se utiliza WebRTC.framework con funcionalidad similar. Ambas bibliotecas generan y analizan SDP automáticamente, pero proporcionan acceso a la cadena SDP sin procesar cuando sea necesario.

Para un control más preciso sobre SDP, existen soluciones de terceros: sdp-transform (JavaScript o Node.js) para analizar y modificar SDP, NICENICE (Java) para trabajar con candidatos ICE y SDK listos de proveedores de infraestructura WebRTC que manejan todo el intercambio de señalización, incluido SDP.