WebRTC: o que é, arquitetura e princípio de funcionamento

O que é WebRTC

WebRTC (Web Real-Time Communication) é um projeto de código aberto iniciado pelo Google em 2011 e padronizado pelo W3C (JavaScript API) e IETF (protocolos). Seu objetivo principal é fornecer comunicação de baixa latência entre navegadores e aplicativos sem instalar plugins ou software de terceiros.

Ao contrário das soluções tradicionais (RTMP, HLS) onde o vídeo passa por um servidor, o WebRTC usa arquitetura peer-to-peer: os dados são transmitidos diretamente entre os participantes. Isso fornece latência de 200-500 ms em comparação com 3-10 segundos do HLS — uma diferença crítica para chamadas de voz e vídeo, streaming de jogos e cirurgia remota.

De acordo com o Google WebRTC Team (2025), a tecnologia é usada em aplicativos com um público total de mais de 5 bilhões de instalações: Google Meet, WhatsApp, Discord, Telegram, Zoom (parcialmente). Mais de 85% das startups de capital de risco em telehealth e edtech escolhem WebRTC como seu transporte base em tempo real.

O desenvolvimento móvel recebeu suporte completo ao WebRTC em 2013 com o lançamento do libjingle_peerconnection — uma implementação nativa para Android e iOS. Hoje ambas as plataformas têm SDKs estáveis com suporte para codificação de hardware de H.264 e VP8, câmara, microfone e alto-falantes do dispositivo.

Arquitetura e protocolos WebRTC

A arquitetura WebRTC consiste em três camadas. A camada superior é a JavaScript API (ou API nativa para plataformas móveis), a intermediária são os protocolos de transporte, a inferior são os codecs e segurança. Cada camada resolve sua própria tarefa, mas todas são necessárias para o estabelecimento da conexão.

APIs principais do WebRTC

MediaStream (getUserMedia) — captura áudio e vídeo do microfone e câmara do dispositivo. RTCPeerConnection — gerencia a conexão P2P: codificação, transporte, adaptação de bitrate. RTCDataChannel — transmite dados arbitrários (texto, ficheiros, mensagens binárias) pelo mesmo canal.

// API JavaScript do WebRTC (exemplo de navegador)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Protocolos em tempo real

WebRTC usa SRTP (Secure Real-Time Transport Protocol) para áudio e vídeo — uma versão segura do RTP com criptografia AES-128. A gestão de sessão é feita através de SCTP (Stream Control Transmission Protocol) sobre DTLS. Cada fluxo de dados é criptografado obrigatoriamente: WebRTC não tem modo não seguro.

• SRTP/SRTCP — transmissão criptografada de fluxos de mídia com proteção contra ataques de repetição
• DTLS-SRTP — estabelecimento de chaves de criptografia via Datagram TLS sobre UDP
• SCTP — entrega de dados confiável ou parcialmente confiável para DataChannel
• ICE (Interactive Connectivity Establishment) — framework para encontrar um caminho de rede entre pares
• Trickle ICE — versão incremental do ICE onde os candidatos são enviados à medida que são descobertos, acelerando o estabelecimento da conexão

NAT traversal: ICE, STUN e TURN

O principal desafio técnico do WebRTC é estabelecer uma conexão P2P entre dispositivos que estão atrás de NAT (Network Address Translation). Sem mecanismos especiais, os dispositivos não podem alcançar-se diretamente porque seus endereços IP locais não são visíveis da internet.

STUN — determinação do endereço público

STUN (Session Traversal Utilities for NAT) — um servidor que responde à pergunta “ qual é o meu IP e porta públicos?”. O cliente envia uma solicitação ao servidor STUN, o servidor vê seu endereço público e o retorna ao cliente. O Google mantém publicamente o servidor STUN stun:stun.l.google.com:19302.

// WebRTC no iOS — configuração de servidores ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — conexão de retransmissão

TURN (Traversal Using Relays around NAT) — um servidor de retransmissão para casos em que o STUN não ajuda (NAT simétrico ou firewalls corporativos). Neste modo todos os dados passam pelo servidor TURN — isso reduz a velocidade e aumenta a latência, mas garante conexão em 99% dos casos.

TURN é o componente mais caro da infraestrutura WebRTC, pois o servidor passa todo o tráfego de mídia através de si. De acordo com Coturn Project (2025), um servidor TURN típico com 8 vCPU e 16 GB de RAM lida com cerca de 200 chamadas de áudio simultâneas ou 40 chamadas de vídeo em HD.

Processo ICE

ICE coleta todos os candidatos possíveis (IP local, IP público via STUN, retransmissão via TURN) e tenta estabelecer uma conexão em ordem de prioridade. Assim que pelo menos um par de candidatos (local-remoto) passa na verificação de conectividade, a conexão é considerada estabelecida.

• Host candidates — endereço IP local do dispositivo na sub-rede (mais rápido, mas não funciona atrás de NAT)
• Server Reflexive candidates — IP público obtido através de um servidor STUN
• Relay candidates — endereço do servidor TURN através do qual a retransmissão ocorre (mais lento, mais confiável)

WebRTC em aplicativos móveis

Para desenvolvimento móvel, o Google mantém libWebRTC — uma biblioteca nativa para Android (AAR) e iOS (XCFramework). A biblioteca inclui toda a pilha de protocolos, codecs (VP8, VP9, H.264, AV1) e aceleração de hardware para codificação/descodificação.

WebRTC no Android

O SDK do Android fornece as classes PeerConnectionFactory, PeerConnection, MediaStream. A aplicação cria uma fábrica, configura os codecs de vídeo, captura o fluxo da câmara através de VideoCapturer e estabelece a conexão entre pares via SDP offer/answer.

// WebRTC no Android — inicialização
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC no iOS

O SDK do iOS usa uma API Objective-C com wrappers RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. A codificação de hardware H.264 está disponível via VideoToolbox. Para exibição de vídeo é usado RTCMTLVideoView (Metal) ou RTCVideoRenderer.

// WebRTC no iOS — captura de vídeo da câmara
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Seleção de câmara (frontal/traseira)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Iniciar captura com FPS máximo
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Para chamadas de vídeo em produção, aplicativos móveis geralmente usam wrappers SDK sobre libWebRTC: Twilio Video, Agora, Daily.co. Estes SDKs simplificam a sinalização, gestão de salas e fornecem componentes de UI prontos para exibir a grelha de vídeo dos participantes.

Sinalização e estabelecimento de conexão

WebRTC não especifica um protocolo de sinalização — a troca de mensagens SDP (Session Description Protocol) entre pares. O desenvolvedor escolhe o transporte para sinalização: WebSocket, MQTT, SIP, XMPP ou REST API. A sinalização entrega offer, answer e candidatos ICE de um par para outro.

Troca SDP Offer/Answer

O processo começa com a criação de uma oferta (o iniciador descreve suas capacidades de mídia), transmitida via sinalização ao segundo par, que responde com uma resposta. Após a troca SDP cada par inicia o ICE e lança DTLS-SRTP para criptografia do fluxo.

// Android — criação e envio de offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Enviar sdp.description para o servidor de sinalização
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protocolos de sinalização

Para aplicativos móveis, a sinalização mais popular é via WebSocket — um canal bidirecional sobre TCP que mantém uma conexão persistente com o servidor. O servidor de sinalização é frequentemente um microsserviço separado (Node.js, Golang, Elixir) que roteia mensagens entre os participantes da sala.

• WebSocket — conexão bidirecional persistente, overhead mínimo, escolha padrão para sinalização
• SIP sobre WebSocket — protocolo VoIP padrão, integra-se com infraestrutura telefónica existente
• MQTT — protocolo pub/sub leve para IoT e redes fracas, mas com maior latência
• Matrix / XMPP — protocolos descentralizados para aplicações focadas em privacidade

Após a conclusão do ICE e DTLS-SRTP, a sinalização não participa mais na transmissão de dados — todo o tráfego de mídia flui diretamente P2P (ou através de um relay TURN). O servidor de sinalização pode ser desligado sem interromper chamadas ativas. Esta é a principal vantagem da arquitetura descentralizada do WebRTC.