SSH Inverso: Soporte a una máquina Linux

sshlogoEn este mundo de las comunicaciones, todos aquellos que nos dedicamos a dar soporte técnico a clientes nos enfrentamos a diario a las dificultades que se nos plantean con muchos clientes a la hora de tratar de resolverle una incidencia. Me refiero sobre todo al típico caso en el que necesitamos acceder de forma remota, por ejemplo, a la centralita del cliente. En muchas ocasiones, dicha centralita está basada en un sistema Linux (puede ser un Asterisk, puede ser una central Elastix, etc.) Y también, en muchas ocasiones, el cliente no puede proporcionarnos un acceso SSH a dicha máquina por multitud de razones.

En esta situación, en la que el necesitamos entrar en la máquina del cliente y éste no puede habilitarnos un puerto externo, podemos encontrarnos con que el cliente nos ofrece la posibilidad de acceder por TeamViewer (un clásico) o cualquier otro sistema similar. He de recordar que tanto esta herramienta como otras similares son herramientas de pago si se usa para fines profesionales y no necesariamente en nuestra empresa tendremos licencias de uso de todas estas herramientas. Incluso en el caso de TeamViewer, si se llega a abusar sin licencia, las sesiones se terminan cortando con lo cual hacen que la prestación del soporte no sea la adecuada.

Dicho esto, voy a explicar una alternativa que seguramente muchos conocéis ya pero que quizás no se le ha prestado nunca la atención merecida. Por mi parte, la vengo poniendo en práctica cada vez que puedo y los resultados la verdad que son satisfactorios. Se trata de usar el llamada SSH Inverso.

Básicamente, consiste en que el cliente es el que inicia la conexión SSH y después, nosotros nos conectaremos usando esa primera conexión para acceder a la máquina final sin necesidad de que el cliente tenga que habilitarnos ningún puerto. Aquí tenéis una imagen del escenario en la que se resume todo el proceso.

SSH Inverso

Os comento el escenario particular que vengo usando yo (el de la imagen anterior), que seguramente será el más sencillo, aunque hay otras posibilidades.

Requisitos

En mi caso tengo una máquina Linux en la nube con una IP fija. Necesitaremos una máquina Linux a la que el cliente se pueda conectar. En principio, una máquina en la nube nos sirve. Dicha máquina debe tener habilitado el acceso por SSH. Vamos a suponer que dicha máquina se llama IPNUBE.

Preparativos por nuestro lado

Conectarnos nosotros a IPNUBE con las credenciales necesarias y crear un usuario de Linux para nuestro cliente. Basta ejecutar el siguiente comando (necesarios privilegios de root) y seguir las indicaciones que nos van saliendo.

> adduser cliente

Por razones de seguridad, lo siguiente que haremos será quitarle al usuario recién creado la posibilidad de iniciar sesión en nuestra máquina para ejecutar comandos. Para ello, editaremos el fichero /etc/passwd con nuestro editor favorito (requiere privilegios de root) y buscar la línea (será la última normalmente) con el usuario creado en el paso anterior. Tendremos que cambiar el final de la línea, que normalmente será /bin/bash y poner /bin/false. Guardaremos los cambios.

Comunicación con el cliente

Una vez preparado todo, debemos comunicar al cliente que debe ejecutar el siguiente comando desde la máquina a la que deseamos conectar:

> ssh -R 7777:localhost:22 cliente@IPBUNE -N -f

  • 7777: Debemos elegir un puerto libre en IPNUBE. En este caso, 7777 es el elegido.
  • 22: El puerto por defecto para acceder por SSH es el puerto 22. Ese puerto 22 debe ser el puerto a través del cual el cliente conecta localmente a la máquina usando SSH.
  • cliente: Es el nombre de usuario que hemos creado para el cliente. En este caso, lo llamamos cliente.

Debemos solicitarle al cliente las credenciales de acceso a la máquina destino (credenciales de root normalmente). El cliente, lo único que deberá hacer es ejecutar el comando comentado en la máquina Linux objetivo y proporcionarnos las credenciales de acceso. Eso es todo por su parte.

Accediendo a la máquina del cliente

Finalmente, nosotros nos conectamos por SSH a IPNUBE con nuestras credenciales y una vez dentro, ejecutamos el siguiente comando:

