Guax

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.

I was trying to define what information was relevant in a implementation of a Call Detail Record (CDR). Then i realized i need to represent all the possible scenarios a call can perform inside a PBX, so i can determine the relevant data i should store to make reports and even what pieces of the call must be recorded.

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.