Author Archives: Christian Cabrera

Inseguridad en Elastix: estadísticas actualizadas (México)

3 Nov
3 noviembre, 2011 Christian Cabrera 18

Hace algunos meses publiqué un artículo sobre estadísticas de inseguridad en Elastix y los resultados fueron bastante alarmantes, ya que el estudio claramente indicaba que quienes se habían encargado de instalar los sistemas no habían seguido muchos de los consejos básicos de seguridad tales como no exponer el HTTPS a internet ni mucho menos cambiar las contraseñas default puestas. Por tal motivo, durante este año se reportaron múltiples casos de empresas  a los que les habían cometido algún tipo de fraude telefónico, representando pérdidas de varios cientos o miles de dólares en tan solo una noche.

Hoy, con motivo del inicio del Elastix World precisamente en México, decidí repetir el ejercicio para hacer un comparativo de como han cambiado los números desde aquel entonces. Aquí mis resultados obtenidos:

Los resultados fueron:

– Total de equipos escaneados (en México): 27.8 millones
– Total de equipos con puerto TCP 443 expuesto: 67,887
– Total de equipos con puerto TCP 443 expuesto y que usan Elastix: 336

De los equipos con Elastix expuesto:

– Presentan algún tipo de vulnerabilidad descubierta: 102 (27.87%)
– Tienen acceso mediante UDP 5060 (SIP):  102 (27.87%)
– Tienen alguna contraseña default en FreePBX: 82 (22.40%)
– Siguen usando ‘palosanto’ como contraseña de Elastix: 9 (2.46%)
– No han parchado la vulnerabilidad del ‘asteriskuser’: 120 (32.79%)
– Usan la misma contraseña para FreePBX y para Elastix: 4 (1.09%)
– Utilizan una versión muy vieja de FreePBX (2.5 o menor): 43 (11.75%)

De los equipos con vulnerabilidades que permiten acceso:

– Se detectaron extensiones completas (usuarios, contraseñas y correos electrónicos) de 1,192 personas

Tomen en cuenta que todos estos números son reales, ya que el estudio fue conducido sobre equipos en producción durante la noche del 2/noviembre/2011.

Tras analizar los números, es posible ver que ha habido una notable mejoría. Sin embargo, muchas empresas siguen desprevenidas contra ataques por no seguir simples reglas de seguridad básicas (las cuales se mencionan en el artículo inicial)

Ahora, tras los números, mi opinión personal: ¿Es Elastix una herramienta insegura? No, no lo es. Ha tenido sus vulnerabilidades relacionadas con las herramientas que incorpora (tal como FreePBX), pero todos estos males podrían haberse resuelto si tan solo los «administradores» que las instalaron hubieran tomado 5 minutos extras en asegurar su conmutador después de haber hecho la instalación. De hecho, creo que el principal problema de las herramientas que hacen la labor de instalación más sencilla (tal como Elastix lo es), es que cualquier persona piensa que por meter un CD y dar unos cuantos clicks ya terminó todo, cuando realmente se requiere preparación y conocimiento detrás de cada acción para saber lo que se está haciendo. Desafortunadamente, personas con este perfil son las que le dan una mala reputación a los sistemas VoIP (y a quienes nos encargamos de ofrecerlos), haciendo que se genere desconfianza para muchos por culpa de tan solo algunos.

Una vez más, no me queda recomendarles mas que asegurar sus equipos. Hoy más que nunca, los fraudes telefónicos están a la orden del día.

¡Suerte!

Como agregar contextos personalizados en todos los servidores de un cluster con Vicidial

13 Oct
13 octubre, 2011 Christian Cabrera 1

Hoy me di a la tarea de implementar un plan de llamadas personalizado en un cluster de Vicidial: mi cliente no quería que existiera la posibilidad de que los agentes marcaran manualmente desde su X-Lite, y al tratarse de un entorno de múltiples servidores, a la larga resultaría complicado mantener por separado cada uno de los archivos extensions.conf de los servidores.

¿Cuál es entonces la mejor manera para crear contextos de plan de llamadas que aparezcan en TODOS los servidores instalados en un cluster de Vicidial sin tener el problema de replicar manualmente los cambios?

La respuesta viene con las últimas versiones de Vici (2.2+) ya que bajo Admin -> System settings viene un espacio interesante donde podemos agregar planes de llamadas personalizados: el Custom Dialplan Entry.

Custom Dialplan Entry para Vicidial

