Dúvidas gerais
Quais as versões de Asterisk são recomendadas pela Khomp?
- 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 estáveis. Entretanto, algumas versões em especial 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.2: nenhuma;
- Série 1.4: nenhuma;
- Série 1.6: nenhuma;
- Série 1.8: versão 1.8.20 ou superior[1];
- Série 10: nenhuma;
- Série 11: últimos builds da série
- Série 12: nenhuma
- Série 13: últimos builds da série
- Série 14: nenhuma
Diversas versões da série 1.4 e algumas da série 1.6 e 1.8 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;
- 1.6.2.6: liberação de portas RTP não funcionando corretamente, o que ocasiona um "vazamento" de descritores e portas UDP não utilizadas, e uma eventual falta de recursos a longo prazo;
- 1.6.2.13 a 1.6.2.14: deadlock entre estruturas internas de canais durante transferência de chamadas, ocasionando em bloqueio geral do sistema.
- 1.8.5 a 1.8.10: deadlocks na fila de atendimento (queue), parcialmente resolvidos na versão 1.8.12.
- 11.19: problemas em extension state e hints.
- 13.3.2 a 13.8: Bug em extension state e hints . Crash utilizando fila.
- ? IMPORTANTE: Há problemas conhecidos e ainda não solucionados na versão 1.8.12, favor verificar pasta patches na distribuição source do channel da Khomp para informações dos problemas e das correções.
Solução de problemas
Não inicializa Asterisk.
- Verifique se k3lserver se encontra em execução, para isso é necessário configurar na interface um EBS ou placa. Para evitar que o Asterisk não inicialize por causa do k3lserver utilize a opção load-error=skip no arquivo khomp.conf
Xinetd + tftpboot
- Nos ambientes como Elastix que utilizam provisionamento é comum que Xinetd ou outro servidor TFTP utilizem a porta 69. Neste caso, o serviço Kibs que também utiliza a mesma porta não consegue se comunicar com o EBS. Para resolver essa situação é necessário inserir o valor //tftpboot no Altenative Path no /etc/khomp/config/kibs.yaml e reiniciar o serviço Kibs.
Quais são as portas utilizadas pelo EBS?
- Portas UDP 37, 69, 14103, 14200, 50000 - 52000;
- Portas TCP 14100, 14101, 14123, 14130, 14161;
- Porta UDP e TCP 14102.
Qual é o uso de banda de rede dos equipamentos EBS?
- A Khomp recomenda o uso dos EBS(External Board Series) conectados diretamente ao servidor em uma placa de rede dedicada e exclusiva para evitar qualquer tipo de interferência e concorrência na rede.
Segue consumo de rede de acordo com cada modelo de EBS:
1 canal = 64kb
1 E1 <= 30: 4 Mbps e 250 pacotes/s (1 pacote a cada 4ms contendo 32 amostras de áudio)
2 E1 <= 60: 8 Mbps e 500 pacotes/s (1 pacote a cada 2ms contendo 16 amostras de áudio)
4 E1 <= 120: 16 Mbps e 1000 pacotes/s (1 pacote a cada 1ms contendo 8 amostras de áudio)
EBS FXO 4 portas - 2 Mbps e 150 pacotes/s (1 pacote a cada 8ms contendo 32 amostras de áudio)
EBS GSM 8 Modens - 4 Mbps e 250 pacotes/s (1 pacote a cada 4ms contendo 32 amostras de áudio)
EBS não sobe.
- Verifique se o cabo de rede está conectado;
- Verifique se o EBS se encontra na mesma faixa IP do servidor;
- Verifique se o kibs está rodando;
- Verifique se o Firewall não esteja bloqueando as portas que o EBS utiliza para a comunicação com o servidor;
- Verifique se a porta "69|37" do sistema está sendo usada por outro serviço diferente do Kibs;
- Em ambientes ELASTIX é comum que haja conflito com a porta 69 e para isso insira o valor //tftpboot no Altenative Path no /etc/khomp/config/kibs.yaml;
- Verifique se não há outro servidor com o mesmo dispositivo configurado;
- Verifique se não existe outro dispositivo utilizando o mesmo IP;
- Verifique se o arquivo fw_ebs.log foi gerado, e se o dispositivo está se comunicando com o servidor.
Problemas de áudio
- Verifique se o Asterisk está em realtime (inicializado com -p);
- Verifique processamento;
- Verifique se a rede não está perdendo pacotes;
- Verifique se não tem falhas no aterramento.
Como configurar o volume nas chamadas em canais KHOMP?
- É possível configurar o volume através de uma das maneiras abaixo:
1 - Aplicação Dial
Dial(Khomp/b0c1+b0c14/input_volume=+2:output_volume=+2)
input_volume: Define o volume de entrada da ligação, podendo variar de -10 a +10;
output_volume: Define o volume de saída da ligação, podendo variar de -10 a +10;
2 - Aplicação "KSetVolume" Esta aplicação tem a função de ajustar o volume de entrada e saída de canais da Khomp, sendo a sua sintaxe a seguinte:
KSetVolume(<volume>)
KSetVolume(<input-volume>|<output-volume>)
Onde os campos possuem o seguinte significado:
volume: Ajusta o volume de entrada e saída (-10 a +10);
input-volume: Ajusta o volume de entrada (-10 a +10, "none" para não alterar).
output-volume: Ajusta o volume de saída (-10 a +10, "none" para não alterar);
3 - Configuração do channel (edite o arquivo /etc/asterisk/khomp.conf)
input-volume: Define o volume de entrada das ligações, varia de -10 a +10 (opção local);
output-volume (antigo "volume"): Define o volume de saída das ligações. Varia de -10 a +10 (opção local);
Bloqueio de chamadas a cobrar
- Para derrubar chamadas a cobrar utilize a opção drop-collect-call = yes no khomp.conf no contexto geral ou indique grupos de canais como segue no exemplo
[channels-b0l0]
drop-collect-call = yes
Também é possível habilitar a variável no dialplan:
[default]
exten => _X.,1,Set(KDropCollectCall=yes)
Timeout dígitos FXS
- Por default o timeout entre os dígitos de FXS é de 7 segundos. Essa configuração se encontra no arquivo khomp.conf
"fxs-digit-timemout = 7"
- Se o dialplan não tiver ambiguidades, este timeout não será necessário. Assim que o número discado for compatível com uma entrada no dialplan (mas somente com uma) enviaremos a chamada para processamento. Caso o dialplan seja genérico ou com ambiguidades, teremos que aguardar o timeout para saber se o número terminou de ser discado ou não.
- Para desconsiderar o timeout no final da marcação e evitar o tempo de espera do próximo dígito sugerimos utilizar a opção immediate-sharp-dial = yes no arquivo khomp.conf. Dessa maneira ao marcar # após o último dígito a ligação prossegue no mesmo instante.
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 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.
A mensagem: "chan_khomp: ERROR: loading K3L API failed: Could not connect to k3lServer. Cause [Socket error: Socket=00000026 - Connection refused (errno=111) (KTools/KD3/Basics/KClientSocket.cpp:84)]" indica que o k3lserver não está em execução.
- Verifique se já foi configurado algum dispositivo no sistema e inicie o serviço k3lserver na interface ou através do comando k3lserver start
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?
- 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:
- Alterar o contexto padrão de segurança do channel da Khomp executando o seguintes comandos:
chcon --reference=/usr/lib/asterisk/modules/app_dial.so
/usr/lib/asterisk/modules/chan_khomp.so
chcon --reference=/usr/lib/asterisk/modules/app_dial.so
/usr/sbin/asterisk
- Desabilitar completamente o SELinux ajustando a linha:
SELINUX=disabled
no arquivo /etc/sysconfig/selinux
ou/etc/selinux/config
Recompilei o asterisk selecionando a flag "DEBUG_THREADS" e depois disso o meu channel não funciona mais direito.
- Ao recompilar o asterisk com flags como "DEBUG_THREADS", "MALLOC_DEBUG" e outras, é necessário baixar os fontes do channel e compilar ele localmente, para gerar um binário compatível com as flags selecionadas.