Arquitetura de Gateway WebRTC-para-SIP: Componentes, Tradução de Protocolos e Topologias de Implantação

Um gateway WebRTC-para-SIP é o elemento de rede que permite a uma aplicação de voz ou vídeo baseada em navegador alcançar a PSTN, um SIP trunk (tronco de voz sobre IP), um PBX ou qualquer peer SIP externo. Ele fica em uma fronteira onde duas pilhas de comunicação em tempo real, que divergem em sinalização, transporte, criptografia, travessia de NAT e identidade, precisam compartilhar uma chamada.

O artigo complementar WebRTC vs SIP: Diferenças e Casos de Uso cobre o que cada tecnologia é e quando escolher uma ou outra. Este artigo assume esse conhecimento prévio e aprofunda um nível: os subsistemas que compõem um gateway, como cada tradução funciona no nível do protocolo e como os componentes se encaixam em uma implantação de produção. Para a mecânica do protocolo SIP que este artigo pressupõe familiaridade, Fundamentos de Sinalização SIP e Fluxo de Chamada SIP Explicado Passo a Passo são as referências complementares.

O Que o Gateway WebRTC-para-SIP Precisa Fazer

Uma PeerConnection WebRTC e um diálogo SIP parecem similares vistos de longe: ambos negociam uma sessão de mídia entre dois terminais, ambos transportam RTP criptografado, ambos rodam sobre UDP. De perto, quase não se sobrepõem. Um gateway precisa resolver cinco problemas de tradução na fronteira, e cada um exige seu próprio subsistema.

Tradução de sinalização mapeia a sinalização da aplicação no lado WebRTC (tipicamente WebSocket transportando SIP-over-WebSocket ou um protocolo JSON proprietário) para SIP padrão no lado da operadora.

Terminação de travessia de NAT recebe candidatos ICE na perna do navegador, apresenta um único endereço estático na perna SIP e opera a infraestrutura STUN/TURN para o lado WebRTC.

Tradução de criptografia de mídia termina DTLS-SRTP em direção ao navegador e re-distribui as chaves de mídia na perna SIP usando o que o peer espera: SRTP via SDES, DTLS-SRTP novamente, ou RTP sem criptografia.

Mediação de codec lida com a lacuna entre Opus (o padrão WebRTC) e G.711 ou G.729 (os padrões SIP), seja por negociação SDP ou transcodificação ativa.

Ponte de identidade insere uma identidade na perna SIP de saída que sistemas downstream possam utilizar (caller ID, assinatura STIR/SHAKEN), pois o WebRTC não possui nada na camada de protocolo para transportar essa informação.

O restante deste artigo percorre cada um desses subsistemas e depois os reúne nas topologias de implantação que realmente aparecem em produção.

Tradução de Sinalização

O WebRTC não define um protocolo de sinalização. A aplicação escolhe um. Na prática, dois padrões dominam.

SIP-over-WebSocket (RFC 7118)

Este caminho executa o próprio protocolo SIP sobre uma conexão WebSocket entre o navegador e o gateway. O navegador usa uma biblioteca SIP em JavaScript (JsSIP, SIP.js); o gateway termina o WebSocket, interpreta a pilha SIP sobre ele e recodifica as mesmas mensagens em um socket SIP normal via UDP, TCP ou TLS em direção à operadora. A tradução é estruturalmente simples porque ambos os lados falam SIP; apenas o transporte muda. Kamailio (com o módulo websocket), OpenSIPS e Janus em modo gateway SIP implementam este padrão.

JSON proprietário sobre WebSocket

É o que a maioria dos SDKs de camada de aplicação utiliza, incluindo Twilio Programmable Voice, Vonage, Zoom Phone e pilhas CPaaS customizadas. O navegador envia mensagens como {"type": "invite", "callee": "...", "sdp": "..."} e o backend da aplicação traduz internamente para SIP. O gateway, neste caso, faz parte do próprio backend, e a fronteira SIP é interna à plataforma.

O que a tradução de sinalização precisa tratar e o SIP não cobre

