Plataforma Exchange (VoIP Peering) - como funciona?

As populares Plataformas VoIP Peering ou Plataformas Exchange podem voltar em um novo formato.

As plataformas VoIP Peering ou Exchange eram bastante populares há alguns anos e, desde então, tivemos um declínio na popularidade delas. No entanto, com o surgimento de novas tecnologias e condições de mercado, essas plataformas poderão ter seu retorno garantido, de uma, ou de outra forma. Vamos ver o que são e como funcionam.

Com o crescimento da popularidade do VoIP no início dos anos 2000, houve um grande aumento no número de operadoras de VoIP independentes (ITSP) em todo o mundo. Havia (e existem) muitos provedores de rotas diretas e muitos atacadistas ou agregadores, bem como varejistas. Os provedores de rotas diretas tentaram interconectar-se diretamente com os varejistas para vender seus produtos, mas como o número de destinos é muito grande, em muitos casos isso levou a um alto número de conexões e contratos ponto a ponto que se tornaram difíceis de gerenciar. Portanto, muitos varejistas utilizaram poucos provedores de rotas diretas para as rotas mais importantes e atacadistas para o restante tráfego. Esta solução funciona em geral, mas em um ambiente muito competitivo não garante os melhores preços e qualidade. Novos fornecedores de rotas diretas apareciam todos os dias, e eles também estavam procurando acesso a compradores que eram difíceis de obter.

Uma das respostas para esse problema foi Trocas (Exchanges). As trocas (Exchanges) possibilitaram que os vendedores oferecessem suas rotas na plataforma de mercado aberto e os compradores procurassem as melhores ofertas. As trocas também levaram a maior parte do trabalho de teste, verificação e compensação financeira para os compradores. Aqui está um exemplo de como o Exchange procura a perspectiva do comprador/vendedor:

Os compradores, com sua capacidade espacial, entraram em contato com a Exchange e ofereceram suas rotas. O Exchange testaria suas rotas quanto à validade, manualmente ou através de algum processo automático. Após os testes, o contrato entre a Exchange e o Vendedor foi assinado, onde o vendedor estava vendendo suas rotas para a Exchange e a troca garante o pagamento. Em seguida, a rota é publicada na plataforma de negociação, sem mencionar os detalhes do vendedor. Em vez disso, foi atribuído algum tipo de número de identificação.

Os compradores, por sua vez, assinariam o contrato com a Bolsa e obteriam acesso à plataforma de negociação da Bolsa. Eles podem ver o preço anunciado das rotas e as estatísticas existentes, como ASR e ACD, e capacidade. Quando decidem comprar a rota, fazem os lances para comprá-la. dependendo do contrato, eles podem ser solicitados a pagar um depósito antes de obter acesso total. Uma vez que o acesso é concedido, os compradores podem começar a enviar seu tráfego para a bolsa e os vendedores aceitando a troca. O tráfego é roteado e cobrado por Exchange com ambas as partes, ou seja, não há transações diretas entre vendedor e comprador, mas o faturamento é liquidado entre a Exchange e o comprador ou/e a Exchange e o vendedor.

As trocas foram bastante populares no início dos anos 2000, sem dúvida a maior delas foi a Arbinet Thexchange, que foi adquirida pela Primus Telecommunications em 2010. Havia também uma série de outras menores, que forneciam acesso a operadoras menores que não podiam acessar os serviços da Arbinet devido a altas taxas de acesso.

Tecnicamente, as trocas tinham alguns detalhes específicos, alguns dos quais eu gostaria de listar abaixo:

• A maioria era anônima, ou seja, o tráfego passava por equipamentos capazes de ocultar endereços IP das partes, como um SBC (no conceito de Controlador da Borda da Sessão, e não como o conceito de um Firewall para SIP);
• Havia mecanismos automáticos de classificação de qualidade de rota em funcionamento que podiam medir parâmetros de qualidade de rota como ASR e/ou ACD;
• As Exchanges podem oferecer algum meio de "classificar" as rotas para os usuários (como os botões de CURTIR nas redes sociais) - para que outros compradores possam optar por usar apenas rotas com determinadas classificações positivas;
• Mecanismo de licitação: para as rotas com capacidade limitada, o licitante mais alto receberá um roteamento de prioridade mais alta.

Hoje, as bolsas de VoIP (VoIP Peering Exchanges) perderam sua posição no mercado, mas isso não necessariamente significa que elas não podem retornar de uma ou outra forma. Novas tecnologias podem ajudá-los a retornar. Um dos problemas que impediu que as Exchanges (trocas) se tornassem amplamente usadas foi a falta de confiança: e vemos o Blockchain como uma solução possível para resolver o problema de confiança. O uso de Blockchain no VoIP em geral foi discutido anteriormente, especialmente como um banco de dados descentralizado: é isso que as Exchanges (trocas) realmente são.

Por Aivís Olsteins.

Asterisk® SCF™ - Dialplan modular

Este é apenas um sumário de um Dialplan no Asterisk® SCF™ implementado a alguns anos, espero que você ache ele tão útil quanto eu achei.

A necessidade surgiu quando administrava em Londrina/PR uma rede, com quatro servidores Asterisk® SCF™, referente a Matriz e Filiais interconectadas e integrada a um pequeno Call Center (interno para SAC), o problema era manter quatro Dialplan separados, o que acabou sendo um esforço cansativo. Este conceito é um FORK de uma ideia de um profissional (Amit Mehta) de Sydney/Australian via e-mail.

Os objetivos deste Dialplan foi o seguinte:

• Modularize todas as tarefas rotineiras que são executadas no plano de discagem.
• Redução substancialmente da quantidade geral e a repetição de código no Dialplan.
• Reduçao da sobrecarga de gerenciamento do Dialplan.
• Tornar a depuração do Dialplan fácil para entendimento e o mais importante, legível.
• Otimizar o uso de variáveis ​​globais e de canal para reduzir a quantidade e os locais de futuras alterações no Dialplan.
• Atualizar o Dialplan da sintaxe do Asterisk® SCF™ v1.4 para Asterisk® SCF™ v11.
• Ex.: Converter todas as Macros e Sub-Rotinas.
• Incorporar o uso de Sub-Rotinas com a capacidade de passar variáveis ​​através do comando "Gosub".

Muito semelhante à versão padrão da extensions.conf no Asterisk® SCF™ v11, com algumas pequenas personalizações para as variáveis passadas para ele. Tecnicamente, não é isso que estou chamando de "modular" (que na verdade é uma Sub-Rotina); este é apenas um exemplo do contexto stdexten que alguns podem achar útil.

