Desde siempre, nos hemos encontrado en el dilema de la elección del ecosistema. Seguro que les suena la eterna batalla: Windows vs. Linux, Mac vs. Windows, etc. Estas decisiones han llegado a los accesorios y aplicaciones que todos usamos y ese dilema de elección ya ha pasado a incluir a prácticamente todo el mundo: IOS, Android, Amazon, Apple, Microsoft, Linux o Google. Está claro que alguien que decide por un ecosistema se va a encontrar con un abanico de ventajas en cuanto a integración con otros componentes (software, plugins, accesorios, dispositivos, etc.) de dicho ecosistema, y también muchos inconvenientes si piensas integrarlo con otros ecosistemas competidores.
La elección de un ecosistema u otro es decisión de cada uno… lo que no es tanta decisión es escoger la forma de comunicarnos, ya que si todos nuestros conocidos utilizan un sistema de mensajería como Whatsapp, básicamente nos están obligando a que también seamos usuarios de esta plataforma. Por suerte, por el momento ser usuario de una plataforma es algo gratuito, pero no lo es tanto si consideramos que nuestros datos son enviados a una empresa o a otra según la plataforma que escojamos. (estamos pagando el servicio con nuestros datos). Por esta razón, Europa se va a poner seria y está planteando una revolución en el ámbito de las comunicaciones al proponer una interconexión obligatoria de las herramientas de comunicaciones mayoritarias que pertenecen a grandes empresas.
Europa va a presentar, dentro de su nueva «Ley de Servicios Digitales y Mercado Digital» varias propuestas entre la que se encuentra la obligación de interconexión de las Grandes Herramientas de Comunicaciones y multas de hasta el 10% de beneficios anuales en todo el mundo en caso de incumplimiento.
Queremos asegurarnos que los usuarios tienen acceso a la libre elección de productos y servicios online y que las empresas compitan libremente. Las obligaciones vinculantes a nivel de la UE se aplicarán a todos los servicios digitales que conectan a los consumidores con bienes, servicios o contenido. El nuevo marco reequilibrará los derechos y responsabilidades de los usuarios, las plataformas intermediarias y las autoridades públicas.
Esta propuesta aborda las consecuencias negativas de determinados comportamientos de las plataformas que actúan como guardias digitales del mercado único. Evitará condiciones injustas para las empresas y los consumidores y garantizará la apertura de los servicios digitales.
¿Cómo?
– Definiendo umbrales cuantitativos para identificar a las empresas gestoras de los datos. – Prohibiendo una serie de prácticas desleales. – Exigiendo a los guardianes que implementen de manera proactiva ciertas medidas. – Imponiendo sanciones por incumplimiento – Permitiendo investigaciones de mercado específicas
Esto, dentro de la idea que propone la Comisión Europea es, que un usuario de (por ejemplo) Whatsapp, pueda conectar y enviar mensajes a un usuario de Telegram o de Slack y que nosotros podamos desarrollar una herramienta que se conecte con todas y cada una de las redes y que nuestros propios usuarios puedan contactar con todos los de otras redes y, lo más curioso de todo: los grandes sistemas deben permitir esa interconexión: Lo que viene siendo: «interconectar las redes de comunicaciones«.
Queremos conocer tu opinión:
¿Crees que esta ley (que seguramente no les haga mucha gracias a las grandes empresas) conseguirá lo que propone Europa?
¿Se podría extender a otros continentes y países para obligar a una interconexión real de las comunicaciones?
¿Crees que permitirá la incorporación de nuevos jugadores que no se atreven a meterse en este mercado debido a la gran ventaja de los jugadores actuales?
A través de un comunicado interno a sus partners de todo el mundo Panasonic anuncia la decisión de cerrar el negocio de todos los sistemas de comunicaciones (PBX) en un plazo de dos años.
Las razones que esgrimen en su mensaje no dejan lugar a dudas lo que venimos anunciando desde hace tiempo, para bien o para mal, el grueso del negocio está en la nube, junto con la reducción de costes, los ahorros en servicios junto con nuevos competidores como Zoom y Teams, hacen que el negocio de vender centralitas en cajas metálicas, cada vez tenga menos futuro.
Esta evolución no es algo nuevo, y muchas empresas seguirán apostando por este tipo de negocios, pero lo que está claro es que un gigante como Panasonic no puede permitirse el lujo de continuar en un modelo de negocio que está en declive y por esto han tomado esta decisión.
Panasonic aguantó todo lo que pudo con un modelo de negocio basado en comunicaciones propietarias y hasta el último momento no dio el salto a centralitas SIP. Por suerte el salto salió muy bien gracias a la gran red de distribuidores y ecosistema que Panasonic tiene por todo el mundo. No obstante, el paso a la VoIP unido a la necesidad de cambio constante hace que este tipo de empresas tengan que flexibilizarse y adaptarse mucho más rápidamente a los nuevos tiempos, creando nuevos productos más modernos y más rápidamente no sólo para atraer a nuevos clientes, si no para evitar que la competencia se lleve a los suyos.
Hace unos días, un amigo me dejó un aparato muy curioso. Por la descripción me recordaba a otros que ya había visto anteriormente, pero cuando me comentó que este aparato es del creador del Snom One (una centralita embebida para pequeñas empresas que sacó Snom hace varios años) consiguió llamar más aún mi curiosidad y le pedí que me lo dejara para echarle un vistazo más de cerca.
El Vodia IO es un dispositivo que incluye:
Un router neutro de redethernet (como centro de nuestra red interna, o acceso a Internet: firewall, gestión de puertos, fibra, adsl, etc.)
Un access point Wifi a 2.4Ghz y 5Ghz
Una base DECT donde conectar teléfonos inalámbricos que sean compatibles con GAP (Generic Access Profile).
Una centralita VoIPmultitenant donde poder configurar no una centralita (un dominio) si no varios dominios donde conectar softphones, operadores SIP y los teléfonos DECT, además de un buen montón de posibilidades de configuración: locuciones, IVR, buzón de voz, etc.
Un equipo muy completo enfocado a una empresa pequeña o mediana (en la que podremos ponerle una centralita independiente a cada uno de los departamentos si lo deseamos, disponer de varios teléfonos inalámbricos y que nos haga de router). Ahora vamos a ver cómo es este aparato super-completo.
Aspecto exterior del Vodia IO
El Vodia IO viene con una fuente de alimentación externa y algunos cables aunque lo que llama la atención es el frontal. Una pantalla frontal donde nada más encenderla aparece la dirección IP para acceder y configurarlo.
La parte delantera ya tiene un buen aspecto, botones que podamos configurar sin necesitar de un ordenador. Tampoco es que vayamos a tocar mucho ahí, pero siempre viene bien.
La parte trasera llama mucho más la atención, ya que ahí están todos los conectores de todo lo que podemos enchufar: – 2 teléfonos analógicos – 2 puertos USB (para conectar en red o labores de mantenimiento) – 4 puertos de red Gigabit – 1 puerto WAN Ethernet Gigabit – 1 puerto de fibra óptica – 1 puerto RJ11 para líneas ADSL
Lo primero que vemos nada más encender, en cuanto conectamos el puerto WAN a Internet, es que el sistema se conecta para actualizarse a su última versión, lo cual puede llevar un buen rato. Se reinicia varias veces hasta estabilizarse en la última versión estable. Es algo que hace por si sólo, aunque se puede deshabilitar y que se actualice manualmente.
Configuración del Vodia IO
Aunque procedan del mismo creador, ni el exterior ni el interior tienen nada que ver con el que tenía el Snom One, salvo una cierta característica en común que suelen tener, en mi opinión, los interfaces de los productos de origen alemán: no se pueden decir que tengan un aspecto visual deslumbrante, un tema moderno con la última tecnología en frontend… pero lo importante es que son robustos y funcionan tal y como se espera.
El frontal deja claro que es un producto alemán, aunque se puede cambiar el idioma
Al acceder podemos tendremos a la vista un menú bastante intuitivo (visto la cantidad de cosas que se pueden hacer) en el que podremos configurar cualquier aspecto típico de un router neutro (rutas, port forwarding, redes wireless, etc.) que además también es wireless.
Por supuesto, este artículo no es sitio suficiente como para explicar cómo configurar este dispositivo, pero sí que hemos grabado un pequeño video donde podemos ver el recorrido del menú y las diferentes acciones que podemos llevar a cabo.
Si bien es cierto que el menú ofrece la posibilidad de trabajar con él en castellano/español, siempre he preferido la versión en inglés porque las traducciones a veces no son lo suficientemente consensuadas como para entender qué hacen o para qué sirven.
Recorrido sencillo por las opciones del Vodia IO
Como podéis ver, éste sistema tiene un gran número de opciones para configurar una centralita estándar (IVR, captura de llamadas, buzón de voz, salas de conferencia, así como cambio de logotipo, subida de locuciones, etc…) pero además, si os habéis fijado en el vídeo, llama la atención algunas características como:
También llama la atención que, si bien utilizamos una empresa (dominio) «localhost«, es posible crear otros, pudiendo utilizar este sistema para ofrecer servicio a varias pequeñas empresas de forma simultánea.
Unboxing Vodia
Frontal
Puertos de conexión
Frontal
Frontal
Pantalla
Vista general
En resumen…
Un dispositivo muy interesante para ciertas empresas que necesiten un todo-en-uno tanto para una pequeña como una mediana empresa que necesite una centralita completa, fácil de instalar, desplegar y configurar.
Si le puedo poner a una pega, no es a este dispositivo en particular, si no a la propia idea de tenerlo todo en un único aparato, ya que en caso de rotura, nos quedaríamos sin centralita, sin teléfonos y sin conexión a internet. Un punto demasiado crítico que nos obligaría a tomar medidas como, por ejemplo, tener otro de respaldo por si el principal se rompe. Un sistema de alta disponibilidad con otro Vodia IO para red, DECT, wifi, etc. (no solo para PBX) sería lo único que le echaría en falta a este aparato. (si lo tiene, no lo he encontrado)
Si queréis una demo, más información o ver alguna característica que os pueda interesar, precios, etc. os animo a que entréis en la página en español Vodia.es y preguntéis ahí.
Siempre he sido de la opinión que no hay que ser un paranoico de la seguridad, simplemente intentar que todo lo que se hace debe ser lo más seguro posible: «La seguridad no es un lema, es una forma de vida» y por esta razón, cuando vi el siguiente gráfico de tiempos que tardaría una máquina en conseguir una contraseña, me entró la curiosidad sobre qué se puede hacer normalmente para evitarlo.
Visto lo visto, con las GPUs que hay hoy día y la potencia de cálculo que tienen los sistemas cloud comerciales, crear una contraseña de menos de 12 caracteres es básicamente instalar una bomba de relojería a la espera de que venga un bot con algo de tiempo y acceda a nuestros sistemas.
Uno puede pensar en contraseñas largas y complejas con más de 15 caracteres, mayúsculas, números, símbolos, alguna coma, un signo dólar y alguna Ñ, pero a la vista de la cantidad de contraseñas que hay que escribir, al final lo mejor y más cómo para evitar repetir la misma contraseña, es utilizar una herramienta que sirva como «llavero» y que contenga las contraseñas que utilizamos, tan grande y complejas como queramos, de manera que no haya que recordarlas.
Herramientas llavero
Suelo utilizar la herramienta KeePass que permite crear varias bases de datos cifradas con las contraseñas que uso para diferentes motivos (empresa, servidores, personal, clientes, loqueseteocurra, etc.) y tras una contraseña maestra para cada base de datos, poder acceder a toda la lista de accesos con total seguridad. Esas bases de datos están en archivos cifrados dentro del sistema de ficheros local, por lo que la seguridad es mucho mejor que tenerlo en un Post-it en el monitor, en una libreta de papel o en una hoja Excel (ya que ésta última no suele ir cifrada).
El problema de este tipo de herramientas es que, cada vez que hace falta acceder a un sitio, hay que abrir la aplicación, meter la contraseña, buscar el acceso que necesitas y gracias al «copy+paste«, poder pegar la contraseña y así, autentificarte de forma segura. No es la fórmula más práctica. (aunque luego explicaré cómo soluciono esto).
2 contraseñas: la segunda, varía con el tiempo
Yubikey con las llaves de casa
No obstante, investigando un poco cómo lo harán en las grandes empresas de seguridad, recuerdo el caso de un amigo que trabaja en Google y que, cuando entró, en el pack de bienvenida, le entregaron además de un montón de merchandising, un portátil y algunas cosas más, una Yubikey: una mochila USB que sirve como sistema de dos pasos automático.
Introduces el login, la contraseña y cuando se comprueba que es correcto, además te pide un código que, en lugar de enviarte un código al móvil, sólo tienes que «tocar» la Yubikey y ésta rellena la parte del código de segundo paso. Si alguien te roba la contraseña no podrá hacer nada, ya que no tendrá tu móvil o la mochila USB para saltarse el segundo paso, y la Yubikey suele ir como una llave más del llavero, por lo que siempre la llevas contigo, igual que tus llaves de casa.
El sistema de autentificación de dos pasos siempre me ha parecido muy interesante desde que hace muchos años (hace más de 13 años) un amigo belga me enseñaba cómo utilizaba la autentificación en dos pasos para sacar dinero de su banco. Un aparato especial le generaba un código que tenía que meter como «segundo pin de seguridad«.
Ahora se ha visto que el hecho de enviar un SMS al móvil no es lo más seguro, ya que hay quien incluso te clona la tarjeta SIM para poder recibir el mensaje y hacerte verdaderos desfalcos (lo que significa que ya tienen tu usuario y contraseña y sólo les para esa doble autentificación), así que me puse a mirar el sistema de Google para el tema de generar el código necesario.
A falta de tener una Yubikey de esas para hacer pruebas, tengo un móvil con el que generar los códigos de segunda autentificación, y una lista interesante de servidores personales y máquinas a las que accedo normalmente por SSH, voy a ver cómo dotarla de algo más de seguridad.
Autentificación de dos pasos para acceder por SSH al servidor
Para ello, se me ocurrió usar la doble autentificación (o autenticación, que es lo mismo) en el acceso SSH, lo único que, en lugar de enviar un SMS, voy a utilizar una aplicación en el móvil que genere un código de seguridad válido gracias a un token.
Para esto existen dos aplicaciones comunes: GoogleAuthentication y FreeOTP(las dos funcionan igual, aunque utilizaré FreeOTP por ser software libre y darme algo más de confianza).
Lo que vamos a hacer será configurar el sistema de acceso por SSH, de manera que una vez introduzca la contraseña, se añada una verificación extra (de ahí lo de «los dos pasos») que me solicite un número variable que sólo tendré yo gracias a la aplicación FreeOTP.
1. Instalación de los paquetes necesarios
Para configurar esto en una Debian, lo primero es instalar un paquete básico:
Este «libpam-google-authenticator» es uno de los módulos del sistema PAM (Pluggable Authentication Modules) de manera que se ejecute después de la autentificación estándar para poder permitir el acceso.
2. Configuración del SSH y del PAM
Acto seguido, vamos a editar el archivo de configuración del demonio SSH /etc/ssh/sshd_config para decirle que queremos utilizar el sistema de módulos PAM. Para ello, nos aseguramos que tenemos estas opciones habilitadas:
UsePAM yes ChallengeResponseAuthentication yes
Nada más asegurarnos de esto, editamos el archivo: /etc/pam.d/common-auth donde añadiremos las siguientes líneas:
# Autentificacion OTP mediante Google Authenticator auth required pam_google_authenticator.so
3. Instalar la aplicación FreeOTP o GoogleAuthenticate.
En mi caso, utilizo FreeOTP que es software libre y se encuentra tanto en Google Play como en la App Store.
Una vez instalado, y ejecutado, hay que dar permisos para utilizar la cámara, ya que tendremos que escanear un código QR que nos saldrá por pantalla con el «token» del servidor al que nos vamos a conectar y que se utilizará para generar las contraseñas en función del tiempo.
Ahora bien, nos logueamos por SSH con el usuario que queramos y ejecutamos el comando:
~$ google-authenticator Do you want authentication tokens to be time-based (y/n) y
Tras esto, nos saldrá por pantalla un código QR que tendremos que escanear desde nuestra aplicación.
Le decimos que «yes» a todo… y guardamos bajo llave los códigos de «emergencia» por si no tenemos nuestro móvil a mano para generar la clave. (Estos códigos sólo se pueden utilizar una vez cada uno, por lo que hay que guardarlos muy bieno volver a generar el token)
4. Reiniciar el servidor para aplicar cambios
Vale, nuestro usuario ya tiene habilitado el token de seguridad, ahora lo último que tenemos que hacer es reiniciar el servidor SSH para que utilice el sistema PAM con el módulo que hemos añadido.
~$systemctl ssh restart
5. Comprobamos el acceso
Ahora que ya está todo funcionando, volvemos a acceder con el mismo usuario que hemos activado el token y veremos que una vez introducida la contraseña, nos pedirá un código.
En este momento, habrá que buscar el código en la aplicación.
Captura del FreeOTP
Tendremos 30 segundos para introducir el código tras lo cual, tendremos acceso al sistema.
En resumen
Vale, lo primero… muy intuitivo no es, y rápido tampoco, pero si es más seguro que un acceso normal.
El hecho de tener que acceder a una aplicación del móvil para poder acceder a nuestra cuenta, no es algo que sea muy práctico si nos pasamos el día accediendo a ella, de ahí la utilidad de la Yubikey. Para este tipo de cosas está la autorización de llave pública y de esta manera evitamos tener que meter contraseñas (incluso utilizando la autentificación que hemos visto) y accedemos rápidamente al sistema que queramos validando directamente la clave de nuestro ordenador con el servidor.
Por lo que, para sistemas en los que necesitemos un extra de seguridad, seguramente sea una buena fórmula.
Si aplicamos este sistema (OTP – One-Time-Password) a otros servicios, posiblemente aumentaremos bastante la seguridad. Como decía al principio, la idea no es ser un paranoico de la seguridad, si no aprender a ser seguros en todo lo que hagamos.
Hace algún tiempo avisamos que Sinologic no publicaría noticias relacionadas con seguridad. Principalmente porque uno debe ser responsable de estar al día de todo lo que surge en cuanto a vulnerabilidades, fallos de seguridad, etc. Por este motivo, todos deberíamos tener en nuestras pantallas un sistema tipo «telex» que nos informe en tiempo real de los problemas que ocurren.
No obstante, y por diversos motivos y proyectos personales, estoy un poco más en el día a día de ciertos temas relacionados con la seguridad, el fraude telefónico y cómo evitarlos, por lo que acabo de ver una vulnerabilidad que merece la pena comentar aquí:
Una vulnerabilidad de PJSIP en un paquete INVITE malintencionado podría provocar un crash de Asterisk.
Este bug ha sido resuelto en las versiones: 13.37.1, 16.14.1, 17.8.1, y 18.0.1
Así que si tenéis una versión anterior y utilizáis PJSIP como el 33% de los usuarios encuestados de Sinologic, os recomendamos actualizar a la siguiente versión cuanto antes.
Sangoma acaba de publicar la versión de Asterisk 18 aprovechando, como suele ser costumbre, su evento Astricon para este anuncio tan importante.
Por razones conocidas por todos, el evento no se ha podido celebrar físicamente, por lo que todo se ha hecho de forma telemática online y el anuncio no se ha hecho esperar:
#Asterisk 18.0.0, 17.8.0, 16.14.0, and 13.37.0 now available at https://t.co/kkl5FxRPnw and just a reminder that 13 and 17 go security fix only in approximately a week! One last bug fix release will occur for each. #ShipIt
El desarrollo de Asterisk 18 ha coincidido con el bloqueo ocurrido por el COVID, por lo que, aunque hay muchas novedades, no hay tantas como se esperaban. Lo que sí hay son muchos bug-fix que hacen de Asterisk 18 una de las más interesantes versiones hasta la fecha.
Entre las novedades principales hay dos documentadas bastante llamativas:
Soporte para multivideoconferencia Hasta ahora, Asterisk soporta videoconferencia entre varias personas, pero a diferencia de como estamos acostumbrados a hacerlas (viendo en todo momento a todo el mundo) Asterisk seleccionaba una única fuente de vídeo (generalmente quien hablaba) y era la que todo el mundo veía en todo momento. Esto en Asterisk 18 cambia y parece que sí vamos a poder ver a todo el mundo como se hacía antiguamente mediante un software que mezclara todos los streams y ofreciera una fuente de vídeo a cada participante. Ahora que la videoconferencia es un must con esto del teletrabajo y las reuniones a distancia, que Asterisk 18 incluya soporte de multivideoconferencia es todo un logro considerando que era una característica que se anunció en la Astridevcon 2007 para la «futura rama» Asterisk 1.6. Más información.
Soporte para negociación de códecs ¿Después de tanto tiempo pensando que Asterisk negociaba el códec y ahora te encuentras con esto? Pues si, el tema de la negociación de códecs es un debate interno y externo allá donde tiene que ver Asterisk y es que Asterisk sólo «deja pasar» pero no negocia, para eso se encargan los endpoints (telefonos), los gateways o los proveedores, hasta ahora Asterisk sólo «permite o no» uno o varios códecs determinado. En algunas versiones incluso definir el orden de estos códecs ayudaba a que la negociación seleccionara un códec frente a otro, pero hasta que no ha llegado Asterisk 18 (y PJSIP) el tema de la negociación de códecs no funcionaba como debería. Personalmente he hecho muchas pruebas y hasta cierto punto siempre he recomendado utilizar un único códec para evitar dicha «no-negociación«. Más información.
Por supuesto aquí tienes los enlaces directos al ChangeLog y al código fuente para que empieces a probarlo cuanto antes y nos cuentes qué te parece.
Uno de los operadores más carismáticos de Europa: Voxbone anuncia su adquisición por otro de los operadores más carismáticos de EEUU: Bandwidth por la nada despreciable cantidad de 446 millones de euros.
Voxbone es uno de los grandes operadores europeos, desde hace muchos años viene participando en eventos sobre VoIP basados en Asterisk y software libre, al igual que Bandwidth que ha sido desde siempre un fiel aliado de Digium y de Asterisk, por lo que esta adquisición se ha hecho con bastante cabeza y seguro que va a traer cosas buenas a ambos mercados (EEUU y Europa).
Considerando que Bandwidth ya era uno de los mayores operadores VoIP de los EEUU, y que Voxbone es uno de los operadores VoIP más grandes de Europa, la adquisición creará una empresa mucho más grande en todos los ámbitos y si bien de cara al usuario puede que no represente muchos cambios, a nivel empresarial casi seguro que han creado uno de los mayores operadores VoIP del mundo.
La empresa fabricante de tarjetas gráficas NVidia lleva algunas semanas dándonos bastantes noticias: la compra de ARM, la creación de su nueva generación de tarjetas gráficas que mejora «en teoría» hasta un 20% el rendimiento de la anterior generación y por último, un sistema en la nube que, potenciado por Inteligencia Artificial gracias a sus procesadores GPU mejoran considerablemente la forma en la que hoy día hacemos videoconferencias.
El sistema NVIDIA Maxine es una plataforma de videoconferencia potenciada por Inteligencia Artificial que, tal y como podéis ver en el siguiente vídeo, mejora las videoconferencias en tiempo real gracias a varias ventajas:
Super-Resolución (permite gracias a la inteligencia artificial) crear un vídeo de alta calidad basado en un vídeo de «baja calidad» de manera que, aunque el ancho de banda sea muy limitado, al receptor de la videoconferencia obtendrá una calidad de imagen casi perfecta. Por supuesto, no puede inventar lo que no existe… pero hablando de Inteligencia Artificial… ¿por qué no?
AutoFrame permite al sistema rastrear y rastrea y mover la sección de video para que siempre esté en el centro de la imagen
Virtual Background, y es que si esta funcionalidad ya estaba en la mayoría de sistemas de videoconferencias, parece ser que con una GPU y un poco de IA, la detección de fondos puede ser algo mucho más fácil.
Denoise, para aquellos que tienen bastante ruido de fondo y necesitan que un sistema de IA analice el audio y filtre convenientemente el ruido que no sea el del interlocutor.
Avatar: de la misma manera que lo hacen los Memojis de Apple, NVidia ha encontrado otra forma de aplicar los movimientos de la cara a figuras y avatares.
Traducción en tiempo real, y es que esto también es algo que tienen algunos sistemas, gracias a la conexión con una fuente de reconocimiento y traducción automática como la de Google.
Compresión de vídeo. Esto considero que es algo muy, muy interesante, y es que permite al sistema reconocer tu cara, los gestos y los movimientos para crear por Inteligencia Artificial tu propia imagen con la nueva postura sin llegar a transmitir todo el frame, únicamente la posición de los puntos clave.
Alineamiento de la cara, y es que ahora gracias a las redes neuronales GAN ya pueden «autocompletar» la información que les falta y pueden mover la cabeza de la persona rellenando con información nueva los datos que no tienen. El resultado es impresionante.
El vídeo completo podéis verlo aquí, y así poder ver en pleno funcionamiento estas nuevas características. Al parecer ya hay empresas que lo están utilizando para sus sistemas de videoconferencia, no tiene pinta de barato, pero lo que sí está claro es que NVidia está dando unos pasos muy grandes para convertirse en otra de las empresas de oro.
Vídeo completo donde ver en detalle estas características.
Otro vídeo por si os habéis quedado con ganas de más
Vídeo donde se explican con más detalle algunas de las características de Maxine
A raíz de una conversación y unas dudas sobre cómo trabajan los usuarios con Asterisk, hace una semana lanzamos una encuesta para conocer de primera mano y de forma anónima qué versión de Asterisk utilizan actualmente los usuarios y por qué razón.
Eramos conscientes de que muchísima gente utilizaba versiones de Asterisk antiguas y que eran pocas las que, de cara a una nueva versión, darían el salto y actualizarían. Los resultados de esta encuesta no son representativos más que de un porcentaje de lectores de Sinologic, aún así, se han recogido 410 respuestas, por lo que lo primero es dar las gracias a todos aquellos que habéis participado compartiendo vuestras opiniones y comentarios.
La versión más utilizada de los usuarios que han participado en la encuesta es Asterisk 13.
El 46% (casi la mitad) de los encuestados usan Asterisk 13. El 22% de los usuarios utilizan Asterisk 16. El 14% utilizan Asterisk 11. Y el 7% utiliza Asterisk 1.8. El 7% restante utilizan versiones más antiguas (Asterisk 1.6 y Asterisk 1.4)
Los resultados aunque esperados, nos han sorprendido ya que hay muchas más personas de las que esperábamos que trabajan con versiones más avanzadas de Asterisk 11 y las principales razones han sido:
Soporte PJSIP.
Soporte WebRTC.
La mayoría que utilizan Asterisk 16 deja claro que van a seguir actualizando las versiones, tienen confianza en los nuevos desarrollos y apuestan por mantener lo más actualizado posible sus sistemas. Otros en cambio dejan claro que es por compatibilidad con WebRTC y PJSIP.
Sobre las razones de por qué utilizan versiones más antiguas Asterisk 13 o inferiores, básicamente son:
Estabilidad. (casualmente la misma razón que han dado otros usuarios que han indicado que usan Asterisk 16)
Instalaciones heredadas (legacy code, compatibilidad con sistemas y desarrollos antiguos, deuda tecnológica, etc.)
También es llamativo que, de todas las respuestas, únicamente 1 persona trabaja con una versión NO LTS (Asterisk 15) indicando que es la versión que venía con la distribución. Por lo demás, TODAS las versiones indicadas en la encuesta eran LTS pese a que pusimos todas las versiones disponibles desde la 1.4 hasta la 16. De aquí también se descubre que la gente conoce bien qué versión es mejor para las instalaciones, que aun no siendo la última, son conscientes de la diferencia entre versiones LTS y no LTS.
Como bien ha comentado un usuario, Asterisk 13 es lo suficientemente antigua como para mantener una compatibilidad con software compatible con Asterisk 11, pero suficientemente moderna como para incluir algunas mejoras interesantes como PJSIP, ConfBridge, TLS, etc.
De las respuestas, podemos sacar algunas conclusiones, que es en definitiva lo que veníamos buscando de todo esto:
Utilidad de Asterisk
Los usuarios de Asterisk son muy conscientes de lo que instalan y qué esperan de la aplicación. No actualizan si no es estrictamente necesario ya que las versiones de hace 4 ó 5 años son suficientes para el trabajo que necesitan que hagan.
Sólo van a actualizar si hay algo que realmente sea necesario: como es el caso de WebRTC, o algún caso puntual de PJSIP (el 26% de los encuestados utilizan este stack SIP).
Rapidez y facilidad de configuración
La mayoría utilizan chan_SIP (el 66% de las respuestas) quizá porque PJSIP es algo menos intuitivo que chan_sip y no lo necesitan. Hay que recordar que en Asterisk 16 el módulo chan_sip está oficialmente obsoleto y se recomienda utilizar PJSIP en adelante.
Muchos usuarios nos indican que no actualizan porque todo lo desarrollado alrededor de su instalación está orientado a esa versión en particular y actualizar requiere modificar el código, rehacer configuraciones, etc, algo que no es prioritario si no implica algún valor añadido que realmente sea interesante.
Seguridad y estabilidad
Debido a que la mayoría de los comentarios han sido «estabilidad» tanto si utilizan Asterisk 11 como si utilizan Asterisk 16, entendemos que prácticamente cualquier versión LTS se puede considerar suficientemente estable para una instalación seria.
Sobre seguridad, es cierto que cuanto más actual, más segura es, ya que se habrán descubierto menos vulnerabilidades. No obstante, los problemas de seguridad reportados son muy puntuales y están bien notificados, por lo que la seguridad de unas versiones frente a otras tampoco es un factor relevante de cara a actualizar.
Por último, repetimos el agradecimiento a todos los que habéis participado y que esto nos sirva a todos para tener una visión que, si bien no tiene por qué ser representativa, si ha sido muy útil para entender ciertos aspectos en cuanto a la versión de Asterisk que utilizan los usuarios.
A la vista de que la próxima nueva versión LTS está a punto de salir (Asterisk 18), hace algún tiempo hablaba con un compañero sobre las razones por las que muchos usuarios habían continuado utilizando versiones obsoletas (Asterisk 1.8 y Asterisk 11 principalmente) en lugar de «abrazar» las nuevas versiones Asterisk 13 o Asterisk 16.
Se nos ocurrieron algunas posibles razones, aunque nuestras razones son muy personales orientadas principalmente por el trabajo que normalmente hacemos y las particularidades que pueden tener. Por esta razón, se nos ocurrió preguntar a los usuarios de Sinologic, de forma anónima, qué versión de Asterisk utilizan frecuentemente y en caso de que no sea la última posible y quiera participar, las razones que hay detrás de utilizar estas versiones.
Así que si os apetece participar en esta breve encuesta de 4 preguntas, (en la que tardaréis apenas 20 segundos) próximamente analizaremos y publicaremos los resultados obtenidos, estamos seguros que a más de uno le sorprenderá bastante.
