Quando o SIP inicializa a chamada, a mensagem INVITE contem a informação para onde enviar as streams de media. O Asterisk se utiliza a si como as pontas das streams de media quando do estabelecimento da chamada. Uma vez que a chamada tenha sido aceita, o Asterisk envia outra mensagem (re) INVITE aos seus clientes com a informação necessária para ter os dois clientes enviando as streams de media diretamente entre si.
• Se algum dos clientes estiver configurado com o canreinvite=NO, o Asterisk não vai lançar de jeito algum um re-invite;
• Se os clientes usam codecs diferentes, o Asterisk não vai emitir um re-invite;
• Se o comando Dial() contem "t", "T", "h", "H", "w", "W" ou "L" ou (esses aparecerem em uma combinação de múltiplos argumentos) o Asterisk não vai inserir um re-invite.
• Conectando os caminhos da media diretamente a uma ponta que está atrás de NAT não seria de bom grado. Especialmente se ambos os dispositivos estão atrás de NAT. Você pode querer tentar usar o módulo nathelper do SER em conjunto, já que o nathelper.so pode reescrever o SDP, de sorte que os endereços IP privados não serão incluÃdos no re-invite.
O Asterisk está conectado em um lado via eth1 ao "mundo externo" (endereço IP
81.223.xxx.xxx) e no outro lado via eth0 na LAN interna
(eth0 tem endereço IP 192.168.1.200, o telefone SNOM tem 192.168.1.201, ...).
Primeiramente, você necessita entender como o SIP por si mesmo foi projetado para estabelecer chamadas entre dispositivos.
A mensagem 'INVITE' do SIP diz "Eu quero estabelecer uma chamada". No corpo dessa mensagem tem um bloco do SDP (Session Description Protocol) que diz "minha ponta de áudio está no endereço IP x.x.x.x porta x, e Eu posso usar os codecs A, B e C".
• Esse INVITE chega ao segundo telefone, o Y, que diz ao Asterisk "OK, Eu estou no endereço IP y.y.y.y:y, Eu escolho o codec C", e o envia de volta ao Asterisk;
• O Asterisk fica contente, assim ele estabelece a primeira perna substituindo o primeiro telefone, o X, e retorna uma mensagem 200 "OK, Eu estou no endereço IP z.z.z.z:z2, Eu escolho o codec C" para o primeiro telefone, o telefone X.
Portanto agora o primeiro telefone, o telefone X, está enviando pacotes entre x.x.x.x:x e z.z.z.z:z2, e o segundo telefone, o telefone Y, está enviando pacotes entre y.y.y.y:y e z.z.z.z:z1.
Assim nas condições normais, as mensagens SIP enviadas pelo Asterisk ao segundo telefone vão conter o endereço IP do primeiro telefone, e vice-versa. Isso quer dizer que ele verifica as mensagens SIP e se comporta como um proxy SIP.
Ainda neste ponto, vejamos o que diz os comentários vindos no arquivo sip.conf do braço estável 1.4 a cerca de como o Asterisk vai manipular a stream de media entre duas pontas remotas quando do estabelecimento de uma chamada entre dois dispositivos SIP:
[*] Para ser preciso, se você tem um NAT firewall entre sua rede interna e a Internet, então alguns pacotes serão capazes de atravessar diretamente entre a sua rede e o mundo externo, com o firewall modificando o endereço IP de origem e/ou a porta no processo. Existe um conjunto completo de truques indecentes que podem ser feitos, tanto no telefone quanto no provedor, o que significa que se você for realmente sortudo você pode fazer que a conexão VoIP funcione dessa forma. No entanto, eu recomendo a você evitar fazer isso. Você está em uma situação cômoda porque seu servidor Asterisk já tem um endereço IP público real, portanto faça uso dele.
Mesmo que o caminho normal de áudio para uma chamada possa ser estabelecido fazendo-se uma ponte nativa (native bridging) entre os dispositivos, o Asterisk às vezes necessita ser capaz de se re-inserir no caminho da media em meio a uma chamada – para fornecer serviços tais como Espera, Transferência, Estacionamento e assim por diante quando são requisitados.
Entretanto, nem todos os telefones suportam esse mecanismo. Se você define o canreinvite=no em um canal SIP, isso está dizendo "esse telefone não suporta o mecanismo do re-INVITE para re-conexão do áudio no meio de uma chamada". Conseqüentemente, o Asterisk decide que ele precisa se inserir na stream de media durante toda a chamada, de sorte que ele já permanece no caminho se depois alguma das partes requisitar alguma daquelas funcionalidades em meio à chamada.
as_implicacoes_do_parametro_canreinvite_para_um_pabx_ip_asterisk.txt (80 views) · Modificado em: 15/01/2008 20:52 por cleviton
Apoio
Blog
Warning: fsockopen() [function.fsockopen]: php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/portal/modules/mod_slick_rss/simplepie.inc on line 2238
Warning: fsockopen() [function.fsockopen]: unable to connect to www.voipmania.com.br:80 (Unknown error) in /var/www/portal/modules/mod_slick_rss/simplepie.inc on line 2238