> ssh -p 7777 localhost

Se nos debe abrir una conexión SSH. Ahí debemos proporcionar las credenciales que nos ha proporcionado el cliente y ¡estaremos dentro de su máquina!

Limpiando

Una vez finalizada la intervención, podremos eliminar el usuario creado en IPNUBE para el soporte con el siguiente comando:

> deluser cliente

Si además, queremos desconectar la conexión abierta por cliente sin que éste haga nada, podremos localizar el proceso con el comando ps:

> ps aux

y matarlo con el siguiente comando:

> kill -9 5568

suponiendo que 5568 es el ID del proceso de la conexión SSH del cliente.

Existe una buena variedad de formas para montar un escenario en el que dar soporte a un cliente usando SSH Inverso. Aquí tan solo se ha explicado una de las formas habituales de realizar este tipo de conexiones. Desde el punto de vista del cliente, las acciones que debe realizar si optamos por este tipo de acceso remoto son mínimas y no requieren de configuraciones adicionales ni, en principio, de la instalación de ningún software extra.

Categorías Linux.

Fotos de los Cursos 3CX Partner Básico y Avanzado

Como ya sabéis, esta semana se han celebrado 2 ediciones de los cursos 3CX Partner en España. Una edición del Curso Básico en Málaga y otra edición del Curso Avanzado en Madrid. Ambas convocatorias han sido todo un éxito. En Málaga hemos sobrepasado los 30 asistentes y en Madrid hemos andado rozando ese número. Como instructor de ambos cursos, me he sentido bastante arropado y a gusto impartiendo la formación, aunque debo reconocer que ha sido una semana intensa. Desde aquí, doy las gracias a todos los asistentes a ambas ediciones, esperando que hayan podido aprender un poquito más sobre 3CX y sobre VoIP. Cualquier crítica constructiva sobre cualquier aspecto de los cursos será bienvenida y considerada. Os dejo a continuación unas fotos tomadas de ambos eventos y espero que para futuras convocatorias, aquellos que no hayáis podido asistir, vengáis.

3CX Partner Básico de Málaga –  12 de Mayo de 2015

3CX Partner Avanzado de Madrid – 14 de Mayo de 2015

Categorías 3CX, Formación.

Publicado Service Pack 1 de 3CX Phone System V12.5 – Actualización Crítica

Logo3CXTr3CX ha liberado la actualización Service Pack 1 para su versión 12.5. Se trata de una actualización crítica ya que tiene que ver con el algoritmo de cifrado SHA-1 (Secure Hash Algorithm) y su caída en desuso.  El servidor de licenciamiento de 3CX estaba basado en el algoritmo de cifrado SHA-1 y han actualizado dicho servidor para que use SHA-2. Esta actualización hace que sea obligatorio actualizar el módulo de licenciamiento de 3CX Phone System para que puedan validar correctamente sus licencias a la hora de activarlas o reactivarlas.

Hay que destacar que, tras la instalación de este Service Pack será obligatorio reactivar la licencia. Destacamos los siguientes factores a la hora de reactivar:

  • La licencia debe tener vigente un seguro de actualización. Este seguro está ya incluído en todas las licencias de 3CX que se compran y tiene una duración de un año. Es decir, hasta la fecha de hoy, cualquier licencia de V12.5 podrá instalar este Service Pack 1.
  • A la hora de reactivar la licencia, tener en cuenta de hacerlo usando la misma interfaz de red local con la que se activó anteriormente.
  • El sistema pasará a Free Edition tras instalar el Service Pack 1 y reiniciar la máquina. Solo se requiere una reactivación.

Podéis encontrar más información en el sitio web oficial de 3CX. Si tenéis algún tipo de duda o incidencia, siempre podéis acudir al Soporte Oficial de 3CX o al Soporte de la empresa que te ha vendido la licencia de 3CX para que te resuelva cualquier tipo de duda o incidencia que pudiera surgir al respecto.

Categorías 3CX, Windows.

Próximo 3CX Training Partner Oficial Avanzado: 14 de Mayo en Madrid

