Softphones e o SBC: registro, travessia de NAT e mídia segura para voz remota

Um softphone transforma um laptop ou smartphone em um ramal corporativo, e para funcionários sentados na LAN corporativa ele funciona sem exigir muita atenção. O problema começa quando o usuário se move. De um escritório em casa, um hotel ou uma rede móvel, o mesmo softphone precisa registrar-se e transportar áudio através de firewalls, Network Address Translation (NAT) e a internet pública, e de repente os registros caem e as chamadas ficam com áudio unidirecional.

Neste artigo, vamos explicar o que é um softphone, como ele se registra, por que redes remotas quebram o SIP e como um Session Border Controller (SBC) na borda de acesso mantém o registro, a travessia de NAT e a segurança de mídia funcionando para voz remota.

O que é um softphone?

Um softphone é um SIP user agent (UA) em software: um programa que realiza as mesmas funções de registro, sinalização de chamada e mídia que um telefone de mesa, implementado inteiramente em software em um dispositivo de uso geral. O Session Initiation Protocol define o user agent como o endpoint que origina e encerra requisições SIP, e um softphone é simplesmente esse endpoint rodando como um aplicativo em vez de hardware dedicado (RFC 3261).

Softphones existem em três formas comuns: aplicativos desktop em computadores, discadores móveis em iOS e Android, e clientes baseados em navegador ou WebRTC embutidos em um aplicativo de comunicações unificadas. Independentemente do host, o trabalho é o mesmo. O softphone se registra em um registrar para que a rede saiba onde encontrar o usuário, envia e recebe mensagens INVITE para estabelecer chamadas, negocia codecs no Session Description Protocol e então envia e recebe mídia Real-time Transport Protocol (RTP).

Softphone vs. telefone SIP

Um telefone SIP, ou hardphone, é o aparelho de mesa que você conecta à rede. Um softphone faz o trabalho SIP idêntico, mas reside em um dispositivo que o usuário já possui. O comportamento do protocolo é o mesmo, então um registrar trata o registro de um softphone da mesma forma que trata um de um hardphone. A diferença que importa para esta discussão é a localização: um telefone de mesa geralmente fica em uma rede gerenciada atrás de um firewall conhecido, enquanto um softphone acompanha o usuário para qualquer rede em que ele esteja.

Por que os softphones mudaram o problema de implantação

Quando os endpoints ficavam na LAN, o caminho de registro e mídia permanecia dentro de um perímetro confiável. Os softphones moveram o endpoint para fora desse perímetro por padrão. Agora um registro chega de uma conexão de banda larga residencial atrás de NAT doméstico, a mídia precisa atravessar a internet pública e a rede não tem controle sobre o firewall no meio. O lado do cliente é fácil. O caminho é a parte difícil.

Como um softphone se registra

O registro é como a rede descobre para onde enviar chamadas de um determinado usuário. O softphone envia uma requisição SIP REGISTER que associa seu address of record (a identidade SIP do usuário) a um endereço de contato (onde ele pode ser encontrado no momento). O registrar desafia a requisição solicitando credenciais, tipicamente com uma resposta 401 ou 407, o softphone reenvia com uma resposta de autenticação digest, e o registrar retorna 200 OK junto com um valor Expires (RFC 3261).

Esse valor Expires define o tempo de vida da associação. O softphone precisa enviar um novo REGISTER antes que o temporizador expire, ou a rede o considera inalcançável e as chamadas de entrada param de chegar. O re-registro é portanto um heartbeat constante, não um evento único, e o intervalo de renovação tem consequências diretas para endpoints remotos porque interage com os timeouts de binding do NAT, que veremos a seguir.

Para voz remota, o ponto arquitetural é onde o SBC se posiciona. O softphone não se registra diretamente no PBX através da internet. Ele se registra no SBC na borda da rede, que é o ponto de contato público, e o SBC encaminha esse registro para o registrar real. O SBC realiza o encaminhamento de registro SIP (SIP registration forwarding), retransmitindo e fazendo proxy dos registros para o registrar upstream em vez de atuar como registrar. O registrar continua sendo seu IP-PBX ou plataforma de voz hospedada, como FreePBX, Asterisk, NetSapiens ou 3CX. O SBC é o gatekeeper posicionado na frente dele.

O que o SBC reescreve no caminho

Conforme o registro e depois a sinalização de chamada passam pelo SBC, ele reescreve os endereços contidos nos cabeçalhos SIP e no corpo SDP para que o registrar upstream veja um endereço de contato alcançável e a mídia de retorno chegue ao lugar certo. Essa reescrita é a base da travessia de NAT, que é o próximo problema a resolver.

Por que o NAT quebra softphones remotos e telefones SIP de mesa

O SIP carrega endereços IP dentro de suas mensagens. Um softphone atrás de NAT consulta seu próprio endereço e escreve um endereço privado, algo como 192.168.x.x, no cabeçalho Via, no cabeçalho Contact e na descrição de mídia SDP. O lado remoto lê esse endereço privado e tenta enviar respostas de sinalização e RTP de volta para ele, e os pacotes não chegam a lugar nenhum porque um endereço privado não é roteável na internet. Os sintomas são conhecidos: registros que não se mantêm, chamadas que conectam mas reproduzem áudio em apenas uma direção, ou nenhum áudio.