Sin embargo, hay un problema, y es que todo lo colocado en esta caja se escribe dentro del contexto [vicidial-auto], por lo que si decidimos ingresar contextos por separado, romperiamos la funcionalidad del plan de llamadas automático de Vici, pero el truco es más sencillo de lo que se cree. Solo tenemos que iniciar y terminar nuestro bloque con las siguientes líneas:

[codesyntax lang=»bash»]

include => vicidial-auto2

; Este es mi contexto personalizado
[agentes]
exten => _ZXXX,1,Dial(SIP/${EXTEN})
; Fin de mi contexto personalizado

[vicidial-auto2]

[/codesyntax]

¿Qué logramos hacer con esto? Hacemos que nuestro cluster genere todos los contextos personalizados que metamos en medio de nuestras lineas, pero además, no rompemos la funcionalidad de Vici porque la línea de include => vicidial-auto2 hace que la inclusión del contexto [vicidial-auto2] sea transparente, de manera que no rompemos ninguna de las funcionalidades del sistema, y evitamos tener que administrar una linea de comandos para que la exportación de la configuración sea más transparente.

Este truco me sacó de un problema que sé que a la larga, se habría perdido el control de la administración tarde o temprano.

¡Suerte!

¡Inauguramos nuestra tienda en línea!

5 Oct
5 octubre, 2011 Christian Cabrera 0

Tienda VoIPEl día de hoy damos por iniciado el proyecto que llevamos algunos meses cocinando: nuestra tienda en línea de equipo VoIP. Obviamente, todo el equipo que ofrecemos es compatible con Asterisk, por lo que no habría ningún problema por instalarlo y echarlo a andar en tu nuevo proyecto o en tu conmutador SIP ya existente.

Al navegar en la tienda encontrarán productos de marcas como Digium, Aastra, Yealink, Cisco, Sangoma y Polycom. Conforme cubramos más territorio en términos de nuevos productos los iremos agregando al catálogo, pero por lo pronto ya pueden conocer los equipos que manejamos y que enviamos a todo México.

Pueden acceder a nuestra tienda en línea usando este link o bien, dando click en la pestaña que aparece en el extremo superior derecho.

 

Recuperar la contraseña de FreePBX

3 Oct
3 octubre, 2011 Christian Cabrera 2

Muchos han pedido un tutorial de como recuperar la contraseña de FreePBX, lo cual es bastante sencillo una vez que tienes la contraseña de root de Linux. Asumiendo esto, el proceso a seguir es bastante fácil, solo hay que cambiar los passwords desde MySQL. Aquí pongo los comandos directos para hacerlo desde el CLI de Linux (estamos asumiendo que el password de root de MySQL es eLaStIx.2oo7)

Si tienes FreePBX 2.5 o inferior:

[codesyntax lang=»bash»]
echo «UPDATE asterisk.ampusers SET password=’minuevopass’ WHERE username = ‘admin'» | mysql -peLaStIx.2oo7 asterisk
[/codesyntax]

Si tienes FreePBX 2.6 o superior

[codesyntax lang=»bash»]

echo "UPDATE asterisk.ampusers SET password_sha1=SHA1('minuevopass') WHERE username = 'admin'" | mysql -peLaStIx.2oo7 asterisk

[/codesyntax]

Con FreePBX 2.6+ la contraseña se guarda como hash SHA1, por lo que no es posible recuperarla. Sin embargo, en versiones anteriores se guardaba en texto plano, por lo que un simple SELECT nos revelaria cual era la contraseña que teniamos.

OJO: obviamente es necesario cambiar «minuevopass» por lo que queramos que sea nuestra nueva contraseña

¡Suerte!

6 razones por las cuales tu campaña en Vicidial podría no funcionar

28 Sep
28 septiembre, 2011 Christian Cabrera 13

Como se ha visto, recientemente hemos tenido mucho movimiento sobre Vicidial, que es una suite open source para instalar un callcenter completo sobre Linux. Pues bien, es bastante común que dado lo complejo que resulta este sistema cometamos errores y que por lo tanto nuestras campañas de marcación predictiva no saquen llamadas al exterior. Aquí recopilo algunos de los errores más comunes al momento de hacer marcación predictiva hacia el exterior:

  • Las campañas tienen el horario incorrecto. Muchas veces, las pruebas las hacemos en las noches y movemos la hora de las llamadas para entender por que no salen. Primer paso: asegurémonos de que la hora de la campaña sea la correcta y que estemos haciendo pruebas dentro del horario REAL en que se supone que nuestras campañas deben de correr.
  • No hay leads disponibles para marcar. Asegurémonos que las listas que tenemos dadas de alta para nuestra campaña tengan leads con los status de marcación válidos. Normalmente, marcamos a los NEW (nuevos leads), NA (No Answer) y B (Busy). Si nuestra lista está llena de leads que no tienen estos status, no se marcará hacia ellos. Agreguemos los nuevos status que queramos dentro de la campaña para ser válidos de remarcarles o bien, importemos nuevos leads para reintentar la operación.
  • No hay leads en el hopper. Si mandamos llamadas demasiado rápido o tenemos muchos agentes, lo más probable es que nos agotemos el hopper realmente rápido. Lo ideal es que nuestro hopper level (a nivel de campaña) esté ubicado en al menos 2.5 veces el número de agentes que podemos tener en línea en un momento dado. Este error es fácil de encontrar ya que nos aparecen indicaciones al hacer login como agente, asi que no debería ser problema localizar de que se trata.
  • Las llamadas no están saliendo a pesar de tener agentes en línea. Esto me pasó recientemente: todos los problemas de arriba habían sido verificados, pero había 5 agentes en línea y ninguno recibía llamadas. El problema fue de que tenía yo creada una campaña de marcación automática con agentes remotos (para enviar mensajes pre-grabados) y esto ocasionó que nos termináramos la cantidad de troncales disponibles para marcar al exterior (aunque nunca se usaron). Moraleja: asegúrate que bajo System Settings, el valor de Max Vicidial Trunks sea más grande que la cantidad total de agentes que tengas en un momento dado, y en caso de que así sea, asegúrate de no tener agentes remotos activos que tengan múltiples lineas de salida activadas. Al parecer, Vicidial reserva lineas aún para los agentes remotos que no las están usando.
  • Las llamadas no enlazan: dan un timeout y la interfaz de agente se queda esperando en estado «ringing». Comúnmente es ocasionado por enlaces digitales que NO son ISDN, como R2 modificado. Algunos proveedores dan mensajes grabados en early media audio dando grabaciones como «el número que marcó no existe». Normalmente, una persona escucharía esto y sabría que hacer, pero un sistema piensa que la llamada nunca se contestó y por lo tanto, ocurre un timeout porque 1) nunca obtuvimos ring y 2) nunca nos contestaron. La única solución es cambiar de enlace o cambiar a marcación manual, de manera que nuestros agentes puedan catalogar por ellos mismos el estado de las llamadas.
  • Las llamadas se cortan a los pocos segundos y nunca se enlazan a los agentes. Descubrí que si en la marcación automática haces un ANSWER antes de enviar un DIAL (es decir, sin un ringing de por medio), Vicidial nunca te enlaza las llamadas y te las marca como NA (No Answer). Lo correcto es que siempre debe haber un ringing antes de que la llamada sea contestada. Con eso evitarás que se marque pero nunca comunique a los agentes.

Como siempre, habrá muchas otras cosas que puedan pasar, pero en este caso estas son las más comunes. Conforme nuestra experiencia vaya aumentando, iremos ampliando la lista.

¡Suerte!

Como reiniciar masivamente todos los dispositivos Cisco SPA de tu red

27 Sep
27 septiembre, 2011 Christian Cabrera 2

El día de ayer publicamos un mini tutorial de como reiniciar masivamente todos los teléfonos Aastra de nuestra red. Hoy publicamos el equivalente aplicable para todos los teléfonos Cisco SPA (esto aplica también para la vieja gama de Linksys/Sipura).

El código es aún más sencillo que el de ayer:

[codesyntax lang=»php»]

#!/bin/bash
RED=192.168.1.1/24
echo "Escaneando $RED ..... "
for IP in `nmap -sP -v $RED | grep "appears to be up" | cut -d' ' -f 2`
do
   wget -qT 1 --no-cache http://$IP/admin/reboot -O - > /dev/null
done

[/codesyntax]

Con un poco de ingenio, podemos mezclar ambos scripts para que en caso de tener mezcla de teléfonos, reiniciemos todo lo que nos encontremos.

¡Suerte!

Terminado el curso de Vicidial

12 Sep
12 septiembre, 2011 Christian Cabrera 1

