Guax

A alguns dias atrás me debati com um problema na compilação do asterisk nas versões 13.1+ do Slackware Linux. Esse problema era causado por um negligência dos desenvolvedores ao linkar os módulos que fazem uso da libcap que causava o seguinte erro ao carrega-los:

[Nov 14 14:05:16] WARNING[3840]: loader.c:433 load_dynamic_module: Error loading module 'res_agi.so': /usr/lib/asterisk/modules/res_agi.so: undefined symbol: cap_set_proc

Apesar da compilação ser feita com sucesso por conta do link ser feito no binário “asterisk” os módulos não são carregados com sucesso. Com o slackware manteve a biblioteca estática no sistema em /usr/lib/libcap.a e este diretório é procurado antes que o /lib pelo GCC na hora de linkar o problema acaba por ocorrer. O certo seria que na compilação dos módulos que fazem uso da libcap estes fossem linkado com o parâmetro -lcap.

A correção mais rápida, fácil e inelegante desse problema é mover a libcap.a para um diretório temporário fora do caminho do linker, compilar o asterisk e devolver ao seu diretório. Para conferir se o seu binário do asterisk foi linkado corretamente com a biblioteca dinâmica da libcap basta usar o comando ldd /usr/sbin/asterisk, o retorno deverá ser semelhante a:

        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb76f2000)
        libcap.so.2 => /lib/libcap.so.2 (0xb76ed000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb76d4000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb76d0000)
        libm.so.6 => /lib/libm.so.6 (0xb76a9000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7692000)
        libc.so.6 => /lib/libc.so.6 (0xb752f000)
        /lib/ld-linux.so.2 (0xb7724000)
        libattr.so.1 => /lib/libattr.so.1 (0xb752a000)

Caso não tenha dado certo o resultado será semelhante a:

        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7797000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb777e000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb777a000)
        libm.so.6 => /lib/libm.so.6 (0xb7754000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb773c000)
        libc.so.6 => /lib/libc.so.6 (0xb75d9000)
        /lib/ld-linux.so.2 (0xb77b0000)

Uma anedota de como o Asterisk se transformou de nossa melhor solução para nosso maior problema num período de menos de 2 anos.

No começo tudo eram flores, as centrais eram instaladas na mão e configuradas com carinho e atenção digno de um artista brincando com uma tela. Esse foi o primeiro grande problema quando estávamos tentando crescer a base instalada e aumentar a estabilidade ao longo de todos os sistemas, o erro aqui não era do Asterisk, mas nosso em acreditar que ele era um pbx. Não é, o asterisk não é mais do que uma plataforma para a construção de soluções de telefonia. Ele é a base dos PBX e não este em si.

Após criarmos uma visão de produto e implementar tudo aquilo que nos faltava, conseguimos maior estabilidade e sincronismo entre as centrais. Nos batemos então com um problema básico e que já foi fonte de reclamações nesse blog a alguns meses atrás. CDR e Transferências. A arquitetura interna do asterisk não possui uma thread para cada canal de ligação, isso faz com que uma “magia negra”, como descrito pelos desenvolvedores, seja necessária para que as transferências sejam possíveis: o maskerading. O fato do plano de discagem do asterisk ser baseado em contexto e não em eventos faz com que as aplicações só possam ser executadas no canal que é dono do fluxo atual da ligação. Isso impede por exemplo que uma gravação seja feita em sua totalidade caso haja uma transferência feita pelo originador da chamada e também impede que o log das ligações seja registrados corretamente no banco de dados.

Nesse ponto, nossa especialidade estava em trabalhar com o Asterisk vanilla usando suas APIs públicas para implementar nossas soluções. Com isso se tornou comum as famigeradas “gambiarras” no código e na configuração do Asterisk para que esses problemas fossem contornados. A solução de software que nos permitiu criar toda uma familia de produtos se tornou agora nosso calcanhar de Aquiles pois as limitações delas agora estão se sobressaindo sobre as nossas próprias.

Esse é o ponto onde estou no momento em que escrevi o texto. Agora começa a batalha para correção desses problemas no próprio Asterisk ou na substituição do mesmo por softwares com outra abordagem como o FreeSWITCH.

URA’s (IVR em inglês) são muito comuns em ambientes com Asterisk. E são normalmente construídas usando a aplicação WaitExten e vários contextos para controle do fluxo. A aplicação WaitExten recebe uma entrada vinda do usuário via DTMF e direciona para a extensão correspondente a essa entrada. Essa não é a melhor abordagem por não permitir uma forma fácil de validar a entrada do usuário e de manter consistência no desvio do fluxo da aplicação. Contextos são legais mas se usados sem moderação você acaba com um nível de complexidade tão grande dentro do seu Dialplan que torna a tarefa de debugar e manter o código algo homérico. Lembre-se que uma URA geralmente é um bloco de código que dificilmente será separado ou usado em partes, se sua URA for complexa o suficiente para isso você precisa de uma reavaliação mental antes de arquitetar o sistema telefônico que seus clientes e usuários terão que passar antes de serem atendidos. Afinal pessoas usam o telefone para falar com pessoas, mas esse é papo para outro post.

Veja um bom exemplo de como usar o Read para ler um digito do usuário:

exten => _XX.,1,Wait(2)
exten => _XX.,n,Read(OPCAO,bem_vindo_menu,1,,,4)
exten => _XX.,n,GotoIf($["${OPCAO}"!=""]?executa)
exten => _XX.,n,Set(OPCAO=0)
exten => _XX.,n(executa),Goto(${OPCAO},1)

