Siguiendo una línea de opinión personal, y tal y como prometí en el anterior artículo Porqué recomiendo Debian y no CentOS, escribo sobre porqué es mejor configurar Asterisk mediante archivos de configuración y no mediante un intefaz web generalista como FreePBX.

Como digo, esta es una opinión personal, no es una tautología ni espero llevar razón en todo. Cuando hablo de interfaces web, hablo principalmente de interfaces web de configuración de Asterisk de forma generalista: FreePBX, Asterisk-GUI, y en cierta medida, el interfaz web de configuración de Elastix entre otros, por ser los más comunes. Fuera quedan interfaces web propios, desarrollados con una orientación especial por empresas para sus clientes, o incluso otros generalistas pero orientados de forma particular tal y como explicaré a continuación que si bien me parecen sistemas ideales para alguien que quiere configurar “su propio Asterisk” para hacer pruebas, o incluso para su propia empresa, no lo veo eficiente, serio ni profesional como para ser incluido dentro de un sistema profesional de comunicaciones.

Dar gracias a todos aquellos que esperaban impacientemente un artículo como este, bien por ser un “tema flame” que causa ampollas entre los defensores de los interfaces webs y los defensores de la línea de comandos. No hay necesidad de ser extremo en ningún punto, ni ser “pro-interfaces” ni ser “pro-consola“, aquellos que son “pro-interfaces” saben que a menudo (y más frecuentemente de lo que quisieran) necesitan de una consola, y aquellos que son “pro-consola” seguro que tienen instalado un interfaz gráfico donde impera KDE o Gnome o incluso XFce o WindowMaker.

Quiero dejar claro que trabajo a diario con interfaces webs, por lo que conozco bastante FreePBX, Asterisk-GUI y otros interfaces generalistas de facturación, de grabación y algunos otros, menos conocidos, que considero proyectos perfectos para la función que deben tener: un sistema de comunicaciones pequeño, bien controlado, bien configurado y sabiendo qué hacen y cómo lo hacen además hacer lo que debe hacer. Este artículo va en otro sentido, y no critico ningún proyecto opensource que, como siempre dijo, merecen todo mi respeto y admiración tanto por parte de sus desarrolladores como el de sus usuarios.

Cuando hablo de “editar tus propios archivos de configuración” me refiero principalmente a crear tu propia configuración a mano, y no crearlo utilizando un interfaz web, no significa que la configuración deba ser mediante archivos de configuración, también puede ser vía base de datos o cualquier otra forma de configuración que permita realizar cualquier acción que deseemos o necesitemos y podamos controlar a la perfección tal y como a continuación explico.

Vamos a entendernos…

Como usuario y desarrollador de Asterisk, me encuentro a diario con necesidades de todo tipo, desde personas que conocen Asterisk, hasta auténticos profanos en la materia que lo mismo les dá si tienen un Asterisk como una lavadora mientras hace lo que tiene que hacer. Es por esto por lo que en muchas ocasiones me encuentro en la tesitura de tener que acceder a los sistemas Asterisk de otras personas para configurar una tarjeta, un gateway, un proveedor IP o simplemente añadir un usuario y configurar un teléfono. Normalmente, el acceso se hace mediante SSH (lo cual facilita la tarea, el tiempo y por lo tanto, el coste de la intervención) y en otras ocasiones, el usuario lo que tiene es un interfaz web de gestión (generalmente FreePBX o sucedáneo) donde, a pesar de rellenar todos los campos correctamente (y que el cliente no tiene ni idea de para qué sirve la mayoría de ellos) la tarjeta/gateway/proveedor no funciona como debería y toca acceder manualmente a los archivos de configuración y añadirlo a mano (lo que se traduce en tiempo desperdiciado en configurarlo vía web, dando vueltas buscando el problema, para al final acceder directamente al archivo y hacerlo manualmente).

Cuando vi por primera vez FreePBX (cuando se llamaba Asterisk@Home), me dí cuenta que muchos usuarios lo instalaban porque no sabían cómo funcionaba Asterisk y este interfaz “facilitaba” su configuración añadiendo un interfaz gráfico, mostrando campos y valores que el usuario debía rellenar utilizando su ratón y un dedo para pulsar teclas. También descubrí que en el interfaz no estaban todos los campos que hacían falta y que, además de ser más lento rellenar un formulario web que escribir texto, este generaba un código demasiado complejo y anti-intuitivo para ser interpretado por alguien que “había instalado el interfaz web para tener su primer contacto de una forma fácil y aprender”, algo que prácticamente nadie ha conseguido y el que lo ha hecho así, ha perdido un tiempo precioso en aprender a configurar Asterisk de una forma seria y organizada en lugar de aprender a interpretar macros que asignan valores a variables que son consultadas si alguien hace una llamada internacional y tiene marcado en el interfaz un checkbox.

