En una centralita IP, sobre todo si usas proveedores IP, es fundamental tener un sistema de QoS (Calidad del Servicio, en inglés), que regule el tráfico de/hacia Internet, y priorice el tráfico importante del que no lo es tanto.
De nada sirve (aunque ayuda) tener una conexión de 20 “megas” si, cuando un usuario de la red enchufa el bittorrent, tu interlocutor se convierte en Robocop. Por ello, la principal función del router será discriminar los paquetes que salen (y llegan) de Internet, en distintas clases, de forma que los pertenecientes a las clases con alta prioridad salgan los primeros, y los menos importantes salgan cuando puedan o, directamente, no salgan. Que un email tarde 20 segundos más en enviarse es un problema menor. Que no te escuchen, o te escuchen mal, es inaceptable.
En el mercado hay multitud de dispositivos que permiten hacer QoS. Routers Cisco, HP, Dell, y un largo etcétera. En la mayoría de casos, caros, muy caros. Si he de ser sincero, debo decir que no tengo experiencia con ningún Router “con mayúscula”. Amigos, la pela es la pela.
Sigue leyendo… Leer más…
Para una instalación que tenemos que hacer, todo con teléfonos SPA922,SPA942 y SPA962, hemos actualizado el sistema de provisionamiento de los PAP2 que publiqué hace tiempo.
Está hecho con la simplicidad como objetivo, y tratando de facilitar futuras instalaciones. Para esto utilizamos un sistema de plantillas en cascada, es decir, empezamos con una plantilla general, y vamos añadiendo personalizaciones, hasta llegar a la última, en la que prácticamente sólo hay que especificar el número de extensión (usuario) y la contraseña.
- {modelo}-default.cfg: Esta plantilla contiene los ajustes por defecto del modelo de teléfono. {modelo} se reemplaza por 922, 942, 962, etc. Más adelante os comento cómo generar este fichero.
- global.cfg: Aquí indicamos, como instaladores, las modificaciones a los ajustes por defecto. Por ejemplo, la regionalización, diccionarios de idiomas, etc. Así evitamos tocar la plantilla anterior, que puede variar con cada actualización del firmware.
- site.cfg: Ajustes para una instalación concreta, es decir, la IP del proxy, servidor NTP, Syslog, Zona horaria, etc.
- {modelo}-site.cfg: Ajustes más específicos para una instalación y modelo. Por ejemplo, para las actualizaciones de firmware, usando el Upgrade_Rule.
- {modelo}-{mac}.cfg: Finalmente la configuración de cada teléfono. Si el resto se ha hecho bien, solo queda indicar la extensión y contraseña.
El fichero de ajustes por defecto se genera a partir del xml que proporciona el teléfono en http://x.x.x.x/admin/spacfg.xml. Hay un script (xml2cfg) que “parsea” el xml, y lo convierte en pares de clave:valor.
Paso 1. Servidor DHCP
Los SPA9xx, cuando arrancan por primera vez (o después de un “factory reset”), buscan un servidor DHCP que les asigne una dirección IP. A continuación, intentan descargar desde el servidor, mediante TFTP, un fichero de configuración: spa922.cfg, spa942.cfg, etc, según el modelo.
En esta primera instancia, lo que haremos será redirigir el teléfono (mediante el parámetro Profile_Rule), a un script en PHP que genere la configuración definitiva. Además, forzaremos al teléfono a que descargue esta configuración lo antes posible (10 segundos, en lugar de 1 hora).
El fichero /tftpboot/spa922.cfg, por ejemplo, quedaría así:
<flat-profile>
<GPP_A ua="na">x.x.x.x</GPP_A>
<Profile_Rule ua="na">http://$A/provisioning/config.php?model=$PSN&mac=$MA</Profile_Rule>
<Resync_Periodic ua="na">10</Resync_Periodic>
<Resync_Error_Retry_Delay ua="na">10</Resync_Error_Retry_Delay>
<Resync_Fails_On_FNF ua="na">Yes</Resync_Fails_On_FNF>
</flat-profile>
Vemos que se dirige a un script (config.php), y que se le pasa como parámetro tanto el modelo como la MAC del teléfono.
Paso 2. El servidor Web
Todo el meollo está en el script config.php. Lo dejamos en /var/www/html/provisioning/, o donde más os guste. Al recibir una petición para un modelo y MAC concretas, leerá las plantillas de ajustes que correspondan, y generará una configuración completa para el teléfono.
Paso 3. Las plantillas de ajustes
Como las plantillas se leen en un orden concreto, y cada plantilla va sobreescribiendo los ajustes de la anterior, bastará con tener una configuración base, la que trae de fábrica el teléfono, y luego sobre esta, ir haciendo las modificaciones que precisemos.
Para generar esta plantilla base, podemos usar un pequeño script que incluyo:
$ cd /etc/provisioning/
$ wget http://ip.del.sp.a/admin/spacfg.xml
$ xml2cfg spa.cfg > 922-default.cfg
$ rm spacfg.xml
El resto de ficheros siguen el mismo formato, Clave:Valor. En el fichero global.cfg, por ejemplo, nosotros incluimos los ajustes de regionalización (frecuencia y cadencia de los tonos de línea, ocupado, etc), y otros ajustes comunes a todas las instalaciones que haremos.
Ejemplo de global.cfg: (Ajustes sacados de http://www.voipnovatos.es/item/2008/01/call-progress-tones-linksys-spa)
Dial_Tone:425@-10;10(*/0/1);
Outside_Dial_Tone: "425@-10;10(*/0/1);
Busy_Tone:425@-20;10(.2/.2/1);
Reorder_Tone:425@-10;10(0.2/0.2/1,0.2/0.2/1,0.2/0.6/1);
Off_Hook_Warning_Tone:425@-10;10(.25/.25/1);
Ring_Back_Tone:425@-10;10(1/4/1);
Call_Waiting_Tone:425@-20;10(0.175/0.175/1,0.0175/3.5/1);
Confirm_Tone:;
SIT1_Tone:950@-10,1400@-10,1800@-10;10(.33/0/1,.33/0/2,0.33/1/3);
SIT2_Tone:;
SIT3_Tone:;
SIT4_Tone:;
MWI_Dial_Tone:425@-10;10(1/0.1/1)" ;
Cfwd_Dial_Tone:425@-10;10(0.5/0.05/1)" ;
Holding_Tone:1400@-20;10(0.4/5/1)" ;
Conference_Tone:;
Secure_Call_Indication_Tone:;
Page_Tone:;
Ejemplo de site.cfg
Proxy_1_:x.x.x.y
Ejemplo de 922-AABBCCDDEE.cfg
Display_Name_1_:Julian
User_ID_1_:201
Password_1_:esunsecreto
Descargar el código
He montado un servidor SVN para éste y futuros proyectos, y para facilitar las mejoras (en forma de parches) que me enviéis ;). Se distribuye bajo licencia GPL:
$ svn co http://svn.julianmenendez.es/spa-provisioning/trunk spa-provisioning
Conclusión
Sé que hay muchas mejoras posibles, pero esto funciona, y al estar basado en plantillas de ajustes, realizar una instalación nueva solo requiere copiar los ficheros, ajustar el fichero site.cfg, y crear los diferentes ficheros de cada teléfono.
Como mejoras que me gustaría implementar, destacan:
- Generación estática de los ficheros de configuración. Después de hacer un “make”, por ejemplo, el script generaría los ficheros directamente en /tftboot/{model}-{mac}.cfg, de forma que sólo se requeriría un servidor TFTP.
- Interfaz web para gestionar las configuraciones
- Autoprovisioning. Detectar los nuevos teléfonos, y desde la interfaz web, poder rápidamente asignarles usuario/contraseña. Plug&Talk
Julián J. M.
Juan Carlos Valero, de Capatres, nos ha prestado un par de tarjetas de OpenVox, para poder probarlas, y de paso hacer un pequeño review. Las tarjetas son la B200P, para 2 puertos RDSI, y la A400P para hasta 4 puertos FXS/FXO.
Las Tarjetas
La A400P es clavadita a la TDM400P. Lleva el chip TigerJet 320, admite hasta 4 módulos FXS y FXO. Para los primeros es necesario proporcionar alimentación adicional a la tarjeta, mediante un conector molex. Los módulos son compatibles con los de Digium. De hecho, en la foto de arriba, los del 1 y 4 son OpenVox, y los 3 y 4 Digium.
La B200P lleva el chip HFC-4S, que puede gestionar hasta 4 puertos. De hecho, si os fijáis, la diferencia es que no tiene soldados los componente de dos de los puertos. Alguien con tiempo libre, y sin miedo a perder la garantía, podría intentar habilitar estos dos puertos extra ;).
Lo bueno de la tarjeta, comparándola con la Billion HFC de un solo puerto, es que dispone de jumpers para seleccionar el modo de operación: TE, para conectarlo a un TR del operador, o NT para conectar un teléfono RDSI. Además, para este último caso, dispone de un conector molex, para poder proporcionar el voltaje necesario a la línea, y que los teléfonos tomen de ahi la energía.
Instalación y configuración
Una vez pinchadas en sendos slots PCI, así es como las detecta el sistema operativo:
$ lspci
[...]
03:08.0 Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface
03:09.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
[...]
La primera de ellas es la A400P, y la segunda la B200P.
A400P
La configuración de la A400P es exactamente igual a la TDM400P de Digium. Es decir, definimos en /etc/zaptel.conf los módulos instalados, en nuestro caso un FXS en el puerto 1 y un FXO en el 4:
loadzone = es
defaultzone=es
fxoks=1 ; La señalización es justo al contrario
fxsks=4
En /etc/asterisk/zapata.conf :
[channels]
language=es
signalling=fxo_ks
context=from-internal
callerid=Extension Zap <201>
channel=>1
;
signalling=fxs_ks
context=from-pstn
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
polarityonanswerdelay=1
channel=>4
Comprobamos en asterisk que los puertos estén disponibles:
tamaja*CLI> zap show channels
Chan Extension Context Language MOH Interpret
pseudo from-pstn es default
1 from-internal es default
4 from-pstn es default
Las llamadas desde la extensión se dejan en el contexto from-internal. Las llamadas desde la red telefónica entran por from-pstn.En /etc/asterisk/extensions.conf:
; Dialplan minimalista
[from-internal]
exten => _[6789]XXXXXXXX,1,Dial(Zap/4/${EXTEN})
;
[from-pstn]
exten => s,1,Dial(Zap/1)
exten => s,n,Hangup
B200P
Seguimos con la B200P. Podemos usar tanto el parche Bristuff, como tirar de chan_misdn. Yo prefiero la segunda opción.
Descargamos e instalamos mISDN (modulos del kernel) y mISDNUser (aplicaciones) desde http://www.misdn.org. El script misdn-init, que se instala en /etc/init.d/ nos permite detectar las tarjetas compatibles y generar el fichero de configuración. Además, usado en el arranque y parada del servidor, carga y descarga los módulos.
$ /etc/init.d/misdn-init scan
[OK] found the following devices:
card=1,0x4
[ii] run "/usr/sbin/misdn-init config" to store this information to /etc/misdn-init.conf
.
$ /etc/init.d/misdn-init config
[OK] /etc/misdn-init.conf created. It's now safe to run "/usr/sbin/misdn-init start"
[ii] make your ports (1-4) available in asterisk by editing "/etc/asterisk/misdn.conf"
Editamos el fichero de configuración /etc/misdn-init.conf. En primer lugar, desactivamos los puertos 3 y 4, ya que esta tarjeta no los tiene. Además, dado que las dos RDSI están configuradas en grupo, en modo PTP, tendremos que modificar ese parámetro:
card=1,0x4
te_ptp=1,2 ; solo dos puertos, yen modo PTP
poll=128
dsp_poll=128
dsp_options=0
dtmfthreshold=100
debug=0
Arrancamos el servicio, para que se carguen los módulos:
$ /etc/init.d/misdn-init start
-----------------------------------------
Loading module(s) for your misdn-cards:
-----------------------------------------
/sbin/modprobe --ignore-install hfcmulti type=0x4 protocol=0x22,0x22,0x2,0x2 layermask=0xf,0xf,0xf,0xf poll=128 debug=0
/sbin/modprobe mISDN_dsp debug=0x0 options=0 poll=128 dtmfthreshold=100
[i] creating device node: /dev/mISDN
Copiamos ahora el fichero de configuración de misdn que viene con asterisk, y lo adaptamos. Básicamente, añadimos esta sección al final:
[telefonica]
ports=1,2
msns=*
context=from-pstn
echocancel=yes
Hemos definido un grupo (telefonica), que utilizará los puertos 1 y 2 de la tarjeta. Aceptará todos los MSN (o DID’s), y entrarán las llamadas al contexto from-pstn.
tamaja*CLI> misdn show stacks
BEGIN STACK_LIST:
* Port 1 Type TE Prot. PTP L2Link DOWN L1Link:DOWN Blocked:0 Debug:0
* Port 2 Type TE Prot. PTP L2Link DOWN L1Link:DOWN Blocked:0 Debug:0
Aún no hemos conectado las líneas, por eso aparecen DOWN.
Así quedaría nuestro dialplan de ejemplo, en /etc/asterisk/extensions.conf:
; Dialplan minimalista
[from-pstn]
exten => 928000000,1,Dial(Zap/1)
exten => 928000000,2,Hangup
[from-internal]
exten => _[6789]XXXXXXXX,1,Set(CALLERID(num)=928000000)
exten => _[6789]XXXXXXXX,n,Dial(mISDN/g:telefonica/${EXTEN})
Estamos usando el grupo que definimos antes para realizar las llamadas. También podríamos utilizar un puerto específico (mISDN/1/${EXTEN} o mISDN/2/${EXTEN}).
Conclusión
Las tarjetas funcionan, el aspecto y fabricación son buenos. Queda eso sí, probarla durante un tiempo en una centralita en producción, pero tengo la sensación de que no darán problemas. Si los hubiese, seríais los primeros en saberlo 
En definitiva, si todo sigue como hasta ahora, y teniendo una empresa en España que distribuya las tarjetas y gestione las garantías (en lugar de reclamar directamente a los chinos de OpenVox), son una opción igual de válida, pero más económica, que las originales.