No meu cenário, sob nenhuma circunstância haveria motivo para alterar o contexto do correio de voz; portanto, os argumentos passados são: Os dispositivos para tocar, o período de tempo limite (por quanto tempo tocar o ramal) e a caixa de correio de voz de destino. Se nenhum dos segundo e terceiro argumentos forem passados, ele assumirá um período de tempo limite de 25 milissegundos e a extensão passada no argumento um como caixa de correio de voz.

Aqui está o contexto stdexten:

[stdexten]
; Standard extension subroutine:
; ${EXTEN} - Extension ; ${ext}
; ${ARG1} - Device(s) to ring ; ${dst}
; ${ARG2} - Dial Timeout ; ${tmt} 25 seconds
; ${ARG3} - Specify voicemail box to use ; ${mbx}
; Syntax: Gosub(context,extension,priority(${ARG1},${ARG2},${ARG3}))
; Use: Gosub(stdexten,${EXTEN} or specify extension,stdexten(SIP/4000&SIP/4002,25,4000))
exten => _X.,1001(stdexten),NoOp(Dialing standard extension)
exten => _X.,n,Set(LOCAL(ext)=${EXTEN})
exten => _X.,n,Set(LOCAL(dst)=${ARG1})
exten => _X.,n,Set(LOCAL(tmt)=${IF($[${ISNULL(${ARG2})} = 1]?25:${ARG2})})
exten => _X.,n,Set(LOCAL(mbx)=${IF($[${ISNULL(${ARG3})} = 1]?${ext}:${ARG3})})
exten => _X.,n,Dial(${dst},${tmt})
exten => _X.,n,Goto(stdexten-${DIALSTATUS},1)

exten => stdexten-NOANSWER,1,Voicemail(${mbx},u)
exten => stdexten-NOANSWER,n,Return()

exten => stdexten-BUSY,1,Voicemail(${mbx},b)
exten => stdexten-BUSY,n,Return()

exten => _stde[x]te[n]-.,1,Goto(stdexten-NOANSWER,1)

exten => a,1,VoicemailMain(${mbx})
exten => a,n,Return()

Aqui está um exemplo simples de uma chamada interna para o stdexten que também incorpora o uso de outro módulo do Dialplan, o "sub-GetSourceCID", para procurar primeiro o identificador de chamadas de origem no banco de dados MySQL do Asterisk® SCF™:

exten => _40XX,1,Gosub(sub-GetSourceCID,${EXTEN},1)
exten => _40XX,n,Gosub(stdexten,${EXTEN},stdexten(SIP/${EXTEN}))
exten => _40XX,n,Hangup()

Bom seria isto, em um futuro post, vou mostrar como migrei este contexto para AEL, e posteriormente para LUA.

Agradecimento ao amigo Amit Mehta.

Bash Script - Registre chamadas simultâneas do Asterisk® SCF™ para o MySQL e outras informações úteis

Aqui está um script em bash rápido, a ideia é registrar as chamadas simultâneas de cada um dos meus troncos de longa distância (DDD) do Asterisk® SCF™ em um banco de dados MySQL para poder analisar rapidamente as tendências de uso. Certamente, provavelmente existem outros softwares de código aberto por aí que podem fazer isso e fornecer gráficos muito pequenos ou não (cdr-stats ou asternic me vêm à mente). mas qual é a graça nisso? Como mencionei, o script é extremamente primitivo (apenas o mínimo necessário, pois não tinha muito tempo para gastar nele) e não contém nenhuma verificação de erro, mas também pode ser usado como uma ideia de informações úteis para suar o Grafana.

Mostrar todas as chamadas SIP ativas em um único tronco

rasterisk -x "core show channels verbose" | grep "^SIP/yourSIPTrunkName-"

Mostrar número simultâneo de chamadas SIP em um único tronco

rasterisk -x "core show channels verbose" | grep -c "^SIP/yourSIPTrunkName-"

Mostrar todas as chamadas DAHDI ativas nos canais 1-24

rasterisk -x "core show channels verbose" | grep "^DAHDI/[1-9]-1\|^DAHDI/1[0-9]-1\|^DAHDI/2[0-4]-1"

Mostrar número simultâneo de chamadas DAHDI nos canais 1-24

rasterisk -x "core show channels verbose" | grep -c "^DAHDI/[1-9]-1\|^DAHDI/1[0-9]-1\|^DAHDI/2[0-4]-1"

Para uma exibição útil em tempo real de chamadas simultâneas em um único tronco, incorpore o comando watch

watch -n .5 'rasterisk -x "core show channels verbose" | grep "^SIP/yourSIPTrunkName-"'

Como observação, sinta-se à vontade para usar o script abaixo, se quiser, mas você terá que escrever suas próprias expressões regulares para corresponder aos canais DAHDI usados em seu ambiente específico.

Você também precisará de um banco de dados MySQL em algum lugar para inserir os dados. Neste exemplo, eu nomeei a tabela “trunkusage” e ela possui quatro colunas.

Os tipos de dados são os seguintes:

• ID – int 11 unsigned auto-increment
• time – datetime
• trunk – varchar 50
• activecalls – int 11 unsigned

Para rodar como um daemon, crie o Shell Script em /etc/init.d/trunkusage e certifique-se de executar chmod + x, assim como executar o update-rc.d para permitir os níveis de execução padrão.

#!/bin/bash
#
# Log Concurrent Calls to MySQL
#
DBUSER='yourMysqlUser';
DBPASS='yourMysqlPass';
DBHOST='yourMysqlServer';
DBNAME='yourMysqlDatabaseName';
TBLNAME='trunkusage';
TRUNKNAME=('mySIPProvider1' 'mySIPProvider2' 'dahdiCircuitProvider');
TRUNKTYPE=('SIP' 'SIP' 'DAHDI');
RUNTIME='5';  # how often to run in seconds

