Ano novo, cheio de novas ideias e desafios.

Pois bem, voltando as atividades normais do blog, resolvi postar aqui uma situação com a qual me deparei no dia de hoje.

asterisk

Nos últimos dias tenho trabalhado para começar a usar o Asterisk 13.6 de forma mais eficiente, utilizando as novas ferramentas e recursos que o software oferece.

Uma das primeiras coisas que resolvi fazer foi migrar de SIP para PJSIP. Durante esta migração já me deparei com pelo menos 2 bugs existentes, que já foram devidamente reportados (https://t.co/64XwqXQuuKhttps://t.co/9bQgy7ommm) e que afetam o uso do Asterisk num ambiente de produção.

Enquanto foi possível implementar um workaround no primeiro bug, o segundo segue aguardando a solução, mas nem por isso eu deixaria de seguir em frente na migração.

Aproveitando a ocasião, passei também a utilizar o alembic para manter o banco de dados. Além disso alterei minhas conexões do banco de dados (postgresql) para odbc, assunto sobre o qual vou tratar neste post.

Mas qual é o problema afinal?

Bom, são dois problemas na realidade. O primeiro deles é que na nova estrutura de tabelas, a coluna calldate não existe mais, mas o cdr_odbc (bem como, conforme relatos, o cdr_mysql, e, possivelmente, o cdr_pgsql) segue dependendo desta coluna para adicionar o registro na tabela.

Ok, pesquisando descobri que isso já estava identificado, então, seguindo as sugestões dos desenvolvedores, passei a utilizar o cdr_adaptive_odbc.

Era isso então?

Infelizmente está abordagem acabou por gerar um novo problema: uma das colunas da tabela CDR (em seu novo “formato”) tem o nome de end, que também é um palavra restrita do postgresql e não pode ser utilizada como nome de coluna.

Depois de pesquisar também sobre o assunto, me deparei com um outro bug, que também encontra-se resolvido, onde somos apresentados a uma solução que na minha opinião está muito aquém do que realmente deveria ser feito (i.e, a alteração do nome da coluna): o uso de aliases.

Ok, então basta adicionar o alias e está tudo certo?

Infelizmente não. Além de adicionar o alias, é preciso renomear a coluna end da tabela, caso contrário ela segue sendo citada no INSERT, causando o erro anterior.

E como fica então a solução?

No arquivo /etc/asterisk/cdr_adaptive_odbc.conf:

[adaptive_connection]
connection=asterisk
table=cdr
alias end => enddate

No psql:

\c asterisk;
ALTER TABLE cdr DROP column "end";
ALTER TABLE cdr ADD column enddate timestamp without time zone;

Enquanto não é disponibilizada uma solução definitiva, esse workaround pelo menos permite que o CDR siga armazenando os dados necessários.

Asterisk 13, Postgresql e cdr_adaptative_odbc
Tags:             
Customized Social Media Icons from Acurax Digital Marketing Agency
%d blogueiros gostam disto:
Visit Us On FacebookVisit Us On TwitterCheck Our FeedVisit Us On Linkedin