Pessoal, boa tarde.<br><br><br>Estou iniciando meu contato com o Asterisk e decidi pelo Elastix para iniciar. Estou utilizando o Elastix 2.2.0 nesses testes iniciais. Tenho uma placa TDM800P instalada no servidor e fiz o reconhecimento de hardware. Aparentemente, tudo ok. As 8 portas foram localizadas e uma delas apresenta-se como disponível para uso (a única porta em que tenho uma linha telefonica conectada).<br>
<br>Estou nos testes iniciais mas já apanhei mais do que lutadores de MMA que encararam o Anderson Silva. Então resolvi bater no tatame e pedir ajuda.<br><br>Pois bem, a princípio eu desejo apenas fazer testes simples entre a linha (direto da PSTN da Oi em Brasilia-DF) e uma extensão SIP que eu configurei no meu notebook.<br>
<br><br>TESTE 1 - chamada entrantes) Ao testar o encaminhamento da chamada para a extensão criada (ramal SIP/2003) o cliente SIP (X-Lite recebe a ligação), porém:<br><br>Problema 1.1: Ao selecionar o botão para desligar/declinar o atendimento o X-Lite "finaliza" a chamada, mas o Asterisk não. Segundos depois a mesma chamada é novamente encaminhada ao clinete SIP.<br>
<br>Problema 1.2: Ao atender a ligação não escuto a pessoa que está realizando a chamada e nem ela me escuta. Depois, analisando a gravação da chamada, vejo que o Asterisk conseguiu gravar a pessoa que discou, mas não grava nada do que eu falei durante a ligação. Fiz teste ligando entre dois ramais SIP e consegui comunicação somente quando coloquei um microfone plugado ao PC (ok, o Asterisk/PSTN não me ouvir deve ser encrenca do X-Lite com o microfone nativo do notebook), mas nos testes sempre consegui ouvir a pessoa do outro ramal (nesse caso então acredito haver algum problema com a chamada recebida da PSTN via canal FXO).<br>
Seria problema com CODECS? Sendo, seriam necessárias que configurações de CODEC nas extensões SIP e nos canais FXO? Pesquisei muito e não achei a resposta.<br> Não sendo: socorro! O que pode ser?<br><br><br>TESTE 2 - chamadas de saída) Ao testar a realização de ligações originadas em uma extensão SIP observo:<br>
<br>Problema 2.1: que as ligações não são completadas<br>Problema 2.2: que o cliente X-Lite não interpreta o fim da chamada e continua com a ligação (muda) ativa.<br><br>Meu arquivo chan_dahdi.conf atualmente está configurado assim:<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(102, 102, 204);" class="gmail_quote"><div style="margin-left: 40px;">[root@elastix /]# cat /etc/asterisk/chan_dahdi.conf<br>
; Auto-generated by /usr/sbin/hardware_detector - E editado por mim para inclusão de dados de canais diretamente nesse arquivo, sem importações.<br>[trunkgroups]<br><br>[channels]<br>context=from-pstn<br>signalling=fxs_ks<br>
rxwink=300 ; Atlas seems to use long (250ms) winks<br>usecallerid=yes<br>hidecallerid=no<br>callwaiting=yes<br>usecallingpres=yes<br>callwaitingcallerid=yes<br>threewaycalling=yes<br>transfer=yes<br>canpark=yes<br>
cancallforward=yes<br>callreturn=yes<br>echocancel=yes<br>echocancelwhenbridged=no<br>faxdetect=incoming<br>echotraining=800<br>rxgain=4.0<br>txgain=4.0<br>callgroup=1<br>pickupgroup=1<br>relaxdtmf=yes<br><br>;Uncomment these lines if you have problems with the disconection of your analog lines<br>
;busydetect=yes<br>;busycount=4<br><br>;immediate=yes<br><br>group=0<br>channel => 1<br>channel => 2<br>channel => 3<br>channel => 4<br>channel => 5<br>channel => 6<br>channel => 7<br>channel => 8<br>
<br>;#include dahdi-channels.conf<br>;#include chan_dahdi_additional.conf<br></div></blockquote><br>Na console do Asterisk observo:<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(0, 0, 153);" class="gmail_quote">
<span style="color: rgb(102, 102, 204);"> -- <SIP/2003-00000006> Playing 'all-circuits-busy-now.gsm' (language 'en')</span><br style="color: rgb(102, 102, 204);"><span style="color: rgb(102, 102, 204);"> -- <SIP/2003-00000006> Playing 'pls-try-call-later.gsm' (language 'en')</span><br>
</blockquote><br>E analisando a gravação da chamada noto que após aproximadamente 9 segs se escutam dois estalos (pode ser uma inversão de polaridade?!) e em seguida ouve-se uma mensagem da operadora OI: "o número que você discou é inválido". Essa mensagem não é tocada no X-Lite (lembrando que ele mantem a chamada ativa e muda).<br>
<br>Retirando o comentário das seguintes linhas do chan_dahd.conf o X-Lite tenta a ligação e informa que a comunicação não pode ser estabelecida. Nesse caso o Asterisk não chega a gravar nenhum arquivo de monitoração de áudio para a chamada.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><div style="margin-left: 40px;"><span style="color: rgb(102, 102, 204);">;busydetect=yes</span><br style="color: rgb(102, 102, 204);">
<span style="color: rgb(102, 102, 204);">
;busycount=4</span><br></div></blockquote><br>Observação importante: testando a linha com um telefone normal observo existir um delay/atraso entre o tempo de tirar o telefone do ganho e de se obter o tom para discagem de 3 segs aproximadamente. Após esse período ouvem-se os mesmos dois estalos observados na gravação do Asterisk e dai sim se tem o tom de discagem.<br>
Quando tento tirar o telefone do gancho e já iniciar a discagem sem receber o tom para isso, BATATA! Mesmo discando um número válido, após 10 segs que o telefone foi tirado do gancho ouvem-se os estalos e em seguida a mensagem "o número que você discou é inválido".<br>
<br>Pesquisei em vários lugares alguma forma de atrasar a discagem através do tronco FXO no Elastix/Asterisk mas não encontrei nada. Essa é a solução mais elegante nesse caso? Ou há como configurar o PABX para aguardar pelo tom de discagem antes de enviar o número desejado?<br>
<br>Sei que escrevi um texto grande, mas o intuito foi dar a maior riqueza de detalhes possível sobre os problemas que estou tendo e sobre as pesquisas e testes que fiz. Agradeço imensamente qualquer colaboração. E espero conseguir retribuir aos colegas em um futuro breve.<br>
<br>Att.,<br>Eduardo Sousa<br>