Mi artículo no es una descripción completa del producto, sino solo una pequeña aclaración de la buena publicación "FusionPBX, o nuevamente, excelente, FreeSWITCH". Me parece que el tema de ACL en FusionPBX no está muy bien cubierto. Intentaré llenar este vacío, basado en mi propia experiencia con FreeSWITCH / FusionPBX.
Y así, hemos instalado FusionPBX con el número de extensión registrado 1010 en el dominio domain.local y una ruta configurada para llamadas externas a la ciudad. Usamos ACL para proteger nuestro sistema de telefonía de llamadas no autorizadas que nos quitarán nuestro dinero. Es decir solo de las redes descritas en ACL permiten llamadas salientes. Y aquí necesita una comprensión muy clara de cómo funciona la ACL en FusionPBX, sus características, lógica y su punto de conexión.
Al igual que el respetado autor del artículo anterior, también pisé todos los rastrillos asociados con la ACL.
Comenzaré con
SipProfiles .
Ambos perfiles (los llamaré así), y el interno y el externo están en el contexto de Público, y esto no es una coincidencia. El registro de números se lleva a cabo en el perfil interno y preste atención. En el perfil interno, los dominios ACL están vinculados como apply-inbound-acl. Esta línea es responsable del funcionamiento de la ACL a nivel de perfil. Hasta ahora con los perfiles.
Contexto
El contexto, entre otras cosas, se usa en el enrutamiento de llamadas. Todas las rutas entrantes están vinculadas al contexto público.
Las rutas salientes (a la ciudad, a celulares, interurbanas, internacionales y cualquier otra) se ubican (por defecto) en el contexto del nombre de dominio (llamémoslo dominio.local).
ACL
Ahora tratemos con la ACL. Por defecto, el FusionPBX recién instalado tiene dos ACL:
acción predeterminada de los dominios: denegar: esta hoja está vinculada al perfil interno
acción predeterminada de lan: permitir
En la lista ACL de dominios, configuramos la red (bueno, por ejemplo, 192.168.0.0/24), hacemos que permitir la red para esta red, use reloadacl.
Luego, registre el teléfono desde esta red, y todo parece estar bien de acuerdo con las instrucciones y lógico.
Comenzamos las pruebas, hacemos una llamada a un número externo y ... obtenemos un bagel, o mejor dicho, un agujero de un bagel. Inesperadamente!
Comenzamos a analizar el registro en la consola oa través del Log Viewer FusioPBX.
Vemos nuestro llamado:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
Vemos la ACL activada:
sofia.c:10208 IP 192.168.0.150 Approved by acl "domains[]". Access Granted.
Y además:
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]
No hay ruta! Aunque la ruta la hemos registrado honestamente.
La respuesta es realmente simple.
La llamada ha llegado. ACL se lo perdió. Y dado que la ACL está vinculada en el perfil interno, y este perfil está en el contexto público, FreeSWITCH analiza honestamente el enrutamiento en el contexto público. Pero en el contexto del público, solo hay enrutamiento entrante, y el sistema nos dice honestamente que no hay rutas a la ciudad allí.
Hay al menos dos formas de salir de esta situación.
- Adjunte esta ACL no al perfil, sino al número interno. Esta puede ser la forma más correcta de resolver, porque Las ACL deben estar lo más cerca posible de la Extensión para una afinación más precisa. Es decir Puede especificar una dirección específica / dirección de red del teléfono desde el que puede hacer una llamada saliente. La desventaja de esta opción es que en cada extensión debe hacer esto.
- Corrija la ACL para que funcione correctamente en el nivel de perfil. Elegí esta opción, porque agregar una red a la ACL una vez me pareció más fácil que escribirla en cada Extensión. Pero esto es específicamente para mi tarea. Para otras tareas, es posible que necesite una lógica de decisión diferente.
Y asi. Arreglemos los dominios de ACL de la siguiente manera:
acción predeterminada de los dominios: permitir
En la lista ACL de dominios configuramos la red:
negar 192.168.0.0/24
Aplicar reloadacl.
Probamos: marcamos nuevamente el número 98343379xxxx y ... el CPV dice ... ALLO. Todo funciona
Vemos lo que sucedió en FreeSWITCH:
La llamada comienza:
switch_channel.c:1104 New Channel sofia/internal/1010@domain.local
ACL no se perdió:
[DEBUG] sofia.c:10263 IP 192.168.0.150 Rejected by acl "domains". Falling back to Digest auth.
y además:
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
El enrutamiento ha pasado, y luego se establece una conexión que va más allá del alcance del tema.
Si cambiamos la dirección de red en la ACL, pero obtenemos la imagen de la primera prueba, es decir, La llamada de ACL se saltará y la ruta dirá NO_ROUTE_DESTINATION.
Eso es probablemente todo lo que quería agregar en la ACL FusionPBX.
Espero que alguien sea útil.