O que é um SIP Proxy? Arquitetura, B2BUA vs. Proxy e interoperabilidade SIP empresarial

Você tem um PBX Cisco no data center, um contact center Avaya em uma sub-rede separada e um provedor de SIP Trunk na nuvem que fala um dialeto SIP ligeiramente diferente dos outros dois. A busca por um “SIP proxy” que faça esses sistemas se comunicarem de forma confiável é o ponto de partida de muitas implantações SIP, e costuma ser onde os engenheiros descobrem que um SIP proxy leve não é a ferramenta certa para o trabalho.

Um SIP proxy, no sentido estrito do RFC 3261, é um servidor que encaminha requisições SIP em direção ao destino sem terminar completamente a sessão de chamada. Ele fica no caminho da sinalização, decide para onde rotear as requisições e as repassa adiante; ele não renegocia como a chamada é configurada, não reescreve cabeçalhos para compatibilidade entre fabricantes e não controla o caminho de mídia. Em um ambiente homogêneo de um único fabricante, essa transparência é exatamente o que você precisa. Nos ambientes multi-fabricante e multi-operadora que caracterizam a maioria das implantações empresariais e de provedores de serviço, você precisa de algo que consiga realmente intervir.

Esta página cobre a arquitetura de SIP proxies, as diferenças críticas entre um proxy e um Agente de Usuário Back-to-Back (B2BUA), onde cada um se encaixa em uma rede real, e por que a maioria dos interconectos com operadoras e implantações SIP empresariais precisa das capacidades completas de um Controlador de Borda de Sessão (SBC).

Como funciona um SIP Proxy

Um SIP proxy é um intermediário de rede que roteia mensagens de sinalização SIP entre User Agents (UAs, incluindo telefones, softclients, sistemas PBX e qualquer terminal que fale SIP). Sua função principal é resolver um SIP URI para um endereço de rede e encaminhar a requisição um salto mais perto do destino.

O proxy adiciona um cabeçalho Via a cada requisição SIP conforme ela passa, registrando seu endereço no caminho de sinalização. As respostas do destinatário percorrem de volta a mesma cadeia de cabeçalhos Via, com cada proxy removendo sua própria entrada conforme a resposta passa. Isso cria uma rota de sinalização rastreável e reversível sem exigir que o proxy mantenha qualquer estado sobre a chamada em si.

Proxies stateless vs. stateful

Um proxy stateless processa cada mensagem SIP isoladamente. Ele lê o URI da requisição, aplica a lógica de roteamento, encaminha a mensagem e a esquece. Não há estado de transação, registro de chamada nem correlação entre uma requisição e sua resposta. Proxies stateless são rápidos e horizontalmente escaláveis, mas não têm capacidade de executar nada que exija consciência da chamada como um todo: sem bifurcação, sem autenticação, sem roteamento de fallback.

Um proxy stateful rastreia transações SIP (a troca completa de uma requisição e suas respostas) e, opcionalmente, rastreia o diálogo (a chamada completa do INVITE ao BYE). Isso permite que proxies stateful realizem funcionalidades como bifurcação paralela (enviar um INVITE para múltiplos destinos simultaneamente), re-roteamento autenticado e distribuição rudimentar de carga. A maioria da infraestrutura SIP em produção usa proxies stateful quando proxies são utilizados.

O que nem proxies stateless nem stateful fazem: modificar o corpo SDP para alterar preferências de codec, reescrever cabeçalhos SIP para acomodar incompatibilidades de fabricantes, terminar o caminho de mídia para aplicar criptografia ou ocultar a topologia da rede interna de partes externas.

O modelo de encaminhamento: Via, Route e Record-Route

Três cabeçalhos SIP definem como os proxies participam de uma sessão:

Via é o mecanismo de rastreamento. Cada proxy adiciona seu endereço (e um parâmetro branch único) ao cabeçalho Via na ida, e as respostas removem as entradas Via na ordem inversa. É assim que uma resposta sabe para onde ir.

Route é uma instrução de roteamento pré-carregada: uma lista de endereços de proxy pelos quais a requisição deve passar, consumidos um por um.