Durante los últimos 4 días estuve en Tampa, FL tomando un curso acerca de Vicidial, una suite open source con marcador predictivo para call centers basados en Asterisk. El curso fue impartido por Matt Florell, el creador del software, y durante las horas que estuvimos en el salón de clases pude aprender y corroborar muchos detalles interesantes sobre este sistema que aunque lleva varios años en el mercado, pocos se han dado a la tarea de conocerlo.

El curso se divide en 2 partes: el Manager y el Admin. Durante el curso de Manager se da una explicación a detalle de como utilizar la interfaz web de Vicidial: como se crean campañas de entrada y salida, como se cargan registros, como se configuran carriers para enviar las llamadas, como podemos controlar la distribución de llamadas entre los agentes, etc. Todas y cada una de las opciones de las más de 200+ que hay para alterar en la suite fueron vistas y explicadas. A pesar de que en la interfaz web es posible leer la documentación HTML que viene con el software, muchas veces las cosas no se comprenden tan bien como cuando puedes debatirlas, y este fue uno de los casos. Inclusive las explicaciones ayudaron a visualizar escenarios que no habiamos contemplado, pero que pueden resultar muy útiles para cualquier callcenter.

En la segunda parte del curso se vieron detalles mucho más técnicos: como instalar el sistema, como hacer troubleshooting, cuales son las causas comunes de que un sistema de estos falle (el famoso time synchronization error o el there are no available sessions), así como muchas otras características avanzadas que el mortal promedio no ocupa, como el uso de los APIs, la captura extendida de números telefónicos, etc. Al final terminamos con una instalación de Vicidial en cluster (lo que ofrece máxima escalabilidad al sistema) y corrimos pruebas de rendimiento para comprobar que todo estuviera bien y supiéramos hasta donde podemos llegar con él. En general, un curso muy teórico y con mucha información. Debo reconocer que mis favoritos fueron los últimos dos días, pues fue cuando realmente tuve oportunidad de jugar con el sistema.

Vicidial hoy en día es un producto que deja muy por atrás a toda la competencia, tanto en funcionalidades como en precio. Aquellos que han probado el módulo de callcenter de Elastix puedo decirles fácilmente que no tiene nada que ver con Vicidial: Elastix fue pensado como un PBX para empresa, no como medios para un callcenter, y Vici está muy por encima en funcionalidades. ¿Acaso el precio podría hacer la diferencia? No, porque es el mismo que con el resto del open source: ¡gratis!, así que tampoco es necesaria una inversión millonaria en sistemas como Avaya o Cisco que a pesar de ser propietarias, se quedan cortos en características.

En mi opinión personal, el único problema que le veo a un software como Vici es precisamente su mayor fortaleza: el grado de complejidad que tiene lo hace para alguien sin conocimientos resulte una tarea muy complicada el tratar de echar a andar una campaña con él. Sin embargo, una vez que se libra esa curva de aprendizaje, los que ahora lo conocemos sabemos que es bastante sencillo de ocupar, y que pueden hacerse cosas geniales con él. Repetiré lo que les digo a mis alumnos del curso de Asterisk: el límite de lo que puedes hacer, es la capacidad del administrador.

Para más información sobre este software, visiten vicidial.org. Si requierieras apoyo profesional para una implementación de Vicidial para un callcenter, por favor utiliza nuestro formulario de contacto.

¡Suerte!

Nueva fecha de Cursos Asterisk para octubre

9 Sep
9 septiembre, 2011 Christian Cabrera 0

Una vez más y por la respuesta obtenida, nuestra fecha de cursos del 21 al 24 de septiembre se llenó. Por la demanda, abrimos una nueva fecha en octubre, quedando así 2 en el mismo mes.

El calendario próximo queda como sigue:

  • México, D.F. del 5 al 8 de octubre.
  • México, D.F. del 26 al 29 de octubre.

Para cualquier duda relacionada con nuestros cursos, visiten la página de nuestros cursos o háganos llegar sus dudas a través de nuestro formulario de contacto.

¡Los esperamos pronto!

Como eliminar el eco en llamadas: instalando OSLEC y usando fxotune

7 Sep
7 septiembre, 2011 Christian Cabrera 25

El eco en una señal de telefonía ocurre cuando tenemos 2 conductores a diferentes impedancias. El desacople de las mismas ocasiona que la señal se refleje y se perciba por nuestro cerebro como 2 señales diferentes. Si el eco es superior a 150ms, comienza a volverse molesto ya que como humanos nos distrae de la conversación que estamos teniendo.