El próximo 14 de Mayo ( Jueves ) se celebra en Madrid el primer curso 3CX Training Partner Avanzado de 2015. En este curso, que al igual que el Training Partner Básico tiene una duración de una jornada, se profundiza en aspectos de seguridad, elementos remotos, resolución de problemas a nivel de SIP, etc. El lugar de la celebración será el Centro de Negocios de Madrid – Business Centre, S.A., Calle del Capitám Haya 1 (Planta 15) Edificio Eurocentro Empresarial:

Como novedad, este año los cursos Training Partner de 3CX se han dividido en Básico y Avanzado, siguiendo ambos unos contenidos marcados directamente por la propia 3CX. Con respecto a anteriores eventos Training Partners, cabe destacar que el Avanzado profundiza a nivel de protocolo SIP, llegando a enseñar formas de analizar una traza SIP, así como pautas a seguir a la hora de detectar las causas de posibles problemas. Igualmente, se hace hincapié en todo lo relacionado con elementos remotos. Este Training Partner Avanzado está enfocado a todo Partner que quiera ampliar conocimientos a nivel de 3CX y VoIP en general.

Así pues, el programa del curso 3CX Training Partner Avanzado de Madrid es el que se refleja a continuación:

09:00 – Apertura de puertas / Registro
09:15 – Jose María Caballero de 3CX presentará la última Central Telefónica 3CX versión 12.5
10:00 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:   

Curso 1: Conceptos avanzados y configuración
1.1 Seguridad con la Central Telefónica 3CX
1.2 Métodos y Plantillas e Aprovisionamiento
1.3 LCR (Least Cost Routing)
Curso 2: conexiones remotas
2.1 NAT y reenvío de puertos
2.2 3CX Tunnel Protocol
2.3 Configurar extensiones remotas
2.4 Configuración de Puente 3CX

12:30 – Pausa coffe-break
13:00 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:

Curso 3: Solución de problemas
3.1 Llamadas VoIP en detalle
3.2 Sistema Telefónico 3CX Solución de problemas
3.3 Wireshark como una herramienta de diagnóstico
3.4 3CX Bin Log Viewer

14:45 – Receso para Almuerzo
15:30 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:

Preguntas y Respuestas
(opcional dependiendo del tiempo restante: 3CX videoconferencias)

16:45 – Preguntas y Respuestas.

Dependiendo de la evolución de la jornada, podremos tratar otros puntos de interés. Por último, un año más, el encargado de realizar esta jornada formativa seré yo mismo. Espero que os animéis y os inscribáis para asistir a este primer 3CX Partner Avanzado del año, que os recuerdo que es totalmente gratuito. ¡Darse prisa, que las plazas vuelan!

Para inscribirse en el curso, podéis hacerlo desde aquí mismo:

Categorías 3CX, Formación.

Próximo 3CX Training Partner Oficial Básico: 12 de Mayo en Málaga

El próximo 12 de Mayo ( Martes ) se celebra en Málaga el primer curso 3CX Training Partner Básico de 2015. En este curso, de una jornada de duración, se trata de explicar el estado actual de todo lo que rodea a 3CX desde un punto de vista técnico, pero al alcance de todos. El lugar de la celebración será el Parque Tecnológico de Andalucía (PTA), en las oficinas del CADE, en Calle Maria Curie 8.

Este año, los cursos 3CX Training Partner han sido actualizados para tener en cuenta la reciente versión 12.5 de 3CX PhoneSystem. Se tratarán puntos tan interesantes como las video conferencias web o WebMeetings y las llamadas a través de WebRTC a elementos internos de la propia centralita, lo cual abre una gran capacidad de comunicación para clientes desde el punto de vista de la accesibilidad a la hora de localizarnos y hablar con ellos a través de la web.

Así pues, el programa del curso 3CX Training Partner Básico de Málaga es el que se refleja a continuación:

09:00 – Apertura de puertas / Registro
09:15 – Jose María Caballero de 3CX presentará la última Central Telefónica 3CX versión 12.5
10:00 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:   

Curso 1: Introducción e instalación
1.1 Introducción a la Central Telefónica 3CX
1.2 Instalación de la Central Telefónica 3CX
1.3 Actualizar o Re-instalar

Curso 2: Teléfonos y Extensiones
2.0 Implementación de 3CXPhone
2.1 Configuración de los teléfonos IP (Snom y Yealink)
2.2 Configuración de Extensiones
2.3 Configuración de reglas de desvío