SDP munging cobre as diferenças entre o SDP que um navegador produz e o SDP que uma operadora espera. A oferta do navegador lista todos os candidatos ICE descobertos, declara DTLS-SRTP obrigatório e anuncia Opus. A operadora espera um SDP sem atributos ICE, com chaves SDES (ou RTP sem criptografia), e uma lista de codecs diferente. O gateway reescreve o SDP completamente em cada perna, apresentando um formato ao navegador e outro à operadora.

Trickle ICE importa porque o WebRTC descobre candidatos ICE de forma assíncrona e os envia ao peer conforme aparecem, após a oferta inicial. O gateway precisa aceitar esses candidatos enviados progressivamente, mas o SIP não possui mecanismo equivalente. Assim, a oferta no lado SIP ou aguarda a conclusão do ICE (end-of-candidates) ou omite o ICE inteiramente e usa um único endereço estático.

Tratamento de re-INVITE torna-se um problema de tradução porque mudanças durante a chamada (espera, mudo, troca de codec, transferência) chegam como renegociação em ambos os lados, porém em formatos diferentes. O gateway precisa mapear entre eles sem derrubar a chamada. Consulte Fluxo de Chamada SIP Explicado para entender como o re-INVITE funciona no lado SIP.

Travessia de NAT e Terminação de ICE

O WebRTC assume que os terminais resolverão o NAT por conta própria. O SIP assume que o operador de rede resolverá. O gateway precisa unir as duas filosofias, o que faz executando ICE completo em uma perna e nenhum ICE na outra.

Na perna do navegador, o gateway executa ICE completo. Ele anuncia seus próprios candidatos ICE (host, server-reflexive via STUN, relay via TURN), testa conectividade contra os candidatos do navegador e seleciona o melhor caminho. Se caminhos diretos falharem, o próprio servidor TURN do gateway faz o relay da mídia. Isso significa que o operador precisa implantar e escalar infraestrutura TURN proporcional ao tráfego WebRTC; em implantações onde a maioria dos navegadores está atrás de NAT corporativo restritivo, o TURN pode transportar uma parcela significativa dos bytes de mídia.

Na perna SIP, o gateway apresenta um único IP e porta estáticos à operadora. Não há ICE nesta perna; a operadora espera um socket RTP fixo no endereço público do gateway. O gateway é responsável por manter esse socket acessível através de qualquer NAT ou firewall à sua frente, o mesmo problema que qualquer SBC resolve com ocultação de topologia e tratamento de NAT remoto.

A assimetria é intencional. O ICE empurra a complexidade para os terminais quando ambos são inteligentes (dois navegadores). Em uma fronteira com a operadora, onde um lado é um switch de hardware que não mudou em quinze anos, o gateway absorve a complexidade.

Criptografia de Mídia: A Transição DTLS-SRTP

Esta é a parte criptograficamente mais interessante do gateway. As duas pernas usam mecanismos de troca de chaves diferentes, e o gateway é a fronteira de confiança entre elas.

Na perna do navegador, o gateway atua como respondedor DTLS. Depois que o ICE seleciona um caminho, o navegador inicia um handshake DTLS no mesmo socket UDP por onde a mídia trafegará. O gateway apresenta um certificado (auto-assinado é aceitável; o fingerprint trafega no SDP), completa o handshake e deriva as chaves mestras SRTP a partir das chaves de sessão DTLS via a API export_keying_material. A mídia vinda do navegador é criptografada com essas chaves.

Na perna SIP, o gateway negocia SRTP de forma diferente. O padrão mais comum é SDES, onde a chave mestra é embutida diretamente no corpo SDP e o corpo é protegido por TLS no canal de sinalização. Menos comumente, o peer SIP também suporta DTLS-SRTP; nesse caso o gateway executa um segundo handshake DTLS na saída. O padrão menos seguro é RTP sem criptografia, onde nenhuma criptografia é negociada; o gateway criptografa a perna do navegador e descriptografa na perna SIP.