Record-Route é como um proxy stateful se insere no diálogo em andamento. Ao se adicionar ao cabeçalho Record-Route, o proxy garante que verá todas as requisições subsequentes no mesmo diálogo, mantendo-se no caminho de sinalização durante toda a vida da chamada. Um proxy que não adiciona Record-Route verá apenas o INVITE inicial, não os re-INVITEs durante a chamada nem o BYE.

Nenhum desses mecanismos dá ao proxy a capacidade de alterar o conteúdo da requisição. Eles governam o roteamento, não o conteúdo.

B2BUA vs. SIP Proxy: principais diferenças arquiteturais

Um Back-to-Back User Agent adota uma abordagem fundamentalmente diferente. Em vez de encaminhar requisições, um B2BUA termina o diálogo SIP do chamador, atuando como User Agent Server (UAS), e origina um diálogo SIP completamente novo em direção ao destinatário, atuando como User Agent Client (UAC). As duas pernas são totalmente independentes. O B2BUA pode alterar qualquer coisa: os cabeçalhos SIP, a oferta SDP, a lista de codecs, o protocolo de transporte, o caminho de mídia.

Essa diferença arquitetural tem consequências de longo alcance sobre o que o dispositivo pode e não pode fazer.

O que um B2BUA pode fazer que um proxy não pode

Como um B2BUA termina e re-origina, ele tem visibilidade e controle completos sobre ambas as pernas de sinalização. Isso permite:

Manipulação de cabeçalhos SIP. Um B2BUA pode adicionar, modificar ou remover qualquer campo de cabeçalho SIP. Na prática, isso significa normalizar implementações incompatíveis de fabricantes: converter um formato de cabeçalho SIP no padrão Cisco para um que o sistema Avaya aceite, ou remover cabeçalhos proprietários que um SIP Trunk de operadora rejeita.

Ocultação de topologia. Em um SIP proxy, os cabeçalhos SIP do chamador refletem os endereços reais da rede interna. Um B2BUA substitui todo o endereçamento interno pelo seu próprio endereço externo, ocultando a topologia interna por completo. Este é um requisito de segurança para qualquer implantação voltada para operadoras ou para a internet.

Renegociação de codecs. Quando dois terminais oferecem listas de codecs incompatíveis em seu SDP, um B2BUA pode modificar a troca de oferta/resposta SDP para intermediar um codec que ambos os lados aceitem, ou invocar transcodificação se nenhum codec comum existir.

Ancoragem de mídia. Um B2BUA pode se posicionar no caminho de mídia, aceitando e encaminhando pacotes RTP, o que permite criptografia/descriptografia SRTP, conversão RTP-para-SRTP, gravação de mídia e pontuação de qualidade MOS.

O trade-off: complexidade vs. controle

Um SIP proxy é mais simples de implantar e adiciona menor sobrecarga de processamento por chamada, sendo apropriado para roteamento interno de alto volume em um ambiente homogêneo. Um B2BUA adiciona alguma sobrecarga de processamento por chamada, aumenta o estado e requer mais configuração. Em contrapartida, ele oferece a superfície de controle necessária para fazer redes SIP heterogêneas funcionarem.

Para qualquer coisa voltada para a internet ou para uma operadora, o modelo B2BUA não é opcional. O modelo de proxy simplesmente não consegue atender aos requisitos de segurança e interoperabilidade.

Normalização SIP: o problema que um proxy não resolve

O padrão SIP (RFC 3261 e seus complementares) define o protocolo. Ele não obriga que cada fabricante implemente cada funcionalidade da mesma forma. Na prática, dois sistemas que declaram conformidade SIP frequentemente discordam em formatação de cabeçalhos, ordenação de codecs no SDP, método de sinalização DTMF, comportamento de UPDATE vs. re-INVITE, tratamento de session timers e dezenas de outros detalhes.

Incompatibilidades SIP multi-fabricante comuns

Os seguintes são problemas reais de interoperabilidade encontrados em redes de voz em produção:

Sinalização DTMF. Alguns terminais enviam dígitos DTMF como áudio in-band (RFC 2833 / RFC 4733 no fluxo RTP). Outros usam mensagens SIP INFO. Outros ainda usam sinalização out-of-band via o formato telephone-event do SDP. Quando dois sistemas usam métodos diferentes, os tons DTMF são perdidos completamente, um problema que destrói a funcionalidade de IVR, acesso a correio de voz e conferências.