12:30 – Pausa coffe-break
13:00 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:

Curso 3: Proveedores VoIP, Gateways PSTN y creación de Reglas
3.1 Configuración de los proveedores de VoIP / SIP Trunks
3.2 Configuración de PSTN Gateways
3.3 Configuración de enrutamiento de entrada
3.4 Configuración de enrutamiento de salida

Curso 4: NAT y reenvío de puertos
4.1 NAT y reenvío de puertos
4.2 Extensiones Remotas
4.3 Inbound y Outbound – Conceptos Básicos

14:45 – Receso para Almuerzo
15:30 – Antonio Luis, Soporte Técnico 3CX en Avanzada7:

Curso 5: Resolución de problemas básicos
5.1 Servidor de registro de actividad
5.2 Servicio de Asistencia y Soporte
5.3 Información y Guías disponibles
5.4 Qué Hacer y Qué No Hacer

Curso 6: 3CX videoconferencia (Opcional si hay tiempo)
6.1 Configuración de una reunión web a través de 3CXPhone
6.2 Cliente de Windows vs WebRTC

16:45 – Preguntas y Respuestas. Final

Dependiendo de la evolución de la jornada, podremos tratar otros puntos de interés. Por último, un año más, el encargado de realizar esta jornada formativa seré yo mismo. Espero que os animéis y os inscribáis para asistir a este primer 3CX Partner Básico del año, que os recuerdo que es totalmente gratuito. ¡No os los penséis mucho, que las plazas se pueden agotar!

Para inscribirse en el curso, podéis hacerlo desde aquí mismo:

Categorías 3CX, Formación.

Parámetros estándares de líneas analógicas españolas

Como mencionaba en el artículo anterior, las líneas analógicas disponen de una serie de parámetros que deberíamos conocer de antemano, o al menos, tener la capacidad de averiguarlos de alguna forma. Las líneas analógicas españolas, y en principio, las de cada país, deben seguir unos estándares donde se definen los parámetros que éstas deben tener. Recogemos en este artículo los parámetros estándares para líneas analógicas españolas.

Tonos Regionales

Los tonos regionales más relevantes a la hora de configurar un gateway sip son: Dial Tone (tono de invitación a marcar), Ring Back Tone (tono que oímos cuando al realizar una llamada, el otro extremo está sonando),  Busy Tone (tono de ocupado) y Congestion Tone (tono de congestión). Los valores para estos tonos son:

Dial Tone: Frecuencia: 425 Hz , Volumen: -11, Cadencia: continuo

Ringback Tone: Frecuencia: 425 Hz , Volumen: -11, Cadencia: 1500 on 3000 off (cadencia en mili-segundos)

Busy Tone: Frecuencia: 425 Hz , Volumen: -11, Cadencia: 200 on 200 off (cadencia en mili-segundos)

Congestion Tone: Frecuencia: 425 Hz , Volumen: -11, Cadencia: 200 on 200 off 200 on 200 off 200 on 600 off (cadencia en mili-segundos)

Impedancia

600 Ohm

Inversión de Polaridad

Si

Método de Caller ID (Identificación de llamadas)

ETSI-FSK entre el primer y el segundo ring

Ejemplo: Grandstream

A continuación, se muestra como ejemplo, como quedarían estos parámetros su tuviéramos entre manos un gateway de la marca Grandstream

Dial Tone: 425@-11,c=0/0
Ringback Tone: 425@-11,c=1500/3000
Busy Tone: 425@-24,c=200/200
Congestion Tone: 425@-24,c=200/200-200/200-200/600

Impedancia de la línea: 600

Inversión de Polaridad: Habilitada (depende del modelo concreto)

Método de Caller ID: ETSI-FSK prior to Ringing with RP

Hay que tener en cuenta las siguientes consideraciones sobre los tonos regionales:

  • El volumen de los tonos busy y congestion se baja hasta -24. Recomendable en Grandstream para mejorar la detección de colgado.
  • Los valores de cadencias se representan el mili-segundos, indicándose así: on/off
  • La detección de Caller ID requiere que la llamada la retengamos en el gateway el tiempo equivalente a, al menos, 2 tonos de ring completos.