Configuración orientada a todos y a nadie

Lo primero que hay que entender, es que un interfaz web tiene como objetivo “simplificar” la configuración de un sistema, tomando ciertos valores con los valores por defecto cuando no es necesario o cuando el valor por defecto es correcto. Esto es así en cualquier interfaz web tipo “front-end” de configuración. Si el interfaz web fuese tan completo que permitiese configurar TODOS los parámetros necesarios, entonces no tiene sentido, ya que los conocimientos que hacen falta para configurar la aplicación serían los mismos que para configurarlo vía web, por lo tanto:

Un interfaz web no tiene TODAS las opciones que podemos configurar, por lo tanto un sistema que ha sido configurado vía interfaz web, no es tan potente ni flexible como uno configurado a mano vía archivos de configuración.

Hasta ahí, creo que queda claro que no sólo no vamos a disponer de todas las opciones si no que además, en el caso de Asterisk, se tomarán ciertos parámetros por defecto, por lo tanto, como en el interfaz no tenemos la opción ‘allowguest’, el sistema (salvo que los desarrolladores indiquen lo contrario) utilizarán el valor por defecto. Vamos a ver cual es:
    allowguest = yes|no : Allow or reject guest calls. Default is yes.

Así que, por defecto, nuestro sistema va a procesar las peticiones SIP entrantes sin necesidad de autentificarse.
<ironic>Es estupendo</ironic>

Ojo, que soy de los que defienden tener un sistema abierto para recibir llamadas SIP sin autenticar para recibir llamadas por SIP, pero esto es otro tema que pocas personas hacen y ya hablaré en otro artículo.

Por suerte, las últimas versiones corrigen este parámetro (pero esto no siempre ha sido así, y la mayoría de los usuarios de interfaces como FreePBX no cambian este parámetro, por lo tanto, dejan la puerta abierta a cualquier petición de llamada a Sierra Leona hecha por parte de una persona que vive a varios cientos de miles de kilómetros de distancia).

Un interfaz web para gestionar un Asterisk como FreePBX sigue la misma filosofía que un interfaz web para gestionar un enlace biónico de compensación molecular en el LHC: Debes saber qué estás configurando para no causar una catástrofe. La parte gráfica puede parecer más intuitiva, pero si no sabes para qué sirve cada opción, lo mismo da lo que estés configurando.

¿Un interfaz web para gestionar el Asterisk de una empresa, es igual al interfaz web para gestionar el Asterisk de un callcenter, el de un proveedor IP o el de una casa?

Rotundamente NO.

Es necesario un interfaz diferente en función del tipo de empresa o instalación que vayamos a configurar.

Son necesidades distintas, son configuraciones distintas y por lo tanto, no todo vale y hay que saber distinguir para qué sirve cada cosa. Por este motivo, la gente de Elastix se dieron cuenta de este concepto e incluyeron una parte específica para callcenter.

¿Qué ventajas tiene editar los archivos a mano?

Soy plenamente consciente que editar un archivo, pese a ser una de las acciones más antiguas y todavía existentes dentro del mundo de la informática, hay mucha gente que lo considera todo un misterio y por eso prefieren que una aplicación se lo haga todo mucho más fácil.

No obstante, cuando introduces un número limitado de entradas y esperas una salida completamente funcional, es más difícil acertar con lo que realmente quieres.

Por ejemplo: Estamos configurando un gateway, y a la hora de hacer una llamada, el sistema no lo hace correctamente y la llamada no sale.

En el interfaz no aparece ninguna información que nos indique el motivo ¿qué hacemos entonces? Aprovechamos la consola de Asterisk con la esperanza de ver algún error que nos indique el motivo de porqué la llamada no sale.
Craso error, miles de líneas de dialplan se agolpan en la consola como personas frente a la central de venta de entradas para un concierto de Justin Bieber… todas esperando a ser procesadas por tu mente e igual de fanáticas y molestas. xD