Ordenação de codecs. Uma oferta SDP lista codecs em ordem de prioridade. Alguns fabricantes exigem que o primeiro codec da lista seja o preferido; outros escolhem o codec de maior qualidade em comum independentemente da posição. Quando uma incompatibilidade na ordem dos codecs resulta na seleção de um codec subótimo, a qualidade da chamada degrada de formas difíceis de diagnosticar.

Formatação dos cabeçalhos Via e Contact. Certos fabricantes de PBX colocam parâmetros extras nos cabeçalhos Via ou Contact que SIP Trunks downstream rejeitam como malformados. Outros fabricantes removem parâmetros que são obrigatórios. De qualquer forma, as chamadas falham, ou falham intermitentemente, dependendo do caminho da chamada.

Session timers. O RFC 4028 define session timers para detectar chamadas travadas. Nem todos os terminais os suportam, e diferentes implementações dos valores de Session-Expires conflitam. Um B2BUA pode normalizar o comportamento de timers em ambas as pernas.

Cabeçalhos P-Asserted-Identity e PAI. Os cabeçalhos de identidade do chamador variam significativamente entre fabricantes e operadoras. Um B2BUA pode normalizá-los para compatibilidade com STIR/SHAKEN, garantindo que as informações de identidade corretas sejam apresentadas na camada de atestação.

Motor de manipulação de cabeçalhos SIP

A solução para os problemas acima é um motor de manipulação de cabeçalhos SIP: um sistema baseado em regras que define, para cada perna de chamada ou grupo de troncos, exatamente quais cabeçalhos são adicionados, modificados ou removidos conforme as chamadas passam. As regras de manipulação operam nas mensagens SIP de entrada e saída de forma independente, permitindo tratamentos específicos por fabricante em cada lado do B2BUA.

Esta é a função de normalização central que faz de um B2BUA SBC o dispositivo certo para ambientes multi-fabricante. Sem ela, cada incompatibilidade de fabricante requer uma regra de firewall como workaround, uma mudança de configuração no sistema do fabricante, ou uma chamada que simplesmente não funciona.

SIP Proxies em arquiteturas de operadoras e empresas

Na prática, SIP proxies aparecem em redes de produção, mas em funções específicas onde suas limitações são aceitáveis.

Onde SIP proxies são usados:

• Como front-ends de registrar SIP, distribuindo requisições REGISTER para um pool de servidores de registro
• Como balanceadores de carga internos entre um cluster de servidores de aplicação idênticos em uma plataforma homogênea (todos rodando o mesmo software, mesmo fabricante, mesmo perfil de codec)
• Como camadas de resolução DNS baseadas em SIP em plataformas de operadoras de grande escala, onde a decisão de roteamento é pura tradução de endereços sem necessidade de modificação de conteúdo

Onde SIP proxies ficam aquém:

• Qualquer interconexão operadora-empresa, onde o SIP Trunk da operadora fala um dialeto SIP e o PBX empresarial fala outro
• Qualquer implantação que exija TLS para sinalização SIP, o que requer terminar a sessão TLS e re-originá-la, exatamente o que um proxy não faz
• Qualquer implantação que exija criptografia de mídia SRTP, o que requer ancoragem de mídia
• Qualquer implantação sujeita a exposição DoS/DDoS: um proxy stateless não oferece proteção; ele encaminha tráfego de flood tão prontamente quanto tráfego legítimo

O Controlador de Borda de Sessão é a classe de dispositivo definida especificamente para atender a esses requisitos nas bordas de rede. Um SBC usa a arquitetura B2BUA internamente e adiciona camadas de segurança, controle de acesso, gerenciamento de topologia e normalização sobre ela.

Para uma análise detalhada de como SBCs se conectam a troncos de operadoras, consulte o guia SBC SIP Trunk. Para um aprofundamento nas capacidades de segurança na camada SIP, acesse o pilar de segurança VoIP.

Registro e autenticação SIP

SIP proxies e SBCs lidam com o registro SIP de formas diferentes, e a diferença importa tanto para segurança quanto para operações.

Um registrar SIP é a entidade que aceita requisições REGISTER e mapeia um SIP AOR (Address of Record, um SIP URI como [email protected]) para um endereço de contato (o endereço IP atual do terminal). Em implantações clássicas, o registrar é uma função de servidor distinta, frequentemente co-localizada com um proxy.

Um SBC com arquitetura B2BUA pode realizar encaminhamento de registro SIP: aceitando requisições REGISTER dos terminais, encaminhando-as upstream para o registrar da operadora e mantendo o mapeamento de registro localmente. Isso dá ao SBC visibilidade total do estado de registro de cada terminal atrás dele, sem exigir mudanças no registrar upstream.

Mais importante, um SBC pode realizar proteção contra varredura de registro SIP: detectando ataques de flood de registro, tentativas automatizadas de força bruta de credenciais por meio do envio de altos volumes de requisições REGISTER, e bloqueando-os na borda antes que alcancem o registrar ou PBX. Um SIP proxy leve não tem mecanismo para distinguir um flood de registro de tráfego legítimo; ele encaminha ambos igualmente.

Esses não são requisitos de caso extremo. A varredura de registro SIP é um dos vetores de ataque mais comuns contra infraestrutura SIP voltada para a internet. Qualquer dispositivo na borda de rede precisa de proteção ativa contra isso.

SIP Proxy no contexto do Microsoft Teams Direct Routing

O Microsoft Teams Direct Routing é o mecanismo que conecta usuários do Teams Phone à rede pública de telefonia comutada (PSTN) através de um SIP Trunk gerenciado pelo cliente. A Microsoft exige que o dispositivo que conecta o Teams ao SIP Trunk seja um Controlador de Borda de Sessão certificado (não um SIP proxy).

As razões são diretas. O Teams exige:

• TLS para sinalização SIP nas pernas voltadas para o Teams e para a operadora. Terminar uma sessão TLS requer que o dispositivo atue como terminal TLS, o que um proxy transparente não pode fazer. Um SBC B2BUA termina TLS em ambas as pernas de forma independente.
• SRTP para criptografia de mídia na perna voltada para o Teams. Isso requer ancoragem de mídia, possível apenas com um B2BUA.
• Normalização SIP entre o dialeto SIP do Teams e o dialeto SIP Trunk da operadora. A implementação SIP do Microsoft Teams tem requisitos específicos de cabeçalho que a maioria dos SIP Trunks de operadoras não atende nativamente.
• Travessia de NAT e ocultação de topologia, garantindo que endereços de rede internos não vazem no caminho de sinalização do Teams.

Um SIP proxy não satisfaz nenhum desses requisitos. A Microsoft testa SBCs contra o conjunto completo de requisitos SIP do Teams: tratamento de cabeçalhos, suporte a codecs, DTMF, comportamento de registro e conformidade TLS/SRTP. Para mais informações sobre como o ProSBC se conecta ao Microsoft Teams Direct Routing, consulte nossa página de produto.

Perguntas frequentes

Qual é a diferença entre um SIP proxy e um Controlador de Borda de Sessão?

Um SIP proxy encaminha requisições SIP sem terminar a sessão de chamada. Ele não pode modificar cabeçalhos SIP para normalização de fabricantes, aplicar criptografia de mídia ou ocultar a topologia da rede interna. Um Controlador de Borda de Sessão (SBC) usa uma arquitetura B2BUA para terminar e re-originar completamente tanto as pernas de sinalização quanto de mídia. Isso lhe confere controle total sobre manipulação de cabeçalhos, negociação de codecs, criptografia de mídia (SRTP), ocultação de topologia, proteção contra DoS/DDoS e controle de acesso, todos necessários em qualquer interface de operadora ou borda de rede multi-fabricante.

Um SIP proxy pode lidar com interoperabilidade SIP multi-fabricante?

SIP proxies leves são mais adequados para ambientes homogêneos de um único fabricante. A interoperabilidade multi-fabricante (onde um PBX Cisco, um sistema Avaya e um SIP Trunk de operadora implementam cabeçalhos SIP, DTMF e negociação de codecs de formas diferentes) requer um SBC B2BUA com motor de manipulação de cabeçalhos SIP que possa normalizar o tráfego de cada fabricante de forma independente.

O Microsoft Teams Direct Routing requer um SBC ou um SIP proxy?

O Microsoft Teams Direct Routing requer um Controlador de Borda de Sessão certificado. Um SIP proxy não pode terminar sessões TLS, ancorar mídia SRTP nem realizar a normalização SIP entre o Teams e os SIP Trunks de operadoras que o programa de certificação da Microsoft valida. A Microsoft mantém uma lista de fornecedores de SBC certificados para o Teams Direct Routing.

O que é um B2BUA?

Um Back-to-Back User Agent (B2BUA) é uma entidade SIP que atua como User Agent Server (UAS) na perna de entrada e como User Agent Client (UAC) na perna de saída. Ele termina o diálogo SIP do chamador e origina um novo diálogo em direção ao destinatário. Diferentemente de um SIP proxy, o B2BUA tem controle total sobre ambas as pernas, permitindo reescrever cabeçalhos SIP, renegociar codecs, ancorar mídia e aplicar criptografia de forma independente em cada lado.

Quando você usaria um SIP proxy em vez de um SBC?

Um SIP proxy é apropriado para roteamento interno em um ambiente de fabricante único onde todos os terminais falam o mesmo dialeto SIP e onde limites de segurança, normalização de cabeçalhos, controle de mídia e proteção contra DoS não são necessários. Qualquer implantação voltada para a internet, um SIP Trunk de operadora ou um ambiente multi-fabricante precisa das capacidades completas de B2BUA de um SBC.

Para que serve um servidor SIP proxy em redes empresariais?

Em redes empresariais, um servidor SIP proxy lida com o roteamento interno de chamadas entre terminais que compartilham a mesma implementação SIP. Ele resolve SIP URIs para endereços de rede, distribui registros e pode realizar balanceamento de carga básico em um cluster de servidores idênticos. Ele não fornece a normalização de cabeçalhos, criptografia de mídia ou aplicação de segurança necessárias nas fronteiras de rede. Para tráfego entre fabricantes ou voltado para operadoras, um SBC substitui ou complementa o proxy.

Um SIP proxy é o mesmo que um SIP gateway?

Não. Um SIP proxy roteia sinalização SIP entre terminais SIP sem conversão de protocolo. Um SIP gateway converte entre SIP e um protocolo ou tipo de rede diferente, como PSTN/TDM, H.323 ou WebRTC. Um SBC combina roteamento semelhante ao de proxy com tradução de protocolo semelhante à de gateway e adiciona segurança em nível de sessão, tornando-o o dispositivo padrão nas fronteiras de rede onde tanto roteamento quanto conversão são necessários.

Um SIP proxy pode realizar balanceamento de carga?

Um SIP proxy stateful pode distribuir requisições INVITE entre múltiplos destinos usando round-robin, distribuição ponderada ou seleção baseada em prioridade. No entanto, ele não pode realizar balanceamento de carga com consciência de sessão (roteamento baseado em contagem atual de chamadas, métricas de qualidade ou saúde do terminal) porque não mantém estado de sessão além do nível de transação. Para distribuição com consciência de sessão, o motor de roteamento de um SBC oferece mais controle.

Conclusão

SIP proxies são um componente fundamental da arquitetura SIP, mas sua função é precisamente definida. Eles roteiam requisições. Eles não terminam sessões, modificam conteúdo, protegem redes nem normalizam implementações incompatíveis. Nos ambientes onde essas limitações não importam (redes internas homogêneas, plataformas de fabricante único, camadas de roteamento puro), eles funcionam bem. Nos ambientes que constituem a maioria das implantações reais de redes de voz, não funcionam.

Interconexões com operadoras, Microsoft Teams Direct Routing, voz empresarial multi-fabricante, integração de plataformas CPaaS e qualquer implantação sujeita a tráfego voltado para a internet exigem a superfície de controle completa de um SBC Controlador de Borda de Sessão B2BUA: manipulação de cabeçalhos SIP, ocultação de topologia, ancoragem e criptografia de mídia, proteção contra DoS/DDoS e o controle de acesso para aplicar tudo isso.

Além da função de encaminhamento do SIP proxy, o SBC se estende a território que o modelo de proxy não alcança: as bordas de rede complexas, multi-fabricante e voltadas para operadoras onde normalização, segurança e controle total de sessão são obrigatórios.