Categorías Analógicos, Gateways, Grandstream.

Líneas analógicas y Gateways SIP

A la hora de integrar una línea analógica con una central SIP, en la mayoría de los casos, acabamos usando Gateways analógicos. Dependiendo del tipo de línea analógica con la que nos enfrentemos, esta tarea puede ser relativamente sencilla o extremadamente complicada. Todo depende al final de la configuración de los parámetros analógicos de la línea en cuestión y de la forma de reflejar esos parámetros en la configuración del Gateway que tengamos entre manos. No vamos a entrar en detalles de configuración de un Gateway en concreto sino que se comentarán las características más relevantes de las líneas, tipos y como deberíamos configurar un Gateway según las mismas.

Parámetros básicos de líneas analógicas

Los parámetros básicos de una línea analógica, en cuanto a la configuración con Gateways SIP analógicos son los siguientes:

  • Inversión de Polaridad: Debemos conocer si la línea realiza inversión de polaridad al establecer y/o colgar una llamada.
  • Tonos regionales: Debemos conocer los tonos regionales que proporciona dicha línea. Los más relevantes son: Dial Tone (tono de invitación a marcar) , Busy Tone (tono de ocupado) , Reorder/Congestion Tone (Tono de congestión, usado normalmente como tono de desconexión de llamada), Ringing Tone (tono de ring).
  • Impedancia: Es un parámetro físico de la línea que toma relevancia cuando tratamos de mejorar la calidad de audio de la línea con el Gateway.
  • Método de Caller ID (Identificación de llamadas): Las líneas analógicas disponen normalmente de la información del número llamante (servicio que habrá que asegurarse tener activado si la línea la proporciona un Operador de Telefonía tradicional). Existen distintos métodos para pasar esta información a través de la línea. Hay que conocer pues, qué método está usando nuestra línea para pasar el identificador de llamada.
Tipos de Líneas Analógicas

Aunque todas las líneas analógicas comparten la misma tecnología y los mismos conceptos, desgraciadamente, no todas son iguales. Para las líneas analógicas españolas, se disponen de una serie de parámetros analógicos estándares que, en principio, todas deberían cumplir. Dichos parámetros son conocidos públicamente. Así pues, teniendo en cuenta este hecho, podemos encontrarnos con esta posible clasificación de líneas:

  • Línea analógica estándar: La clásica línea de voz que contratamos con Movistar. Cumple con los estándares.
  • Línea analógica de otros Operadores de Telefonía: El mismo caso de antes, pero líneas servidas por Ono, Jazztel, etc. Suelen cumplir los estándares, pero podemos encontrarnos casos de todo tipo.
  • Línea analógica proporcionada por un Trac Analógico-GSM (a.k.a. Licea): Aunque suelen proporcionarlos los Operadores de Telefonía, lamentablemente no suelen cumplir los estándares.
  • Línea analógica proporcionada por una centralita (Alcatel, Ericsson, etc.): Tampoco suelen cumplir los estándares.
  • Línea analógica que proviene de un Router de Fibra: Este tipo de líneas, tan de moda ahora con los packs integrados de conexión a Internet y telefonía no suelen cumplir los estándares tampoco.
La problemática real

Como podemos observar, el problema realmente no lo tendremos en nuestra capacidad a la hora de configurar un Gateway, sino a la hora de conocer los parámetros de la línea que tenemos entre manos. Conociendo estos datos de una línea, podemos configurar el Gateway analógico que queramos con nuestra central SIP sin mayores problemas.

