WebRTC vs SIP: diferenças e casos de uso

WebRTC e SIP transportam voz em tempo real, mas foram projetados para mundos diferentes. O SIP surgiu da pilha de telefonia de operadoras e empresas, onde a sinalização padronizada entre fornecedores e a interconexão limpa com a PSTN são a razão de existência do protocolo. O WebRTC surgiu do navegador, onde o objetivo era permitir que duas páginas web enviassem mídia uma para a outra sem que ninguém precisasse instalar um plugin. O resultado são dois ecossistemas que se sobrepõem em capacidade, mas discordam em quase todas as decisões arquiteturais por baixo.

Este guia é uma comparação orientada à tomada de decisão. Ele aborda o que cada tecnologia realmente é, onde elas diferem na prática (sinalização, transporte, criptografia, identidade, travessia de NAT), os casos de uso em que cada uma vence e o que muda quando precisam se comunicar através de uma fronteira. Se você deseja entender a mecânica do protocolo SIP em si, o artigo complementar Fundamentos da sinalização SIP cobre os papéis e a arquitetura do protocolo em um nível mais alto, e Fluxo de chamada SIP explicado passo a passo acompanha as mensagens no fio. Este artigo assume esse conhecimento prévio e foca em como o WebRTC se compara.

Um tema que este artigo não aborda é a arquitetura completa de implementação de um gateway WebRTC-to-SIP. Esse tópico merece tratamento próprio, e um artigo dedicado à arquitetura de gateway será publicado em seguida. Aqui mantemos a discussão sobre gateway no nível necessário para tomar decisões, não para configurar uma implantação.

O que o WebRTC realmente é

WebRTC é um conjunto de APIs de navegador (e um conjunto correspondente de protocolos de rede) que permite a uma aplicação web capturar um microfone ou câmera, criptografar o fluxo e enviá-lo a outro terminal sem plugin e sem cliente instalado. O modelo mental adequado é: uma API JavaScript no navegador, uma pilha de mídia fixa por baixo e uma peça explicitamente ausente por cima.

A pilha de mídia fixa é opinativa. O transporte é UDP. A criptografia de mídia é SRTP, e é obrigatória; não existe modo sem criptografia. A troca de chaves usa DTLS-SRTP, realizada no próprio caminho de mídia. A travessia de NAT é integrada através de ICE, STUN e TURN, que juntos permitem que dois navegadores atrás de NATs separados encontrem um caminho funcional ou recorram a um relay. Os codecs são restritos a um pequeno conjunto, com Opus como padrão de áudio e VP8/VP9/H.264/AV1 no lado de vídeo.

A peça ausente é a sinalização. O WebRTC deliberadamente omite como dois terminais se encontram, trocam descrições de sessão ou aprendem os candidatos ICE um do outro. Isso fica a cargo da aplicação, que normalmente transporta as mensagens de sinalização via WebSocket, um esquema HTTP customizado ou qualquer outro canal que o desenvolvedor escolher. Esta é a maior diferença arquitetural em relação ao SIP. O SIP é um protocolo de sinalização; o WebRTC não possui nenhum.

A consequência prática é que dois navegadores rodando a mesma aplicação web podem se comunicar de ponta a ponta, mas dois navegadores rodando aplicações diferentes não podem. Não existe equivalente WebRTC a “discar qualquer URI SIP”. A federação acontece na camada de aplicação, não na camada de protocolo.

As diferenças fundamentais

A tabela a seguir resume as decisões arquiteturais de cada tecnologia. A maioria dos trade-offs nas seções seguintes remete a uma destas linhas.

Onde as arquiteturas diferem na prática

A tabela é um resumo justo, mas as consequências só se tornam visíveis quando analisamos como cada decisão de design se manifesta em uma implantação real.

WebRTC não possui protocolo de sinalização

Esta é a diferença estrutural da qual tudo o mais decorre. Uma aplicação WebRTC escolhe seu próprio transporte de sinalização (tipicamente WebSocket transportando JSON), define seus próprios formatos de mensagem e roteia mensagens entre usuários através de seu próprio backend. Se a aplicação desaparece, a sinalização desaparece com ela. O SIP é o oposto. A sinalização é o padrão, e qualquer terminal compatível pode se comunicar com qualquer outro terminal compatível sem coordenação prévia com a aplicação que o construiu.

Essa propriedade é o motivo pelo qual o SIP é o protocolo de interconexão. Duas operadoras, dois fornecedores de PBX, ou um PBX e uma plataforma UCaaS hospedada podem trocar chamadas sem compartilhar código de aplicação. O WebRTC não tem equivalente.

SIP desacopla sinalização de mídia; WebRTC as une por design

No SIP, o caminho de sinalização e o caminho de mídia são independentes. O SIP negocia a sessão (sobre UDP, TCP ou TLS), e o RTP ou SRTP flui diretamente entre os terminais em um conjunto diferente de portas. A mídia pode seguir uma rota completamente diferente pela rede em relação à sinalização, e frequentemente segue.

