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

7 Comentários on “asterisk mfc/r2 (unicall VS placas nacionais)”

  1. Olá,
    Trabalho na Khomp há 6 anos, e pertenço ao suporte técnico e treinamento há pelo menos 4. Achei bastante interessante teu artigo e seu ponto de vista. Esse feedback é bastante importante para nós aqui dentro da Khomp, para que melhoremos cada vez mais nossos produtos.
    Você e todos que utilizam Khomp sabem que tem um canal aberto aqui na empresa, de fácil acesso. Qualquer dúvida, basta entrar em contato.
    Quanto ao código fonte, já está sendo disponível na sessão de downloads, dentro da área restrita.
    Grande abraço.

  2. alef disse:

    Opa. Quem me atende aí é a Denise.
    Ela resolve tudo!

  3. Rafa disse:

    Uso asterisk ha 3 anos Alex.Inclusive ha 2 anos com placas da Digium + Redhat Enterprise 4 (com o unicall recompilado claro)e uma caixinha com 4 chips GSM ligados numa QUAD FXO da Digium tb.Nunca tive problemas com a instalação.A unica ressalva que faço é : se vc manja dos dialplans,etc,etc fuja desses asterisk in a box da vida.
    Todos complicam muito a vida quando se quer fazer um dialplan simples pra uma empresa.No final acabo usando todos os arquivos *_custom.conf pq de outra forma ia ter que ler mais 2 mil linhas de diaplan dos caras…só pra fazer a ele discar pra fora.Quando ce for fazer integração com outros asterisk via IAX por exemplo é que a merda vai pro ventilador.Aqui vale a maxima KEEP IT SIMPLE DUMBASS!
    abraçao e curti o blog.

  4. Moises Silva disse:

    The truth is that no vendor (AFAIK) supports MFC/R2 in hardware. Digivoice has the R2 protocol login in chan_dgv. Unfortunately I don’t have the source code for Kohmp implementation (sorry, but I think that’s just so lame), but is likely their R2 implementation is also in the channel driver, not on the board (the same apply to PIKA R2 implementation). So makes no sense to blame Digium or Sangoma for not support MFC/R2 in their boards. We can blame them for not having a well supported R2 stack though. However, thanks to Sangoma support, that is changing (or already did). The OpenR2 project is gonna be integrated in Asterisk 1.6.x and many people is already using libopenr2 as their R2 solution. Take a look at it when you have a chance:

    http://www.libopenr2.org/

  5. alef disse:

    Oh yeah. The khomp’s R2 implementation is actually made in the library used by the channel driver, almost like all the other. The fact is that we’re not currently blaming either Digium or Sangoma, it’s just a little different to get the whole thing working while on the other hand khomp provides an easier and faster installation, with a nice configutation tool. Also, since it’s manufactured in Brazil, it’s easier to get support, updates, etc.
    I currently have some customers using Sangoma and just about 2 weeks ago I moved from libmfcr2 to libopenr2. It’s working fine and I would like to thank you for the great job.
    Again, the fact is: it’s not “plug and play (yet)”. When a person like me, consultant, having to deal with tens of customers, compiling all the stuff, fixing specific details on each system, SLA, etc, it’s painful.

  6. Moises Silva disse:

    Thanks for responding.

    If you have any suggestions to improve the user experience I’d be glad to hear them. I have in my TODO list to have some kind of configuration tool to make R2 links configuration easier, at least first for the biggest users of R2 like Brazil and Mexico.

    Stay connected for updates :-)

  7. Leonardo Lang disse:

    Good afternoon,

    I work in the development area of Khomp, in the SoftPBX division – which includes the channel driver development. I found this post looking for some other info, but I think there is some points to make clear about the board and its R2/MFC implementation.

    The Khomp board supports *ALL* R2 protocol in hardware. There is no host processing for signaling, neither for the protocol itself. And this goes even further, since every audio processing is also made in the hardware: echo cancellation, amplitude (volume) control, automatic gain control (AGC), DTMF suppression, DTMF detection, etc.

    The library that comes with the installation is there to abstract the protocols and boards, giving a generic interface for the channel driver and other applications which might work directly with the boards. There are some higher layers of other protocols which are implemented on host (inside the library), but R2/MFC is made completely inside the board.

    About the channel driver source code, all GPL requirements are followed by the company: the source code is readily available for download to all clients which buy the board and receive the binary installation (in the same way as the binary installation works).

    Best regards,
    Leonardo

    -x-

    Boa tarde,

    Trabalho no desenvolvimento da Khomp, especialmente na área de SoftPBX – que inclui o desenvolvimento do channel driver. Encontrei esta notícia procurando algumas outras informações, e acredito que há um ponto importante a esclarecer sobre a placa Khomp e a implementação R2/MFC.

    No caso da Khomp, *TODO* o protocolo R2 é tratado em hardware. Não existe nenhum processamento em software relacionado ao áudio da sinalização, nem aos estados da chamada em si – que são tratados diretamente em hardware. Todo processamento de áudio também é pela placa: cancelamento de eco, controle de volume, AGC, supressão e detecção de DTMFS, etc.

    A biblioteca serve apenas para abstrair os diversos protocolos e placas, e entregar uma interface única para o channel driver e outras aplicações. A bibliteca até abriga algumas camadas mais altas de outros protocolos (em software), mas o protocolo R2/MFC é feito completamente na placa.

    Sobre o código fonte do channel, a empresa segue os requisitos da GPL: o código-fonte está disponível para download para todos os clientes que adquirem a placa e recebem os pacotes de instalação (assim como funciona com a instalação binária).

    Abraços,
    Leonardo


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s