Si sólo queríamos procesar un intento de llamada, ¿porqué toda esa cantidad de líneas?

Porque un interfaz web generalista, no sabe qué necesitas y por lo tanto, tiene que estar preparado para cualquier cosa que se te ocurra (dentro de sus propios límites), así que empieza a procesar variables, ver si el usuario SIP que hace la prueba tiene permisos, configurando el DID de salida si el número a llamar es geográfico, móvil o internaciona, realizar condiciones sobre macros por si el número marcado lleva un 4 en el tercer dígito y has configurado tu país de residencia como Afganistan, o si has marcado un *59 número que previamente se ha configurado como “desvío”… o cualquier otra opción sobre el número que hemos marcado para hacer la prueba de salida en un gateway.
Creo que todos nos hemos encontrado alguna vez con este problema, así que no voy a incidir más sobre él.
El problema viene que si queríamos ver el error, vamos a perder al menos 15 o 30 minutos en visualizar todos los mensajes que aparecen por la consola (o el archivo de log) y entender qué está haciendo el interfaz, pero difícilmente veremos el error, porque, para evitar asustar a los usuarios, muchos interfaces “configuran el Asterisk” para que no aparezcan ciertos mensajes o errores por la consola CLI.

En cambio, configurando el sistema a mano, tu controlas todo lo que se ejecuta en cada momento, por lo que al escribir algo como:

exten=>_9XXXXXXXX,1,Dial(SIP/gateway/${EXTEN})

podremos ver en seguida cual es el motivo de porqué no sale la llamada, ya que “por defecto” sí que aparecen los mensajes de error por la consola y sólo hay que esperar que se ejecute una única línea, no miles, por lo tanto, el tiempo de depuración se reduce a menos de un minuto.

Porque muchas veces, el sistema ya viene con herramientas para facilitar añadir fácilmente usuarios, por ejemplo, utilizando plantillas de Asterisk, o bien otras herramientas que ya vimos en la presentación del VoIP2DAY del 2008 sobre trucos para Asterisk.

Por lo tanto, cuando tenemos 400 extensiones o usuarios, cualquiera que edite los archivos de configuración a mano, tardará mucho menos en configurarlas que utilizando un interfaz web:

...
[usuario325](extensiones)
secret=vn4n3ms94.

[usuario326](extensiones)
secret=tiekd934kd
...

Únicamente hay que escribir dos líneas por cada extensión (teniendo una plantilla bien configurada), si no utilizamos el truco del #exec <script>, con lo que terminaríamos incluso bastante antes, aunque claro, para eso hay que saber configurar un Asterisk.

 

Interfaces, sí, pero responsablemente

No todos los parámetros son intuituvos

Pese a todo lo que pueda parecer, no estoy completamente en contra de los interfaces web, de hecho soy partidario a ofrecerle al usuario final un interfaz de gestión (importante a lo de “GESTION”, que no configuración), el usuario no tiene porqué configurar nada, ya que él no sabe configurar el sistema, el debe gestionarlo, entiéndase esto como, añadir un usuario, modificar los datos, cambiar las locuciones, habilitar o deshabilitar las grabaciones o los desvíos, ver a qué número llaman sus usuarios, etc. pero no para configurarlo. ¿Un usuario normal de una centralita sabe para qué sirve el campo ‘reinvite’ en la configuración de un gateway? ¿qué deberá poner ahí? ¿deberá dejarlo por defecto? ¿y si por defecto viene mal configurado?

No tiene sentido un interfaz web, si este no es utilizable de forma intuitiva y sin requerir ningún tipo de conocimiento, y en el caso en que así lo fuera ¿para qué haría falta un profesional como tú que lees estas líneas?.

El problema viene que muchas empresas instalan el único interfaz que conocen, que es gratuito y que tiene actualizaciones periódicas: FreePBX, el interfaz que tuvo que cambiar de nombre por temas legales y que inicialmente se llamaba “Asterisk en casa” ¿os imagináis a una empresa de 4.000 empleados, con altos niveles de seguridad, puertas biométricas, decenas de primarios, y todas las comunicaciones gestionadas por un programa llamado “Asterisk en casa“?

Yo si 🙁