No WebRTC, o caminho de mídia é totalmente especificado pela pilha de protocolo: UDP, candidatos ICE negociados através da sinalização, handshake DTLS no socket de mídia, chaves SRTP derivadas desse handshake. A sinalização é independente no sentido de que a aplicação a controla, mas o caminho de mídia é rigidamente definido e assumido de ponta a ponta entre os dois terminais PeerConnection.

Criptografia obrigatória vs criptografia opcional

A mídia WebRTC é sempre criptografada. Não há como negociar RTP puro entre dois peers WebRTC. A troca de chaves acontece através de DTLS-SRTP no socket de mídia, o que elimina a dependência da segurança na camada de sinalização para a confidencialidade das chaves.

O SIP permite mídia criptografada (SRTP, geralmente com chaves via SDES dentro de um corpo SDP que trafega sobre sinalização protegida por TLS), mas não a exige. Uma parcela considerável do tráfego de operadoras e troncos ainda se move como RTP puro porque o operador considera a rede confiável. Para mais informações sobre como a troca de chaves SRTP difere entre SDES e DTLS-SRTP, veja O que é SRTP?.

Identidade e confiança

O SIP possui mecanismos explícitos de identidade. O cabeçalho P-Asserted-Identity transporta uma identidade de chamador afirmada dentro de uma rede confiável, o cabeçalho SIP Identity (usado pelo STIR/SHAKEN) atesta criptograficamente o número do chamador, e as operadoras mantêm relações de confiança que dão significado a esses cabeçalhos. O WebRTC não possui nada disso na camada de protocolo. A identidade em uma aplicação WebRTC é o que a aplicação decidir impor, geralmente um token de login vinculado a uma conta de usuário no mesmo backend que gerencia a sinalização.

Isso importa quando o tráfego WebRTC acaba tocando a PSTN. Um framework de mitigação de robocalls como o STIR/SHAKEN é significativo dentro do SIP. Ele não é significativo para uma chamada entre dois navegadores de dois usuários da mesma aplicação.

Filosofia de travessia de NAT

O SIP assume que o operador de rede resolverá o NAT. A solução clássica é colocar um SBC na borda para que os terminais internos se registrem em um elemento de face pública que gerencia keepalives de NAT, reescrita de endereços e travessia de NAT remoto. ALGs SIP em firewalls tentam fazer algo semelhante em implantações menores, frequentemente com resultados inconsistentes.

O WebRTC assume que os próprios terminais resolverão o NAT. O ICE percorre cada par de endereços candidatos (host, server-reflexive via STUN, retransmitido via TURN), testa-os e escolhe o melhor. Um servidor TURN é o fallback quando caminhos diretos falham, e em muitas implantações de grande porte o TURN acaba transportando uma fração substancial da mídia. O benefício é que o protocolo funciona em praticamente qualquer lugar; o custo é que os operadores precisam manter infraestrutura STUN e TURN.

Casos de uso onde o SIP vence

O SIP é o protocolo indicado sempre que uma chamada precisa sair de uma organização e chegar a outra, sempre que toca a PSTN, ou sempre que um equipamento precisa interoperar com algo diferente de uma cópia de si mesmo.

• Interconexão entre operadoras e acesso à PSTN são os casos de uso originais. Toda operadora Tier 1, todo ITSP e todo switch Class 4/5 em produção hoje fala SIP ou seu parente SIP-I.
• Microsoft Teams Direct Routing é uma integração SIP. O Teams Phone usa sinalização SIP em direção ao SBC e SRTP no caminho de mídia, com o SBC traduzindo entre o dialeto SIP do Teams e o que a operadora entrega. A mecânica completa é abordada em O que é Teams Direct Routing?.
• Telefonia empresarial multifornecedor depende do SIP para que um IP-PBX de um fornecedor, uma plataforma de contact center de outro e um Controlador de Borda de Sessão de um terceiro possam compartilhar troncos.
• Implantações de IP-PBX e SIP Trunking assumem SIP de ponta a ponta. Mesmo quando os telefones de mesa são softphones e o tronco é entregue pela internet, a sinalização por baixo da aplicação é SIP.
• Trunking de contact center em escala, incluindo BYOC para Genesys, Five9 ou NICE, usa SIP porque o lado da operadora não tem outra forma de entregar chamadas de entrada.

Onde existe um plano de numeração, uma operadora ou um PBX, o SIP é a resposta.

Casos de uso onde o WebRTC vence

A força do WebRTC está em alcançar o usuário sem pedir que ele instale nada. Em qualquer cenário onde o terminal é um navegador, um dispositivo do cliente que o operador não controla, ou uma aplicação móvel que precisa de uma pilha de mídia pequena e previsível, o WebRTC tende a ser a escolha certa.