Qualquer que seja a combinação, o gateway mantém dois contextos SRTP independentes ao mesmo tempo e recriptografa cada pacote ao cruzar a fronteira. Os pacotes mudam: valores de SSRC são reescritos, números de sequência são reiniciados e as chaves são completamente diferentes em cada lado. Não há compartilhamento de chaves entre as pernas; esse é exatamente o objetivo.

Mediação de Codec e Posicionamento da Transcodificação

Opus é o padrão WebRTC. G.711 (mu-law ou A-law) é o padrão PSTN. O gateway tem três opções quando uma chamada cruza a fronteira.

Negociar um codec comum. Se a operadora suporta Opus no SIP trunk (a maioria não suporta) e o navegador suporta G.711 (a maioria suporta), o gateway pode encaminhar sem transcodificação. Algumas implantações MSP e CPaaS configuram dessa forma para eliminar completamente o custo de transcodificação.

Transcodificar. O gateway decodifica o RTP de entrada, recodifica no codec de saída e encaminha o novo stream. Opus-para-G.711 é o caso mais comum. Para uma visão mais ampla de como a transcodificação funciona na borda do SBC, o artigo Transcodificação AMR para G.711 no SBC percorre o mesmo ciclo de decodificação/recodificação para codecs de redes móveis.

Rejeitar a chamada. Se nenhum dos lados consegue negociar algo que o outro aceite (raro, mas possível com troncos exclusivamente G.729), o gateway retorna 488 Not Acceptable Here.

O posicionamento da transcodificação na arquitetura do gateway tem consequências práticas. Transcodificação por software em CPUs genéricas funciona bem para G.711 para G.711 (A-law para mu-law é essencialmente gratuito) e para capacidade limitada de Opus. Transcodificação Opus-para-G.711 em alta densidade é dominada por aritmética de DSP, e a maioria das implantações de grau operadora descarrega esse trabalho em hardware dedicado para manter margem de CPU disponível para as demais responsabilidades do gateway.

Para um SBC posicionado na perna SIP de uma implantação de dois níveis, o posicionamento ideal geralmente é manter a transcodificação G.711 em software (A-law para mu-law é suportado nativamente no ProSBC) e descarregar AMR e G.729 para uma unidade de transcodificação em hardware como o TSBC-HW-TRANS. O codec na perna de entrada WebRTC é o que determina a necessidade de DSP, não o codec do lado SIP.

Ponte de Identidade

O WebRTC não possui identidade na camada de protocolo. A aplicação afirma a identidade em seu próprio backend, geralmente com um token de login vinculado a uma conta de usuário. Quando essa chamada cruza para o SIP, a operadora precisa de algo concreto para inserir no cabeçalho From, no cabeçalho P-Asserted-Identity e (nos EUA) no cabeçalho STIR/SHAKEN Identity.

O gateway resolve isso mapeando a identidade do usuário WebRTC para uma identidade SIP na fronteira. O gateway é configurado com uma identidade de SIP trunk (um número de serviço, uma faixa de DID ou uma identidade assertada por B2BUA) e insere no INVITE de saída essa identidade, além de atestação por chamada de que o gateway autenticou o usuário upstream.

Para STIR/SHAKEN, o gateway pode assinar com nível de atestação A somente quando opera como operadora de origem. Se o gateway repassa para uma operadora que assina, o gateway fornece a identidade de origem e o serviço de assinatura da operadora produz o cabeçalho Identity. O ProSBC integra com TransNexus ClearIP e Neustar via SIP exatamente para esse padrão: o gateway roteia a chamada para um NAP cujo service_type é AUTHENTICATION, o ClearIP retorna um 302 com o cabeçalho Identity anexado e a chamada prossegue para a operadora. A mecânica de normalização de cabeçalhos portadores de identidade entre dialetos SIP de diferentes fornecedores é coberta em Manipulação de Cabeçalhos SIP.

O que não pode ser transportado: tokens de identidade WebRTC (JWTs, fluxos OAuth) não sobrevivem à fronteira SIP. Toda confiança que o backend da aplicação estabeleceu é trocada pela relação de confiança própria do gateway com a operadora.

Topologias de Implantação

Três padrões dominam em produção. A escolha depende da escala, da necessidade de conferência multiponto e de o operador preferir um único elemento fazendo tudo ou elementos especializados fazendo uma função cada.

Gateway de nível único

Um único dispositivo termina o lado WebRTC, realiza a tradução e apresenta uma interface SIP à operadora. Janus com o plugin SIP, Kamailio com os módulos websocket e rtpengine, e vários appliances de fornecedores CPaaS seguem esse padrão. A vantagem é simplicidade operacional: uma única máquina para escalar e monitorar. A desvantagem é que o gateway precisa fazer tudo, incluindo transcodificação pesada em DSP e o trabalho de SBC do lado da operadora (manipulação de cabeçalhos, proteção contra fraude, ocultação de topologia, absorção de registrador). Em pequena escala é aceitável; em escala de operadora, consolida responsabilidade demais em um único elemento.

Dois níveis: gateway WebRTC em frente a um SBC

Este é o padrão de produção mais comum. Um gateway WebRTC dedicado trata a perna voltada ao navegador: terminação de WebSocket, ICE, DTLS-SRTP, TURN, envio progressivo de candidatos ICE e asserção de identidade a partir do backend da aplicação. O gateway então entrega uma sessão SIP normalizada a um SBC que trata a perna voltada à operadora: SIP sobre TLS, SRTP com SDES, normalização de cabeçalhos, ocultação de topologia, controle de admissão de chamadas, pontuação de fraude e integração STIR/SHAKEN. A divisão permite que cada elemento se especialize e escale independentemente do outro.

O ProSBC se encaixa neste padrão no lado SIP. Ele não é um gateway voltado ao WebRTC e não termina sinalização WebSocket; o gateway WebRTC à sua frente (Janus, Kamailio, OpenSIPS ou um servidor de aplicação CPaaS) trata o lado do navegador. O ProSBC trata tudo downstream: TLS para sinalização SIP, SRTP para mídia (relay ou conversão RTP-para-SRTP), manipulação de cabeçalhos SIP por grupo de troncos para atender o que cada operadora espera, ocultação de topologia entre a zona WebRTC e a operadora, e integração com detecção de fraude e parceiros STIR/SHAKEN.

Topologia de implantação em dois níveis: um gateway WebRTC trata a perna voltada ao navegador (sinalização WebSocket, ICE, DTLS-SRTP, TURN) e entrega uma sessão SIP normalizada ao ProSBC, que trata a perna voltada à operadora (SIP/TLS, SRTP, manipulação de cabeçalhos SIP, ocultação de topologia, integração com fraude e STIR/SHAKEN). Clique para ampliar.

Três níveis com servidor de mídia

Para implantações que necessitam de conferência multiponto, um SFU (Selective Forwarding Unit) ou MCU (Multipoint Control Unit) fica entre o navegador e o gateway. O SFU trata o processamento da conferência (encaminhamento de streams de vídeo para todos os participantes e mixagem de streams de áudio entre participantes), e o gateway faz a ponte entre a saída SIP do SFU e a operadora quando a conferência inclui um participante PSTN. Esta é a arquitetura por trás da conferência com discagem para a maioria das grandes plataformas de reunião e implantações de contact center.

O padrão de três níveis adiciona um SFU entre o cluster de navegadores e o gateway WebRTC, com o restante do caminho SIP inalterado.

Escalabilidade: TURN, Sinalização e Mídia

Cada subsistema escala em um eixo diferente, e o planejamento de capacidade de um não diz muito sobre o planejamento de capacidade de outro.

Largura de banda TURN é o item mais variável. Um caminho direto do navegador ao gateway usa zero largura de banda TURN. Um navegador atrás de NAT simétrico ou firewall corporativo restritivo faz relay pelo TURN durante toda a duração da chamada, e o servidor TURN arca com os bytes em ambas as direções. Planeje a capacidade TURN para a fração de pior caso de usuários que não conseguem encontrar um caminho direto, não para a média. Em implantações com tráfego corporativo significativo, essa fração regularmente supera 20%.

Capacidade de sinalização no gateway é limitada pela densidade de conexões WebSocket, não pelo volume de mensagens. Cada navegador conectado mantém um WebSocket aberto; dezenas de milhares de WebSockets ociosos em um único host são viáveis se a memória for dimensionada corretamente. A tradução de sinalização em si é barata por mensagem, mas as conexões de longa duração dominam.

Capacidade de mídia escala com a carga de transcodificação por chamada. Relay puro (sem transcodificação, ambos os lados no mesmo codec) escala próximo à taxa de linha da rede. Transcodificação Opus-para-G.711 é limitada por ciclos de DSP ou CPU; a densidade publicada para transcodificadores em hardware chega a milhares de sessões simultâneas por servidor de processamento de mídia, enquanto a transcodificação por software tipicamente é uma fração disso.

No lado SIP, o ProSBC suporta até 60.000 sessões de sinalização simultâneas por servidor com transcodificação por software apenas para G.711; AMR e G.729 requerem uma unidade de transcodificação em hardware. Combinar os dois de forma limpa é o que permite a uma implantação de dois níveis escalar o plano de mídia independentemente do plano de sinalização: o gateway WebRTC dimensiona para densidade de WebSocket e throughput TURN, enquanto o SBC dimensiona para sessões SIP e (quando presente) unidades de transcodificação.

Alta Disponibilidade e Observabilidade

Um gateway WebRTC-para-SIP está no caminho crítico de voz, o que significa que cada componente precisa de um par redundante e os modos de falha precisam ser visíveis a partir de ambos os lados.

Para HA, o gateway WebRTC pode operar em modo ativo-ativo atrás de um balanceador de carga, pois conexões WebSocket são independentes e stateless do ponto de vista do cluster. Os servidores TURN tipicamente operam em ativo-ativo atrás de anycast ou DNS round-robin. O SBC na perna SIP mais frequentemente usa ativo-standby com IP virtual. O ProSBC suporta HA 1+1 em modo ativo-standby para máximo uptime, com a ressalva de que o failover não é sem perda; algumas chamadas em andamento caem durante a troca, e a implantação deve ser projetada para retentá-las rapidamente em vez de tentar prevenir a queda.

Para observabilidade, a rastreabilidade entre as pernas é o problema difícil. Uma chamada que falha entre um navegador e um destino PSTN passa pelo backend da aplicação, pelo gateway WebRTC, pelo SBC e pela operadora; cada componente registra logs em seu próprio formato, e correlacionar uma única chamada entre todos eles exige propagar um identificador de chamada por cada salto. A prática padrão é injetar um identificador único como cabeçalho SIP na perna SIP e como campo customizado na sinalização da aplicação na perna WebRTC, expondo ambos em logging centralizado.

O ProSBC expõe métricas por NAP e por chamada (CPS, ASR, ABR, PDD, jitter) por meio de sua REST API, podendo encaminhá-las para a plataforma de observabilidade de preferência do cliente. Melhores práticas de monitoramento VoIP cobre o que essas métricas significam e quais limiares importam em uma implantação de voz em produção.

Perguntas Frequentes

Conclusão

Um gateway WebRTC-para-SIP é o elemento de fronteira que permite a duas pilhas de comunicação em tempo real compartilhar uma chamada sem que nenhum dos lados conheça as decisões de protocolo do outro. O gateway é construído a partir de cinco subsistemas: tradução de sinalização, terminação de ICE, recriptografia DTLS-SRTP, mediação de codec e ponte de identidade. Cada um tem seu próprio perfil de escalabilidade, e a implantação de produção mais comum os distribui em dois níveis: um gateway WebRTC dedicado no lado do navegador e um SBC no lado da operadora, para que cada elemento se especialize no trabalho que faz melhor.

Ao avaliar componentes de gateway para uma implantação em produção, as perguntas a fazer são: qual lado cada elemento termina, onde a transcodificação reside (hardware ou software), como TURN e capacidade de sinalização são dimensionados independentemente, e como a identidade é transportada através da fronteira para assinatura STIR/SHAKEN. As respostas determinam se a implantação é um appliance de nível único, uma divisão em dois níveis ou uma topologia de conferência em três níveis.