while true  # Infinite loop
do
        i=0
        for trunk in "${TRUNKNAME[@]}" ; do
                unset ACTIVECALLS;
                if [ "${TRUNKTYPE[$i]}" == "SIP" ] ; then
                        ACTIVECALLS=$( /usr/sbin/asterisk -x "core show channels verbose" | grep -c "^${TRUNKTYPE[$i]}/${trunk}-" ) > /dev/null 2>&1;
                        mysql -u ${DBUSER} -p${DBPASS} -h ${DBHOST} ${DBNAME} -e "INSERT INTO ${TBLNAME} (time,trunk,activecalls) VALUES (NOW(), '${trunk}', '${ACTIVECALLS}');" > /dev/null 2>&1;
                        ((i++));
                elif [ "${TRUNKTYPE[$i]}" == "DAHDI" ] ; then
                        # Regex pattern for channels 1-24
                        ACTIVECALLS=$( /usr/sbin/asterisk -x "core show channels verbose" | grep -c "^${TRUNKTYPE[$i]}/[1-9]-1\|^${TRUNKTYPE[$i]}/1[0-9]-1\|^${TRUNKTYPE[$i]}/2[0-4]-1" ) > /dev/null 2>&1;
                        mysql -u ${DBUSER} -p${DBPASS} -h ${DBHOST} ${DBNAME} -e "INSERT INTO ${TBLNAME} (time,trunk,activecalls) VALUES (NOW(), '${trunk}', '${ACTIVECALLS}');" > /dev/null 2>&1;
                        ((i++));
                fi
        done
        sleep ${RUNTIME};
done

Erro no AEL Reload (ael.flex:654 ael_yylex: Unhandled char(s):)

Eu estava no meu trabalho belo e suando sangue (como fala meu amigo Francisco Oliveira!) para resolver este erro no AEL. Veja na imagem a seguir o que ocorre quando eu executo AEL RELOAD:

Então me lembrei do meu tempo de PIA! E fui no nosso querido e bom Shell, e executei o comando para ver a estrutura do arquivo em questão, com o comando:

# file -i  

Como eu esperava não estava no padrão Unix, e é importante que todos os arquivos do Asterisk fique no padrão Unix. Então eu simplesmente instalei o BOM e VELHO dos2unix! veja na imagem a seguir:

Então executei o comando do dos2unix em todos os arquivos do Asterisk AEL.

E quando uma vez no Command Line Asterisk (*CLI>) ao executar AEL RELOAD, o erro sumiu! 

Ótimo!!! Espero que ajudem alguém. Até a próxima!

Como Instalar o Ansible AWX sem Docker no CentOS 7/RHEL 7

O AWX Project (AWX) é um projeto comunitário de código aberto. Além disso, é a versão OpenSource do software Ansible Tower patrocinado pela Red Hat, que permite aos usuários controlar melhor o uso do projeto Ansible em ambientes de TI. Neste tutorial, mostraremos a você como instalar e configurar o AWX sem o Docker no CentOS 7 / RHEL 7 usando um RPM Community Edition.

Requisitos do sistema para o servidor do AWX:

• 2 GB de memória;
• 2 núcleos de cpu;
• 20 GB de espaço;

Etapa 01: Configurações do Selinux e do Firewall

01 - Em primeiro lugar, vamos instalar o policycoreutils-python e permitir que o nginx se conecte à rede conforme abaixo:

# yum -y install policycoreutils-python
# setsebool -P httpd_can_network_connect 1

02- Se o firewalld estiver ativo, teremos que habilitar o tráfego http, execute o seguinte comando:

# firewall-cmd --permanent --add-service=http
success
# firewall-cmd --reload
success

Etapa 02: Memcached, Ansible e pacotes necessários para a instalação

01- Execute o seguinte comando para instalar o repositório EPEL Release, Memchached e Ansible:

# yum install -y memcached ansible epel-release

02 - Habilite e inicie o serviço Memcached:

# systemctl enable memcached
# systemctl start  memcached

Etapa 03: Instalação do Servidor PostgreSQL

01- AWX requer o servidor de banco de dados PostgreSQL, siga este tutorial Como instalar o PostgreSQL 10 no CentOS 7/RHEL 7.

02 - Depois de instalar e iniciar o PostgreSQL Server, temos que criar o banco de dados awx chamado awx e conceder acesso ao usuário awx conforme abaixo:

# sudo -u postgres createuser -S awx
# sudo -u postgres createdb -O awx awx

Etapa 04: Instalação do RabbitMQ

01 - Crie o Repositório RabbitMQ como abaixo:

# echo "[rabbitmq-erlang]
name=rabbitmq-erlang
baseurl=https://dl.bintray.com/rabbitmq/rpm/erlang/20/el/7
gpgcheck=1
gpgkey=https://dl.bintray.com/rabbitmq/Keys/rabbitmq-release-signing-key.asc
repo_gpgcheck=0
enabled=1" > /etc/yum.repos.d/rabbitmq-erlang.repo

02 - Instale o RabbitMQ e ative/inicie o serviço RabbitMQ executando os seguintes comandos:

# yum install erlang-R16B-03.18.el7.x86_64

# yum install -y rabbitmq-server.noarch

# systemctl enable rabbitmq-server
# systemctl start rabbitmq-server

Etapa 05: Instalação e Configuração do nginx como proxy do servidor web para o AWX

01 - Instale o nginx executando o seguinte comando

# yum install -y nginx

02 - Configurar o nginx como proxy web para o AWX:

# cp -p /etc/nginx/nginx.conf{,.org}
# wget -O /etc/nginx/nginx.conf https://raw.githubusercontent.com/sunilsankar/awx-build/master/nginx.conf

03 - Ativar e iniciar o nginx:

# systemctl enable nginx
# systemctl start nginx

Etapa 06: AWX instalação e inicialização

01 - Para instalar o AWX, execute os seguintes comandos:

# wget -O /etc/yum.repos.d/awx-rpm.repo https://copr.fedorainfracloud.org/coprs/mrmeee/awx/repo/epel-7/mrmeee-awx-epel-7.repo
# yum install -y awx

02 - Vamos importar os dados do banco de dados do AWX:

# sudo -u awx /opt/awx/bin/awx-manage migrate
Operations to perform:
  Apply all migrations: auth, conf, contenttypes, main, oauth2_provider, sessions, sites, social_django, sso, taggit
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying taggit.0001_initial... OK
  Applying taggit.0002_auto_20150616_2121... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0001_initial... OK
  Applying main.0001_initial... OK

03 – Crie uma conta de usuário de acesso web do AWX chamada admin e uma senha de configuração:

# echo "from django.contrib.auth.models import User; User.objects.create_superuser('admin', 'root@localhost', 'password')" | sudo -u awx /opt/awx/bin/awx-manage shell

04 - Inicialize o AWX executando os seguintes comandos:

# sudo -u awx /opt/awx/bin/awx-manage create_preload_data
Default organization added.
Demo Credential, Inventory, and Job Template added.
(changed: True)

