Sinologic

Etiqueta: desarrollo

  • Recomendaciones básicas de seguridad en desarrollo

    Hace unos días, leyendo un tweet en X, leí a una persona que denunciaba que le habían robado todas las cryptomonedas que tenía en su wallet. Esta persona es alguien técnica (se dedica a la informática profesionalmente), es decir, con conocimientos informáticos suficientes como para no haber sufrido nunca a nivel de seguridad a este nivel. En este tweet (que podéis ver abajo), explica paso a paso qué le ha ocurrido y cómo evitar que nos pase a los demás:

    La lectura está orientada principalmente al tema crypto (criptomonedas y trading de monedas digitales) no obstante, como siempre me gusta ver los problemas desde varios ángulos, me dí cuenta de un problema que posiblemente a alguien más le puede ocurrir, y si con esta llamada de atención se pueden hacer algunos cambios que mejoren la seguridad de todos, mucho mejor… 😉

    Resumiendo el enorme hilo (que recomiendo leer completamente), una extensión (del interfaz de desarrollo Cursor) logró acceder al archivo .env, enviar su clave privada al atacante y éste vació su wallet en cuestión de horas. La pérdida fue poca (apenas unos cientos de dólares), pero éste incidente evidencia cómo incluso los más cuidadosos pueden caer en ataques de cadena de suministro.

    Hay que decir que se recomiendan que las contraseñas se almacenen en variables de entorno, por lo que un .env es un sitio habitual donde se almacenan estos valores, no obstante hoy día, para aplicaciones con contraseñas importantes y muy sensibles, se recomienda utilizar aplicaciones como:

    • HashiCorp Vault (software libre)
    • AWS Secrets Manager
    • Google Secret Manager

    Estos sistemas permiten almacenar de forma segura usuarios y contraseñas a la vez que generan tokens temporales para poder acceder a ellos de forma segura y cifrada. De esta manera, un atacante no tendría acceso más que a un token de un servicio y no a nuestros datos de acceso críticos.

    Uno de los puntos en los que cualquier sistema de desarrollo seguro hace referencia es en la necesidad de «separar entornos«: Esto es: disponer de un entorno de desarrollo, completamente separado del entorno de pruebas y completamente diferente al entorno de producción (además, de otros posibles entornos gemelos y separados 100% para calidad, testeo, etc.). Esto implica que cada entorno debe tener autorizaciones diferentes para que, tanto el desarrollador, como el resto de personas que participan en el desarrollo no tengan nunca acceso a los datos de configuración de producción.

    Por lo tanto y resumiendo un poco… hay que tener en cuenta las recomendaciones:

    • No almacenar claves en .env,
    • Verificar la autenticidad del autor del software y de las extensiones que utilicemos,
    • Usar exclusivamente carteras frías para fondos importantes,
    • Auditar extensiones,
    • Separar entorno de trabajo para hacerlos mucho más seguro,
    • Vigilar periódicamente todo…

    Siempre he dicho que «la seguridad es contraria a la comodidad«. Normalmente trabajamos para solucionar y hacer la vida más sencilla a los usuarios, pero al añadir «seguridad«, esa «sencillez» a veces se transforma en «incomodidad«, no hay más que ver un ejemplo de que, para acceder a cualquier sitio de forma segura, tenemos que acceder utilizando la verificación en dos pasos, y para ello es necesaria una aplicación OTP (One Time Password) lo que implica abrir una aplicación externa (además de introducir usuario/contraseña) algo que no es precisamente cómodo.

    Aún así, los que trabajamos en la trinchera, desarrollando soluciones, a veces tenemos que tomar más medidas de seguridad y trabajar con más incomodidades de las habituales en pos de la seguridad tanto del proyecto como del resto de proyectos de la empresa.

    Siempre que alguien trabaja y protege su sistema únicamente con usuario contraseña me acuerdo de que:

    • La gran mayoría de personas reutilizan sus contraseñas en algunos o en todos los servicios…
    • Alguno de los servicios han sido atacados obteniendo datos como usuarios, contraseñas, etc… https://haveibeenpwned.com/
    • Una contraseña cifrada puede ser descifrada en cuestión de…

    Así que… si alguna vez piensas: ¿debería hacer esto para aumentar la seguridad? la respuesta es siempre SI. Mejor pecar de paranoico a que te roben lo que sea… y es que, el objetivo final es que no nos ocurra algo similar a lo que le ha ocurrido a este hombre. ¿o no?

  • Demasiada información no es control, es desinformación

    Demasiada información no es control, es desinformación

    Hace unos años, participé en el desarrollo de un proyecto piloto consistente en crear un producto desde cero, partiendo de una supuesta solución ante un determinado problema y orientado a un nicho muy concreto, aprovechamos algunos nuevos conceptos y metodología de diseño de productos que algunos compañeros habían aprendido, nos pusimos manos a la obra y a poner en práctica aquellas lecciones que más adelante pasaron a ser nuestras también.

    Entre estas metodologías para empezar a pensar en un producto viable, se encontraba uno bastante conocido llamado «Design Thinking» y basándonos en este sistema elaboramos una serie de características para un nuevo producto que, de no haber utilizado este sistema, y basándonos únicamente en nuestra experiencia y conocimientos, hubiera sido muy diferente.

    El resultado, años después, fue un software bastante bueno, utilizado por muchas empresas de todo el país y con una cuota de mercado mucho más grande de la que imaginábamos en un principio cualquiera de los que participamos en el desarrollo (tanto a nivel de programación, como comercialmente, y como a nivel de gestión y control). El uso de una metodología como Design Thinking nos enseñó a discernir entre «lo que nosotros creemos importante desarrollar» frente a lo que «el usuario considera importante».

    Esta diferencia la he visto antes y después en elementos y características de otros productos y debo decir que ha sido una constante, ya que productos y herramientas que no utilizan este sistema tienen un enfoque muy «técnico» o muy «personal» llevando al desarrollo de ciertas características que nos puede parecer vitales o super-importantes y que realmente el usuario que lo vaya a utilizar apenas le interesa, o todo lo contrario… le interesa pero apenas con la profundidad que esperaba.

    Ejemplo de esto que comento es una característica que seguramente os suena: la información de depuración.

    Alguien quiere un software para gestionar un servidor y cuando lo desarrollamos nos centramos en extraer toda la información posible, almacenarla en enormes tablas y bases de datos para que, llegado un momento determinado, el usuario pueda obtener cualquier información que pueda necesitar.

    Como técnicos y más concretamente como personal de sistemas, solemos estar acostumbrados a guardar logs de todo: llamadas, uso del procesador, memoria, disco duro, cantidad de información leída, escrita, número de hilos, número de procesos, recursos de cada proceso, destinos de llamadas, cuantas llamadas por minuto, y un larguísimo etcétera que se encarga de llenarnos el espacio de disco duro de información que «puede» que algún día nos sea necesaria.

    Si nuestro sistema tiene algún problema, nos alegramos de tenerlo todo guardado, poder sacar gráficas, estadísticas, analizar estos datos y descubrir por qué un proceso ha caído sin ningún motivo aparente pero que, coincidiendo con el elevado y puntual aumento del número de INSERTS en la base de datos, podemos elaborar una teoría consistente en que, cuando se escribe bastante en la base de datos, la aplicación deja de funcionar.

    No obstante, cuando un sistema está en producción y el comportamiento se considera «estable», esta cantidad de información se sigue almacenando, pero pasamos a un sistema paranoico basado en crear alertas por cualquier evento que nos pueda generar cualquier tipo de incertidumbre. ¿Qué pasa si el procesador está por encima del 60%? Quiero que me mande una alerta! ¿Qué ocurre si hay un porcentaje de llamadas no contestadas en la última hora? Quiero que me mande una alerta! ¿Qué ocurre si recibimos más de N peticiones HTTP a la web en menos de N minutos? Quiero que me mande una alerta!

    Cuando todo esto se asocia a un producto software, pasamos a tener un software genera alertas por cualquier circunstancia y es entonces cuando nos empezamos a acostumbrar a recibir alertas, bajando nuestro nivel de atención ante lo que puede ocurrir que sí es importante.

    Se entiende que la capacidad de monitorizar los recursos en un sistema de comunicaciones hasta el infinito puede ser un elemento diferenciador de cara a conseguir usuarios que estén interesados en monitorizar estas características pero ¿y aquellos a los que no les interesa? ¿Realmente es necesario generar gigas de información cuando el usuario no tiene el más mínimo interés o peor aún… no entiende qué es lo que se está informando?

    Somos conscientes que hay que disponer de una importante cantidad de datos de alta calidad para poder tomar ciertas decisiones, de ahí la importancia de saber «reducir» la ingente información que somos capaces de almacenar, en información de calidad que realmente sirva para esa toma de decisiones.

    Pero también es importante de cara a desarrollar productos, entender quién es el objetivo de nuestro desarrollo, el usuario al que va destinado el producto y entender que esa información, más que ayudarle, le está perjudicando en la adaptación. Los desarrolladores solemos cometer varios fallos importantes, considerando que «lo que a nosotros nos interesa, también le interesa al usuario» y por esta razón, creamos opciones, botones, parámetros incomprensibles que a nosotros como desarrolladores nos llevará un tiempo considerable en configurar, y que al usuario jamás le interesará tocar por que, o bien no entiende cómo funciona, o bien necesita otra información más importante.

    En resumen, los programadores debemos aprender que lo que nosotros creemos que es importante, para quien va a utilizar la aplicación, no tiene por qué serlo. De ahí la importancia de contar con otras personas, compañeros que tienen más trato con los usuarios y que sean capaces de hacernos ver qué es realmente lo que el usuario necesita.

    Manejar una ingente cantidad de información nos da el control completo del sistema, pero ese control se vuelve inútil cuando esta información nos bombardea constantemente de alertas que, llegado el momento, no nos sirve para nada ya que las verdaderas alertas importantes y que hay que tener en cuenta, se hallan entre 40 o 50 alertas que de nada sirven.

  • Desarrollo de aplicaciones VoIP

    Desarrollo de aplicaciones VoIP

    El desarrollo de aplicaciones de voz es un concepto muy amplio que engloba desde desarrollos básicos de centralitas, programación de IVR, programación de entornos de red orientados a protocolos VoIP, gestión de paquetes, desarrollo de códecs, criptografía, programación de chatbots, y un largo etcétera que no tendría fin.

    A pesar de esto, y centrándonos en este artículo en un desarrollo básico, vamos a hablar sobre los tres modos de desarrollar soluciones más comunes, utilizando herramientas conocidas por todos: Asterisk, Kamailio y WebRTC.

    En próximos artículos hablaremos sobre otras técnicas y herramientas no tan conocidas pero que nos ofrecerán soluciones diferentes a las que se pueden llevar a cabo utilizando una de estas herramientas.

    Asterisk

    Asterisk nació como un software de centralita, pensada desde un principio como una herramienta software para actuar como PBX: (central de teléfonos) y con opciones incluidas en su código tan básicas como la música en espera (music-on-hold), buzón de voz (voicemail), transferencia de llamadas, grabación de llamadas, colas y agentes, reproducción de locuciones, IVR, etc. No obstante, cualquiera que desee una centralita al uso e instale un Asterisk por primera vez seguramente se encuentre con grandes frustraciones:

    • Nada más instalarlo, requiere de una gran cantidad de configuración para llegar a tener un sistema telefónico que cumpla mínimamente con lo que se requiere en una PBX estándar.
    • Requiere de unos conocimientos básicos nada básicos para alguien profano en la materia que desconoce cómo funcionan protocolos, códecs, dialplan, etc. para llegar a configurarlo de una forma mínimamente decente.
    • No incluye una herramienta que facilite la configuración a la vez que el mantemiento, teniendo que optar por soluciones externas como FreePBX, Issabel o soluciones comerciales.

    Dicho lo cual, Asterisk dejó de ser un «software de PBX» para convertirse en una herramienta para la creación de aplicaciones de Voz (entre lo que se incluye, lógicamente, la creación de sistemas PBX). Gracias a esto, Asterisk hoy día es más conocido entre desarrolladores que necesitan crear su propia solución a medida, que entre empresas que necesitan una PBX tal cual. Y es por esta razón por la que Asterisk se podría considerar una de las mejores herramienta para desarrollar soluciones VoIP a medida, ya que incluye muchos medios y canales con los que poder desarrollar prácticamente cualquier solución que necesitemos.

    Hemos hablado hasta la saciedad de los «interfaces» con los que cuenta Asterisk:

    • CLI (Command Line Interface), que es la forma más básica de acceder a Asterisk desde el terminal de consola y nos permite ejecutar comandos simplemente tecleando lo que queremos.
    • AGI (Asterisk Gateway Interface), un pseudo-lenguaje que nos permite externalizar acciones ejecutadas desde el propio Asterisk. De esta manera Asterisk «ejecuta» una aplicación externa a él mismo, permitiéndole acceder a recursos que, de otra manera, no sería posible al no tener soporte el propio Asterisk.
    • AMI (Asterisk Manager Interface), un puerto TCP al que nos podemos conectar para enviar comandos y recibir eventos de todo lo que sucede en el Asterisk, gracias a un protocolo muy sencillo para cualquiera que sepa mínimamente programar.
    • ARI (Asterisk REST Interface), un interfaz REST que permite tanto a Asterisk como a una aplicación, interactuar con canales, llamadas, usuarios, bridges, etc. de forma asíncrona y utilizando una conexión WebSocket para la comunicación de órdenes y datos mediante JSON.

    Estos son los interfaces con los que cuenta Asterisk para desarrollar cualquier solución que se necesiten. Cada una de ellas realmente tiene ejemplos muy sencillos, pero también verdaderamente avanzados, ya que cualquiera de ellas permite una gran cantidad de posibilidades y flexibilidad para ayudarnos a crear cualquier cosa.
    Pese a todo el potencial que tienen estos interfaces, existen limitaciones en todos y cada uno de ellos. Hay necesidades que los AGI no pueden satisfacer y hay que acudir al AMI. Hay soluciones que el AMI es difícil y es mejor recurrir a ARI y hay necesidades que podemos ahorrar mucho tiempo y esfuerzo si utilizamos simplemente el CLI.

    Kamailio

    No obstante, existen necesidades y proyectos en los que Asterisk no es la herramienta ideal, Asterisk siempre puede ayudar, pero llega un momento que hay que mirar más allá y ver qué otras soluciones se pueden utilizar.

    Por poner un ejemplo rápido y fácil de entender, podemos echarle un vistazo al proyecto HOMER.

    HOMER es una herramienta muy conocida por todos, y cuya función se basa en recopilar, clasificar y gestionar el tráfico SIP, permitiéndonos llevar un control perfecto de todo lo que sucede en uno o varios servidores. ¿Cómo hace esto? Necesita de una herramienta que pueda capturar el tráfico SIP y enviarlo a un sistema que pueda clasificarlo y ejecutar código por cada paquete que le llegue. ¿Qué herramienta hace esto? ¿Asterisk?
    Podría… pero en este caso, un Asterisk manejando un gran volumen de llamadas SIP podría necesitar de grandes recursos, así que la solución que optaron para la versión HOMER 5 fue: Kamailio.

    Kamailio es un servidor SIP PROXY / SIP REGISTRAR / etc. que se encarga de recibir paquetes SIP y procesarlos uno a uno. Al ser una herramienta orientada a esto, es muy, pero que muy eficiente, ya que no ha de manejar el audio RTP, ni hacer grabaciones, ni escuchar tonos DTMF, ni manejar transferencia, ni nada de nada, simplemente se centra en procesar cada paquete SIP que le llega. Por esta razón, un Kamailio es una herramienta supereficiente de procesamiento de paquetes SIP y la herramienta seleccionada por HOMER 5 para esta tarea.

    La idea es fantástica si en nuestro desarrollo necesitamos procesar paquetes SIP (analizar los campos From, To, Contact, PAI, etc.) ya que podremos utilizar el archivo de configuración para programar qué queremos hacer ante cualquier paquete SIP que nos llegue.

    WebRTC

    No obstante, nos estamos centrando en desarrollo de aplicaciones de Voz basados en SIP pero ¿y si nuestro proyecto está por encima de este requisito? ¿Y si queremos desarrollar un proyecto pero no tenemos por qué hacerlo con extensiones SIP? En ese caso, otra de las soluciones que habría que estudiar es una librería muy famosa llamada WebRTC.

    Aunque de WebRTC hemos hablado largo y tendido, hay que conocer bien lo que es para entender bien su alcance. Normalmente WebRTC está asociado a varios términos: Navegador Web moderno y/o softphone web.

    WebRTC es mucho más que esto… aunque suene a descripción de la wikipedia, WebRTC es una librería de herramientas que nos permitirá desarrollar todo tipo de aplicaciones en las que intervenga cualquier tipo de «media» en tiempo real (eso puede ser audio, vídeo o también texto, archivos, captura de pantalla, etc.) utilizando para ello un navegador web.

    No obstante, WebRTC nos permite crear aplicaciones en las que intervengan voz, audio o cualquier otro tipo de dato en tiempo real conectándonos a un servidor mediante WebSockets, lo que nos permite interactuar con cualquier aplicación remota que pueda conectarse vía WebSocket, eso elimina la necesidad de utilizarla «entre» navegadores web y nos abre las posibilidades con prácticamente cualquier otro dispositivo, desde herramientas de IoT, robots, domótica, seguridad, y un largo etcétera.

    Por lo tanto, y aunque soy consciente que la curva de aprendizaje de WebRTC no es fácil, que requiere de muchos conocimientos previos bastante avanzados de Javascript, pero las posibilidades son realmente ilimitadas y son justamente éstas las que nos abrirán las puertas (y las están abriendo ahora mismo) con los nuevos proyectos que están surgiendo hoy día y que facilitarán la vida en los próximos años.

    ¿Conoces otras herramientas que pueden ser prácticas para desarollar aplicaciones, soluciones y proyectos VoIP?
    Anímate y escríbelas en los comentarios.

  • Taller de desarrollo de Kamailio en Alicante

     

    kamailio-world-01

    Daniel-Constantine Mierla, creador del proyecto Kamailio acaba de anunciar que está preparando un taller para aprender a desarrollar en Kamailio en Alicante (España) los próximos días 15 y 16 de Febrero en lo que se ha bautizado como Kamailio Development Workshop.

    kamailio-logo-2015El coste del taller es de 180€ que viene a ser los costes logísticos para realizar el curso (básicamente el alquiler del lugar del evento) y los puntos que se verán son:

    • internal architecture
    • SIP parser
    • memory manager
    • locking manager
    • database API
    • config file language interpreter
    • RPC interface
    • pseudo-variables and transformations framework
    • internal libraries
    • module interface – write your own extensions in C as modules
    • exported C functions and the relations with routing blocks in kamailio.cfg
    • documentation docbook format

    Para más información: http://www.kamailio.org/w/development-workshop/

     

  • Descubre qué incluye el nuevo Asterisk 14

    http://www.sinologic.net/Como ya explicamos en este artículo sobre cómo funcionan las versiones de Asterisk, la versión Asterisk 14 es una versión orientada a incluir nuevas características, lo que se conoce como una versión de «desarrollo» y por lo tanto no es recomendable utilizada en entornos de producción. No obstante, es muy interesante conocer qué características va a incluir para ir desgranándola y viendo las posibilidades que tendrán nuevas y futuras versiones de Asterisk.

    Sobre Asterisk 13, poco qué decir… en mi opinión, es una versión LTS basada en Asterisk 12 pero con características que no terminan de ser todo lo estables que deberían para un entorno de producción. Eso no quiere decir que no se pueda utilizar Asterisk 13 en un entorno de producción, pero las características más importantes de Asterisk 13 (PJSIP, ARI, Codec Negotiation, SIP sobre Websocket, etc…) aún no son todo lo estables que a mí me gustaría para un entorno en producción. Ahora bien, si no se utilizan estas características, el sistema es similar a Asterisk 11 con las ventajas de una versión superior, por ahí todo perfecto.

    Con Asterisk 14 volveremos a la senda del desarrollo de nuevas características y eso me choca, ya que soy consciente que muchos usuarios de Asterisk tampoco utilizan las nuevas características de Asterisk 13 por lo que continuar añadiendo nuevas características a Asterisk sin conseguir que la comunidad asimile las características de Asterisk 13 creo que es un error, no obstante, la lista de características ya es pública, así que vamos a ver en qué consisten:

    (más…)

  • Elastix Market: el espacio disponible para la comunidad

    Elastix-addons-module

    Desde la versión 2.0 de Elastix, se introdujo un espacio dedicado a lo que se conoce como «aplicaciones de terceros«, un lugar donde usuarios, desarrolladores y empresas tuvieran una forma de publicar aplicaciones que interactuaran de alguna forma con Elastix y sirviera para concretar el uso que un usuario le daba a su sistema de comunicaciones.

    Ese espacio se rige por el conocido sistema de publicación «dictador benevolente«, y es que es PaloSanto (la empresa que hay detrás de Elastix) la que comprueba cada aplicación y admite o rechaza los addons que estarán disponibles en el Elastix Market. Un sistema que aunque inicialmente puede generar bastante desconfianza, es el modelo típico que utilizan otros Markets como la AppStore de Apple, Google Play, y cualquier otro.

    (más…)

  • Estado del proyecto Asterisk 12 y petición de colaboración

    developers

    Matthew Jordan, coordinador del proyecto Asterisk, acaba de enviar un mensaje a toda la comunidad de usuarios con el estado actual de lo que será el nuevo Asterisk 12.

    Hola a Todos!

    Ha pasado algún tiempo desde la última actualización del proyecto, y ya que estamos en la recta final de Asterisk 12, sentíamos que era el momento para otra actualización. Como un vistazo general al estado de las cosas, todo el trabajo que se hace ahora para Asterisk 12 consiste en la resolución de problemas y documentar las novedades en las páginas del wiki. Hay todavía muchas cosas por hacer y muchas oportunidades para participar y colaborar. Si estás interesado, te animamos a que preguntes en #asterisk-dev o en la lista de correos de Asterisk-dev.

    Tenemos tareas y cosas por hacer para todo tipo de participación, muchas de las cuales requieren diferentes niveles de esfuerzo, así que si te parece bien y quieres contribuir, no te preocupes, seguro que hay cosas que puedes hacer.

    . . .

    Nuevo canal SIP

    . . .

    API unificada

    . . .

    Bridging Framework

    . . .

    Estoy seguro de que me estoy olvidando de cosas, y como se puede ver, hay mucho trabajo que hacer. Como mencioné anteriormente, la colaboración y ayuda siempre es de agradecer – probando la versión, desarrollando, documentando, o simplemente proveer ideas y opiniones. Está quedando bien, pero todavía nos queda mucho camino por recorrer, y cuanto más la colaboración que recibimos, tanto mejor será Asterisk 12.

    Puedes ver el mensaje completo y original aquí:
    http://lists.digium.com/pipermail/asterisk-dev/2013-May/059848.html

    A colación con el artículo anterior sobre «Qué versión de Asterisk instalar«, es evidente que, el hecho de que Asterisk 12 sea una versión orientada a características nuevas, es algo muy atractivo para los desarrolladores y la comunidad de usuarios ya que nos permite ver y probar nuevas posibilidades, pero el hecho de que pidan ayuda para desarrollar o para muchas otras tareas, es algo no muy frecuente en este tipo de proyectos tan grandes y que cuentan con tantos apoyos.

     

  • Taller de desarrollo de Kamailio en Alicante

    kamailio

    La empresa Asipto junto a la Universidad de Alicante, organizan un taller de programación de Kamailio los próximos días 14 y 15 de Febrero (2 días de duración).

    Es importante destacar que este taller de dos días no es para aprender a configurar y administrar un Kamailio, si no para desarrollar nuevos módulos, parches, características sobre este sip proxy.

    • internal architecture
    • SIP parser
    • memory manager
    • locking manager
    • database API
    • config file language interpreter
    • RPC interface
    • pseudo-variables and transformations framework
    • internal libraries
    • module interface – write your own extensions in C as modules
    • documentation docbook format

    El coste por persona es de 140€ y aquellos que vayan a asistir también al Kamailio World (el 16  y 17 de abril), obtendrán 30€ de descuento.

    Para más información:
    http://www.kamailio.org/w/2013/01/kamailio-development-workshop-feb-14-15-2013-alicante-spain/

     

  • Asterisk 12: Una API para gobernarlos a todos

    http://www.sinologic.net/Acabamos de recibir el email de la lista de desarrolladores de Asterisk indicándonos que ya está disponible la nueva versión de Asterisk 11.0.0 y mientras tanto, empiezan a hacerse públicas algunas decisiones y debates que tuvieron lugar en la AstriDevCon 2012 sobre la próxima versión de Asterisk 12.

    Saúl ya comentó en su blog algunas de las novedades que traería esta nueva versión (y que esperamos ansiosamente que sean ciertas) como una nueva pila SIP y soporte de MSRP.

    No obstante, por otros medios hemos descubierto una serie de cambios que podrían hacer de Asterisk algo completamente distinto a lo que estamos acostumbrados a ver y, confío que, aquellos cuyo negocio esté basado fuertemente en las características actuales de Asterisk, vayan pensando en adaptarse de una forma rápida a los cambios globales que parecen, van a ser cada vez más frecuentes, o empiecen a crear un fork de Asterisk y mantener su propio sistema, ya que algo me dice que van a cambiar muchas cosas, y muchas de ellas no van a gustar a los que piensan en Asterisk como un sistema base para centralitas.

    (más…)

  • Adiós a Asterisk SCF? Digium paraliza su desarrollo

    Lo bueno del software libre es que cualquiera puede descargar el código fuente de una aplicación, modificarla, mejorarla, arreglarla y publicarla de nuevo: cada modificación forma parte del desarrollo. No obstante, en todo proyecto suele haber una o varias personas que son las que llevan el «liderazgo» de un proyecto, los que confirman los cambios, los que organizan las mejoras que deben aparecer, ya que si cualquiera sube cambios, el proyecto puede acabar en un auténtico desbarajuste caótico difícilmente mejorable.

    Otra posibilidad es crear un fork, una versión paralela en la que dicho liderazgo cambie en la nueva versión, quizá con otras metas u objetivos, quizá con el simple deseo de evitar que el proyecto inicial termine desapareciendo o corrompiéndose.

    Hoy nos hemos levantados con una noticia triste, Digium ha anunciado que no puede continuar con el desarrollo de Asterisk SCF de la misma forma que venía haciéndolo y «como los usuarios de Asterisk están acostumbrados«, lo que implica, no solo que Asterisk SCF pasa a un segundo o un tercer plano, si no que el apoyo de esta solución va a decaer al perder el «liderazgo» del que hablábamos en un principio.

    El agravio comparativo en cuanto a sencillez, cantidad de conocimientos necesarios, etc, con respecto a Asterisk es brutal, por lo que apenas un 0,5% de los usuarios de Asterisk han llegado a instalar Asterisk SCF alguna vez, y de ellos, estoy convencido que muy pocos lo utilizan habitualmente, por lo que, a falta de tiempo y desarrolladores, es preferible continuar con el desarrollo de Asterisk que el de un proyecto que no tiene un público tan numeroso y entusiasmado como Asterisk.

    (más…)