Dúvidas gerais
- Q: Quais as versões de Asterisk são recomendadas pela Khomp?
- A: A Khomp continuamente realiza testes utilizando versões diversificadas do Asterisk, desde as versões estáveis da série 1.2 até as últimas versões da série 1.6 e 1.8. Entretanto, algumas versões em especiais são recomendadas, visto questões de estabilidade, ou não suportadas, visto problemas conhecidos. Como um guia de referência rápido, as versões que recomendamos:
- Série 1.4: versão 1.4.19.2;
- Série 1.6: versão 1.6.2.17;
- Série 1.8: suportada, mas ainda em homologação interna; recomenda-se utilizar a última versão estável, se não for possível utilizar a série 1.6.
Diversas versões da série 1.4 não são recomendadas visto problemas que afetam seu funcionamento direto, conforme a listagem abaixo:
- 1.4.11: vazamento de memória na contabilização de chamadas (CDR)
- 1.4.20 a 1.4.24: diversos problemas associados aos hooks de áudio, utilizados para gravação e monitoramento de chamadas, apresentando ausência de amostras na gravação;
- 1.4.25: transferência assistida inoperante;
- 1.4.26 a 1.4.28: application Background sobrescrevendo o extension atual de maneira incorreta ao retornar;
- 1.4.29: transferência assistida inoperante, apenas funciona se for transformada em transferência cega (por desligamento do transferidor);
- 1.4.30 a 1.4.34: durante uma transferência assistida, mesmo quando transferidor e transferido desistem da ligação, o softpbx continua chamando o destino (para onde foi feita a transferência), ocasionando falta de áudio ou tom de ocupado caso o telefone seja atendido.
- Q: A minha distribuição Linux não está na lista de distribuições homologadas pela KHOMP. Isso significa que a placa não irá funcionar?
- Q: Como faço para minha distribuição GNU/Linux funcionar com placas da KHOMP?
- Q: Se a KHOMP não homologou a versão/distribuição do GNU/Linux que uso, isso significa que a placa não funcionaria nesta distribuição, independentemente do meu kernel?
- A: A KHOMP enumera distribuições GNU/Linux em que o pacote do channel foi compilado e testado. Entretanto, como existem várias distribuições, com várias versões e variações, torna-se inviável certificar todos os sistemas.
Isto não significa que, se um determinado sistema não está listado como homologado, não irá funcionar - muito pelo contrário. Os drivers e o instalador são desenhados para funcionarem de maneira independente de distribuição, o que facilita sua instalação nos mais diversos sistemas GNU/Linux sem maiores dificuldades.
No entanto, alguns pontos devem ser verificados, como requisitos para o bom funcionamento dos drivers:
- a versão do kernel adotado - todas versões da série 2.6 são suportadas, mas de preferência deve-se utilizar a versão 2.6.22 ou mais atual;
- a versão do compilador gcc - suportado desde o GCC 3.4, recomendado GCC 4.1 ou superior;
- a versão da biblioteca glibc - suportada desde a GLIBC 2.3.6;
- a versão do Asterisk - as séries 1.2.x, 1.4.x e 1.6.1.x são suportadas.
Solução de problemas
- Q: O channel está me mostrando mensagens de erro do comando "CM_DISCONNECT". O que isto significa?
- A: Estas mensagens podem aparecer em versões do channel 2.3 ou anteriores. Caso estas mensagens sejam esporádicas, não há problemas acontecendo: é possível que o channel tenha enviado o comando de desconexão para um canal, mas este já estava desconectado - o que ocasionou um erro no envio. Isto não afeta as outras ligações, nem afeta o canal que recebeu o comando.
- Q: O channel está me mostrando mensagens de erro do comando "CM_ADD_STREAM_BUFFER". O que isto significa?
- A: Estas mensagens costumam aparecer em versões 2.2 ou anteriores do channel, quando o Asterisk e/ou algum cliente SIP está enviando pacotes fora da taxa de transferência correta, ou enviando-os de maneira muito concentrada para a placa da Khomp. Se as mensagens forem esporádicas, ocorrendo a em uma taxa aproximada de uma mensagem por segundo por canal, isto não figura problema. Entretanto, se a mensagem aparecer várias (mais que 50) vezes por segundo, por canal afetado, isto é um problema de áudio, e precisa ser investigado.
- Q: O áudio do Playback/MusicOnHold aparece ruim/cortado/lento, mesmo quando há alguma carga no Asterisk. Entretanto, com poucas ligações, não há problemas.
- A: O Asterisk, por padrão, instala arquivos de áudio apenas no formato GSM e MP3. Isso significa que cada nova ligação que execute um playback - ou um música em espera - vai iniciar um novo processo de conversão de áudio, de MP3/GSM para A-law. No caso de uma aplicação de URA, em especial, esse problema se manifesta ainda mais: por estar em constante playback, o uso de processador aumenta bastante, comprometendo a qualidade da conversão.
Nestes casos, é indicado manter também versões em 'alaw' dos arquivos de som. Isso pode ser feito através do utilitário 'sox', com a seguinte linha de comando (considerando "/var/lib/asterisk/sounds" o diretório atual):
for file in *.gsm */*.gsm; do echo $file; sox $file -twav -A -r8000 \
"$(dirname $file)/$(basename $file .gsm).alaw"; done
- Q: Coloquei o Asterisk entre meu PABX legado e a central pública, e está funcionando bem, mas mesmo fazendo pass-thru das ligações pela placa da Khomp (numa mesma placa, a ligação entra em um link e sai pelo outro), estou com problemas para utilizar aparelhos de FAX. O que pode estar acontecendo?
- A: É necessário verificar se o modo bridge nativo está ativo, nesta situação, que é a única situação onde há garantia de funcionamento do FAX. Caso não esteja, quando o Asterisk estiver em maior carga, o áudio pode apresentar um atraso grande demais para que os canceladores de eco dos aparelhos de FAX consigam funcionar.
O delay da entrega do áudio também deixa de ser garantido, visto que o áudio é convertido de TDM para pacotes, e então, para TDM novamente. Isto pode levar a uma falha de poucos mili-segundos entre pacotes, que é imperceptível ao ouvido humano, mas pode ocasionar problemas em aparelhos de FAX e em modems.
- Q: Quando executo o Asterisk, aparece a seguinte mensagem de erro ao carregar o chan_khomp.so: "cannot restore segment prot after reloc: Permission denied". O que pode estar acontecendo?
- A: Distribuições Linux mais recentes como o Red Hat Enterprise 5.1 e seus derivados (Fedora Core, CentOS) têm habilitado diretivas de segurança do projeto SELinux por padrão. Essas diretivas permitem um controle mais refinado sobre a segurança do sistema. Contudo, o SELinux também altera alguns comportamentos do sistema original, como no carregamento de bibliotecas dinâmicas, que pode ser problemático à programas de terceiros. Para corrigir o problema, você pode:
- Q: O driver da KHOMP e o serviço KServer estão sendo carregados automaticamente no meu sistema, porém o KServer não consegue inicializar. O que pode estar acontecendo?
- A: O Kserver precisa ser inicializado sempre depois da montagem do filesystem como escrita e leitura ter sido finalizada. Verifique como está a inicialização do seu sistema, e de preferência inicialize o KServer apenas após a montagem final do sistema de arquivos.
- Q: Não estou conseguindo inicializar o Asterisk, o channel driver da Khomp está me retornando o seguinte erro:
chan_khomp: ERROR: loading K3L API failed: Não foi possível conectar ao servidor.
Entretanto, o serviço das placas está executando, e o módulo de kernel está carregado.
- A: Devido a uma alteração recente no KServer, o mesmo passou a restringir os IPs de origem para conexão e acesso às placas. Verifique suas regras de roteamento e NAT da máquina - em especial, verifique se o seu sistema não está realizando mascaramento das rotas de IP de qualquer endereço. Isto pode fazer com que, mesmo numa conexão local (pela interface lo), o IP apresentando como de origem seja da sua interface de rede de acesso externo, o que fará com que o KServer rejeite a conexão.
Uma forma de resolver o problema é alterar a seguinte configuração do firewall de:
# iptables -t nat -A POSTROUTING -j MASQUERADE
Para:# iptables -t nat -A POSTROUTING \! --destination 127.0.0.1 -j MASQUERADE