# sudo -u awx /opt/awx/bin/awx-manage provision_instance --hostname=$(hostname)
Successfully registered instance ylclawxas02.yallalabs.local
(changed: True)
2019-04-03 11:07:22,758 DEBUG    awx.main.dispatch publish awx.main.tasks.apply_cluster_membership_policies(eec7263e-bf52-4dad-ad4d-7d4245c47ae4, queue=awx_private_queue)

# sudo -u awx /opt/awx/bin/awx-manage register_queue --queuename=tower --hostnames=$(hostname)
2019-04-03 11:07:35,496 DEBUG    awx.main.dispatch publish awx.main.tasks.apply_cluster_membership_policies(d4a3314d-b3da-42a6-8cbe-a177f97e2e79, queue=awx_private_queue)
Creating instance group tower
2019-04-03 11:07:35,542 DEBUG    awx.main.dispatch publish awx.main.tasks.apply_cluster_membership_policies(f6be7d7d-fcbd-47dd-a1ec-10abe56420c3, queue=awx_private_queue)
Added instance ylclawxas02.yallalabs.local to tower
(changed: True)

04- Iniciar e ativar serviços AWX:

# systemctl start awx-cbreceiver && systemctl enable awx-cbreceiver
# systemctl start awx-dispatcher && systemctl enable awx-dispatcher
# systemctl start awx-channels-worker && systemctl enable awx-channels-worker
# systemctl start awx-daphne && systemctl enable awx-daphne
# systemctl start awx-web && systemctl enable awx-web

Etapa 07: Acessando a interface da web do AWX

- Para concluir, abra seu navegador e acesse a interface da eeb do AWX com o IP ou FQDN do seu servidor, o nome de usuário é admin e a senha é password.

Conclusão
Você instalou com sucesso o AWX Ansible Tower no seu sistema CentOS 7 / RHEL 7. Para mais informações, você pode visitar a página oficial da Documentação do Ansible Tower.

Credito:

LOTFI WADERNI => Yalla-labs.

Como Instalar o PostgreSQL 10 no CentOS 7/RHEL 7.

O PostgreSQL é um poderoso sistema de banco de dados relacional de objetos de código aberto (ORDBMS). Ao contrário de outros sistemas de bancos de dados relacionais, o PostgreSQL permite que os usuários criem operadores exclusivos, tipos de dados complexos, funções agregadas, caractere de conversão de tipo de dados e outros vários objetos de banco de dados por meio da função SQL. Neste artigo, mostraremos como instalar o banco de dados PostgreSQL 10 no CentOS 7 / RHEL 7. A última versão estável do PostgreSQL 10 inclui melhorias como

• Replicação lógica usando publicar/assinar;
• Particionamento de tabela declarativa;
• Paralelismo de consulta aprimorado;
• Melhorias significativas no desempenho geral;
• Autenticação de senha mais forte baseada em SCRAM-SHA-256;
• Melhor monitoramento e controle.

Etapa 1: adicionar o repositório do PostgreSQL 10

# yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7.3-x86_64/pgdg-redhat10-10-2.noarch.rpm -y 

Etapa 2: Instale o PostgreSQL 10

# yum install postgresql10 postgresql10-server postgresql10-contrib postgresql10-libs -y

Etapa 3: Inicie o PostgreSQL

- Inicialize o PostgreSQL:

# /usr/pgsql-10/bin/postgresql-10-setup initdb
Initializing database ... OK 

- Iniciar/Ativar o PostgreSQL:

# systemctl enable postgresql-10.service
# systemctl start postgresql-10.service

Etapa 4: Acessando o Banco de Dados

- Mude para o usuário postgres:

# su – postgres

- Conecte-se ao terminal do PostgreSQL:

# psql

Etapa 5: exemplos de uso

- Listar todos os bancos de dados:

# \list

- Conecte-se a um banco de dados:

# \c database_name

- Listar todas as tabelas

# \d

- Crie um banco de dados

# createdb database_name
# createdb database_name OWNER rolename;

- Crie uma tabela

# create table employees (name varchar(25), surname varchar(25));

- Inserir registros

# INSERT INTO employees VALUES ('Lotfi','waderni');

- Saia do prompt do PostgreSQL:

# \q

Esperamos que este tutorial tenha sido bastante útil. Se você precisar de mais informações, ou tiver alguma dúvida, apenas comente abaixo e teremos o maior prazer em ajudá-lo!

Se você quer apreender mais sobre PostgreSQL o professor Marco Maddo, tem um ótimo curso no Youtube! Segue a playlist do curso.

Si buscas más conocimientos sobre PostgreSQL, sigue el Playlist del canal Tecnología Binaria;

Instalando a Web Semaphore Ansible UI no CentOS 7

Neste guia, vamos instalar a UI do Semaphore Ansible Web no CentOS 7. O Semaphore é uma solução baseada na Web de código aberto que torna o Ansible fácil de usar para equipes de TI de todos os tipos. Ele fornece uma interface da Web de onde você pode iniciar e gerenciar tarefas do Ansible.

Semaphore depende das seguintes ferramentas:

• MySQL >= 5.6.4/MariaDB >= 5.3;
• Ansible;
• Git >= 2.x.

Vamos iniciar a instalação garantindo que essas dependências estejam instaladas em seu servidor CentOS 7. Portanto, siga as etapas nas próximas seções para garantir que tudo esteja definido.

Etapa 1: Instalar o servidor de banco de dados MariaDB:

 Use este post para instalar o MariaDB em seu CentOS.

OBS: Lembre-se de anotar a senha do root configurada no servidor de banco de dados.

Etapa 2: Instalando a versão mais recente do Git (Git 2.x) no CentOS 7:

Confirme a versão do git.

$ git --version
git version 2.16.5

Etapa 3: Instalar o Ansible:

Instale o Ansible em seu servidor CentOS 7.

sudo yum -y install epel-release
sudo yum -y install ansible

Teste a disponibilidade do Ansible e sua versão com este comando:

$ ansible --version
 ansible 2.7.9
   config file = /etc/ansible/ansible.cfg
   configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
   ansible python module location = /usr/lib/python2.7/site-packages/ansible
   executable location = /usr/bin/ansible
   python version = 2.7.5 (default, Oct 30 2018, 23:45:53) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]

Etapa 4: Baixando o Semaphore:

Visite a pagina de Releases do Semaphore ou copie o link para baixar o mesmo no seu Sistema Operacional.

sudo yum -y install wget
wget https://github.com/ansible-semaphore/semaphore/releases/download/v2.5.1/semaphore_2.5.1_linux_amd64.rpm

Agora instale o pacote do Semaphore:

