asterisk mfc/r2 (unicall VS placas nacionais)

O asterisk é meia boca, e todo mundo sabe. Tem zilhões de bugs, erros no código, problemas de design (é, não se assuste, mas ele foi mal projetado), etc etc etc. Porém, com alguns truques na configuração é possível deixá-lo estável pra ambientes específicos – especialmente quando se trata de links E1.

As placas importadas – pelo menos Digium e Sangoma (melhor opção) – não oferecem suporte nativo ao protocolo de sinalização mais comum aqui do Brasil, que é o MFC/R2. Nesse caso, pra usar essas placas é necessário compilar o unicall, que oferece esse suporte por meio de software.

No voip-info há uma página inteira só com informações sobre como instalar e usar links com sinalização MFC/R2 com placas digium. É relativamente simples, porém o unicall é relativamente instável e tem vários dead locks aleatórios, que muitas vezes não são possíveis reproduzir pra testar e achar uma solução.

A alternativa é usar placas nacionais, como as da Digivoice ou da Khomp. Além disso, essas empresas fabricam outros produtos muitos interessantes como placas PCI com interface celular – que você coloca os chips GSM e usa a linha direto pelo asterisk – e também as interfaces FXS/FXO. A Digivoice tem um produto muito interessante, que é o Channel Bank 3000, pra multiplexar diversas linhas ou aparelhos de telefone analógicos / fax em um link E1 MFC/R2.

Depois de testar tudo isso, quebrar a cabeça e passar várias madrugadas recompilando coisas, cheguei à seguinte conclusão: a mais simples, mais estável e melhor das placas pra usar E1 com asterisk é a Khomp.

Apesar dos problemas no programa de configuração da placa com unicode no Debian e Ubuntu – parece que resolveram na última versão – essa placa é boa e o software também. Quando me refiro ao software, falo do módulo do kernel, programa de configuração bem completo com todas as opções possíveis e imagináveis do link MFC/R2, canal do asterisk, e esquema de debug.

Nesse conjunto, do meu ponto de vista, a Khomp supera todos os outros.

Quando comparada aos produtos importados:

  1. Não precisa usar unicall;
  2. Suporte local por telefone e email;
  3. Pra ter o unicall funcionando, precisa ter até libtiff (xlib, ugh) na máquina!

A Digivoice não é ruim, porém o software é um problema. A filosofia deles é melhor que da Khomp, pois ao adquirir uma placa eles dão o source code do módulo e do canal do asterisk, enquanto a Khomp dá um self-extractor sujo feito em bash com tudo binário – mas se você pedir com jeito no suporte, eles dão os fontes pelo menos do módulo do kernel.

O que encontrei com os módulos da Digivoice:

  1. Problemas do módulo com SMP;
  2. Eles sugerem desligar o ACPI – não funcionou pra mim / ubuntu gutsy default kernel
  3. Depois de desligar o ACPI (com SMP), colocar só o módulo da placa no CPU1 e todo o resto no CPU0 – com echo 2 > /proc/irq/NN/smp_affinity. Não muda muita coisa;
  4. Ao remover o módulo, rola um dump no kernel e só volta a funcionar depois de reiniciar a máquina;
  5. Qualquer reboot ou halt gera outro dump no kernel e só desliga no botão;
  6. Em load médio (60 canais simultâneos), todos os canais do asterisk travam e só voltam depois de reiniciar o serviço.

Enfim, são problemas que aparentemente estão relacionados ao código do módulo, que do meu ponto de vista é mau feito. Fora isso, em algumas máquinas – tipo ProLiant HP e alguns IBM – a placa some após algum reboot, e só volta a aparecer (inclusive no lspci, dmidecode) após trocá-la de slot PCI.

Isso também já aconteceu com a Khomp, e com outras placas nacionais de captura de imagem/tv. Não sei exatamente o que é, mas só vi isso na vida com placas nacionais, nunca com as importadas.

O fato é que pra quem não quer saber de compilar kernel, e nem usar fedora – tudo Debian e Ubuntu, a Khomp é muita moleza. Dois comandos e o asterisk tá no ar com ela.