Los problemas más relevantes que se nos pueden presentar son los siguientes:

  • Detección de colgado: El problema se da cuando, una vez establecida una llamada, se finaliza y la línea se queda ocupada. El Gateway en cuestión no detecta el colgado. Esto puede deberse a una configuración errónea de inversión de polaridad y/o configuración de tonos regionales. Para detectar el cuelgue, los Gateways usan distintos métodos (detección del tono de ocupado o de congestión, detección de inversión de polaridad, etc). Si no conocemos los tonos regionales que nos proporciona la línea o no sabemos si ésta realiza o no inversión de polaridad, no sabremos que debemos configurar en el Gateway, con lo cual, es probable que nuestro Gateway termine con una configuración no acorde con la línea que tenemos entre manos y éste no funcione correctamente a la hora de detectar el colgado.
  • Calidad de audio de llamadas: Este problema se da sobre todo cuando tenemos un parámetro de impedancia incorrecto o no acorde con la línea que nos ocupa. Debemos conocer la impedancia de la línea y configurar el Gateway acorde a la misma.
  • Salida de llamadas: Puede darse el caso en el que el Gateway no sea capaz de sacar llamadas a través de la línea. Puede deberse también a un problema de configuración de impedancia.
  • No se ve el Caller ID en llamadas entrantes: Este problema se cuando, obviamente, el servicio de Caller ID no está activo sobre la línea, con lo cual, habría que asegurarse de este hecho. Posteriormente, hay que tener en cuenta que tenemos el método de Caller ID correctamente configurado en nuestro Gateway en función de la línea que tiene conectada. Igualmente, también es necesario retener la llamada en el Gateway, por lo general, al menos 2 tonos de ring para que el Gateway sea capaz de ejecutar el proceso de detección de Caller ID. Un error muy común es caer en la tentación de querer hacer que la llamada pase inmediatamente a la parte SIP. Con esto, solo conseguiremos perder el Caller ID cuando entren llamadas del exterior.
Conclusiones

Como vemos, en general, el hecho de que un determinado Gateway presente problemas a la hora de tratar de integrarlo con una línea analógica no significa que el Gateway esté defectuoso o que el técnico en cuestión no sepa configurarlo. Tampoco significa que la línea esté mal. El problema básicamente está en conocer los parámetros de la línea y trasladarlos de forma correcta a nuestro Gateway.

Lo ideal siempre es tratar de conocer los parámetros de las líneas (consultando al Operador, al fabricante del enlace GSM Analógico, consultando la documentación del Router que la provee, etc.). En caso negativo, no nos quedaría más remedio que ir probando configuraciones poco a poco hasta afinar, de la mejor forma posible, los parámetros analógicos.

Categorías Analógicos, Gateways.

Uso de XML en la Autoconfiguración de productos Grandstream

Logo GrandstreamTodos aquellos que estamos en contacto con productos del fabricante Grandstream y con su proceso de auto configuración de terminales, gateways y demás, sabemos que este proceso se basa en una serie de plantillas en formato de texto plano, en las cuales vienen enumerados los parámetros de configuración de cada uno de los productos. Recordemos que existe una plantilla de texto para cada producto de la marca. Dichas plantillas las tenemos disponibles para su descarga desde el siguiente enlace:

http://www.grandstream.com/tools/GAPSLITE/config-template.zip

Si descomprimimos ese fichero ZIP tenemos las plantillas comentadas. Si nos centramos en una de ellas, por ejemplo, gxp2130_40_60_config_1.0.4.21.txt (todas son similares) veremos que el formato que tiene puede ser intuitivo: se define en cada línea un parámetro y su valor, teniendo en cuenta que cualquier línea que comience por # es un “comentario” y no se tiene en cuenta a la hora del procesamiento de configuraciones.

Cada línea en la que se define un parámetro es de la forma:

PXXX = VALOR

Algunos ejemplos:

# Account Name
# String
P270 = Cuenta 1

# SIP Server
# String
P47 = voip.miservidor.com

Cada número de parámetro es único. En estos casos, P270 define el nombre de la primera cuenta SIP de mi terminal (le pongo “Cuenta 1” en mi caso) y P47 define el servidor SIP de la primera cuenta SIP de mi terminal (le pongo “voip.miservidor.com”).

Pues bien, llegados a este punto, sabemos como establecer configuraciones de parámetros de terminales sobre plantillas.

Hay que destacar además que, una plantilla puede contener los parámetros que consideremos necesarios, es decir, no tenemos que tener siempre una plantilla con todos los parámetros definidos. Si por ejemplo, me interesa tener una plantilla donde solo defina, por ejemplo, el servidor SIP de la cuenta 1, bastará con tener definido únicamente el P47, borrando el resto de parámetros. Una plantilla solo modifica los parámetros que ella misma define, no alterando el resto de las configuraciones del producto.

¿ Cómo consigo mi fichero XML ?

