Por que a Retell criou seu próprio gateway SIP e WebRTC

Antes de a Retell criar seu próprio gateway, um fornecedor líder de mercado conectava as chamadas telefônicas e de navegador aos agentes de IA da Retell. A plataforma do fornecedor teve incidentes repetidos, e ele levava em média de 50 a 60 minutos para resolver cada um. Não tínhamos como resolver um incidente mais rápido. Algumas chamadas recebidas nunca chegavam à Retell, então nossos sistemas não tinham nenhum registro delas. Ficávamos sabendo das chamadas perdidas pelos tickets de atendimento ao cliente.

Queríamos ter controle sobre a qualidade e a disponibilidade de cada chamada, então criamos nosso próprio gateway SIP e WebRTC. Desde outubro de 2026, o gateway transporta 100% das chamadas telefônicas e de navegador da Retell.

O gateway da Retell é o sistema que conecta as redes telefônicas e os navegadores web aos agentes de voz com IA da Retell. Ele fala SIP (Session Initiation Protocol), o padrão que os sistemas telefônicos usam para iniciar e encerrar chamadas, e WebRTC (Web Real-Time Communication), o padrão que os navegadores usam para áudio ao vivo.

O gateway estabelece cada chamada, transporta o áudio e faz a mixagem para todos os participantes, além de gerenciar transferências, escuta ao vivo (um supervisor ouve a chamada enquanto ela acontece), assumir a chamada (um supervisor ou agente humano assume o lugar do agente de IA no meio da chamada) e encerramentos.

Para fazer essas mudanças, substituímos o fornecedor em três etapas.

Principais resultados:

• A latência de infraestrutura é cerca de 90% menor, caindo de 50 ms para 0,5 ms.
• Toda chamada telefônica chega primeiro à Retell, inclusive as que falham.
• Os recursos de chamada são lançados no cronograma de releases da própria Retell.

O que existe entre quem liga e um agente de IA

As demonstrações de IA de voz geralmente mostram a última etapa de um sistema complexo: o modelo que escuta e responde. Um agente de voz por telefone em produção precisa de muito mais do que isso. Normalmente, várias camadas ficam na frente do modelo. Elas decidem se uma chamada se conecta, a velocidade com que o áudio trafega e o que acontece quando algo falha.

Uma chamada para um agente da Retell passa pelas quatro camadas a seguir:

1. A PSTN (rede telefônica pública comutada) é o sistema telefônico global. As chamadas de navegador chegam a partir de um site ou aplicativo web.
2. Um session border controller (SBC) é o ponto de entrada seguro para chamadas telefônicas. Ele recebe chamadas externas e decide para onde cada uma vai. As chamadas de navegador não passam pelo SBC e se conectam diretamente ao gateway.
3. A camada de mídia. Ela estabelece cada chamada, transporta o áudio nas duas direções, faz a mixagem para todos os participantes e executa controles de chamada, como transferências e encerramentos. As chamadas telefônicas chegam a ela via SIP. As chamadas de navegador chegam via WebRTC. Na Retell, o gateway é a camada de mídia.
4. A infraestrutura de IA da Retell. Ela conduz a conversa com quem ligou.

Antes do gateway, o fornecedor cuidava das camadas 2 e 3. A Retell executava um software entre elas, chamado audio relay. O áudio atravessava a internet pública entre o fornecedor e o relay, um salto de cerca de 50 ms, e o relay então o repassava para a infraestrutura de IA da Retell.

Por que a plataforma do fornecedor não atendia às nossas necessidades

A plataforma do fornecedor ficava no caminho de todas as chamadas, então seus incidentes afetavam diretamente os clientes da Retell.

O fornecedor levava em média de 50 a 60 minutos para se recuperar de um incidente. Durante alguns incidentes, as chamadas recebidas nunca chegavam do fornecedor à Retell. As chamadas perdidas não deixavam registro nem evento em nossos sistemas, o que significava que não tínhamos como detectar a falha por conta própria.

Depender do fornecedor causava outros problemas:

• Os requisitos dos clientes dependiam do que o fornecedor suportava, então não conseguíamos lançar nada que não fosse suportado.
• Era difícil atender aos requisitos de segurança e conformidade por meio da plataforma do fornecedor.
• O salto pela internet pública adicionava latência a todas as chamadas.
• A conta do fornecedor chegava a milhões de dólares por ano.