Claro, no todas las empresas que tienen FreePBX tienen 4.000 empleados y una seguridad extrema en sus instalaciones, el resto son empresas pequeñas de no más de 20 empleados y que pueden permitirse que les entre un bot un sábado por la mañana y se dedique a hacer llamadas sin parar a Sierra Leona hasta el lunes por la mañana haciendo un gasto por valor de decenas de miles de euros, por un parámetro mal configurado por alguien que no sabía configurar un Asterisk en condiciones y prefirió dejar la suerte de configuración en manos de un interfaz gratuito y exento de responsabilidades.

Resumiendo

Quizá lo peor de un interfaz, no sea la configuración generalista que ejecuta 1200 líneas para una llamada entre usuarios SIP, ni los errores de seguridad que cuando se presentan son terribles, quizá lo peor no sea incluso la cantidad de tiempo que hay que perder para configurar una instalación en condiciones de unos 50 o 60 teléfonos, 2 gateways y un proveedor IP, lo peor de estos interfaces webs, es que el 90% de las empresas que no saben de Asterisk y se dedican a comercializar sistemas “profesionales”, lo utilizan.

Lo utilizan vendiéndolo como “sistema para que el usuario tenga el control completo“, pero en el fondo suelen ser empresas que no saben de comunicaciones, no saben de Asterisk y no saben de SIP lo suficiente para configurar el sistema convenientemente para su cliente, por lo tanto, cuando hay algún problema no saben resolverlo y eso da mala fama a los que trabajamos con Asterisk.

La prueba más conveniente de lo que digo es cierto, es que los alumnos que han asistido a un curso de Asterisk, que inicialmente suelen utilizar interfaces web como FreePBX para configurar su Asterisk, al salir del curso y aprender cómo se configura un sistema vía archivos de configuración, no vuelven a utilizarlo jamás, es más, suelen programarse sus propios interfaces web, esta vez orientados a sus clientes y son capaces de resolver los problemas que se presentan porque conocen cómo funciona el sistema por dentro.

Nota final

Por supuesto, en todo hay excepciones y profesionales que utilizan interfaces web generalistas pero que conocen perfectamente cómo funciona por dentro Asterisk y son capaces de resolver cualquier problema que pueden presentarse, pero un 5% de los usuarios no es una cantidad suficientemente importante como para evitar generalizar.

 

