[AsteriskBrasil] ENC: RES: Problemas com Nat

[Leandro Leal]

Olá Rodrigo!

Dê uma olhada na explicação a baixo desse cara...

Depois por favor não esqueça de reportar para nós como encontrou a solução.

Eu poderia te ajudar a testar isso?

Abraços,

Leandro Leal

-----Mensagem original-----
De: asteriskbrasil-bounces em listas.asteriskbrasil.org
[mailto:asteriskbrasil-bounces em listas.asteriskbrasil.org] Em nome de Lucio
Gonzalez
Enviada em: segunda-feira, 27 de março de 2006 22:21
Para: asteriskbrasil em listas.asteriskbrasil.org
Assunto: Re: [AsteriskBrasil] RES: Problemas com Nat

valeu fernando...
----- Original Message ----- 
From: <fernando.gomes em ciavox.com>
To: <asteriskbrasil em listas.asteriskbrasil.org>
Sent: Monday, March 27, 2006 10:08 PM
Subject: Re: [AsteriskBrasil] RES: Problemas com Nat


Se entendi bem, seu servidor tem IP publico e os clientes estão atrás de 
NAT.

Há realmente algumas dificuldades neste cenário. Basicamente, o problema
ocorre porque o Asterisk media a ligação com sinalização de controle, mas
pode "sair fora do circuito" para as transmissões de voz.

A solução consiste em você impedir que, após a sinalização de controle
inicial, o Asterisk "saia fora" e deixe os "clientes sozinhos falando entre
eles".

Coloque no sip.conf

[general]
;blah blah blah
canreinvite=no

Eu sugiro que você procure no http://www.voip-info.org/ por esse tópico. Tem
muito conteudo lá. É uma valiosa fonte de consulta.


Quanto a STUN:
O STUN funciona cooperativamente com o stack SIP instalado em seu telefone 
IP ou
softphone, visando resolver o problema criado com os n tipos diferentes de
implementação NAT, inclusive as que não estão em conformidade com os
padrões estabelecidos pelo http://www.ietf.org/.

O STUN funciona, a bem grosso modo, assim:
1. Seu cliente SIP vai falar primeiro com o STUN antes de falar com o 
servidor
Asterisk;
2. Seu cliente sip manda um pacote identificando-se a si mesmo para o STUN
server;
3. Este pacote contém o IP que o cliente acredita ter. Note que pode ser um 
IP
de LAN (entenda: atrás de NAT) e não um IP publico.
4. Como há um NAT no meio, o NAT vai substituir o IP de LAN pelo IP publico 
no
header TCP/IP. Entretanto, dentro do pacote, segue a area de dados, onde o
cliente SIP colocou o IP que ele acredita ter. Com isso, o IP no header vai
ficar diferente do IP na area de dados do frame TCP/IP.
5. O STUN server compara o IP no header com o IP informado na área de dados.
Como a comparação deu diferente, o STUN server sabe que o cliente SIP está
atrás de um NAT. Bom... agora falta descobrir qual tipo de NAT.
6. O STUN server encaminha então o frame TCP/IP recebido do cliente SIP para
outro STUN server (o STUN server secundário).
7. O STUN server secundário responde ao cliente SIP.
8. Dependendo o tipo de NAT, o pacote de resposta será bloqueado, porque 
veio
de um endereço publico desconhecido para a tabela associativa do NAT.
9. Se o cliente SIP não receber o pacote, o STUN secundário conclui então 
que
o NAT trata-se de um determinado tipo ou conjunto de tipos.
10. Se o cliente SIP receber o pacote, ele responderá ao STUN secundário, 
que
concluirá que o NAT é de outro determinado tipo, ou conjunto de tipos.

O negócio é mais complicado. É só para ilustrar. Se quiser o PDF completo,
procure no google por "SNOM STUN" e [acho!] vc vai encontrar logo.

Se vc configurar seu cliente SIP para que ele acesse um STUN server, no 
final
dessa confusão toda que expliquei acima, o cliente vai saber qual o tipo de
NAT que tem no meio, se é que há um NAT. Com isso, o cliente SIP consegue
decidir se é melhor continuar falando através da intermediação do Asterisk
ou se é melhor tentar conversar diretamente com o outro cliente SIP.

Se vc tem um STUN server, isso ajuda bastante as coisas. Mas as vezes tem 
outros
problemas também. Dependendo do roteador utilizado por seus clientes (por
exemplo: o famigerado D-Link 500G)... então danou-se! As vezes o roteador 
tem
algum bug que interrompe a comunicação UDP e pode até mesmo "congelar" o
roteador. No caso do D-Link 500G, não tem muito o que fazer... não tem 
update
de firmware para aquela coisa. A unica coisa que dá para fazer é colocar o
roteador em modo bridge e colocar um telefone IP com portas WAN e LAN atras
dele. O telefone IP vai funcionar como roteador neste caso. Dependendo do
telefone IP, tem PPPoE e tudo o mais.

Obrigado

Fernando Gomes
http://www.ciavox.com/wiki

_______________________________________________
LIsta de discussões AsteriskBrasil.org
AsteriskBrasil em listas.asteriskbrasil.org
http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil

_______________________________________________
Acesse o  wiki AsteriskBrasil.org:
http://www.asteriskbrasil.org

_______________________________________________
LIsta de discussões AsteriskBrasil.org
AsteriskBrasil em listas.asteriskbrasil.org
http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil

_______________________________________________
Acesse o  wiki AsteriskBrasil.org:
http://www.asteriskbrasil.org