$ sudo rpm -Uvh semaphore_2.5.1_linux_amd64.rpm
 Preparing…                          ################################# [100%]
 Updating / installing…
    1:semaphore-2.5.1-1                ################################# [100%]

Valide se o binário do Semaphore está presente no seu $PATH:

$ which semaphore
/usr/bin/semaphore

$ semaphore  -version
v2.5.1

Etapa 5: Faça o setup do Semaphore:

Execute o seguinte comando para iniciar a configuração (setup) do Semaphore em seu sistema.

# semaphore -setup
 Hello! You will now be guided through a setup to:
 Set up configuration for a MySQL/MariaDB database
 Set up a path for your playbooks (auto-created)
 Run database Migrations
 Set up initial semaphore user & password 
   DB Hostname (default 127.0.0.1:3306): 127.0.0.1:3306
   DB User (default root): root
   DB Password:   
   DB Name (default semaphore): semaphore
   Playbook path (default /tmp/semaphore): /opt/semaphore
   Web root URL (optional, example http://localhost:8010/):  http://localhost:8010/
   Enable email alerts (y/n, default n): n
   Enable telegram alerts (y/n, default n): n
   Enable LDAP authentication (y/n, default n): n 

Confirme se esses valores estão corretos para iniciar a configuração.

Is this correct? (yes/no): yes
 Config output directory (default /root): 
 WARN[0037] An input error occured:unexpected newline    
 Running: mkdir -p /root..
 Configuration written to /root/config.json..
 Pinging db.. 
 Running DB Migrations..
 Checking DB migrations
 Creating migrations table
......
Migrations Finished

Vamos definir o nome de usuário.

Username: computingforgeeks
Email: computingforgeeks@example.com
WARN[0268] sql: no rows in result set                    level=Warn
 Your name: computingforgeeks
 Password: StrongPassword 
 You are all setup computingforgeeks!
 Re-launch this program pointing to the configuration file
 ./semaphore -config /root/config.json

To run as daemon:
 nohup ./semaphore -config /root/config.json &
You can login with computingforgeeks@example.com or computingforgeeks.

Você pode definir outros valores de configuração no arquivo /root/config.json.

Etapa 6: Configurando o SystemD:

Agora vamos configurar a interface do usuário do Semaphore Ansible para ser gerenciada pelo SystemD. Crie o arquivo da unidade de serviço SystemD.

sudo vim /etc/systemd/system/semaphore.service

E adicione isto:

[Unit]
Description=Semaphore Ansible UI
Documentation=https://github.com/ansible-semaphore/semaphore
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/bin/semaphore -config /etc/semaphore/config.json
SyslogIdentifier=semaphore
Restart=always

[Install]
WantedBy=multi-user.target

Crie o diretório de configurações Semaphore:

sudo mkdir /etc/semaphore

Copie seu arquivo de configuração para o diretório criado:

sudo ln -s /root/config.json /etc/semaphore/config.json

Vamos parar a execução das instâncias do Semaphore:

sudo pkill semaphore

Confirme:

ps aux | grep sema

Recarregue o SystemD e inicie o serviço do Semaphore:

sudo systemctl daemon-reload
sudo systemctl start semaphore

Verifique o status para ver se está sendo executado:

$ systemctl status semaphore 
 ● semaphore.service - Semaphore Ansible UI
    Loaded: loaded (/etc/systemd/system/semaphore.service; disabled; vendor preset: enabled)
    Active: active (running) since Thu 2019-04-04 22:49:24 CEST; 31s ago
      Docs: https://github.com/ansible-semaphore/semaphore
  Main PID: 9779 (semaphore)
    CGroup: /system.slice/semaphore.service
            └─9779 /usr/bin/semaphore -config /etc/semaphore/config.json
 Apr 04 22:49:24 mydebian systemd[1]: Started Semaphore Ansible UI.
 Apr 04 22:49:24 mydebian semaphore[9779]: Using config file: /etc/semaphore/config.json
 Apr 04 22:49:24 mydebian semaphore[9779]: Semaphore v2.5.1
 Apr 04 22:49:24 mydebian semaphore[9779]: Port :3000
 Apr 04 22:49:24 mydebian semaphore[9779]: MySQL root@127.0.0.1:3306 semaphore
 Apr 04 22:49:24 mydebian semaphore[9779]: Tmp Path (projects home) /opt/semaphore
 Apr 04 22:49:24 mydebian semaphore[9779]: Checking DB migrations

Configure o serviço para iniciar no boot do Sistema Operacional:

$ sudo systemctl enable semaphore
Created symlink /etc/systemd/system/multi-user.target.wants/semaphore.service → /etc/systemd/system/semaphore.service.

Verifique se a porta 3000 ficou aberta agora:

# ss -tunelp | grep 3000
 tcp    LISTEN     0      128      :::3000  :::*   users:(("semaphore",pid=9779,fd=3)) uid:999 ino:45866 sk:6 v6only:0 <->

Etapa 7: Configurar o Proxy Ngnx (Opcional).

Para poder acessar a interface da Web Semaphore com um nome de domínio, use a guia da URL abaixo para configurar.

URL Como configurar o Proxy Nginx para interface da Web Semaphore Ansible.

Etapa 8: Acessando a interface da Web Semaphore Ansible:

No seu navegador, abra o Web Semaphore Ansible, digitando o IP do seu servidor seguindo da porta 3000. Caso tenha realizado a Etapa 7 digite o domínio configurado. Você deve receber a imagem mostrada a seguir.

Use o nome de usuário ou e-mail criado anteriormente durante a instalação para entrar. O console da Web para o Semaphore deve ser mostrado após a autenticação. Como mostrado na imagem a seguir.

Você está pronto para gerenciar seus servidores com uma interface, o Web Semaphore Ansible UI é poderoso, e muito pratico de usar.

As etapas iniciais necessárias são:

• Adicionar as chaves (Keys) SSH e chaves (Keys) API usadas pelo Ansible - Em Key Store > Create Key.

• Criar um arquivo de inventário com servidores que vamos gerenciar - Em Inventory > Create Inventory.

• Crie os usuários e adicione à(s) equipe(s);
• Crie os ambientes;
• Adicione os repositórios dos Playbooks.

• Crie modelos de tarefas e execute.

Para além disso, verifique um guia detalhado sobre a interface do Web Semaphore Ansible UI, na URL a seguir.

URL: Web Semaphore Ansible UI.

Para instalação em Ubuntu ou Debian, verifique em:

URL: Instalando a Web Semaphore Ansible UI no Debian/Ubuntu.

Fonte: Computing For Geeks.

Arquitetura do Asterisk

Olá, pessoas! Vamos falar sobre a arquitetura geral do Asterisk? Do ponto de vista arquitetônico, o Asterisk consiste em vários módulos diferentes. Esta modularidade oferece flexibilidade quase ilimitada no desenvolvimento de sistemas baseados em Asterisk  Open Source Communications Framework. Como administrador do sistema Asterisk, você pode escolher quais módulos você pode carregar e configurar. Cada módulo carregável fornece recursos diferentes para o sistema. Por exemplo, um módulo pode permitir que seu sistema Asterisk se comunique com linhas telefônicas analógicas (POTS), enquanto outro pode adicionar relatórios de chamadas detalhados de recursos. neste post, discutiremos o estado geral de alguns componentes do Asterisk, vários tipos de módulos e seus recursos.

O Asterisk é um programa grande com um grande número de componentes interconectados. Abaixo está um diagrama simplificado destinado a ilustrar as inter-relações de alguns dos principais componentes entre si e com objetos fora do Asterisk.

É necessário entender e saber como o Asterisk funciona com dispositivos de rede externos e arquivos na rede local.

Arquitetura do Asterisk: o Asterisk tem um kernel que pode interagir com vários módulos. Os módulos, chamados de drivers de canal, fornecem canais que seguem a caixa de diálogo do Asterisk para executar o comportamento programado e facilitar a comunicação entre dispositivos ou programas fora do Asterisk. Os canais geralmente usam um mecanismo de ponte para interagir com outros canais. 

CORE (PBX) do Asterisk: o coração de qualquer versão do Asterisk é o Kernel chamado de CORE, que também pode ser chamado de PBX. O CORE (PBX) principal é um componente importante que fornece toda a infraestrutura. Entre as principais funções, o kernel lê os arquivos de configuração, incluindo no Dialplan (extensions.conf, extensions.ael e extensions.lua), e carrega todos os outros módulos, vários componentes, que fornecem maior funcionalidade. O kernel carrega e constrói o roteamento, que é um dos principais componentes de qualquer versão do Asterisk. O Dialplan contém uma lista de comandos que o Asterisk deve seguir para saber como lidar com chamadas de entrada e saída do Softswitch PBX IP.

Módulos do Asterisk: além da funcionalidade fornecida pelo núcleo do Asterisk, os módulos fornecem todas as outras funções. Muitos módulos são distribuídos com o Asterisk, embora outros módulos possam estar disponíveis para membros da comunidade ou mesmo empresas que criam módulos comerciais. Módulos distribuídos com o Asterisk podem ser criados com a instalação do Asterisk. Os módulos não são construídos apenas arbitrariamente, mas você pode afetar o tempo de carregamento, se eles serão carregados, a ordem de carregamento ou até mesmo descarregá-los/carregá-los em tempo de execução. A maioria dos módulos é configurada de forma independente e possui seus próprios arquivos de configuração. Alguns módulos suportam uma configuração que será lida estaticamente ou dinamicamente (em tempo real) a partir de bancos de dados. Em termos de logística, esses módulos são geralmente arquivos com a extensão ".so", que estão localizados no diretório de módulos do Asterisk (geralmente, isto é /usr/lib/asterisk/modules/). Quando o Asterisk inicializa, ele carrega esses arquivos e adiciona sua funcionalidade no sistema. Os módulos Asterisk que fazem parte do Kernel (CORE, que pode ser chamado de PBX) têm um nome de arquivo que se parece com pbx_xxxxxx.so.

Alguns exemplos de módulos: 

• o chan_pjsip usa o res_pjsip e muitos outros módulos res_pjsip para fornecer uma pilha SIP para dispositivos SIP e para interagir com o Asterisk e uns com os outros através do Asterisk.
• o app_voicemail fornece recursos de correio de voz tradicionais.
• o app_confbridge fornece salas de conferência com muitos recursos adicionais. 
• o res_agi fornece o Asterisk Gateway Interface, um API que permite gerenciar chamadas de scripts e programas externos ao Dialplan do Asterisk.

Chamadas e Canais do Asterisk: o principal objetivo do Asterisk é criar sistemas tolerantes a falhas e aplicativos em tempo real. Na maioria, mas não em todos os casos, isso significa que você estará lidando com o conceito de "desafios!". As chamadas na terminologia de telefonia geralmente se referem a um telefone que está se comunicando (chamando, comutando) com outro telefone através da rede telefônica. No entanto, no caso do Asterisk, a chamada geralmente usa um ou mais canais. Aqui estão alguns exemplos de chamadas/comutação:

• O telefone chama outro telefone pelo Asterisk;
• O telefone chama vários telefones de uma só vez (por exemplo, paginação) através do Asterisk;
• O telefone chama o aplicativo, por exemplo, app_voicemail ou app_queue;
• Criando um canal local para interagir com aplicativos ou outro canal.

Canais do Asterisk: os canais são criados pelo Asterisk usando o Channel Drivers. Eles podem usar outros recursos no sistema Asterisk para facilitar vários tipos de comunicação entre um ou mais dispositivos. Os canais podem ser conectados a outros canais e expostos a aplicativos e recursos. Os canais podem usar muitos outros recursos fornecidos por outros módulos ou bibliotecas externas. Por exemplo, os canais SIP usarão CODECs e módulos de formato ao transmitir áudio. Canais podem interagir diretamente com muitos módulos diferentes.

Roteamento do Asterisk: o Dialplan é uma das principais formas de controlar o comportamento do Asterisk. O Dialplan existe como arquivos de texto (por exemplo, extensions.conf) ou na linguagem de script interna do Dialplan, nos formatos de Asterisk Extension Language - AEL (extensions.ael) ou LUA (extensions.lua). Como alternativa, o Dialplan pode ser lido no banco de dados juntamente com uma configuração de módulo diferente. Ao escrever o Dialplan, você ativamente usará aplicativos e funções para influenciar canais, como o AGI, para receber instruções de controle de chamadas de scripts e programas externos.

Tipos de módulos do Asterisk: existem muitos tipos diferentes de módulos, cada um dos quais fornece suas suas próprias funções e recursos do Asterisk. Use o comando module module show na *CLI> para ver todos os módulos carregados em seu sistema Asterisk.

Drivers de Canal do Asterisk: os drivers de canal interagem com dispositivos fora do Asterisk e traduzem essa sinalização ou protocolo específico no kernel.

Aplicações Dialplan do Asterisk: aplicativos fornecem funções de chamada para o sistema. Um aplicativo pode atender uma chamada, reproduzir uma frase de som, desligar uma chamada ou fornecer um comportamento mais complexo, como um conjunto de filas, correio de voz ou chamadas em conferência.

Recursos Dialplan do Asterisk: as funções são usadas para recuperar, instalar ou controlar várias configurações da chamada. Por exemplo, uma função pode ser usada para definir o identificador de chamadas para uma chamada de saída.

Recursos do Asterisk: como o nome sugere, os recursos fornecem recursos para o Asterisk e seus módulos. Exemplos comuns de recursos incluem música em espera e chamada de estacionamento.

CODES do Asterisk: CODEC (que é um acrônimo para COder/DECoder) é um módulo para codificação ou decodificação de áudio ou vídeo. Normalmente os CODECs são usados para codificar a mídia para que ela ocupe menos largura de banda. Eles são necessários para converter o som entre CODECs de áudio e os tipos de cargas usados por vários dispositivos.

Driver de Formato de Arquivos do Asterisk: o driver de formato de arquivo é usado para salvar mídia em disco em um formato específico e para converter esses arquivos em fluxos de mídia na rede.

Driver de Gravação Detalhada de Chamadas (CDR) do Asterisk: os drivers de CDR gravam logs de chamadas no disco ou em um banco de dados.

Driver de Log de Eventos dos Canais (CEL) do Asterisk: os logs de eventos de chamadas são semelhantes aos logs de CDR, mas registram informações mais detalhadas sobre o que aconteceu dentro do Asterisk durante uma chamada específica.

Drivers de Ponte do Asterisk: os drivers de ponte são usados pela arquitetura de ponte do Asterisk e fornecem várias maneiras de conectar mensagens multimídia entre os participantes da chamada.

Módulos de Driver de Canal do Asterisk:  todas as chamadas de fora do Asterisk passam pelo driver de canal antes de chegar ao kernel, e todas as chamadas de saída passam pelo driver de canal no caminho para o dispositivo externo. O driver de canal PJSIP (chan_pjsip), por exemplo, se comunica com dispositivos externos usando o protocolo SIP. Ele converte a sinalização SIP no núcleo. Isso significa que o núcleo do Asterisk sinaliza um agnóstico. Portanto, o Asterisk não é apenas um mecanismo de comunicação SIP ou VoIP, é um mecanismo multi protocolo. Todos os drivers de canal tem um nome de arquivo que se parece com chan_xxxxx.so, tais chan_pjsip.so ou chan_dahdi.so.

Módulos de Aplicação para o Dialplan do Asterisk: módulos de roteamento fornecem função de chamada para o sistema. Esses aplicativos são lançados sequencialmente no plano de discagem. Por exemplo, uma chamada pode usar um aplicativo para atender uma chamada, outro para reproduzir um prompt de voz do disco e um terceiro aplicativo que permite ao chamador deixar o correio de voz em uma caixa de correio específica. Todos os módulos de aplicativos têm nomes de arquivos que se parecem com app_xxxxx.so, por exemplo, app_voicemail.so, no entanto aplicativos e funções também podem ser fornecidos pelo kernel e outros módulos. Módulos, como res_musiconhold e res_xmpp, fornecem aplicativos relacionados à sua própria funcionalidade.

Módulos de função de plano de discagem do Asterisk: as funções Dialplan são um pouco semelhantes às aplicações de Dialplan, mas em vez de executar o trabalho em um canal ou chamada específica, elas simplesmente recuperam ou definem uma configuração específica em um canal ou realizam manipulações de texto. Por exemplo, o recurso Dialplan pode extrair informações de ID do chamador de uma chamada recebida, filtrar texto ou definir um tempo limite para o chamador entrar. Todos os módulos de função do Dialplan tem nomes de arquivos que parecem func_xxxxx.so, por exemplo, func_callerid.so, mas aplicativos e funções também podem ser fornecidos pelo kernel e outros módulos. Módulos, como res_musiconhold e res_xmpp, fornecem aplicativos relacionados à sua própria funcionalidade.

Módulos de recursos do Asterisk: recursos fornecem funcionalidade ao Asterisk que pode ser chamada a qualquer momento durante uma chamada, mesmo se outro aplicativo estiver sendo executado em um canal. Os recursos são normalmente usados como eventos assíncronos, como reproduzir música no modo de espera quando uma chamada é colocada em espera ou a chamada está sendo estacionada. Módulos de recursos têm nomes de arquivos que se parecem com res_xxxxx.so, por exemplo, res_musiconhold.so. Os módulos de recursos podem fornecer aplicativos e funções, mesmo se esses aplicativos ou funções não tiverem módulos separados.

Módulos CODECs do Asterisk: os módulos do CODEC têm nomes de arquivos que se parecem com codec_xxxxx.so, como codec_alaw.so e codec_ulaw.so. CODEC são algoritmos matemáticos para codificação (compressão) e decodificação (descompressão) de fluxos de mídia. O Asterisk usa módulos CODEC para enviar e receber multimidia (áudio e vídeo). O Asterisk também usa módulos CODEC para converter (ou transcodificar) fluxos de mídia entre diferentes formatos. O Asterisk está equipado com módulos CODEC para os seguintes tipos de mídia:

• ADPCM, 32 kbps;
• G.711 A-law, 64 kbps;
• G.711 U-law, 64 kbps;
• G.722, 64 kbps;
• G.726, 32 kbps;
• GSM, 13 kbps;
• LBC-10, 2,4 kbps;

O núcleo do Asterisk fornece um recurso de PCM Signed Linear de 16 bits que codifica ou decodifica todos os CODECs. Há outro módulo CODEC, codec_resample, que permite que o Signed Linear reveja diferentes taxas de amostragem de 12, 16, 24, 32, 44, 48 96 ou 192 kHz para facilitar a tradução. Módulos CODEC similares também podem ser instalados de suas dependências forem detectadas durante a compilação do Asterisk. Se os drivers DAHDI forem detectados, o codec_dahdi será instalado. Se as bibliotecas de desenvolvimento da Speex (www.speex.org) forem encontradas, o codec_speex também será instalado. Se a biblioteca de desenvolvimento do iLBC forem encontradas (www.ilbcfreeware.org), o codec_ilbc também será instalado. O suporte para os CODECs proprietários G.729A (caiu em domínio publico em janeiro de 2017) ou G.723.1 (também caiu em dominio publico em janeiro de 2017) é fornecido pela Digium em uma base comercial usando software (G.729A) ou hardware (G.729A e G.723.1). Para obter mais informações sobre a compra de licenças ou equipamentos para usar os CODECs G.729A e/ou G.723.1 com o Asterisk, visite o site da Digium.

Suporte para os CODECs Siren7 e G.722.1C Siren14 carregados de patentes, mas gratuitos, ou para SILK CODEC for Skype, podem ser incluídos no Asterisk fazendo o download dos módulos binários dos CODECs no site da Digium. Na interface de linha de comando do Asterisk (*CLI>), use o comando core show translation para exibir o tempo de tradução entre todos os formatos de áudio registrados.

Driver de formato de Arquivos do Asterisk: o Asterisk usa módulos de formato de arquivo para transferir arquivos de mídia (como áudio e vídeo) da rede e salvá-los em disco ou extrair arquivos especificados do disco e convertê-los de volta no fluxo de mídia. Embora isso seja frequentemente associado aos CODECs, pode haver mais de um formato disponível em um disco para um CODEC específico. Os módulos de formato de arquivo têm nomes de arquivo que se parecem com format_xxxxx.so, como format_wav.so e format_jpeg.so. A seguir está uma lista de módulos de formato incluídos nas versões mais recentes do Asterisk:

• format_g719;
• format_g723;
• format_g726;
• format_g729;
• format_gsm;
• format_h263;
• format_h264;
• format_ilbc;
• format_jpeg;
• format_ogg_vorbis;
• format_pcm;
• format_siren7;
• format_sirem14;
• format_sln;
• format_vox;
• format_wav_gsm;
• format_wav;

Driver de gravação de chamadas (CDR) do Asterisk: os módulos CDR são usados para armazenar registros de detalhes de chamadas (CDRs) em vários formatos. Os mecanismos populares de armazenamento incluem arquivos delimitados por vírgula (CSV), bem como bancos de dados relacionais, como MySQL ou PostgreSQL. Registros com informações detalhadas sobre chamadas geralmente contêm um registro por chamada e fornecem informações detalhadas, por exemplo, quem fez a chamada, quem atendeu a chamada, o tempo necessário para ligar e assim por diante. Os gravadores de detalhes da chamada possuem nomes de arquivos que se parecem com cdr_xxxxx.so, por exemplo, cdr_csv.so. O módulo recomendado para conexão com back-ends de armazenamento de CDR é o cdr_adaptive_odbc.so.

Módulo de Driver de Evento (CEL) do Asterisk: os registros de eventos de chamadas registram as várias ações que ocorrem durante uma chamada. Assim, eles, como regra, descrevem os registros detalhados de chamadas com mais detalhes. Por exemplo, um registro de chamadas pode mostrar que Paula ligou para Roberto, que a ligação de Roberto soou por vinte segundos, depois o telefone tocou por quinze segundos e a ligação foi para o Correio de Voz de Roberto, onde Paula deixou o Correio de Voz por vinte e cinco segundos e desligou. O sistema também permite registrar eventos personalizados. Os módulos de registro de eventos de chamada possuem nomes de arquivos que se parecem com cel_xxxxx.so, como cel_custom.so e cel_adaptive_odbc.so. O módulo recomendado para conexão com back-ends de armazenamento de CEL é o cel_adaptive_odbc.so.

Módulo de Ponte do Asterisk: começando com o Asterisk 1.6.2 Standard, o Asterisk introduziu um novo método para conectar chamadas. Ele depende de vários módulos de ponte para controlar como os fluxos de mídia devem se misturar para os participantes quando forem chamados. Os módulos de ponte possuem nomes de arquivos que se parecem com bridge_xxxxx.so, como bridge_simple.so e bridge_multiplexed.so.

Diretórios e Estrutura de Arquivos do Asterisk: os diretórios de nível superior usados pelo Asterisk podem ser configurados no arquivo de padrão. Abaixo de cada cabeçalho, você também pode ver uma linha de configuração correlacionada no arquivo asterisk.conf.

• Arquivo de Configuração do Asterisk;


• astetcdir => /etc/asterisk/;
• Este local é usado para armazenar e ler arquivos de configuração do Asterisk. Estes são geralmente arquivos .conf, .lua e .ael.


• Módulos do Asterisk;


• astmoddir=> /usr/lib/asterisk/modules/;
• Módulos para download no formado Shared Object (.so), instalados pelo Asterisk ou pelo usuário, estão aqui.


• Várias Bibliotecas;
• astvarlibdir => /var/lib/asterisk/;
• Aqui, elementos adicionais da biblioteca e arquivos contendo dados usados no tempo de execução são adicionados.
• Diretório de Banco de Dados;
• astdbdir => /var/lib/asterisk/;
• Esse local é usado para armazenar o arquivo de dados do banco de dados interno do Asterisk. Nas versões do Asterisk usando o banco de dados SQLite3, o arquivo será nomeado como astdb.sqlite3.
• Chaves de Criptografias;
• astkeydir => /var/lib/asterisk/;
• Ao configurar a criptografia baseada em chave, o Asterisk irá procurá-las nesse diretório.
• Catálogo de dados do Sistema;
• astdatadir => /var/lib/asterisk/;
• Por padrão, sons do Asterisk são salvos e lidos no subdiretório de sons (sound/br) daquele local.
• Interface AGI (Asterisk Gateway Interface);
• astagidir => /var/lib/asterisk/agi-bin/;
• Ao usar vários aplicativos AGI, o Asterisk, por padrão, procura os scripts AGI nesse diretorio.
• Diretorio de Fila;
• astspooldir => /var/spool/asterisk/;
• Este diretório é usado para armazenar arquivos de filas de vários componentes do kernel e módulos do Asterisk. A maioria deles usa seus próprios subdiretórios, por exemplo:
• dictate;
• meetme;
• monitor;
• outgoing;
• recording;
• system;
• tmp;
• voicemail;
• Processos em execução;
• astrundir => /var/run/asterisk/;
• Quando o Asterisk estiver rodando, você verá dois arquivos aqui: asterisk.crl e asterisk.pid. Estes são o soquete de controle e os arquivos PID (ID do Processo) para o Asterisk.
• Logs;
• astlogdir => /var/log/asterisk/;
• Quando o Asterisk é configurado para fornecer saída de log, eles serão armazenados nesse diretório. 
• Diretório binário do Sistema;
• astsbindir => /usr/sbin/;
• Por padrão, o Asterisk procura neste diretório por quaisquer binários do sistema que ele usa, se você mover o arquivo binário do Asterisk ou qualquer outro que ele usar, você precisará alterar este local.

Thats All FOLKS! (Isso é tudo, pessoal!)