Mas não pense que a placa irá resolver os problemas do asterisk, porque tem muito mais coisa envolvida nisso.

Tem mesmo que ser muito malandro pra ter um asterisk estável. Usar uma placa pra E1 que elimina parte dos problemas já é um bom começo.

Anúncios

o que é freeswitch?

O FreeSWITCH é um soft-switch modular, escrito em C e licenciado sob a Mozilla Public License. Ele surge como uma alternativa viável para a maioria das necessidades em aplicações de voz, desde roteamento de sinalização SIP e mídia RTP ou SRTP, até URAs e fácil integração com aplicações externas.

Apesar das versões preliminares serem utilizadas em alguns ambientes de produção, com vazão de 300 chamadas por segundo, poderemos utilizá-lo com mais segunraça a partir do dia 26 de maio, quando será lançada sua versão 1.0.

Já existem alguns bindings da API do FreeSWITCH para algumas linguagens, como: Python, Java, Perl, Lua, Javascript; além de alguns frameworks que se conectam ao Event Socket e exportam funções para o disparo e controle de chamadas. Em ambos os casos, a abstração esperada é alcançada.

A arquitetura do FreeSWITCH foi cuidadosamente montada para evitar deadlocks, race conditions e todos os outros problemas enfrentados por usuários e programadores do Asterisk. Outra diferença para o Asterisk, é que o núcleo (core) do FreeSWITCH é consistente e não depende de módulos externos. O núcleo não deveria, nunca, depender de módulos externos, porém o do Asterisk depende.

Tudo isso se traduz em aprender com os erros e escrever software que trabalhe conosco, não contra nós. O core é orientado por uma máquina de estados, que controla o estado de cada nova sessão (ou chamada) criada. A cada transição de estado, um evento é gerado. Qualquer módulo pode registrar event handlers que são chamados quando determinados eventos são gerados. Inclusive, é possível que existam diversos event handlers pra um determinado evento. A propagação do mesmo se dará até que um dos event handlers chamados retorne SWITCH_STATUS_FALSE.

Toda essa coerência torna desnecessário os hacks para alcançar os objetivos de um soft-switch moderno, além de tornar o FreeSWITCH uma plataforma de desenvolvimento – mas não pára por aí.

Por padrão, o software lê suas configurações a partir de arquivos XML, mas qualquer módulo poderia ser o responsável por requisitar e interpretar as configurações. Uma estratégia interessante, é utilizar o mod_xml_curl, que já faz parte do FreeSWITCH, para solicitar todas as configurações via HTTP, ao invés de ler arquivos XML do disco.

Assim, poderia existir um servidor de configuração, que rodaria um webserver, um banco de dados e alguma linguagem de scripting ou um CGI. Poderiam existir 10 servidores com FreeSWITCH rodando, que executariam GETs no servidor de configuração, que entregaria a opção desejada.

Arquitetura simples, com configuração centralizada e desempenho escalonável: se uma expansão for necessária, é só adicionar mais um servidor com FreeSWITCH, igual aos outros já existentes. As configurações que podem ser puxadas remotamente não se limitam à adição e exclusão de usuários, mas a toda e qualquer opção configurável do software. Isso inclui o dialplan, que é flexível o suficiente para tomar decisões não apenas baseado em extension matching, mas também em endereços de rede, variáveis do canal, dados do usuário, etc., o que torna o esquema todo muito flexível.

  • Protocolos VoIP suportados: SIP, IAX e Jinggle
  • TDM: Linhas analógicas (FXS e FXO) e ISDN PRI
  • Codecs: G.711, G.722 (passthru), G.723.1 (passthru), G.726, G.729 (passthru), AMR (passthru), iLBC, Speex, lpc10 e DVI4.
Suporte para MFC/R2, amplamente utilizado no Brasil, está sendo escrito. Desta forma, poderemos utilizar os benefícios de uma plataforma VoIP livre e confiável.
Links, todos com conteúdo em inglês: