newchannel: SIP/192.168.10.252-00000008
newchannel: SIP/1001-00000009
link: SIP/192.168.10.252-00000008 - SIP/1001-00000009
unlink: SIP/192.168.10.252-00000008 - SIP/1001-00000009
link: SIP/192.168.10.252-00000008 - SIP/1001-00000009
unlink: SIP/192.168.10.252-00000008 - SIP/1001-00000009
link: SIP/192.168.10.252-00000008 - SIP/1001-00000009
unlink: SIP/192.168.10.252-00000008 - SIP/1001-00000009
link: SIP/192.168.10.252-00000008 - SIP/1001-00000009
unlink: SIP/192.168.10.252-00000008 - SIP/1001-00000009
newchannel: Local/1002@transferencias-aaa8,1
newchannel: Local/1002@transferencias-aaa8,2
newchannel: SIP/1002-0000000a
link: Local/1002@transferencias-aaa8,2 - SIP/1002-0000000a
link: SIP/1001-00000009 - Local/1002@transferencias-aaa8,1
unlink: SIP/1001-00000009 - Local/1002@transferencias-aaa8,1
link: SIP/1001-00000009 - Local/1002@transferencias-aaa8,1
unlink: Local/1002@transferencias-aaa8,2 - Local/1002@transferencias-aaa8,1
hangup: Local/1002@transferencias-aaa8,1
hangup: Local/1002@transferencias-aaa8,2
unlink: SIP/1001-00000009 - SIP/1002-0000000a
newchannel: Transfered/SIP/192.168.10.252-00000008
link: SIP/192.168.10.252-00000008 - SIP/1002-0000000a
hangup: SIP/1001-00000009
hangup: Transfered/SIP/192.168.10.252-00000008
unlink: SIP/192.168.10.252-00000008 - SIP/1002-0000000a
hangup: SIP/1002-0000000a
hangup: SIP/192.168.10.252-00000008

Uma ligação com transferência.

A é uma ligação vinda da PSTN e é direcionada para B que é um ramal interno. B transfere a ligação para C, outro ramal interno. A fala com B durante 2 minutos, o tempo de atendimento foi de 10 segundos sendo no total 2:10 minutos de ligação. A fala com C por outros 2 minutos e espera 10 segundos também para ser atendido (transferência cega). Temos um total de 4:20 de ligação e 4:00 de conversação.

Até ai tudo bem, só que esses 4 minutos não são o tempo pelo qual A foi bilhetado. Ele foi cobrado por 4:10 de ligação já que somente os primeiros 10 segundos de chamada o canal dele estava em estado não atendido. Essa conta fica mais maluca de ser extraída do CDR do Asterisk se considerar que num sistema de produção de médio porte temos transferências feitas pelo originador, transferências para PSTN e cadeias intermináveis de transbordo em filas e grupos de ramais.

Múltiplas tarifações na mesma ligação são possíveis em conferências por exemplo onde geralmente liga-se para o cliente e transfere para a sala de conferência. Nesse caso todos os canais devem ser tarifados e não somente uma vez o tempo da ligação.

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.

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.

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

I searched for a diagram that could represent the call flow in a more intuitive way. I didn’t found something that was easy and clear enough for me. So i sketched some small diagrams and developed the following diagram structure that i will use on my documentation about telephony. I am still accepting better suggestions about representing calls in a more clear way.

update: why? Sometimes we need to draw things to our boss and clients to understand, people usually don’t have the same data abstraction skills that you have on seeing a lot of CDR’s rows and messages as audio streams flowing through dialplan logic. I had a good experience to explain what happened to calls using this. So i’m sharing. =)

Basic Call Representation

The first call we can represent is the most basic and common case on telephony. A calls B and that’s everything that happens.

A simple call that connects A to B

As you see those two elements represent communication end-points that we can say are physical channels that comes and goes out from the PBX. Could represent a persons phone or a PSTN or a trunk with another PBX.

The number on the connection line determinate the order the calls were placed on the system. So we can use a dashed line to represent calls that were not answered by our called party (B). By now we have the basic call redirection scenario where the first destination does not answer so the call is made with C instead of B.

B don't answer and the call overflowed to C

Another way a call can walk between end-points is when one of these points transfer its party. When this happens we need to keep track of who made the transfer. That is represented by the curved arrow that shows who transfer to who and in what moment.

B transfer A to C.

Note that transfer can make a communication channel as well between B and C during the transfer operation, the attended transfer. In this cases you can represent it textually, since most of people don’t care about that conversation.

Not all the times calls fallow an specific order. We have situations where many end-points are talking in the same time in the same call, in a conference for example. Conferences are the most common way to unite two calls that starts independently and when it appear in complex scenarios we will need a more complete way to represent the time sequence of call placing, but i will let this for later work. For now we can just represent the connections on a special element and say that all the connections happened at the same time.

A conference between A, B, C and N more end-points.

Applications and Contextualization

PBX’s are known for give some intelligence in call routing. This is the ability to use applications that apply one specific logic on the calls. These can be queues, call groups or even the Interactive Voice Response systems (IVR’s). The main difference between them is that some may answer the call and make data transmission to the connection party. When the application answer the call is easy to represent it as and special end-point, as we did with conferences. When just routing is involved we need to contextualize a group of calls in the scenario so we can determine the actions taken by the app. We can see those two cases in the next diagram.

Call Contexts

Approach Issues

One concern i have with this representation is that it could be a little confuse in a first moment about how the call flowed. I didn’t made the diagram in a standard way by considering that i am not taking a peer point of view, but the macro view of the call flow. In a simpler approach it would be ignored for example in a conference what was the path taken by the other participants, since the most common way to someone to get into a conference is to be transfered to the number that represents it.

I understand some misconceptions can happen since i am trying to represent something that is dynamic in a static view which is the call states along a time period. A snapshot of the PBX in any moment will only show a simple call.

PS. English corrections will be appreciated.

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/

• Remoção da geração dos arquivos de configuração de exemplo do asterisk. (make samples) – uma modificação na configuração do slackbuild traz esses arquivos de volta.
• Compilação usando make -j2
• Plataforma i686 como padrão
• Inclusão automática da app_pickup2

Para download siga o caminho dourado até pub/slackware/packages/ ou pub/slackware/sources/asterisk.

Uma solução que eu implementei com sucesso até agora é a implementação manual de um sistema de capturas usando um script AGI e a app Pickup presente por padrão no Asterisk.

A aplicação Pickup efetua capturas de ligações recebendo como parâmetro uma extensão em um contexto. Esse tipo de captura não me ajuda em nada na maioria das vezes mas a app Pickup tem uma boa carta na manga: o contexto PICKUPMARK.

Quando o contexto passado como parâmetro para a aplicação é PICKUPMARK a aplicação vai procurar ligações que contenham a variável de canal definida como o conteúdo do exten.  Ex: Pickup(desenvolvimento@PICKUPMARK) irá procurar ligações que contenham a variável PICKUPMARK definida como ‘desenvolvimento’.

Para marcar e  capturar é necessário encontrar o real realizador da chamada e resolver seu grupo, para isso eu uso um script AGI que faz a identificação do grupo de captura baseado no callerid do originador da chamada.

;Configuração para extensão de captura
exten => _*8,1,AGI(resolv_pickup_group.php,${CALLERID(num)})
exten => _*8,n,Pickup(${PICKUPGROUP}@PICKUPMARK)
exten => _*8,n,Hangup

O funcionamento desse AGI é muito simples, o que ele faz é uma consulta no banco de dados onde estão configurados meus ramais e retornar o grupo de captura referente ao ramal passado como parâmetro.

Usa-se o mesmo script para definir o grupo da ligação quando uma ligação é efetuada para o ramal, não esqueça de executar isso antes de cada dial para o ramal que se deseja ter essa feature ativa.

;Configuração para extensão de captura
exten => _X.,1,AGI(resolv_pickup_group.php,${CALLERID(num)})
exten => _X.,n,Set(__PICKUPMARK=${PICKUPGROUP})
exten => _X.,n,Dial(${EXTEN},60,twk)
exten => _X.,n,Hangup

Perceba o pulo do gato: ao atribuir a variável eu estou usando dois _ (underlines) antes do nome da variável para determinar herença infinita na variável. Assim não é necessário defini-la como variável global e sem isso a captura não funciona quando se tem ligações concorrentes.