El fichero XML de aprovisionamiento tiene el siguiente formato, para cualquier producto Grandstream:

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<gs_provision version=”1″>
<mac>000b82123456</mac>
<config version=”1″>
<PXXX>VALOR1</PXXX>
<PYYY>VALOR2</PYYY>

<PZZZ>VALOR3</PZZZ>
</config>
</gs_provision>

Si nos fijamos, para generar un XML de configuración para un producto necesitamos 2 cosas:

  • La MAC del producto
  • Los PXXX que queremos definir.

Así pues, para generar un XML de configuración para el caso que nos ocupa, suponiendo que la MAC de mi producto es 000b82123123, tendría que escribirlo de la siguiente forma:

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<gs_provision version=”1″>
<mac>000b82123123</mac>
<config version=”1″>
<P270>Cuenta 1</P270>
<P47>voip.miservidor.com</P47>
</config>
</gs_provision>

El nombre del fichero XML debe ser cfg{mac}.xml. Por lo tanto, en mi caso, el fichero debe llamarse cfg000b82123123.xml. Bastará coger el fichero XML y depositar dicho fichero en mi servidor de aprovisionamiento (TFTP, HTTP o HTTPS) para que el terminal lo descargue cuando proceda.

El proceso completo de aprovisionamiento de Grandstream es bastante extenso. EL objetivo de este post es explicar el uso de XML en dicho proceso. Queda fuera la explicación del sistema completo de aprovisionamiento de Grandstream así como posibles configuraciones de seguridad relativas al aprovisionamiento en sí.

Categorías Grandstream, xml.

Facebook compra WhatsApp

Facebook ha anunciado la compra de WhatsApp este Miércoles 19 de Febrero. La noticia ha saltado hoy mismo en la red. La operación de compra asciende a un total de unos 19 mil millones de dolares. Se trata de una cifra bastante alta, pero, hay que tener en cuenta el gran volumen de usuarios de los que dispone WhatsApp a día de hoy (según ellos, más de 450 millones). Por otro lado, es una aplicación cuyos usuarios son bastante activos.

Habrá que ver cual es el futuro que tiene pensado Facebook para WhatsApp. ¿Quizás algún tipo de integración con su plataforma de mensajería?, ¿seguirá siendo de pago?, ¿tendremos por fin WhatsApp vía web?. El tiempo nos despejará todas las dudas que nos puedan surgir acerca de esta compra estratégica por parte de Facebook. Aunque según WhatsApp , para los usuarios , este movimiento por parte de ambas empresas no va a traducirse en ningún cambio para el usuario final, ya que, según dicen, seguirá operando de forma independiente.

Categorías Mensajeria.

Nueva Certificación de 3CX

3CX ha actualizado su sistema de certificaciones. Hasta el momento, el único título oficial era el 3CX Certified Professional. Para la obtención de dicho certificado, había que pasar una prueba online de tipo test registrándose en la web de la academia de 3CX. Se trataba de un título personal pero que, al mismo tiempo, convertía a la empresa del alumno en empresa certificada en 3CX, lo cual suponía ciertas ventajas de reconocimiento en este mundillo.

Pues bien, desde hoy, existen 2 certificados nuevos, los cuales se pueden obtener siguiendo la misma vía, es decir, registrándose en la web de la academia de 3CX. Dichos certificados son:

  • 3CX Certified Engineer.
  • 3CX Advanced Certified.

 

El 3CX Certified Engineer es equivalente al antiguo 3CX Certified Professional. En este caso, se puede considerar que tan solo es un cambio de nombre y de logo del certificado.

El 3CX Advanced Certified es un nuevo certificado de mayor nivel de reconocimiento técnico de 3CX. Para poder obtener el Advanced Certified se necesita disponer antes del Certified Engineer.

Con respecto a cualquiera de los 2 exámenes online, tened en cuenta que sólo se dispone de una única oportunidad de realizarlo. Para aprobar no es suficiente con tener la mitad de las preguntas completamente correctas (no puedo decir más). Si se suspende, se puede solicitar un nuevo intento desde la web de la academia de 3CX. Suelen otorgar un segundo intento, pero al cabo de un tiempo.

Categorías 3CX, Certificación, Windows.