9 Comentarios

  • Hola Elio,

    Es mi primera participación en tu excelente blog. Lo sigo desde hace tiempo, pero hasta el momento no me había atrevido a aportar algún comentario. Aquí tengo uno desde mi particular punto de vista:

    Si bien tienes toda la razón sobre lo de que configurar a mano es mejor porque tienes control total sobre lo que estás haciendo (y algunas tareas las haces más rápido), debo decir que las interfaces me han reducido mucho el tiempo de soporte para mis clientes, ya que me ha permitido estandarizar mejor las características a ofrecer y también la manera de atacar ciertas problemáticas (casos “extras” que los clientes piden y que las interfaces no te permiten hacer). Al tener al 90% de mis clientes con una interfaz estandarizada, mi base de conocimientos es más centrada y cuando alguien me pide algo nuevo, es muy probable que ya haya hecho una personalización similar para alguien más.

    En los cursos de Asterisk que doy frecuentemente recibo la pregunta: “¿Recomiendas utilizar interfaces gráficas?” a lo que respondo “Si, puedes usar la interfaz para hacer el 90% de las cosas que comunmente necesitas, pero para el 10% restante DEBES aprender a configurar Asterisk a mano para que sepas lo que estás haciendo al modificar los archivos directamente”. En mis cursos es solamente CLI, CLI y más CLI, porque de otra manera siento que las personas se acostumbran a solo picar botones sin nunca poner atención a lo que están haciendo. Al final, si terminan usando Elastix/Trixbox o lo que sea, tendré la esperanza de que al menos ya saben lo que están haciendo.

    Obviamente sé que las interfaces no son para todos. Un mini carrier que ocupe Asterisk no tiene uso para la interfaz porque lo que quiere es rendimiento y no que el plan de llamadas ande dando vueltas (yo sé que Asterisk no da mucho comparado con OpenSIPs o FreeSwitch, pero mi punto se entiende). Pero como dices tu, para mi este es el 5% de los clientes, y para el otro 95% creo que es más sencillo cortarlos lo más parecido al molde original, y ya solo mover los archivos de configuración a mano para las personalizaciones específicas de cada uno.

    Sobre el tema de la seguridad, es obvio que no puedes garantizar la seguridad cuando usas un software que tu no hiciste, pero creo que si sigues las buenas prácticas puedes aprovechar las bondades de una interfaz sin preocuparte de que alguien quiera llamarle a sus primos en Somalia o Cuba con tu equipo.

    Al final, creo lo que importa es la habilidad del que configura más allá de las limitantes o características de la interfaz, ya que si es un conocedor el que lo hace, sabrá que hay tareas más rápidas para hacer en un lado y otras más rápidas en otro, por lo que sabrá balancear adecuadamente para lograr el máximo trabajo con el mínimo esfuerzo (que creo que es la regla general de los ingenieros)

    Saludos desde México,

  • Hola Christian, me alegra que te hayas animado a participar. 🙂

    Dices que un interfaz te reduce el tiempo de soporte para tus clientes, y me parece genial, pero no llego a entender una cosa ¿en el tiempo de soporte está comprendido el análisis de lo que ocurre? analizar el problema, ver el código, la salida de la consola, ver el error, todo eso entra dentro del tiempo de corrección y es 1000 veces más cómoda de analizar, una configuración hecha a mano, que una configuración como la que ejecuta FreePBX (por poner un ejemplo).
    Entiendo que, una vez estandarizado todos los clientes con el mismo interfaz, el tiempo para resolver el problema, puede reducirse, pero me cuesta creer que tardes menos en solucionar un problema con FreePBX que con una línea de comandos y tu propia configuración.

    Por otro lado, estoy completamente de acuerdo que no es lo mismo un interfaz para un carrier (SIPWiseCE por ejemplo) que para una empresa (FreePBX) son necesidades distintas, aunque te puedo decir que conozco más de un carrier que utiliza FreePBX para gestionar a sus clientes. Esta gente controla mucho de FreePBX, de eso no hay duda y seguro que gracias a su experiencia, solucionan cualquier problema en muy poco tiempo, pero eso no quita que el interfaz “generalista” (vuelvo a decir) sea la mejor opción.

    Imagínate que pudieras hacerte un interfaz web a medida para todos tus clientes y para ofrecerle un mejor servicio. ¿Seguirías utilizando entonces FreePBX? ¿Tu interfaz tendría las mismas opciones que ofrece FreePBX?

    🙂

  • Bienvenido Cristian….holas elio como vas!!!!
    Excelente aporte, realmente me sentí totalmente de acuerdo con lo que dicen los 2…
    Elio es totalmente cierto 95% no tienen ni idea…y si la solución muchas veces es una nueva GUI…ejemplo Dream PBX, mirenla que está muy buena…la pega…no es GPL….pero bueno es muy intuitiva y vale la pena como intermedio…
    Cristian es totalmente cierto tambien lo que dices…no nos olvidemos las máximas, estrategia KISS y que +seguridad = – operatividad por lo cual es un excelente balance….
    EN mi caso siempre hibrido…FreePBX como interfaz para lo simple..y tocar a mano para lo realmente interesante que expanda al freepbx…UN gran saludo a los 2!!! Discusiones de este tipo enriquecen muchisimo el blog…

  • Cristian, Fernando, una consulta ¿Ustedes les permiten el acceso a sus cliente a FreePBX?, si es asi, esto no seria un riesgo ya que podrian cambian parametros importantes de la central, y como dice Elio con una interface a la medida los usuarios no podrian hacer esto.

    Saludos

  • Julio,

    Yo le permito a mis clientes el acceso solo cuando el proyecto se basa en una instalación y no me contratan póliza de soporte. Sé que quizá suene un poco cruel pero si ellos solos tiran su equipo por hacer cosas que no resulta mejor para mi, porque el cobro se hace por evento y no por servicio, de manera que mientras más arruinen, más trabajo hay. Cuando hay póliza de por medio es al revés: el acceso se cierra y si necesitan un cambio, me deben levantar un ticket y uno de nuestro personal los atiende.

    Elio,

    Sobre lo que dices, en efecto, debuggear con FreePBX es más difícil que si yo hubiera hecho el código. Sin embargo, con la experiencia he comprendido la arquitectura del FPBX bastante bien e identifico las partes fácilmente. Casi estoy seguro de que no falla (casi), asi que confio en el código la mayoría de las veces y no veo razón para debuggear el proceso, sino la entrada de los datos, y ahí es donde casi siempre está el error. Aún así y para ser más específico, lo que me refería es que si todos los clientes tienen lo mismo, aún y cuando me tome minutos más aprender o entender que fue lo que salió mal, queda hecho y aprendido para el que sigue, por lo que el siguiente cliente con el mismo problema (y la misma interfaz), será atendido en menos tiempo.

    Ese tipo de trucos que se van aprendiendo con el tiempo son el tipo de cosas que publico en mi blog de manera periódica, conforme voy encontrando pequeñas soluciones a grandes problemas que sin experiencia, no tendría.

    Un saludo a todos,

  • Que buen post Elio, mi caso es particular me toco aprender como se comportaba y que era freepbx y a2billing, luego aprendi asterisk y pude entender mucho mejor que hacia cada macro y todo el “enredo” de la GUI y ahora soy ECE e instalo Elastix, que con sus ” posibles fallos” es en mi caso particular una muy buena alternativa.

    En el diario trabajar con GUIs es necesario saber tocar a mano los .conf y tambien saber que hace cada proceso, pero como dice Christian cuando uno come esto se hace mas sencillo entender los fallos, errores, etc. y esto lo complementa unas buenas practicas en reforzar la seguridad, porque es finalmente el profesional que instala el que permite fallos que cuestan dolares a cualquier empresa.

    Lo ideal seria darle a cada cliente lo justo, pero esto demandaria tambien mucha personalizacion y desarrollo por parte de nuestras empresas, tu mismo en dias pasados mostraste interfases personalizadas y justas para que el cliente cambie una clave o agregue un usuario estandard, que bueno seria contar con 3 o 4 plantillas para ello, pero eso esta muy lejos!

    Muy objetivo tu articulo Elio y como siempre gracias por tus buenos aportes a la comunidad, muchos saludos!

  • Elio,
    Primero agradecerte por el excelente articulo, por el aporte a la comunidad y por aguantar mis repetidos y cansadores pedidos de este articulo.
    Este es un tema caliente, siempre es un debate entre colegas, normalmente hay muchos proconsola y otros prointerfaces.
    Abordaste el tema excelente ya que va mostrando todos los puntos a tener en cuenta.

    Por mi lado empece con trixbox, no sabia ni de donde salian las cosas, lo configuraba, pero no sabia, y eso me molestaba, por lo que empece con asterisk puro y me cayeron mil fichas en mi cabezota y al mismo tiempo se me abrio la cabeza a no solo pensar lo que se podia hacer con la interfaz, despues de eso la unica interfaz que utilizo es elastix. O sea asterisk puro o elastix. O elastix con toques propios cuando es necesario.

    Pero vamos por partes, toda interfaz web es un punto a tener muy en cuenta al implementar seguridad, SIEMPRE va a ser mas vulnerable la plataforma si tiene interfaz web (ahora empiezan los prointerfaces a matarme,:) ) por el simple hecho de que existen diversos ataques que se pueden utilizar. Le pueden decir backdoor o como quieran. vamos a un ejemplo, configuraste todo dentro de lo normal, o sea no a nivel paronoico como debe ser, :), no permitiste llamadas anonimas, a nivel sip rejectas todo lo que no sea una ip autenticada o sipuser, en el plan de discado no permitis ninguna de las llamadas a esos lugares que alguna vez te nombraron en la escuela, limitaste canales, iptables, fail2ban, etc (para no aburrir), pero como el cliente quiere ver sus reportes o en su defecto le habilitaste lo web (ahora que no empiecen a decir que ninguno lo hace, o utilizan webmin??????????? eso en mi opinon esta mal) entran al tmp del centos que tiene permisos de ejecucion con un php inyection que te muestra toda la info de los troncales, extensiones, (bug freepbx). Si en un troncal tenes configurado un proveedor ip, sacan esos datos y lo utilizan desde otros lugares, y el resto de tu buena configuracion queda cuidando el espacio….
    Nota: Siempre pedir al proveedor ip que valide por ip o si no es posible que solo deje que la cuenta sip se registre desde una ip fija publica, para eso un enlace dedicado.

    Con respecto al funcionamiento Asterisk puro va a hacer lo que vos le digas(para bien y para mal) lo que vos indiques, para mi es mucho mas facil ver el error, en vez de estar viendo 1.500 lineas. En eso te admiro Cristian o a mi amigo Ludwig, si ya sabes a la perfeccion todo lo que puede tirar Freepbx, de primera, digamos que no es lo normal :).
    O sea cuando llevas un tiempo ya reconoces los errores comunes, pero a mi me pasa que hay errores que me llevan tiempo, y tenes que ver una cadena de cosas, googlear, etc.

    A nivel performance para grandes cantidad de llamadas simultaneas etc, sin dudas asterisk puro.

    Lo mejor seria tener tus propias GUIs, si es cierto, se necesita tiempo, y en eso no hay nada que rebatir. Nada mejor que lo uno pueda programar.

    Por el lado de la instalacion con elastix se puede hacer muy rapido, generas las extensiones en el csv utilizas el batch para cargarlas, despues utilizas el provisioning para los equipos, tiene cosas muy buenas que te ayudan a una instalacion muy rapida, en eso no estoy de acuerdo Elio. He utilizado plantillas y son fantasticas pero a mi me resulta mas rapido la interfaz.
    Las vistas para los usuarios es una de las mejores cosas de elastix, ya que le podes decir que le permitis ver y ejecutar a cada nivel de usuario.
    Darle el acceso a los clientes a la configuracion es un peligro.

    En consecuencia, hay clientes con los que utilizo asterisk puro y otros elastix. Segun como sea el proyecto.

    Por ultimo es un lujo este tema y los que intervienen, ya que Cristian en su sitio hizo 2 estudios de la cantidad de elastix que estaban por default o que tenian vulnerabilidades (reconozco que el primer articulo me puso de muy mal humor). Pero fueron muy buenos, el segundo me puso de mejor humor 🙂
    Las distros basadas en asterisk son muy vulnerables, porque el problema es el que las configura, y despues todas las fallas que pueden tener, pero primero la capa 8. Elastix puede tener sus fallas, pero las responsabilidad de la seguridad es del proyecto o de la empresa en este caso Palosanto y el implementador.

    Muchas veces dar todo tan masticado trae sus problemas y eso se puede ver en las listas de elastix como en la asterisk-es. Tambien se puede ver que al tratar de automatizar tantos procedimientos y operaciones, muchos no saben ni que es lo realmente estan haciendo.

    Elio ya anote el proximo tema que dijiste que ibas a escribir 🙂

    Muchas gracias

    Saludos

  • Buen post. En los 7 años que llevo usando Asterisk, que por cierto la primera vez me tardé 2 meses por allá en el 2004 en compilar mi primer Asterisk por lo cuál toda la configuración la hice a través de archivos de configuración -ahora hasta le he metido mano al código algunas veces fallido otras exitosas- posteriormente en el 2006 fue cuando probé FreePBX, todo instalándolo sobre un Ubuntu, posteriormente probé Asterisk@home => tribox, Elastix, PBX in a Flash, etc, pero no me convencieron y hasta la fecha tengo mi propio script para instalar Asterisk from Scratch en Ubuntu Server. Definitivamente los extremos nunca son buenos, creo que un GUI es suficiente para un usuario final que generalmente solo la usan para reportes, pero definitivamente la consola es la herramienta para el soporte,en mi caso en todos los PBX ofrecidos les instalo un cliente VPN con lo cuál de forma remota tengo el acceso SSH, Web, SIP, etc así me es más fácil depurar cada instancia que solicite el cliente.

  • Hola elio comparto mucho tu artículo, casualmente me toco lidear con un cliente que otras personas le habían puesto un FreePbx y se los dejaron mal configurados y daba un error fatal en la interfaz y bueno el cliente no sabia que hacer, luego instalaron un Elastix pensando que todo iba super bien y me llamaron, les comente la posibilidad de usar debian + asterisk y dejar todo listo, para no hacer tan largo el cuento, una vez resuelto un problema con el Telco y una E1, procedimos a configurar el Elastix y al reiniciarlo dejaba de levantar el chan_dahdi.so, sin ninguna razon, dmesg no daba error el log tampoco y el debug menos, por alguna razón dejo de funcionar, se corrió un backup realizado y funciono bien se reinicio la compu para montar unas tapas y ya dejo de levantar el chan_dahdi de nuevo sin ninguna muestra de error, eso ya tirando domingo 6 de la tarde, le dije a mi cliente mira tengo un debian con asterisk ya instalado y montado incluso con asterisk-gui porque querían administrarlo ellos sin nuestro soporte,y lo montamos y listo, santo remedio, es un poco de lo que me paso hace unos días. Quería compartirlo con ustedes pues son de mucha ayuda.

    Saludos Elio y demás integrantes de este hermoso blog

Dejar un comentario

Archivos

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales