Provisión de terminales

Introducción

IvozProvider soporta provisionar terminales vía HTTP/HTTPS que sigan la forma de provisionarse que se explica a continuación:

  • Cuando un terminal sale de la caja, se alimenta y se conecta a la red:

    • Pide IP por DHCP.

    • Se fija en la opción 66 de DHCP que le indica a quién tiene que pedir su configuración.

    • Pide un primer archivo añadiendo a la ruta recibida por DHCP un archivo estático (cada modelo de terminal, uno distinto).

    • En ese archivo se le puede indicar un siguiente archivo a pedir.

Todo terminal que sea capaz de adaptarse a este formato podrá provisionarse utilizando la sección Configuración general > Fabricantes de terminales.

Ejemplo Cisco SPA504G

  • Cisco 504G se despierta y pide IP.

  • Recibe “http://provision.ejemplo.com/provision”

  • Pide la configuración vía http a http://provision.ejemplo.com/provision/spa504g.cfg

  • Todos los 504G solicitan el mismo archivo (spa504g.cfg), añadiéndolo a la ruta que reciban.

  • En ese primer archivo común se especifican los parámetros comunes a todos los terminales de ese modelo concreto y qué archivo tienen que pedir a continuación (ejemplo https://provision.example.com/provision/$MAC.cfg)

  • De esta forma, hacemos que cada terminal (la MAC es única) pida un archivo concreto (y distinto) una vez que ha pedido el genérico.

  • En este archivo se le sirve su configuración específica:

    • Usuario

    • Contraseña

    • Dominio SIP

Nota

El sistema de provisión de IvozProvider, a día de hoy, configura los terminales con el único objetivo de que se registren y se queden en el idioma del usuario.

Configuración de modelos soportados

IvozProvider utiliza un sistema de plantillas que permite que el operador global (God) defina nuevos modelos de terminales y configure los archivos que se les servirá.

La sección de ayuda de Fabricantes de Terminales contiene ejemplos que funcionan (en el momento de escribir esta documentación) con el sistema de provisión de IvozProvider.

Consejo

Estos modelos aparecen en la sección tras la instalación, pero hay que entrar a cada uno de ellos a cargar la configuración por defecto antes de poder usarlos (opción Restore default template).

Error

Cambios en el firmware de los terminales pueden provocar que los ejemplos proporcionados dejen de funcionar. Se intentará mantenerlos actualizados, pero no podemos garantizar que siempre lo estén.

Analizando las plantillas sugeridas, puede hacerse una idea básica de la flexibilidad del sistema para configurar cualquier modelo de terminal en el mercado y para adaptarse de posibles cambios en los ejemplos dados.

Detalles técnicos

Imaginemos un escenario con esta configuración:

¿Qué URLs de petición serán correctas?

Para el archivo genérico, solo una: http://PROV_IP/provision/y000000000044.cfg

Para el archivo específico, la petición tiene que satisfacer las siguientes reglas

  • Todas las peticiones HTTP son erróneas.

  • Las peticiones HTTPS al puerto 443 son erróneas (se tiene que usar PROV_PORT)

  • Las subrutas después de la URL de provisión son ignoradas, tanto en la petición como en el campo specificUrlPattern.

  • La extensión de la petición tiene que ser la misma que la extensión del campo specificUrlPattern (en caso de que la tenga). Si no, la extensión es ignorada.

  • El nombre del archivo solicitado tiene que coincidir exactamente con el nombre especificado en specificUrlPattern, una vez que {mac} se sustituya por el valor adecuado.

  • La dirección MAC no distingue mayúsculas/minúsculas y puede contener dos puntos o no.

Analicemos los siguientes ejemplos para entender estas reglas mejor:

Ejemplo 1 - TerminalModels.specificUrlPattern: {mac}.cfg

Peticiones correctas:

https://PROV_IP:PROV_PORT/provision/aabbccddeeff.cfg
https://PROV_IP:PROV_PORT/provision/aa:bb:cc:dd:ee:ff.cfg
https://PROV_IP:PROV_PORT/provision/aabbccdd:ee:ff.cfg
https://PROV_IP:PROV_PORT/provision/aabbccddeeff.cfg
https://PROV_IP:PROV_PORT/provision/AABBCCDDEEFF.cfg
https://PROV_IP:PROV_PORT/provision/subpath1/aabbccddeeff.cfg
https://PROV_IP:PROV_PORT/provision/subpath1/subpath2/aabbccddeeff.cfg

Peticiones erróneas:

https://PROV_IP:PROV_PORT/provision/aabbccddeeff.boot
https://PROV_IP:PROV_PORT/provision/subpath1/subpath2/aabbccddeeff.boot

Este ejemplo es idéntico a ‘t23/{mac}.cfg’, ya que las subrutas se ignoran.

Ejemplo 2 - TerminalModels.specificUrlPattern: {mac}

Todos los ejemplos anteriores son correctos, ya que la extensión de la petición se ignora al no haber especificado extensión alguna en specificUrlPattern.

Este ejemplo es idéntico a ‘t23/{mac}’, ya que las subrutas se ignoran.

Ejemplo 3 - TerminalModels.specificUrlPattern: yea-{mac}.cfg

Todos los ejemplos anteriores son incorrectos, ya que ninguno contiene ‘yea-‘ (en minúsculas).

Peticiones correctas:

https://PROV_IP:PROV_PORT/provision/subpath1/yea-aabbccdd:ee:ff.cfg

Peticiones erróneas:

https://PROV_IP:PROV_PORT/provision/subpath1/yea-aabbccdd:ee:ff.boot
https://PROV_IP:PROV_PORT/provision/subpath1/YEA-aabbccdd:ee:ff.cfg

Este ejemplo es idéntico a ‘t23/yea-{mac}.cfg’, ya que las subrutas se ignoran.

Ejemplo 4 - TerminalModels.specificUrlPattern: yea-{mac}

Como no se especifica ninguna extensión:

https://PROV_IP:PROV_PORT/provision/subpath1/yea-aabbccdd:ee:ff.cfg
https://PROV_IP:PROV_PORT/provision/subpath1/yea-aabbccdd:ee:ff.boot

Peticiones erróneas:

https://PROV_IP:PROV_PORT/provision/subpath1/YEA-aabbccdd:ee:ff.cfg

Este ejemplo es idéntico a ‘t23/yea-{mac}’, ya que las subrutas se ignoran.