En un sistema 100% VoIP el eco no existe. Definitivo: no existe. Sin embargo, dado que aún ocupamos medios analógicos para poder nosotros enviar o recibir el audio (micrófonos y altavoces), es en estos dispositivos donde el eco puede ocurrir. El punto más común donde se produce el eco es en el medio que ocupemos para conectarnos con medios 100% analógicos, como la línea telefónica, así que es responsabilidad de nuestras tarjetas o gateways, hacerse cargo de cancelar este eco, ya sea mediante hardware o software (recuerden que en VoIP, la voz al final son datos, y los datos pueden manipularse por software).

Para poder manipular el eco en Asterisk tenemos 2 opciones:

  1. Hardware: es la más cara de las opciones, ya que nos exige comprar hardware dedicado a esta función. Sin embargo, es la de mejor rendimiento ya que libera al CPU de esta carga extra.
  2. Software: justo lo contrario, es la opción más económica, pero depende del CPU para hacer el procesamiento.

Para opciones de hardware podemos comprar tarjetas que soporten esta característica. En tarjetas Sangoma podemos ir por los modelos que tengan la letra D (como la B600DE, A200DE, A101DE). El problema con estas tarjetas es que no son actualizables, es decir, no podemos comprar el módulo de cancelador de eco después. Las tarjetas Digium tienen la ventaja de que podemos adquirir el módulo de cancelador de eco por separado, asi nuestra inversión está asegurada.

En este artículo nos centraremos en las soluciones para software, ya que la mayoría de nosotros tiene equipos que no cuentan con el módulo en HW necesario para lograr esta función, y para hacerlo, primero haremos la instalación de OSLEC (Open Source Line Echo Canceller), la cual, tiene que ser compilada dentro de DAHDI.

Empezando con el trabajo: primero necesitamos conseguir el código fuente de DAHDI y también el código fuente de Wanpipe (los drivers de Sangoma que contienen la referencia a OSLEC).

cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.4.1.2+2.4.1.tar.gz
wget ftp://ftp.sangoma.com/linux/current_wanpipe/wanpipe-3.5.22.tgz
tar -zxf dahdi-linux-complete-2.4.1.2+2.4.1.tar.gz
tar -zxf wanpipe-3.5.22.tgz

Quizá se pregunten: ¿por qué descargar wanpipe si lo podemos conseguir en el código fuente de Linux? Simplemente porque wanpipe es más pequeño y tarda menos en descargarse.

Luego, creamos las carpetas necesarias dentro del código de DAHDI y copiamos la parte de OSLEC que necesitamos:

cd /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers
mkdir staging
cp -r /usr/src/wanpipe-3.5.22/OSLEC/echo staging

En este punto, hay 2 archivos que debemos de modificar:

/usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/staging/echo/Kbuild
/usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild

Empezamos por el primero (el cual está vacio). Solo necesita que agreguemos una línea en su interior:

#
# Archivo /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/staging/echo/Kbuild
#
obj-m += echo.o

El segundo archivo si tiene contenido. Buscamos un contenido similar a este:

# Archivo: /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild

# Only enable this if you think you know what you're doing. This is not
# supported yet:
#obj-m += dahdi_echocan_oslec.o
#
# A quick and dirty way to build OSLEC, if you happened to place it
# yourself in the dahdi source tree. This is experimental. See README
# regarding OSLEC.
#obj-m += ../staging/echo/

Quitamos el comentario a las 2 lineas de código para dejarlo así:

# Archivo /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild

# Only enable this if you think you know what you're doing. This is not
# supported yet:
obj-m += dahdi_echocan_oslec.o
#
# A quick and dirty way to build OSLEC, if you happened to place it
# yourself in the dahdi source tree. This is experimental. See README
# regarding OSLEC.
obj-m += ../staging/echo/

Procedemos a recompilar DAHDI desde nuestra carpeta /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1


cd /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1
make
make install

2 passos más: editamos /etc/dahdi/system.conf

#
# Archivo /etc/dahdi/system.conf
#
# Tomen en cuenta reemplazar sus canales por los de su equipo
# En este ejemplo tengo una tarjeta de 4 puertos FXO
fxsks=1-4
echocanceller=oslec,1-4

Y aplicamos los cambios desde el CLI de Linux:

dahdi_cfg -vv
DAHDI Tools Version - 2.4.0.1

DAHDI Version: 2.4.0.1
Echo Canceller(s): OSLEC
Configuration
======================

Channel map:

Channel 1: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 2: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 3: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 03)
Channel 4: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 04)