Também avaliamos outros fornecedores. As avaliações reforçaram o que já pensávamos: para controlar a qualidade do produto, precisávamos criar nosso próprio gateway.

Como substituímos o fornecedor em três etapas

Cada etapa transferiu uma parte do caminho da chamada para a infraestrutura da Retell.

Colocar os session border controllers da Retell na frente do fornecedor

Implantamos nossos próprios SBCs e direcionamos toda a sinalização SIP para eles. Os clientes passaram a enviar suas chamadas telefônicas para o endereço da Retell em vez do endereço do fornecedor. Eles também adicionaram os endereços IP da Retell às suas allowlists, as listas de endereços dos quais seus sistemas telefônicos aceitam chamadas. No início, os SBCs encaminhavam todas as chamadas para o fornecedor.

Ter nossos próprios SBCs nos deu controle sobre o roteamento. Toda chamada telefônica passou a chegar primeiro à infraestrutura da Retell, onde podíamos vê-la, independentemente de ela se conectar ou não.

Por um tempo, as chamadas fizeram um caminho mais longo. Entre os SBCs da Retell e a infraestrutura de IA da Retell, cada chamada saía da nossa rede em direção ao fornecedor e voltava. No trajeto, ela atravessava a internet pública duas vezes. As chamadas de navegador continuavam indo direto para o fornecedor.

Migrar as chamadas telefônicas para o gateway em etapas, de 1% a 100%

Em seguida, criamos o gateway e o implantamos atrás dos SBCs, dentro da rede da Retell. Com o gateway em operação, cada chamada telefônica podia seguir um de dois caminhos: pelo fornecedor ou pelo gateway.

Os SBCs escolhiam o caminho das chamadas recebidas. A infraestrutura de IA da Retell escolhia o caminho das chamadas realizadas. Aumentamos a participação do gateway nas chamadas telefônicas em etapas: 1%, 5%, 10%, 20%, 30%, 50% e, por fim, 100%. No caminho do gateway, o salto entre os SBCs e o gateway leva cerca de 0,5 ms, porque ambos ficam dentro da rede da Retell.

Migrar as chamadas de navegador para o gateway com o WebRTC SDK da Retell

As chamadas de navegador foram as últimas a continuar no fornecedor. Criamos nosso próprio WebRTC SDK (kit de desenvolvimento de software), o código que um site ou aplicativo web usa para fazer chamadas de navegador, e roteamos essas chamadas pelo gateway.

Com as chamadas de navegador migradas, desativamos o fornecedor e o audio relay. Agora, uma chamada permanece na rede da Retell desde o momento em que chega até alcançar a infraestrutura de IA da Retell.

Por que a migração foi difícil

O desafio era assumir o controle sem alterar nenhum comportamento do qual os clientes dependiam. A parte difícil foi substituir o fornecedor durante chamadas ao vivo sem causar atrito para os clientes. Chamadas recebidas, chamadas realizadas, transferências, chamadas de navegador e controles de chamada precisavam continuar funcionando como antes durante toda a migração.

Isso significava preservar quatro coisas:

• Comportamento do protocolo (como o gateway fala SIP com os sistemas do outro lado da chamada): as operadoras e os sistemas telefônicos dos clientes precisavam receber o comportamento esperado.
• Sincronização do áudio (quando o áudio chega a cada lado da chamada): o áudio precisava trafegar nos dois sentidos sem novas lacunas ou atrasos.
• Permissões dos participantes (quem na chamada pode ouvir, falar ou assumir a chamada): um supervisor usando a escuta ao vivo precisava manter os mesmos direitos.
• Semântica do ciclo de vida da chamada (como uma chamada começa, muda e termina): toda chamada precisava começar, ser transferida e terminar da mesma forma, enviando os mesmos eventos para os sistemas da Retell.

A implementação em etapas nos permitiu testar cada comportamento em uma pequena parcela de chamadas telefônicas reais. Só ampliávamos a parcela depois que o comportamento se mostrava estável.

A principal lição para nós é que uma migração de gateway como essa depende de ter controle sobre o roteamento, de uma observabilidade robusta e de testes que cubram todo o ciclo de vida da chamada. Observabilidade significa conseguir ver o que cada chamada está fazendo enquanto ela acontece.

