SDP — o que é, formato de descrição de sessões e papel no WebRTC

O que é SDP (Session Description Protocol)?

SDP é um protocolo de camada de aplicação projetado para descrever parâmetros de sessões multimídia em formato de texto. Foi desenvolvido dentro do grupo de trabalho MMUSIC (Multiparty Multimedia Session Control) da IETF e padronizado pela primeira vez na RFC 2327 em 1998. Em 2021, a especificação atual RFC 8866 foi publicada, substituindo a versão anterior RFC 4566.

A principal tarefa do SDP é fornecer aos participantes da sessão todas as informações necessárias para estabelecer uma conexão: quais fluxos de mídia serão transmitidos, quais codecs são suportados e através de quais endereços de rede e portas a transmissão ocorrerá. O SDP não transmite os próprios dados de mídia, mas apenas descreve como a conexão deve ser organizada.

De acordo com a IETF RFC 8866, o formato SDP consiste em um conjunto de linhas, cada uma começando com um tipo de uma única letra, seguido por um sinal de igual e um valor. Por exemplo, a linha m=audio 5004 RTP/AVP 0 significa que a sessão inclui um fluxo de áudio na porta 5004 com protocolo de transporte RTP/AVP e codec PCMU (tipo 0).

História e padronização do SDP

A primeira versão do SDP foi publicada na RFC 2327 em abril de 1998 como resultado do trabalho do grupo MMUSIC. O protocolo foi originalmente criado para anunciar sessões multicast dentro do Mbone (Multicast Backbone). Com o desenvolvimento do VoIP e videoconferência, o escopo de aplicação do SDP se expandiu, e em 2006 a especificação atualizada RFC 4566 foi publicada.

Um verdadeiro avanço no uso do SDP ocorreu com o advento do WebRTC em 2011. O Google integrou o SDP como o principal mecanismo para descrever sessões de mídia em seu framework para comunicação em tempo real baseada em navegador. Desde então, o SDP tornou-se um componente obrigatório de qualquer implementação WebRTC — de navegadores a aplicativos móveis em iOS e Android.

Em 2021, o grupo de trabalho da IETF publicou a RFC 8866 — a especificação atual do SDP, substituindo a RFC 4566. A versão atualizada esclareceu o processamento do ICE (Interactive Connectivity Establishment), o suporte a DTLS (Datagram Transport Layer Security) e expandiu as capacidades de descrição de sessões em grupo.

Diferença entre SDP e protocolos de transporte

SDP difere fundamentalmente dos protocolos de transporte por não participar na transmissão de dados. Ele desempenha uma função puramente descritiva — semelhante aos metadados de um arquivo multimídia. Enquanto o RTP (Real-time Transport Protocol) transmite pacotes de áudio e vídeo, e o RTCP controla a qualidade da transmissão, o SDP apenas especifica quais codecs e portas usar.

Uma analogia do desenvolvimento web: SDP é como a marcação HTML que descreve a estrutura da página, enquanto RTP são as imagens e o texto reais. Sem SDP, os participantes da sessão não sabem como se conectar uns aos outros, mesmo que a conexão de rede já esteja estabelecida. O mecanismo de NAT traversal (ICE) também depende do SDP para transmitir informações sobre candidatos de rede.

Como o SDP é estruturado

A estrutura do SDP é organizada como uma sequência de linhas de texto, cada uma seguindo o formato type=value. O tipo de uma letra define o propósito da linha e o valor contém o valor correspondente. Todas as linhas são separadas por um caractere CRLF.

O padrão RFC 8866 define vários campos obrigatórios e opcionais. Os campos obrigatórios incluem a versão do protocolo (v=), o nome da sessão (s=) e o horário de início e fim da sessão (t=). Os campos restantes são opcionais, mas para sessões WebRTC, as descrições de mídia (m=), atributos (a=) e informações de rede (c=) também são necessárias.

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

O exemplo acima mostra um segmento SDP típico para uma sessão WebRTC. A linha v=0 indica a versão do protocolo. O campo o= contém o identificador do proprietário da sessão e sua versão. A linha s=- especifica o nome da sessão (um hífen significa nome vazio). O campo t=0 0 indica que a sessão não tem limite de tempo.

O campo a=group:BUNDLE audio video é um atributo que agrupa múltiplos fluxos de mídia em um único canal de transporte. O mecanismo BUNDLE permite economizar recursos de rede transmitindo áudio e vídeo através de uma única conexão. Isso é especialmente importante para dispositivos móveis com largura de banda limitada.

Campos obrigatórios do SDP

A especificação RFC 8866 define um conjunto de campos obrigatórios e opcionais. Os campos obrigatórios incluem v= (versão), s= (nome da sessão) e t= (tempo). O campo o= (proprietário), embora não seja estritamente obrigatório pela RFC, está quase sempre presente em implementações reais.