Si todo carga sin errores, ¡listo! tenemos habilitado el cancelador de eco OSLEC, que es considerablemente mejor contrarestando el eco que el default de MG2.

Estos pasos son bastante buenos para reducir el eco de nuestra línea, pero si aún así tenemos problemas, podemos usar fxotune para virtualmente, eliminar el eco remanente. Es muy sencillo de usar. El procedimiento sería el siguiente:

  1. Detenemos Asterisk para que los canales DAHDI no estén en uso
  2. Creamos el archivo /etc/fxotune.conf (se crea automáticamente usando el comando fxotune -i)
  3. Cargamos los coeficientes encontrados cada vez que arranque el sistema
  4. Reiniciamos Asterisk

Visto en código sería algo así:


/etc/init.d/asterisk stop
fxotune -i # Esto puede demorar algunos minutos
echo 'fxotune -s' >> /etc/rc.local
/etc/init.d/asterisk start

Nota final: El fxotune debe ser ejecutado cuando Asterisk NO está corriendo. En el ejemplo anterior, estoy agregando el fxotune -s al rc.local para que cargue en automático, pero esto hará que tras el re-arranque, se ejecute hasta después de que Asterisk ya inició (lo cual no está bien). Si queremos asegurarnos que cargue siempre, podemos agregar al rc.local las instrucciones para que Asterisk se detenga, se ejecute fxotune y luego re-arranque Asterisk. Hay muchas maneras de hacer esto, pero eso escapa a la intención de este artículo.

Siguiendo todos estos pasos, el eco debe quedar prácticamente eliminado. Hasta el momento he hecho instalaciones que han mantenido eco con uno de estos pasos, pero nunca alguno que haya persistido con los 2.

¡Suerte!

Elastix hack: Usar los Cisco SPA5XX con el endpoint configurator de Elastix

19 Jul
19 julio, 2011 Christian Cabrera 8

En numerosas ocasiones he usado el Endpoint Configurator de Elastix para facilitar la configuración de múltiples teléfonos de manera rápida y sencilla. Sin embargo, recientemente que empecé a ocupar los teléfonos Cisco SPA502G y SPA504G me topé con que Elastix no los reconoce (o al menos, no directamente), así que no podía usar el configurador automático con ellos.

Los teléfonos de la serie SPA provienen de Linksys, el fabricante de equipo de red para SoHo que Cisco adquirió, pero estos a su vez provienen de Sipura, que es un fabricante que pocos conocen y que hace mucho tiempo, Linksys compró. La configuración entre los diferentes modelos no ha cambiado mucho a pesar de los años, así que un Cisco SPA504G se configura prácticamente igual que un Linksys SPA942, y esos SI son detectados por el configurador de Elastix.

Entonces… ¿Cómo hacemos para que Elastix detecte estos nuevos modelos?

Una forma muy sencilla es engañando al configurador, haciéndolo creer que se tratan de SPA942. Para hacerlo, solo tenemos que agregar las MACs de Cisco dentro del archivo /var/www/db/endpoint.db (el cual viene en formato de sqlite). El código sería el siguiente:

sqlite3 /var/www/db/endpoint.db
sqlite> INSERT INTO "mac" VALUES(45, 4, 'C8:9C:1D', 'Cisco - SPA504G');
sqlite> INSERT INTO "mac" VALUES(46, 4, 'E0:5F:B9', 'Cisco - SPA504G');
sqlite> .quit

Estas 2 series de MACs, la E0:5F:B9 y la C8:9C:1D son las que por experiencia he encontrado que estos nuevos teléfonos tienen. ¿Qué quieren decir los otros campos?

  • El ’45’ es el número de la fila. Por default vienen otros 44 registros en la tabla mac, pero podemos reemplazarlos por cualquier otro número (como 100 o 101)
  • El ‘4’ es el que le dice a Elastix que el teléfono encontrado es un Linksys
  • El ‘E0:5F:B9’ o ‘C8:9C:1D’ corresponde al inicio de la MAC del teléfono. Mismos modelos suelen tener el mismo comienzo de MAC
  • El último campo es solo una descripción de lo que se está agregando. Esto no se usa, es solo para que los humanos entendamos de que se trata la fila.

Tras hacer el cambio, podemos re-ejecutar el endpoint y obtendremos algo como esto:

Esto nos indica que nuestros teléfonos ya fueron reconocidos, así que podemos aplicar la configuración de la extensión para configurar nuestros nuevos teléfonos.

¡Suerte!