A idéia aqui é poder mexer com a entrada do usuário a vontade, sem ter que ser redirecionado para algum lugar logo após alterar o EXTEN ou sem ter que ficar copiando o EXTEN após o waitexten.

Dica do guax para o Asterisk segunda edição. Como colocar aquivos de som no formato WAV que o Asterisk consegue entender e tocar.

O Asterisk só consegue tocar arquivos no Playback, Read e outras aplicações do tipo que tenham as seguintes caracteristicas:

Channels       : 1
Sample Rate    : 8000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

Ou seja, 8khz mono 16-bit Signed Integer PCM. Para converter um audio de outro formato para esse vamos usar a aplicação sox. O comando é basicamente:

$ sox arquivo_origem.wav -r 8000 -c 1 -e signed-integer -b 16 arquivo_destino_convertido.wav

O que cada parâmetro desses faz é:

• -r 8000 Muda a freqüência para 8khz
• -c 1 Converte para mono (1 canal)
• -e signed-integer Muda o encoding para PCM signed
• -b 16 Em conjunto com o de cima faz com que o PCM seja 16 bits.

Pronto, agora esse arquivo já pode ser colocado no seu /var/lib/asterisk/sounds/ e ser tocado normalmente.

Dica do dia para o Asterisk. A aplicação GotoIf tem uma sintaxe que pode ser considerada pegadinha de newbie. Veja:

exten => _X.,1,GotoIf($["${VARIAVEL}"=""]?labeltrue:labelfalse)
exten => _X.,n(labeltrue),Noop(Acao a ser executada caso true)
exten => _X.,n(labelfalse),Noop(Acao a ser executada caso false)

Observe que é muito parecido com um operador ternário da maioria das linguagens de programação. Dicas:

1. Não coloque nenhum espaço separando as condicionais, ? e : do contrário ele não lerá “labeltrue” mas “(ESPAÇO)labeltrue(ESPAÇO)”
2. Em nenhuma hipotese coloque a variavel sem as ” (aspas duplas) caso a variável seja nula ou não definida você ganha um erro do interpretador e não será levado ao labelfalse
3. Perceba que $[] delimita que ali está ocorrendo uma comparação ou qualquer operação que retornará 1 ou 0, true ou false.
4. No lugar das labels “labeltrue” e “labelfalse” você pode colocar o índice da prioridade sem problema nenhum, nesse caso 2 e 3 respectivamente. Eu prefiro usar label já que ela move junto com minhas edições. E é bem mais legível.

Dica adicional: “Sempre escreva seu código como se o cara que vai dar manutenção é um maníaco homicida que sabe onde você mora” – Dicas do Visual Studio

O Call Detail Record no Asterisk PBX é feito por um modulo homônimo que aceita diversos backends para persistencia dos dados em SGDB’s, csv, odbc, etc. Sua força está na sua simplicidade quanto ao uso, já vem por padrão no Asterisk e funciona muito bem para a maioria dos casos. Mas nem tudo são flores, dentre seus problemas mais graves estão: inconsistencia na gravação do status da ligação em transferencias cegas, ligações que deveriam ser ANSWER estão NOANSWER. Nenhuma confiabilidade nos dados de transferencia assistida. O campo ‘uniqueid‘ NÃO É UNICO.

Asterisk sobre Você

Ainda há o fato da tabela do banco de dados ter uma estrutura travada e não mapeavel, o que faz com que a customização da mesma seja um processo doloroso e até mesmo inviável.

O que fazer? Fazer um só pra você horas. Todo bom nerd que se prese acha sabe que pode fazer melhor. Então vamos ver como poderemos criar nosso próprio cdr com ajudinha de alguns AGI’s.

Um script AGI que você executa após cada tentativa de Dial() e que grava automaticamente informações como DIALSTATUS, BILLSEC, DUURATION se mostra mais eficiente já que pode-se adaptar a gravação do log conforme a sua estrutura de controle de ligações.

Até ai tudo bem, podemos fazer o controle de ligações simples com as informações que eu bem entender, mas ainda nos resta as ligações que passam por filas de atendimento e ligações que são transferidas.

Filas: Aqui temos um problema, a forma nativa de executar um AGI dentro da app_queue não é satisfatória já que ela executa o script somente quando a ligação é atendida pelo membro da fila. Assim perdemos o status das primeiras ligações caso elas tenham sido recusadas e as informações são as mesmas que colcoar o agi para executar depois da execução do Queue() no dialplan.

Podemos nesse caso, implementar uma Queue via AGI ou Monitorar o Queue log em busca dessas informações.

A solução mais elegante ao meu ver é modificar a aplicação do Queue para que ao invés de implementar o dial diretamente seja possível direcionar para um contexto, assim é possível monitorar todo o comportamento da ligação e da fila em geral. (entra na TODO list)

Transferencias: As transferencias é um problema simples de resolver, ao setar a variavel global TRANSFER_CONTEXT para um contexto qualquer você consegue executar seu AGI lá dentro e resolver esse problema, com um pouco de esforço ainda se pode gerar uma estrutura complexa e bonita com árvore de chamada para não perder os dados da ligação geral e ainda ter o status da ligação primária.

Sempre há a possibilidade de se esperar pela próxima versão, não testei a versão 1.6 do asterisk ainda. Mas até onde fui informado ela teria solucionado esses bugs. Mas ainda sobra a rigidez estrutural.

update: encontrei uma boa discussão sobre o assunto e sobre esses problemas em uma lista de discussão da Digium: http://lists.digium.com/pipermail/asterisk-dev/2008-November/035305.html

update2: nessa discussão tem uma documentação que resume algumas coisas e explana outras, vale a leitura: http://svn.digium.com/svn/asterisk/team/murf/RFCs/