• Softphones baseados em navegador para funcionários internos ou agentes remotos eliminam completamente o problema do cliente desktop. Uma URL e um login são a única superfície de implantação.
• Click-to-call em páginas de marketing conecta um visitante do site a uma fila de vendas ou suporte sem software de discagem no lado do visitante.
• Desktops de agente de contact center no navegador permitem que os agentes atendam chamadas dentro da mesma aba do CRM em que trabalham o dia todo, eliminando um cliente softphone separado.
• Suporte ao vivo com voz e vídeo para clientes se integra diretamente em aplicativos móveis e fluxos web; os usuários não precisam trocar de contexto para iniciar uma chamada.
• Aplicações de colaboração interna (a categoria ampla que inclui Google Meet, Discord, o cliente web do Zoom) usam WebRTC porque o custo de distribuir um cliente nativo para cada participante de uma reunião é inaceitável.
• Cenários de onboarding com baixa fricção como consultas de telemedicina, assessoria financeira ou plataformas de entrevista se beneficiam do acesso sem instalação para a parte voltada ao cliente.

O padrão comum é que um lado da conversa é uma pessoa na internet aberta que não deve ser solicitada a instalar software. O WebRTC é o protocolo projetado para esse lado.

Quando precisam se comunicar

A maioria das implantações do mundo real é mista. Um softphone baseado em navegador precisa alcançar a PSTN. Um cliente web de contact center precisa rotear chamadas de entrada de um SIP Trunk. Um widget click-to-call precisa entrar em uma fila servida por um ACD tradicional. Nesses pontos os dois mundos precisam se encontrar, e quatro elementos precisam ser traduzidos na fronteira.

Sinalização é a primeira tradução. O lado WebRTC fala o que a aplicação escolheu (comumente WebSocket transportando SIP-over-WebSocket conforme RFC 7118, ou um protocolo JSON proprietário). O lado SIP fala SIP padrão sobre UDP, TCP ou TLS. Um gateway termina ambos e faz o mapeamento entre eles.

Criptografia de mídia é a segunda. O WebRTC exige DTLS-SRTP. O lado SIP pode entregar SRTP com chaves via SDES, ou RTP puro. O gateway termina o handshake DTLS em direção ao navegador e re-chaveia a mídia na outra perna usando o que o peer SIP requer.

Codec é a terceira. Navegadores usam Opus por padrão; a PSTN e a maioria dos SIP Trunks usam G.711 por padrão. Se ambos os lados suportam um codec comum, a chamada passa; caso contrário, o gateway faz transcodificação ou rejeita a chamada. A transcodificação Opus-para-G.711 não é gratuita; ela requer capacidade de DSP de hardware em plataformas como o ProSBC (o add-on TSBC-HW-TRANS).

Travessia de NAT é a quarta. O lado WebRTC executa ICE contra o endereço alcançável do gateway. O lado SIP não faz isso; o gateway termina o ICE na perna do navegador e apresenta um terminal SIP/RTP estático para a operadora ou PBX.

Um SBC no estilo B2BUA é o encaixe arquitetural correto para essa fronteira porque termina completamente ambas as pernas e dá ao operador controle total sobre cada cabeçalho, codec e contexto criptográfico. Um SIP proxy não consegue fazer esse trabalho; as pernas são diferentes demais. Um artigo dedicado à arquitetura de gateway cobrirá os detalhes de implementação (tradução de sinalização, terminação de ICE, posicionamento de transcodificação, escalabilidade).

Onde o ProSBC se encaixa

O ProSBC é um SBC B2BUA em software que termina o lado SIP de implantações onde o tráfego WebRTC chega upstream. O papel típico é a perna SIP-para-operadora (ou SIP-para-PBX): o gateway voltado ao WebRTC entrega uma sessão SIP normalizada ao ProSBC, e o ProSBC lida com interoperabilidade de operadora, terminação TLS e SRTP em direção ao tronco, normalização de cabeçalhos SIP para o lado PSTN e ocultação de topologia entre a nuvem e a operadora.

Nessa perna, o ProSBC fornece TLS 1.3 para sinalização SIP e SRTP (retransmissão ou conversão RTP-para-SRTP) para mídia, com configuração de transporte e criptografia por grupo de tronco. O motor de manipulação de cabeçalhos SIP lida com as diferenças entre o que um CPaaS ou gateway WebRTC produz e o que uma operadora espera receber.

O ProSBC por si só pode realizar transcodificação para codecs G.711 A-law e mu-law. Para suporte a mais codecs, o ProSBC trabalha em conjunto com uma unidade de hardware TSBC-HW-TRANS para garantir que todos os sistemas alcancem negociação e tradução de codec em tempo real para cada chamada.

O ProSBC não inclui um registrar SIP integrado e não é o produto adequado para a perna voltada ao WebRTC em si. O gateway voltado ao navegador (um servidor de aplicação ou um gateway WebRTC como Janus ou Kamailio com o módulo WebSocket) fica na frente. O ProSBC fica atrás dele, no lado SIP.