O caminho da chamada na Retell hoje: SBCs, gateway e WebRTC SDK

Nosso novo caminho de chamada tem três partes.

Os SBCs da Retell ficam voltados para o mundo externo. Eles recebem a sinalização SIP das operadoras e dos sistemas telefônicos dos clientes e, em seguida, roteiam cada chamada.

O gateway faz o trabalho que antes era do fornecedor. Ele estabelece as chamadas, transporta e mixa o áudio e executa os controles de chamada. Ele se comunica com a infraestrutura de IA da Retell por HTTP e WebSocket, duas formas padrão de os servidores trocarem requisições e transmitirem dados.

O WebRTC SDK da Retell permite que sites e aplicativos web enviem chamadas de navegador diretamente para o gateway.

Os controles de segurança e conformidade fazem parte do design. Eles incluem acesso autenticado, permissões dos participantes, tratamento de áudio sensível e ocultação de informações sensíveis.

O que mudou com o gateway próprio

Ter o controle do caminho da chamada significa que respondemos por todos os aspectos da qualidade de uma chamada.

Não dependemos mais de um fornecedor para criar recursos de chamada. Um cliente do setor de seguros precisava de cabeçalhos SIP personalizados nas mensagens SIP BYE para uma de suas campanhas. Os cabeçalhos SIP são campos que transportam informações adicionais junto com uma chamada. Uma mensagem BYE é o sinal que encerra uma chamada. Na época, o fornecedor não suportava cabeçalhos personalizados em mensagens BYE, então criamos o recurso no gateway. Como controlamos o código e o processo de release, lançamos no nosso próprio cronograma.

Agora podemos atender por conta própria aos requisitos de segurança de um cliente (HIPAA, SOC 2 etc.). A Retell também pode implantar o gateway em novas regiões de nuvem quando os clientes precisarem.

Quando criar a sua própria solução é a decisão errada

Um gateway é o projeto errado para uma equipe que não tem capacidade de engenharia para operar uma infraestrutura de comunicações em tempo real, ou requisitos de produto que o justifiquem.

Nosso trabalho continuou após o lançamento. Operar um gateway exige uma equipe qualificada, além de investimento contínuo em:

• Interoperabilidade de telefonia
• Redes
• Processamento de mídia
• Segurança
• Monitoramento
• Operações de plantão

Interoperabilidade de telefonia significa manter o gateway compatível com as diversas operadoras e sistemas telefônicos aos quais ele se conecta.

Ter o próprio gateway também significa assumir a resposta a incidentes, o planejamento de capacidade, a manutenção e a implantação segura. A Retell fez esse investimento porque a qualidade das chamadas, a disponibilidade, a personalização e a melhoria rápida são centrais para o nosso produto.

Dicas para equipes que querem fazer o mesmo

Se a sua equipe decidir criar o próprio gateway, veja o que funcionou para nós:

1. Assuma primeiro o controle do seu ponto de entrada SIP, para gerenciar o roteamento e ver todas as chamadas telefônicas antes de substituir a camada de mídia.
2. Migre as chamadas telefônicas gradualmente, criando seu gateway atrás dos seus SBCs.
3. Trate as chamadas de navegador como uma integração completa, que inclui o SDK, a autenticação, o estabelecimento da conexão e o transporte de áudio.
4. Incorpore controles de segurança e conformidade desde o início, como fizemos com o gateway da Retell.
5. Meça a latência, a qualidade do áudio e o comportamento em falhas durante toda a migração, incluindo as chamadas que falham antes de chegar à sua aplicação.

Conecte seu sistema telefônico à Retell

Se os requisitos de telefonia têm atrasado a implementação da sua IA de voz, comece pelo nosso guia de telefonia personalizada. Ele mostra como conectar seu sistema telefônico à Retell por meio de um SIP trunk (uma conexão SIP direta entre dois sistemas telefônicos) e quais endereços da Retell incluir na allowlist. Para mais conteúdo técnico, confira nossos artigos sobre Real-Time Reliability, Retell Workflows e Retell Memory.

E se você opera com altos volumes de chamadas ou lida com requisitos rigorosos de conformidade, fale com a nossa equipe.