Meu artigo não é uma descrição completa do produto, mas apenas um pequeno esclarecimento sobre a boa publicação “FusionPBX, ou ainda, ótimo, FreeSWITCH”. Parece-me que o tópico da ACL no FusionPBX não está muito bem coberto. Vou tentar preencher essa lacuna, com base na minha própria experiência com o FreeSWITCH / FusionPBX.
E assim, temos o FusionPBX instalado com um número de ramal registrado 1010 no domínio domain.local e uma rota configurada para chamadas externas para a cidade. Usamos ACLs para proteger nosso sistema de telefonia contra chamadas não autorizadas que custarão nosso dinheiro. I.e. somente as redes descritas na ACL permitem chamadas de saída. E aqui você precisa de uma compreensão muito clara de como a ACL no FusionPBX funciona, seus recursos, lógica e seu ponto de conexão.
Como o respeitado autor do artigo acima, eu também pisei em todos os rakes associados à ACL.
Vou começar com
SipProfiles .
Ambos os perfis (os chamarei assim), internos e externos, estão no contexto de Público, e isso não é coincidência. O registro dos números ocorre no perfil interno e preste atenção nele. No perfil interno, os domínios ACL são vinculados como apply-inbound-acl. Essa linha é responsável pela operação da ACL no nível do perfil. Até agora com perfis.
Contexto
Contexto, entre outras coisas, é usado no roteamento de chamadas. Todas as rotas de entrada estão vinculadas ao contexto Público.
As rotas de saída (para a cidade, para celular, intermunicipal, internacional e outras) estão localizadas (por padrão) no contexto do nome de domínio (vamos chamá-lo de domain.local).
ACL
Agora vamos lidar com a ACL. Por padrão, o FusionPBX recém-instalado possui duas ACLs:
ação padrão dos domínios: negar - esta planilha está vinculada ao perfil interno
ação padrão da lan: permitir
Nos domínios ACL-list, configuramos a rede (bem, por exemplo, 192.168.0.0/24), permitimos a rede dessa rede, use reloadacl.
Em seguida, registre o telefone nesta rede e tudo parece estar bem de acordo com as instruções e lógica.
Começamos a testar, ligamos para um número externo e ... pegamos um pãozinho, ou melhor, um buraco no pãozinho. Inesperadamente!
Começamos a analisar o log no console ou através do Log Viewer FusioPBX.
Vemos a nossa chamada:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
Vemos a ACL acionada:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.
E mais:
mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context public switch_core_state_machine.c:311 No Route, Aborting switch_core_state_machine.c:312 Hangup sofia/internal/1010@domain.local [CS_ROUTING] [NO_ROUTE_DESTINATION]
Nenhuma rota! Embora a rota temos honestamente registrado.
A resposta é realmente simples.
A ligação chegou. O ACL perdeu. E como a ACL está vinculada ao perfil interno e esse perfil está no contexto público, o FreeSWITCH analisa honestamente o roteamento no contexto público. Mas no contexto do público, há apenas roteamento de entrada, e o sistema nos diz honestamente que não há rotas para a cidade lá.
Há pelo menos duas maneiras de sair dessa situação.
- Anexe esta ACL não ao perfil, mas ao número interno. Essa pode ser a maneira mais correta de resolver, porque As ACLs devem ser amarradas o mais próximo possível da extensão para um ajuste mais preciso. I.e. Você pode especificar um endereço específico / endereço de rede do telefone a partir do qual ele pode fazer uma chamada. A desvantagem dessa opção é que em cada extensão você deve fazer isso.
- Corrija a ACL para que funcione corretamente no nível do perfil. Eu escolhi essa opção, porque adicionar uma rede à ACL uma vez me pareceu mais fácil do que escrevê-la em cada extensão. Mas isso é especificamente para a minha tarefa. Para outras tarefas, você pode precisar de uma lógica de decisão diferente.
E assim Vamos corrigir os domínios da ACL da seguinte maneira:
ação padrão dos domínios: permitir
Nos domínios ACL-list, configuramos a rede:
negar 192.168.0.0/24
Aplique reloadacl.
Testamos: discamos novamente o número 98343379xxxx e ... o CPV continua ... ALLO. Tudo funciona.
Vemos o que aconteceu no FreeSWITCH:
A chamada começa:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
O ACL não perdeu:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.
e ainda mais:
mod_dialplan_xml.c:637 Processing 1010 <1010>->98343379xxxx in context domain.local sofia/internal/1010@domain.local Regex (PASS) [Sity] destination_number(98343379xxxx) =~ /^9(8343[23]\d{6})$/ break=on-false
O roteamento passou e, em seguida, é estabelecida uma conexão que vai além do escopo do tópico.
Se alterarmos o endereço de rede na ACL, mas obter a imagem do primeiro teste, ou seja, A chamada da ACL será ignorada e o roteamento indicará NO_ROUTE_DESTINATION.
Provavelmente é tudo o que eu queria adicionar ao FusionPBX ACL.
Espero que alguém venha a calhar.