O campo m= (media) é um dos mais importantes. Ele descreve um fluxo de mídia específico e contém o tipo de mídia (audio, video, text, application), porta, protocolo de transporte e lista de codecs suportados. No WebRTC, os tipos mais comumente usados são audio e video com protocolos de transporte RTP/SAVPF (Secure Audio/Video Profile with Feedback) ou UDP/TLS/RTP/SAVPF.

O campo a= (attribute) é o mais flexível e extensível. Pode conter rtpmap (mapeamento do número do codec para o nome), fmtp (parâmetros do codec), fingerprint (impressão digital da chave DTLS), ice-ufrag e ice-pwd (credenciais ICE) e muitos outros atributos. É através dos atributos que o SDP suporta mecanismos modernos de segurança e NAT traversal.

Como o SDP funciona no WebRTC

Na arquitetura WebRTC, o SDP atua como um protocolo de sinalização para descrever e negociar parâmetros de sessão de mídia entre dois participantes. O SDP em si não define o mecanismo para transmitir essas descrições — esta tarefa é tratada pelo canal de sinalização, que o desenvolvedor implementa independentemente via WebSocket, HTTP ou outro protocolo.

O processo começa quando o iniciador (caller) cria uma oferta SDP (Offer). Para isso, o navegador chama o método createOffer() no objeto RTCPeerConnection. A descrição SDP gerada contém todos os parâmetros de sessão do lado do iniciador: codecs suportados, endereços de rede, candidatos ICE e requisitos de segurança.

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

// Adicione faixas de mídia antes do createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

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

// Enviar SDP para o peer remoto via canal de sinalização
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Após criar a Offer e definir a descrição local através de setLocalDescription(), o iniciador envia a string SDP para o participante remoto através do canal de sinalização. O participante remoto, ao receber a SDP Offer, cria uma Resposta SDP (Answer) e a devolve. Esta troca é chamada de troca de sinalização e é uma etapa obrigatória antes de estabelecer uma conexão peer-to-peer.

De acordo com a especificação WebRTC do W3C, a troca SDP deve ocorrer antes do início dos candidatos ICE. Na prática, muitas implementações enviam candidatos ICE em paralelo com o SDP usando o mecanismo ICE trickle. Isso reduz o tempo de estabelecimento da conexão, especialmente para redes móveis com alta latência.

O papel do ICE no SDP

ICE (Interactive Connectivity Establishment) é um mecanismo que usa atributos SDP para transmitir informações sobre candidatos de rede. Os candidatos ICE descrevem possíveis caminhos de conexão: host (endereço local), srflx (endereço após NAT, obtido via STUN) e relay (endereço do servidor TURN).

No SDP, os candidatos ICE são transmitidos através de atributos a=candidate:, bem como através dos campos ice-ufrag e ice-pwd para autenticação de tráfego ICE. Cada candidato inclui o protocolo de transporte (UDP, TCP), endereço IP, porta e prioridade. Uma conexão bem-sucedida é estabelecida através do primeiro candidato que passa nas verificações de conectividade. O mecanismo ICE restart permite atualizar a conexão quando a rede muda.

Para aplicativos móveis, os candidatos ICE são especialmente importantes porque os dispositivos estão frequentemente atrás de NAT ou firewalls corporativos. O mecanismo ICE permite encontrar um caminho funcional mesmo em condições de rede complexas, e o SDP serve como contêiner de transporte para esta informação.

Segurança do SDP no WebRTC

SDP no WebRTC inclui necessariamente atributos de segurança, particularmente a impressão digital DTLS e os parâmetros SRTP. O campo a=fingerprint:sha-256 contém a impressão digital do certificado DTLS, usado para autenticação e criptografia do fluxo de mídia. Sem este atributo, a conexão WebRTC não será estabelecida.

Mecanismos de segurança adicionais incluem o atributo a=setup:, que define o papel do handshake DTLS (active, passive, actpass), e a=ice-lite: para uma implementação ICE simplificada no lado do servidor. Todos estes parâmetros são transmitidos dentro do SDP e verificados por ambas as partes antes do início da transmissão de dados de mídia.

Tipos de SDP: Offer e Answer

No modelo WebRTC, existem dois tipos de mensagens SDP: Offer (oferta) e Answer (resposta). A Offer é criada pelo iniciador da conexão e contém uma descrição completa da sessão de mídia desejada. A Answer é criada pelo participante remoto em resposta à Offer e contém suas capacidades considerando as restrições impostas pela oferta.