Detecção de NAT remoto (far-end NAT detection)

O SBC resolve isso confiando no que ele observa em vez do que o endpoint declara. Ele compara o endereço escrito dentro da mensagem SIP com o endereço real de onde o pacote chegou e, quando eles diferem, usa o endereço e a porta públicos reais para o tráfego de retorno. Isso é a detecção de NAT remoto (far-end NAT detection), e é o que faz um softphone remoto registrar e receber chamadas sem que o usuário precise mexer no roteador doméstico.

RTP simétrico

O mesmo princípio se aplica à mídia. Com RTP simétrico (symmetric RTP), o SBC envia áudio de volta para o mesmo par de endereço IP e porta de onde realmente recebeu áudio, em vez de confiar no endereço anunciado no SDP (RFC 3550). Como o dispositivo NAT abriu essa porta quando o softphone enviou seu primeiro pacote de mídia para fora, responder na mesma porta faz o áudio chegar pelo pinhole aberto. Essa única técnica resolve a maioria das reclamações de áudio unidirecional de trabalhadores remotos.

Keep-alives e o binding de NAT

Os pinholes de NAT não ficam abertos para sempre. O roteador fecha um mapeamento ocioso após um timeout, e uma vez fechado, chamadas de entrada não conseguem mais alcançar o endpoint. Dois mecanismos mantêm o pinhole ativo: a renovação de registro, vinculada ao valor Expires mencionado anteriormente, e keep-alives periódicos de SIP ou RTP que enviam um pacote pequeno com frequência suficiente para resetar o temporizador do NAT. Ajustar o intervalo de renovação abaixo do timeout do NAT é o que mantém um softphone remoto continuamente alcançável.

SIP ALG, o anti-fix

Muitos roteadores domésticos vem com um SIP Application Layer Gateway (ALG) ativado, que tenta reescrever o SIP por conta própria e geralmente o corrompe, trabalhando contra o tratamento correto do SBC. A recomendação padrão é desativá-lo, e na verdade ele já vem desativado em muitos modelos para escritório doméstico ou corporativo. Explicamos por que o ALG em um firewall causa mais problemas do que resolve em nosso guia sobre segurança do SBC.

Protegendo a voz remota

O tráfego de softphone remoto cruza redes que você não controla, então deve ser criptografado do endpoint à borda. A sinalização roda sobre SIP com Transport Layer Security (TLS) na porta padrão 5061, e a mídia roda sobre o Secure Real-time Transport Protocol (SRTP), que adiciona criptografia e autenticação aos fluxos RTP comuns (RFC 3711). O softphone negocia ambos com o SBC na borda de acesso.

O SBC atua como a fronteira de criptografia para o trecho remoto. Ele termina TLS e SRTP do softphone, e então apresenta o que o registrar upstream ou o tronco SIP espera, incluindo relay de SRTP e conversão entre mídia criptografada e não criptografada quando os dois lados diferem. Para como um SBC é configurado para terminar TLS e apresentar SRTP em cada trecho, veja nosso guia de configuração de TLS e SRTP.

Softphones em escala

Os modelos híbridos e de trabalho remoto transformaram o softphone de uma conveniência ocasional no endpoint primário para forças de trabalho inteiras. Um único provedor ou empresa pode agora ter milhares de registros de softphone, cada um uma associação persistente de uma rede diferente e não confiável. O caso de uso de segurança de acesso SaaS do ProSBC é construído exatamente para esse padrão: SIP sobre TLS e SRTP para usuários remotos e em home office acessando aplicações de voz hospedadas, com capacidade de classe carrier de até 350.000 registros de endpoints e 60.000 sessões por servidor.

A borda de acesso precisa fazer várias coisas ao mesmo tempo nesse volume: manter um grande número de registros persistentes, aplicar proteção contra varredura de registros para bloquear ataques de flood de registro que visam qualquer serviço de voz voltado para a internet, executar detecção de NAT remoto por endpoint e manter TLS e SRTP em cada trecho remoto. Para provedores de serviços gerenciados (MSPs) entregando voz para muitos sites de clientes, essa carga se multiplica entre tenants.

Tempestades de registro

Quando muitos endpoints se registram ao mesmo momento, após uma falha de rede ou um evento de failover, a borda precisa absorver o pico sem perder bindings. Dimensionar a capacidade de registro e o comportamento de renovação para o pico, não para a média, é o que mantém o serviço contínuo. Para como a redundância e o failover são tratados por baixo, veja nosso guia de alta disponibilidade.

Perguntas frequentes

Conclusão

Um softphone em si é simples: um SIP user agent em software, fazendo o mesmo trabalho que um telefone de mesa. A dificuldade nunca é o SIP User-Agent, é o caminho no momento em que o endpoint sai do escritório. O registro precisa sobreviver ao NAT e renovar a tempo, a mídia precisa encontrar o caminho de volta pelo pinhole, e tudo que cruza a internet pública precisa ser criptografado.

Um SBC na borda de acesso é o que resolve os três problemas: ele encaminha registros para o registrar upstream, lida com detecção de NAT remoto e RTP simétrico, e termina TLS e SRTP para cada trecho remoto.