Ok, eu olhei e olhei, e não consigo encontrar ninguém que esteja escrito sobre esse problema. Eu tenho uma configuração de escritório simples, onde há duas extensões de telefone SIP (Polycom 331) atrás de um Sonicwall TZ180. Estou usando o Plivo como o PBX. As extensões se registram diretamente no Plivo.
Plivo --> [Internet] --> TimeWarner Modem --> Sonicwall TZ180 --> POE Switch --> Polycom 331s x2
Eu configurei o firewall & Regras de NAT no TZ180 de tal forma que tudo funciona ... por um tempo. Depois da sonicwall & os telefones são reinicializados, os telefones podem receber e fazer chamadas sem problemas. Depois de algum tempo (sem ter certeza de quanto, mas mais do que algumas horas, pode demorar alguns dias), os telefones param de aceitar as chamadas recebidas, mas as chamadas feitas são boas.
Então, para mim isso parece um problema NAT, exceto pela parte em que tudo funciona bem por algum tempo! E eu realmente quero dizer que funciona bem. Ligue para o telefone 1, fale um pouco, ligue para o telefone 2, fale um pouco, ligue novamente para o telefone 1, fale um pouco, ligue para o telefone 2, fale um pouco, repita. Mas, depois de algum tempo desconhecido sem chamadas, o texto acima deixa de funcionar para os dois telefones.
O firewall Sonicwall está definido para transmitir UDP 5060-5061 e UDP/TCP 10000-20000 . Os telefones são fornecidos com IPs privados estáticos pelo Sonicwall. O NAT consistente do Sonicwall é ativado e as transformações do SIP são desativadas (o que parece ser o consenso que encontrei em outro lugar).
Alguma ideia? A única maneira de detectar que os telefones pararam de funcionar para as chamadas recebidas é esperar até que uma mensagem de voz seja entregue, mas alguém estava sentado ao lado do telefone. Além disso, prefiro não ter que reinicializar toda a minha rede apenas para obter outro dia ou dois de cada vez.
Ok, depois de lutar com o wireshark, eu descobri que o Sonicwall TZ180, sendo tão antigo quanto é, simplesmente não gosta de manter múltiplos caminhos NAT abertos. Eu resolvi o problema com um Raspberry Pi executando um asterisco e agindo como um Proxy SIP.
Tags networking nat voip sip