Redes
NAT, STUN e ramais SIP remotos

Nesta página
- Três problemas diferentes, normalmente atribuídos a um só: o que você precisa saber?
- Caminho um: punch-through, que o manual recomenda em primeiro lugar: o que você precisa saber?
- Caminho dois: mapeamento de portas, quando a política exige: o que você precisa saber?
- STUN e os dois cabeçalhos que corrigem o áudio em um só sentido: o que você precisa saber?
- Links móveis e redes difíceis: o que você precisa saber?
- Lista de verificação para um ramal remoto
Três problemas diferentes, normalmente atribuídos a um só: o que você precisa saber?
"O telefone remoto não funciona" cobre ao menos três defeitos distintos, e cada um tem uma correção diferente:
- O PBX está atrás de NAT e os terminais remotos não conseguem encontrá-lo.
- O telefone está atrás de NAT e o PBX não consegue enviar a mídia de volta a ele.
- Ambos estão atrás de NAT, o que combina os dois casos e é onde o áudio em um só sentido costuma aparecer.
Descobrir qual dos três casos você tem em mãos exige uma única pergunta: o telefone consegue se registrar? Se o registro falha, o problema é encontrar o PBX. Se o registro funciona mas o áudio corre em um só sentido, o problema é a tradução de endereços no caminho da mídia.
Caminho um: punch-through, que o manual recomenda em primeiro lugar: o que você precisa saber?
O PBX inclui um serviço de travessia de NAT descrito como o método preferencial. Quando ele é ativado, o equipamento gera um domínio de punch-through próprio, montado a partir de um código de acesso de segurança e dos seis últimos caracteres do endereço MAC do equipamento, na porta 5090. O telefone remoto passa então a se registrar nesse nome de domínio, em vez de em um endereço IP público.
Duas consequências decorrem disso. Primeira: a instalação não precisa publicar nem manter um IP público para o PBX, e nenhum encaminhamento de portas é necessário. Segunda: o domínio está atrelado ao equipamento, então substituir o hardware muda o endereço — uma mudança a planejar, e não uma surpresa a descobrir.
Caminho dois: mapeamento de portas, quando a política exige: o que você precisa saber?
Mapeamento de portas significa que o roteador à frente do PBX encaminha o tráfego para ele. Três detalhes decidem se isso funciona:
- O PBX precisa ter um endereço IP fixo na interface WAN, e não uma concessão DHCP, ou a regra de encaminhamento vai acabar apontando para o vazio.
- É preciso encaminhar a porta de sinalização SIP e também o intervalo RTP. O intervalo RTP padrão é 10010 a 10266, e cada chamada usa duas portas — uma para RTP e uma para RTCP —, de modo que quatro chamadas simultâneas precisam de oito portas abertas.
- Mapear as portas externas para os mesmos números no lado interno evita uma classe de problemas mais adiante. Quando o endereço público é dinâmico, o PBX tem suporte a DDNS integrado e o manual lista os serviços de provedor que ele consegue atualizar.
Se a instalação não puder publicar nem um endereço fixo nem um domínio de punch-through, mantenha os telefones remotos em uma VPN. O OM20G e o OM50G trazem um cliente OpenVPN integrado, e o manual é explícito quanto ao uso previsto: conectar troncos SIP a um servidor em uma rede privada, com o arquivo de certificado carregado como client.ovpn. Ele não é uma VPN de acesso remoto de uso geral para aparelhos.
STUN e os dois cabeçalhos que corrigem o áudio em um só sentido: o que você precisa saber?
O STUN vem ativado por padrão na plataforma, usa a porta 3478 e se renova em um intervalo padrão de 60 segundos, dentro de uma faixa de 30 a 65535 segundos. Ele oferece dois comportamentos: registrar novamente com o servidor SIP, ou registrar novamente e atualizar o endereço NAT. O segundo é o indicado quando o endereço público da instalação muda.
Quando o áudio corre em um só sentido, a correção normalmente não é o STUN, e sim duas configurações de tipo de endereço no tronco SIP ou no ramal:
- Tipo de endereço do cabeçalho Contact do SIP — definido como LAN ou WAN.
- Tipo de endereço da conexão SDP (c=) — definido como LAN ou WAN.
Essas duas configurações decidem qual endereço o PBX escreve em sua sinalização e em sua descrição de mídia. Inverta-as e a chamada é estabelecida perfeitamente, mas não transporta áudio em um dos sentidos. Os ramais remotos também devem ter a detecção automática de servidor ativada, o que mantém as chamadas recebidas chegando corretamente quando o telefone está em movimento.
Links móveis e redes difíceis: o que você precisa saber?
Quando o PBX fica atrás de um roteador celular, a plataforma acrescenta um conjunto de quatro opções para operação com NAT em 4G, que vão do tratamento completo a um modo que não atualiza nem os endereços SIP nem os SDP. Instalações apoiadas em um link celular devem testar os dois sentidos da fala antes de entrar em operação, e observar que apenas o OM20G aceita um modem USB 3G ou 4G para discagem de saída — o OM50G explicitamente não suporta nenhum.
No lado da LAN, o acesso remoto não é a única questão de segurança. O PBX suporta autenticação de porta 802.1X, um bloqueio de login que, por padrão, entra em vigor após seis tentativas falhas por dia, com bloqueio de dez minutos, uma lista de permissões de acesso de até 20 endereços e opções de criptografia da sinalização SIP e da carga útil de voz. Nada disso substitui um projeto de rede criterioso, mas fecha as portas óbvias.
Lista de verificação para um ramal remoto
- Registro: endereço do servidor, porta (5060 por padrão), nome de usuário e senha de autenticação. Além disso, o registro do próprio telefone precisa estar ativado e o estado deve ser conferido na página de ramais IP do PBX.
- Áudio de entrada: detecção automática de servidor ativada, tipos de endereço do Contact e do SDP ajustados ao caminho.
- Áudio de saída: STUN ativado com o comportamento de atualizar o endereço NAT, e o intervalo RTP aberto de ponta a ponta.
- Todo o resto: a mesma ordem de codecs e o mesmo modo DTMF do restante do sistema, para que chamadas internas e remotas se comportem de maneira semelhante.
Teste de fora da edificação, nos dois sentidos, com o telefone no tipo de rede que ele realmente vai usar. Um aparelho testado no Wi-Fi do escritório não prova nada sobre o mesmo aparelho em uma conexão residencial.


