Olá sejam muito bem-vindos a mais uma documentação para ajudar a comunidade, antes de qualquer coisa não deixe de contribuir, nos acione e envie material para que possamos fazer deste site um grande repositório de informações para todos.
Este material te auxilia a fazer o passo a passo para criação do backup no seu FreePBX, vamos lá!
Faça o login na interface web do FreePBX visitando o endereço IP do seu PBX.
Navegue em Admin -> Backup e Restauração
Clique em Backups e depois em New Backup
Escolha um "nome" e uma "descrição" para o backup e insira um "endereço de e-mail" que será
notificado quando o backup for executado. Para fazer backup de tudo em seu servidor, incluindo correios de voz, gravações, arquivos de configuração, etc., você deverá clicar e arrastar os seguintes Modelos para a seção Itens de backup:
Backup Completo
CDRs
Sistema de áudio
Correio de voz
Observe que isso NÃO incluirá gravações de chamadas, o que pode tornar seu backup muito grande. No entanto, se você precisar deles incluídos no seu backup, você pode clicar no "+" (mais) na parte inferior da lista "Itens" e adicionar um diretório com o caminho "__ASTSPOOLDIR __/monitor" (sem as aspas).
Em Storage Locations, arraste “Local Storage (local)” para a coluna Storage Servers (Opcional) Se você deseja executar o backup automaticamente em uma base regular, escolha a frequência que deseja que o servidor faça backup. Se você estiver configurando backups automáticos, é altamente recomendável definir um tempo ou quantidade "Excluir após", caso contrário, os backups antigos nunca serão removidos e você poderá ficar sem espaço em disco.
Acima em -Hooks são scripts que podem ser definidos para interagir antes e depois do backup.
Clique em Salvar.
Para executar o backup agora, vá até o fundo novamente e clique em "e executar"
Após isso você já pode contar com uma rotina de backup automatica, configurando da forma que melhor lhe atender! É possível conferir a listas de backups, os mesmos ficam salvos no caminho: /var/spool/asterisk/backup no linux.
Espero que essa documentação possa lhe auxiliar, encerramos por aqui, até a proxima!
Olá sejam muito bem-vindos a mais uma documentação para auxiliar a comunidade não só freepbx, mas também Issabel, este que usa o freepbx(2.11) não muda muita coisa, somente a interface web, mas o coração é do nosso guerreiro, bom vamos lá. Este trata a interligação de um Freepbx com um Issabel usando tronco IAX2, o mesmo server para uma comunicação entre sites, se necessário. Vamos por a mão na massa!
Antes de seguir não deixe de compartilhar os conteúdos do nosso site e contribuir com o mesmo, assim conseguimos ainda mais ajudar a comunidade.
Laboratório (Freepbx)
Virtualbox 6.0;
CentOS 7;
HD 10GB;
Memoria: 1024 MB;
Freepbx 14.
Laboratório (Issabel)
PROXMOX 5.3;
CentOS 7;
HD 40GB;
Memoria: 1024 MB;
Issabel.
Observações: O HD do Issabel está um pouco maior por ser um servidor de laboratorio que já existia, mas não se preocupe com esse detalhe, se for o caso pode criar ambos do mesmo tamanho.
Configurações [FreePBX]
Crie um tronco do tipo IAX2 com as seguintes informações:
Trunk Name: Issabel
Trunk Name (Outgoing): Issabel
PEER Details:
username=freepbx
type=friend
trunk=yes
transfer=no
secret=AsteriskHelp
qualify=yes
host=IP_DO_SERVIDOR_ISSABEL
disallow=all
context=from-internal
allow=ulaw&alaw&gsm
Se caso tiver alguma duvida, suas configurações devem estar como a imagem abaixo:
Uma parte do trabalho foi feita que é criar o tronco, agora precisamos adicionar uma rota de saida para conseguir ligar para outra ponta, Issabel!
Nas rotas de saída crie uma rota com as seguintes informações abaixo:
Acima em Route Name coloque o nome da rota de saida, esta foi definida como "dial-issabel", em Trunk Sequence for Matched Routes, este você deve atribuir o tronco que foi criado, neste caso issabel.
Agora na guia "Dial Patterns" adicione a regra de discagem para conseguir ligar nos ramais da central ISSABEL, este que estão na range 3000 ao 3999, sendo assim será usado a mascara 3XXX.
Configurações [Issabel]
Crie um tronco do tipo IAX2 com as seguintes informações:
Trunk Name: freepbx
Trunk Name: freepbx
PEER Details:
username=issabel
type=friend
trunk=yes
transfer=no
secret=AsteriskHelp
qualify=yes
host=IP_DO_SERVIDOR_FREEPBX
disallow=all
context=from-internal
allow=ulaw&alaw&gsm
Se caso tiver alguma duvida, suas configurações devem estar como a imagem abaixo:
Agora vamos configurar uma rota de saída para para que seu server Issabel possa discar para os ramais do servidor FreePBX.
Assim como no tronco anterior, este foi adicionado a regra de discagem para conseguir ligar nos ramais da central FreePBX, este que estão na range 1000 ao 1999, sendo assim será usado a mascara 1XXX.
Agora que os troncos e rotas foram criadas, vamos checar o status da interligação em ambos os lados.
[root@asteriskhelp ~]# asterisk -vvvvvvvvcgi
asteriskhelp*CLI> iax2 show peers
Name/Username Host Mask Port Status Description
issabel/freepbx 192.168.1.95 (S) 255.255.255.255 4569 (T) OK (1 ms)
[root@issabel~]# asterisk -vvvvvvvvcgi
issabel*CLI> iax2 show peers
Name/Username Host Mask Port Status Description
freepbx/issabel 192.168.1.38 (S) 255.255.255.255 4569 (T) OK (1 ms)
Testes de ligações
-- Called IAX2/freepbx/1000
-- Call accepted by 192.168.1.38 (format ulaw)
-- Format for call is (ulaw)
-- IAX2/freepbx-16860 is ringing
-- IAX2/freepbx-16860 is ringing
issabel*CLI>
Called IAX2/issabel/3000
-- Call accepted by 192.168.1.95:4569 (format ulaw)
-- Format for call is (ulaw)
-- IAX2/issabel-18020 is ringing
-- IAX2/issabel-18020 is ringing
asteriskhelp*CLI>
Os testes foram efetuados com sucesso, desta forma a comunicação entre os servidores esta estabelecida e testada, espero que esta documentação possa lhe auxiliar, não deixe de comentar e contribuir com o site da comunidade.
Olá , sejam bem-vindos a mais uma documentação voltada para o ambiente asterisk e FreePBX, esta trata a transferência cega (Blind transfer) ou seja, você transfere a chamada para o ramal destino sem saber se ele quer ou não atender, essa demanda especifica surgiu e achei interessante compartilhar com a comunidade. Este processo será necessário algumas customizações nos arquivos conf do asterisk, nada de outro mundo, fiquem tranquilos. A inicio será alterado o contexto padrão da variável “${TRANSFER_CONTEXT}” esta que é acionada todas vezes que é executado uma transferência e logo a seguir dentro do contexto customizado será tratado a variável de canal “${BLINDTRANSFER}” usada na transferência cega, desta forma quando transferir a chamada ele aguardará o time especificado e logo a seguir devolve a chamada para a extensão que originou a transferência.
No terminal do linux vamos as alterações nos arquivos do asterisk, sempre sugiro que faça esse processo no seu ambiente de testes para não ter problemas com o sistema em produção.
A descrição do laboratório são de dois ambientes que um usando Debian 8(Raspberry Pi) e o outro CentOS6.
Laboratório 01:
Raspberry Pi;
Asterisk 11.21;
Debian 8.
Laboratório 02:
Servidor IBM;
Asterisk 11.21;
CentOS 6.
[root@asteriskhelp ~]# vim /etc/asterisk/globals_custom.conf
TRANSFER_CONTEXT = custom-test_transfer
Logo em seguida pressione a tecla [ESC], depois ":x!" para sair do arquivo salvando as alterações. Obs. Sem as ASPAS!
A seguir será adicionado o contexto que vai tratar a transferência e devolve-la para o ramal que originou.
[root@asteriskhelp ~]# vim /etc/asterisk/extensions_custom.conf
[custom-test_transfer]
exten => _X.,1,NoOp(Entering custom-test_transfer)
exten => _X.,n,Set(timeoutd=25) ; Aqui adicione o tempo que deseja como timeout
exten => _X.,n,Set(extLeng=${LEN(${EXTEN})})
exten => _X.,n,NoOp(The extenlength is ${extLeng})
exten => _X.,n,Dial(Local/${EXTEN}@from-internal,${timeoutd})
exten => _X.,n,Set(CALLERID(name)=RB:${CALLERID(name)})
exten => _X.,n,Dial(Local/${BLINDTRANSFER:4:${extLeng}}@from-internal)
exten => _X.,n,Hangup()
Logo em seguida pressione a tecla [ESC], depois ":x!" para sair do arquivo salvando as alterações.
Agora será necessário executar um reload no asterisk para que ele reconheça o novo contexto criado, observe a seguir que serão rodados três comando, um para entrar no console do asterisk, outro para dar o reload nos contextos o ultimo para checar se o já existe e foi reconhecido pelo asterisk.
Agora que já alimentou os arquivos e o asterisk reconheceu o contexto, como mostra o resultado acima, já pode iniciar os testes. Lembrando que essa documentação foi homologada em ramais SIP que utilizam o modulo "chan_sip".
Espero que tenha auxiliado e até a próxima, abraços.
Olá sejam bem-vindos a mais uma documentação voltada para Freepbx, esta será curta e objetiva.
O nosso amigo e parceiro
RAFAEL TAVARES
da
Ibinetwork
desenvolveu um script de instalação customizada do freepbx 14 e asterisk 13 para Linux CentOS versão 7, este estamos trabalhando em melhorias juntamente com o apoio da comunidade no telegram
[FreePBX Brasil Community]
o mesmo faz a instalação dos módulos básicos para uso no dia-dia, regras sip para o firewalld, instalação dos áudios em português, codec g729 e tratamento de hangupcause, abaixo o link do script onde pode conferir mais detalhes, contamos com a sua ajuda para melhora-lo ainda mais.
O procedimento abaixo não será extenso como a maioria, apenas para documentar as configurações desconexão do equipamento DINSTAR(FXO), ao observar que existe uma certa carência deste tipo de documentação para tal modelo, este processo foi resolvido juntamente com o auxilio do Luciano Cavalcante amigo e parceiro da comunidade FreePBX Brasil Community.
Laboratório:
Asterisk 11;
DINSTAR – MODELO DAG1000-4O;
Linha Analógica da Operadora Oi.
Antes de mais nada se possível atualize seu equipamento, abaixo o link para acesso ao diretório compartilhado com as ultimas firmwares.
No equipamento no caminho:
Advanced
»
FXO Parameter
Segue a imagem abaixo:
Preencha com as seguintes informações de cadência: 250,230,250,230,250,230,330,230
Confira as demais informações acima e se caso tiver algo diferente no seu equipamento, ajuste.
Espero que esta documentação ajude e não deixe de compartilhar e contribuir com a comunidade, se caso você tiver alguma documentação relevante que queira compartilhar aqui, nos contate que será um prazer criarmos um post com novos conhecimentos.
O Systemd é responsável por gerenciar sistemas e serviços de alguns OS Linux. Foi desenvolvido para ser compatível com os scripts init do SysV e disponibiliza vários recursos, como a iniciar serviços em paralelo ao linux no momento do boot, a ativação por demanda de daemons ou a lógica de controle de serviço baseada em dependência. Um exemplo no CentOS 7 assim como em sistemas baseados em Red Hat , o systemd substitui o Upstart como o sistema init padrão.
O conceito de unidades systemd, são representadas por arquivos de configuração de unidade localizados em um dos diretórios listados na tabela abaixo,“Localizações de arquivos da unidade Systemd” e disponibilizam informações sobre serviços do sistema e outros objetos que são importantes para o sistema init, este será mencionado a seguir. Para ter acesso a mais informações sobre a lista completa dos tipos de unidade systemd disponíveis, confira na lista a seguir,“Tipos de unidade systemd disponíveis”.
Tipos de unidade systemd disponíveis
Tipo de Unidade
Extensão de Arquivo
Descrição
Unidade de serviço
.service
Um serviço do sistema.
Unidade alvo
.target
Um grupo de unidades systemd.
Unidade de montagem automática
.automount
Um ponto de montagem automática do sistema de arquivos.
Unidade do dispositivo
.device
Um arquivo de dispositivo reconhecido pelo kernel.
Unidade de montagem
.mount
Um ponto de montagem do sistema de arquivos.
Unidade de caminho
.path
Um arquivo ou diretório em um sistema de arquivos.
Unidade de escopo
.scope
Um processo criado externamente.
Unidade de fatia
.slice
Um grupo de unidades organizadas hierarquicamente que gerenciam processos do sistema.
Unidade de instantâneo
.snapshot
Um estado salvo do gerenciador do systemd.
Tomada de unidade
.socket
Um soquete de comunicação entre processos.
Unidade de swap
.swap
Um dispositivo de troca ou um arquivo de troca.
Unidade de temporizador
.timer
Um temporizador systemd.
Localizações dos arquivos da unidade Systemd
Diretório
Descrição
/usr//lib/systemd/system/
Arquivos unitários do Systemd distribuídos com pacotes RPM instalados.
/run/systemd/system/
Arquivos unitários do Systemd criados no tempo de execução. Esse diretório tem precedência sobre o diretório com arquivos da unidade de serviço instalados.
/etc/systemd/system/
Arquivos unitários do Systemd criados por systemctl enable arquivos de unidade adicionados para estender um serviço. Esse diretório tem precedência sobre o diretório com arquivos de unidade de tempo de execução.
Agora que foi feita uma breve abordagem do Systemd, será descrito a seguir um pouco do antecessor, init.
No sistema operacional Linux, init é a forma simplificada de Initialization. O init é um processo daemon que inicia no boot do servidor e continua em execução até que ele seja encerrado. O init é o primeiro processo que começa quando seu servidor inicializa, tornando-o o pai de todos os outros processos em execução direta ou indiretamente e normalmente é atribuído e identificado nos processos como "pid=1".
Se ocorrer algum erro e o daemon init não puder iniciar, nenhum dos demais processos serão inicializados e o sistema no boot irá apresentar falhas normalmente identificada como “Kernel Panic”. init é geralmente referido como Sistema de V (abreviado, SysV ou System Five) de inicialização. O System V é o primeiro sistema operacional UNIX comercial projetado e o uso do init na maior parte do Linux Distribution de hoje é idêntico ao System V OS com algumas exceções, como o Slackware usando estilo BSD e o Gentoo usando init customizado.
A demanda para substituição do init por algo melhor foi identificada no momento que foram desenvolvidas, algumas das substituições do init nativa da distro, segue algumas:
Upstart - Um daemon de substituição de init implementado no Ubuntu GNU / Linux e projetado para iniciar o processo de forma assíncrona.
Epoch - Um daemon de substituição de init criado em torno da simplicidade e do gerenciamento de serviços, projetado para iniciar o processo de thread único.
Mudar - Um daemon de substituição de init escrito em Python, implementado no Pardus GNU / Linux e projetado para iniciar o processo de forma assíncrona.
systemd - Um daemon de substituição de init projetado para iniciar o processo em paralelo, implementado em um número de distribuição padrão - Fedora, OpenSuSE, Arch, RHEL, CentOS, etc.
Analisando essas mudanças e observando que surgem algumas dúvidas no caso do CentOS 7, o habito de fazer uso do rc.local para inicialização de scripts customizados no boot do servidor, etc.
A seguir será apresentado duas formas de trabalhar com essas mudanças, a inicio será criado no systemd para no boot iniciar o seu script, no caso do laboratório será usado um script bash como exemplo, em segundo ambiente de estudo, será descrito como ativar no systemd para que carregue o rc.local do Linux.
Laboratório:
Virtualbox v5.2.26
OS - CentOS Linux Release 7.5.1804(Core)
Memoria 1024 MB
Disco 40GB
Este será criado no systemd para iniciar um script básico de firewall como um serviço comum do servidor.
Vá até o diretorio abaixo:
[root@labfreepbx ~]# cd /etc/rc.d/
Crie o seguinte arquivo:
[root@labfreepbx ~]# vim firewall.sh
Com o conteúdo:
#!/bin/bash
# Autor: Profº Kowalski
# Comunidade FreePBX Brasil
# Variaveis
LAN="enp0s3"
REDE_INTERNA="172.16.100.0/24"
# Limpa regras
iptables -t filter -F
iptables -t nat -F
# Policy default
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
# Liberar interface lo e rede interna
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -s $REDE_INTERNA -i $LAN -m comment --comment "REDE LOCAL" -j ACCEPT
Observações:
As variáveis “$LAN” e “$REDE_INTERNA” devem ser alteradas para as que atendam o seu ambiente de estudo, lembrando que este é apenas um script de estudo usado para simular uma necessidade diária, se for fazer uso deste em produção recomendo que revise e adeque as suas necessidades.
Após alimentar o script com as informações corretas do seu ambiente, salve e saia, se caso não souber no VIM usa-se ESC + :x! (Dois pontos, X minúsculo e exclamação), assim você salva e sai do arquivo forçando as alterações.
Agora será necessário a permissão de execução do script.
[root@labfreepbx ~]# chmod +x firewall.sh
Pronto, script criado, se for caso para não ter surpresas execute o mesmo somente para efeito de teste, e a seguir será criado o arquivo que o systemd inicie seu script no boot.
Onde “After=network.target” significa que ele inicializará após o serviço de rede, “ExecStart” defini o caminho do nosso arquivo bash e o “WantedBy” em qual destino da inicialização ele será executado.
Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.
Agora já pode reiniciar o seu servidor e veja se ao iniciar o mesmo executou o script como deve ser.
Até agora já abordamos como criar no systemd a inicialização dos seus serviços, correto! Mas Profº Kowalski se eu quiser utilizar o meu rc.local sem necessidade de criar para cada script um serviço no systemd, isso é possível? Sim, claro vamos lá! Você pode sim fazer desta forma, será descrito a seguir.
Desative seu atual serviço para não conflitar com as configurações a seguir ou se preferir pode remover.
Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.
A seguir reinicie o seu servidor para validar seu procedimento, ao voltar rode o seguinte comando:
[root@labfreepbx ~]# systemctl status rc-local.service
Observe que o status deve está como “Active” sendo assim o systemd está executando o rc.local no boot corretamente.
Essa foi mais uma documentação para comunidade, não deixe de acompanhar as nossas mídias sociais, um forte abraço e até a próxima.