A principal diferença entre Offer e Answer está na semântica dos atributos. A Offer lista todos os codecs, protocolos de transporte e endereços de rede suportados que o iniciador pode propor. A Answer seleciona um subconjunto destas capacidades que a parte remota suporta. Por exemplo, se a Offer propõe opus, ISAC e PCMU, a Answer pode selecionar apenas opus como o codec mais preferido.

O processo de troca é governado pela especificação WebRTC do W3C e inclui vários estados do RTCPeerConnection. Após criar a Offer via createOffer() e defini-la como descrição local, a conexão entra no estado have-local-offer. Após receber a Answer e defini-la como descrição remota através de setRemoteDescription(), a conexão entra no estado stable — o estado final pronto para transmissão de mídia.

Uso do SDP em SDKs móveis

Os SDKs móveis para WebRTC — Google WebRTC para Android e WebRTC.framework para iOS — suportam completamente a troca SDP via Offer e Answer. No Android, a classe PeerConnection com o método createOffer() é usada para criar uma Offer, semelhante à API do navegador. A descrição SDP resultante é transmitida como uma string através do canal de sinalização.

No iOS, o trabalho com SDP é feito através da classe RTCSessionDescription do framework WebRTC. Ao inicializar, o tipo (RTCSdpTypeOffer ou RTCSdpTypeAnswer) e a string SDP são especificados. A plataforma analisa automaticamente o SDP e configura a conexão de acordo com os parâmetros transmitidos.

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

// Criar SDP Offer no Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Enviar string SDP para o peer remoto
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

A capacidade de trabalhar diretamente com a string SDP dá flexibilidade aos desenvolvedores: eles podem modificar o SDP antes de enviar, adicionando ou removendo codecs específicos, configurando parâmetros ICE ou adicionando atributos personalizados. Para aplicativos Android, muitas vezes é necessário desativar o vídeo no SDP quando a largura de banda da rede está baixa — isso é feito removendo as linhas m= correspondentes da descrição SDP.

SDP no desenvolvimento mobile

No desenvolvimento mobile, o SDP é usado principalmente no contexto do WebRTC — para criar aplicativos com videochamadas, chats de voz e streaming. Aplicativos móveis em Android e iOS podem atuar tanto como iniciadores quanto como receptores de mensagens SDP, permitindo conexões peer-to-peer simétricas.

Uma característica dos aplicativos móveis é a necessidade de trabalhar com SDP em condições de qualidade de rede variável. Ao alternar entre Wi-Fi e internet móvel, bem como quando a largura de banda muda, pode ser necessária a geração de uma nova descrição SDP. Isso é feito usando o mecanismo de renegoriação — uma troca repetida de SDP via createOffer() e setLocalDescription().

De acordo com a equipe Google WebRTC (2023), otimizar a troca SDP para dispositivos móveis inclui usar ICE restart durante mudanças de rede, priorizar codecs de baixa taxa de bits (opus para áudio, VP8 para vídeo) e minimizar o tamanho da string SDP excluindo fluxos de mídia desnecessários. A vantagem principal é a redução da latência ao estabelecer uma conexão em condições de redes móveis.

Otimização do SDP para redes móveis

Uma das tarefas principais ao trabalhar com SDP em dispositivos móveis é minimizar o tamanho da descrição SDP. Um SDP completo para uma sessão WebRTC típica com áudio e vídeo pode ocupar 2–5 KB, o que é significativo para redes lentas. A otimização inclui o uso de BUNDLE (multiplexação de fluxos), remoção de codecs não suportados e compressão de candidatos ICE.

Um problema adicional para dispositivos móveis é o tempo de vida limitado do SDP. Em condições de conexão instável, o SDP pode ficar obsoleto antes que o participante remoto possa processá-lo. A solução é usar tempos limite curtos para receber a Answer e reenviar o SDP se necessário. O mecanismo ICE restart permite atualizar a conexão sem recriar completamente o RTCPeerConnection. O atributo a=ice-lite simplifica a implementação ICE no lado do servidor.

Bibliotecas populares para trabalhar com SDP

Desenvolvedores de aplicativos móveis têm acesso a bibliotecas prontas que simplificam o trabalho com SDP. libjingle_peerconnection (Google WebRTC) é a biblioteca principal para Android, fornecendo uma API completa para gerenciar SDP. Para iOS, é usado o WebRTC.framework com funcionalidade similar. Ambas as bibliotecas geram e analisam SDP automaticamente, mas fornecem acesso à string SDP bruta quando necessário.

Para um controle mais preciso sobre o SDP, existem soluções de terceiros: sdp-transform (JavaScript ou Node.js) para analisar e modificar SDP, NICENICE (Java) para trabalhar com candidatos ICE e SDKs prontos de provedores de infraestrutura WebRTC que lidam com toda a troca de sinalização, incluindo SDP.