Conectandonos al mundo Real: El planeta Gateway I

En estos momentos mi pretension se encuentra en poder ofrecer servicios de la PSTN a mi centralita Asterisk. En la actualidad existen dos opciones principales:

1. Hacer la conexion a traves de tarjetas internas, PCI o PCIe en el servidor Asterisk
2. Hacerla a traves de Gateways que utilizan principalmente el protocolo SIP y a traves de una interfaz ethernet comunicarse con ellos.

Obviamente cada opcion tiene sus ventajas y desventajas. La primera opcion, al ser parte del servidor, se configura a traves del modulo Dahdi, y para grandes instalaciones resulta muchisimo mas sencillo hacer una instalacion de las mismas, ya que copiando los ficheros de configuracion de uno a otro se conseguirian los mismos resultados. Ademas el manejo de las mismas es “puro” y solo intervendria el sistema operativo y el propio Asterisk, aunque esto no tiene porque ser realmente una ventaja.

Por otro lado los gateways, tienen una espectacular ventaja sobre las tarjetas, y un pequeño inconveniente bajo mi criterio (a lo mejor tienen mas y estoy abierto a descubrirlos), pero que quiza haga que la espetacular ventaja sea muy superior a todos los inconvenientes y particularmente incline la balanza en un gran numero de casos en los que sea necesaria una implantacion de las mismas.

Y la gran ventaja de la que hablo es sencilla: La alta disponibilidad al minimo coste. Cuando contamos con 1 o mas gateways (preferiblemente mas de 1), realmente es como si contaramos con multiples servidores. Si tenemos por ejemplo dos servidores Asterisk funcionando, con heartbeat de por medio y un sistema de varios Gateways en funcionamiento, en caso de caer un servidor, automaticamente el segundo utilizaria exactamente los mismos gateways para su funcionamiento, sin la necesidad de tener que redundar las tarjetas para este supuesto. Hoy en dia en casos de Comunicaciones de Voz, la alta disponibilidad es crucial, ya que en la mayor parte de los casos, llamadas perdidas supone, clientes perdidos. Hoy en dia una centralita caida es mas dramatico que el servidor de bases de datos caidos, ya que las operaciones que comunmente podemos hacer a traves de un ordenador, pueden hacerse temporalmente a mano para aliviarlo, pero los clientes que no tienen forma de contactar con nosotros… ¿que podemos hacer en contrapartida para hacer que sea menos dañino? En la mayor parte de las ocasiones, sin un sistema alternativo… nada, clientes perdidos.

Curiosamente, a nivel comparativo, Gateways de diferentes marcas, cuestan exactamente igual que tarjetas con las mismas especficaciones. Esto es, un Gateway Linksys SPA8000 con 8 extensiones FXS cuesta apenas 200 euros en Octubre 2010, frente a lo que podria costar una TDM800P con sus 2 tarjetas FXS de 4 extensiones FXS cada una cuesta exactamente el triple. Y encima con el gateway conseguimos lo comentado anteriormente.

Lo mismo ocurriria con las lineas ISDN (RDSI). Un gateway normalito como podria ser un Epygi Quadro ISDN con 4 puertos BRI TE/NT cuesta exactamente lo mismo que una de las tarjetas mas baratas como la Beronet QuadBRI que en este caso ni siquiera tiene mucho mas que ofrecer por no ser propio de Digium, lo que da mucho que pensar si verdaderamente merece la pena. Tambien tenemos las tarjetas especificas Digium como la B410P que tampoco eleva el coste demasiado, pero considerando lo anterior, no es para menos.

Pero ya puestos un poco sobre antecedentes, y el porque de mi decision, ahora viene quiza lo mas interesante de este articulo: Las configuraciones de los Gateways. He conseguido hacerme con los dos gateways que puse de ejemplo. Para los puertos FXS disponia como opciones los Grandstrem, y para los BRI, disponia tambien como opcion los gateways Vegastream Europa. Concretamente los primeros en diversas pruebas se ha demostrado que reportan una muy inferior calidad comparativamente a los Linksys, con respecto a los segundos no puedo decir lo mismo, pero el costo en este caso hablaba por si solo (algo mas de un 20% para los 4 canales, similiar a las tarjetas especificas Digium).

En este caso mi idea de configuracion es muy sencilla:

En el gateway Epygi, montar en los dos primeros puertos, dos linea RSDI, que forman un grupo ISPBX reportado por la operadora, y en los dos segundos, montar dos Enlaces GSM cortesia de la operadora tambien, con puertos ISDN. Por tanto en ambos casos los cuatro puertos se configuran como TE (Terminal Equipment) puesto que son los que van a recibir el servicio.

La interfaz web del Epygi Quadro ISDN , es un poco escabrosa y bastante poco intuitiva pero cuando le coges el truco no desvela un gran misterio:

Primero hay que configurar las opciones ISDN. En el apartado Telephony -> ISDN Settings aparcen los 4 “troncales” numerados. Contamos con que en el troncal 1 y 2 montamos las RDSI y en el 3o y 4o montamos los enlaces GSM RDSI. Hay que configurarlos uno a uno, aunque tampoco es demasiado sofisticado

Pantalla Principal de configuración de los Puertos ISDN

Dentro del primer troncal, elegimos la interfaz tipo User porque esta conectado a la central (recordemos TE) y PTMP point to multipoint, realmente no va a cambiar mucho si ponemos PTP porque solo es un metodo de comprobacion que no tenemos el troncal ISDN conectado a mas sitios aparte de la Quadro, esto no va a generar ningun tipo de inconveniencia a priori, aunque sinceramente me queda investigar las posibles implicaciones colaterales e mantener esto en PTMP aun a riesgo de no tener por mi parte conectado el troncal ISDN a otros aparte del gateway y utilizar este modo.

Le damos a Next y en la siguiente parte, el Tipo MSN (multiple subscriber number), porque en caso de las RDSI es muy comun tener opcion a contratar multiples numeros que nos pasara la operadora y nosotros luego podremos enrutar en nuestra centralita para que se dirijan a una interfaz un a otra.

Seguimos adelante con Next, y aqui nos aparece toda la seleccion posible de MSN que tenemos a nuestra disposicion (las operadoras les llaman numeros DID (direct inward dialing) en este caso nuestro interes es mandarlo directamente a nuestra centralita Asterisk por esto seleccionamos la opcion por cada numero: Routing with inbound destination number

Tambien podemos poner el Caller ID por defecto en las llamadas salientes por este medio. En este caso el Caller ID debera ser uno de los MSN preferentemente el cabecera. Esta opcion no es imprescindible.

Y si continuamos a la siguiente pantalla sin haber marcado la opcion de Opciones Avanzadas (de momento sin entrar en mas materia no es necesario señalarla) ya habremos concluido la configuracion del primer troncal.

Para el segundo troncal exactamente lo mismo. Pero para el tercer y cuarto troncal seria bueno hacer una pequeña distincion. En estos casos, no es verdaderamente necesario señalar la opcion MSN (en este caso ponemos No MSN), ya que con los Enlaces GSM RDSI no se pueden aplicar multiples numeraciones. El resto es muy sencillo, la unica diferencia que no aparecer la lista en la que podemos ir señalando cada uno de los multi-numeros (como les llama Telefonica mas concretamente).

Para finalizar esta parte de la configuracion del Gateway finalmente, nos toca configurar en detalle como tratara el mismo las llamadas entrantes y salientes. Porque al igual que en un Plan de Marcacion, se pueden especificar rutas.

Todo esto se hace desde Telephony -> Call Routing -> Call Routing Table

Pantalla Principal de configuración de los enrutamientos de llamadas

Por un lado tenemos que configurar el camino Gateway -> Asterisk. Para ello pulsamos la opcion Add de añadir y seguimos con:

Enable Record activado
Tipo de llamada, SIP
Pattern: * (para que sean todas las llamadas sin distincion)
Descripcion: asterisk (aqui ponemos lo que queremos, yo pongo asterisk para saber hacia donde va)

Y seguimos hacia la siguiente pantalla, con Next:

Destination Host: Nuestro servidor Asterisk
Destination Port: El Puerto, por regla general 5060
Usuario y Contraseña, esto lo tendremos que configurar en el sip.conf!
Lo mas importante: FailOver Reason, Any o seleccionamos las que deseemos. Esto es por el hecho que vamos a decirle que en caso que el canal uno este ocupado los dos canales, automaticamente nos pase las llamadas al tercer y cuarto canales del troncal numero 2. El resto por defecto.

Seguimos adelante con Next hasta las opciones de llamada entrante:

Inbound Call Type: ISDN
Pattern: * (lo mismo que antes)
Number of Discard Symbols: 1 (si ponemos 1 en la mayor parte de los casos eliminamos una serie de informacion innecesaria para recibir el Caller ID)

Y ya el resto podemos seguir hasta el final con los parametros por defecto.

Por otro lado tenemos que configurar el camino Asterisk -> Gateway (trunks ISDN). En este caso nuestra intencion es que el 100% de las llamadas salgan por los Gateways GSM, pongamos por el hecho de que obtenemos una mejor tarifa a traves de ellos, o en otro caso podriamos configurar para salir por el troncal que deseemos en funcion de nuestro interes.

Lo curioso de esta centralita es que posee un pequeño handicap que tenemos que resolver a traves de patrones de llamada: No podemos de forma directa establecer un patron de rotacion entre canales mas alla del troncal en que nos encontremos, ya que por cada ruta, solo podemos asociar un unico Troncal. De aqui puede surgir la pregunta: ¿Y como pasamos las llamadas que no podemos atender con el troncal seleccionado, al siguiente libre? Sencillo: Simplemente establecemos una Razon de Failover dentro de la ruta del troncal desbordado, y automaticamente pasara a sucesivos troncales, en el orden en el que establezcamos las rutas. En este caso, segun vemos en la imagen, todas las llamadas saldrian por la ruta numero 2. Si los dos canales estuvieran usandose, entonces existiria una razon incondicional de failover, y saltarian automaticamente hacia el segundo troncal (en este caso Troncal numero 4), que estaria establecido en la ruta con identificador numero 3.

¿Como podriamos establecer un sistema de rotacion automatico? Si pusieramos un patron diferente en la ruta 2 y la ruta 3, ejemplo 2* y 3* (siendo asterisco, el numero que sea despues del 2 o el 3 respectivamente) entonces, podriamos realizar la decision previamente desde nuestra centralita y pasar el patron del numero con el prefijo 2 o 3 delante. Seria un pseudo mecanismo de rotacion, pero digamos, que esto podriamos incluirlo en el saco de las desventajas de los gateways, los firmwares tan “pesimos y limitantes” que suelen traer por defecto.

Pero igual, ¿como configurar esto aqui descrito?

Pulsamos la opcion Add como anteriormente y seguimos con:

Enable Record activado
Tipo de llamada, ISDN
Pattern: * (para que sean todas las llamadas sin distincion)
Descripcion: isdn 1 (aqui ponemos lo que queremos, yo pongo isdn 1 para saber que es el primer troncal de salida)

Seguimos hacia adelante con Next:

Port ID: Trunk 3 (recordemos que era el troncal 1 de nuestros Gateways GSM ISDN)
Failover Reason: Any (failover incondicional como explique antes)

Seguimos adelante,

Seleccionamos los dos Time Slots, y a continuacion:

Pattern: * (igual que siempre)
Inbound Call Type: SIP (justo al contrario que antes, la idea es conseguir SIP->ISDN en este caso)

Y para finalizar, en el siguiente paso: Inbound Host, seleccionamos la IP de nuestro servidor Asterisk y finalizamos

Para la segunda ruta, la del Trunk 4, todo se hace exactamente igual, a excepcion, de poner en Port ID: Trunk 4 (como es logico) y en la razon de Failover, None, para que no de mas vueltas si ya desbordamos a partir de ahi (¿a donde va a desbordar si no tenemos nada mas?) A mi solo se me ocurre una posibilidad: quiza podria ocurrir, que mientras los dos primeros canales estan ocupados, se ocupen los dos siguientes, y a la quinta llamada de salida, ocurra que uno de los dos primeros canales se liberase. En este caso podriamos poner Failover: Any tambien, y al volver a tratar de buscar un canal libre, encontraria uno de los dos del primer troncal. Asi que esto lo dejo abierto al gusto de cada uno.

Y ya esta por hoy. Tendriamos finalmente configurado nuestro Gateway ISDN Quadro de Epygi, muy robusto y la verdad, aun poco intuitiva interfaz, cuando le coges el truco, no tiene perdida como podéis observar.

En la proxima sesion de Gateways explicare como configurar el fichero sip.conf para asociarse con este troncal gateway (adelanto que es una configuracion MUY parecido a lo que podria ser un operador SIP como hablamos en anteriores entradas), y tambien como configurar el plan de marcacion, para aceptar llamadas entrantes de este gateway, y salientes a traves del mismo (mas de lo mismo que los operadores SIP, no tiene mucha perdida)

Y tambien incluire algo acerca del Linksys SPA8000, que aunque aun no domino a la perfeccion sobre para dar el servicio a nivel de funciones especiales para los telefonos analogicos, como teclas para Voicemail, transferencia de llamada, llamada en espera, etc y todavia estoy investigando acerca de esto, pero al menos para ir empezando, la configuracion basica para ponerlos en funcionamiento.

Con este blog, quiero recordar a cualquiera, que lo animo para montarse a muy bajo coste una potente centralita propia, y autogestionada, que como esta hoy el mercado de las PBX, supone un espectacular ahorro de costes para cualquier empresa, especialmente cuando hablamos de PYMES.

Una Nueva Maquina para el Sistema

Por razones de la vida, he encontrado una maquina HP Proliant ML 110 de Cuarta Generacion (G4), abandonada en una de las instalaciones. Realmente no estaba abandonada, pero estaba siendo infrautilizada, asi que he decidido tomarla prestada, para cambiarla por el servidor que actualmente estoy utilizando, que es parecido, pero no es HP.

Realmente este servidor no trae nada especial, ya que en realidad la serie ML110 vienen a ser Workstations con procesadores de Servidor, y en este caso una placa que soporta hasta 8GB de memoria ECC DDR2. De igual forma como de momento no estoy llevando el servidor a niveles de produccion, he preferido instalarle buena cantidad de memoria no-ECC para que resulten las cosas como corresponden, ya que originalmente solo traia un modulo de 512Mb DDR2 PC5300 ECC que aunque sea Linux, ya no me convence esta cantidad demasiado para ninguna labor de hoy en dia. He montado 2 memorias de 2Gb DDR2 PC6400 no-ECC en Doble Canal. El resto por defecto de fabrica. Llegado el momento, aqui tambien montare la Tarjeta Digium que envie el otro dia en Garantia ya que posee varios slots  PCI, mas que el PC-Workstation que estaba utilizando con anterioridad (y quiza en un futuro tambien poder montar alegremente la tarjeta de Primario para las pruebas correspondientes)

Este mensaje realmente lo escribo como una primera aproximacion de lo que seria una rapida migracion de sistema, para demostrarme a mi mismo, que aun bajo una caida de mi centralita, la reposicion seria cuestion de minutos/horas desde mi atencion.

En primer lugar, instalo Ubuntu Server, monto el sistema RAID con mdadm y LVM2 encima en tres particiones tal y como se explico en el mensaje:
http://www.10000horas.com/2010/08/08/primer-sistema-base-ubuntu-server-y-md-raid/

En segundo lugar, la instalacion del Sistema Asterisk, paso facil y bastante “automatizado” de momento:
http://www.10000horas.com/2010/08/09/manos-a-la-obra-con-asterisk/

En tercer lugar, en el servidor antiguo simplemente copio los directorios que han incurrido en posibles modificaciones (realmente son unos pocos ficheros, pero me gustaria conservar todos los pequeños cambios y no quiero que se me olvide nada). En modo super usuario en el servidor antiguo:

# cd etc
# tar -cf asterisk.tar asterisk/
# scp asterisk.tar ipdelnuevoservidor:/tmp/
# tar -cf dahdi.tar dahdi/
# scp dahdi.tar ipdelnuevoservidor:/tmp/

NOTA (26/10/2010): Tras ampliar mi abanico de conocimientos he observado que se requieren mas carpetas para migrar el sistema completo. La verdad es que no me lei a fondo la documentacion con respecto a los directorios que utiliza el sistema Asterisk por defecto.

El comando “magico” (agradecimientos a Elio Riojano) para conseguir un backup completo de asterisk: tar cvfj asterisk-backup-`date +%Y%m%d-%H%M%S`.tgz /etc/asterisk /var/lib/asterisk /var/spool/asterisk /etc/dahdi
Seguramente se pueda completar aun mas, pero para mis propositos actuales, me sobra y me basta.

Finalmente, copiamos estos ficheros de nuevo a nuestro directorio /etc del nuevo servidor Asterisk. Aqui voy a dar algunos pasos innecesarios realmente, pero que podrian ser utiles y no son dañinos realmente

# cd /etc
# mv /tmp/asterisk.tar /etc/
# mv /tmp/dahdi.tar /etc/
# mv asterisk/ asterisk.old/ (opcional)
# mv dahdi/ dahdi.old/  (opcional)
# tar -xf dahdi.tar
# tar -xf asterisk.tar

Ahora ya tenemos configurado el sistema tal y como lo teníamos antes. Probamos si funciona y si esta todo correcto, podriamos borrar esos directorios .old o mantenerlos por si necesitamos mirar algo (aunque en teoria para eso esta el directorios de ejemplos (samples) que creamos durante la compilacion, asi que estos datos dejarlos ahi seria innecesario realmente).

Finalmente y opcional hasta este punto, copiar las grabaciones que hicimos (si son de calidad, no es mi caso en este momento)

# tar -cf sounds.tar /var/lib/asterisk/sounds/
# scp sounds.tar ipdelnuevoservidor:/tmp/

Y luego justo al reves, copiamos de tmp a sounds en nuestro nuevo servidor, exactamente igual que hicimos antes con las configuraciones

Hacemos algunas llamadas de pruebas, tanteamos nuestro servidor SIP externo, y en teoria ya deberia estar todo funcionando.

Tiempo estimado total: 2 horas, de las cuales 1 hora y media son desatendidas entre instalaciones y compilaciones.

La verdad que con esta gestion he conseguido autodesmitificarme que la migracion ante una posible incidencia grave, resulta verdaderamente sencilla. Y en este caso ya hemos identificado tres directorios que seriainteresante tenerlos en una rutina de backup eventual para poder reestablecer el sistema en caso de tener problemas, quiza con cron. Ya veremos resumidamente algunas rutinas basicas con cron, para establecer entre otras cosas, actualizaciones de sincronizacion de hora efectivas, y como aqui planteado, backups automaticos.

Combate Analogico: Primer Asalto

En estos dias, como ya adelante, he estado tratando de integrar la telefonia Analogica en la centralita de pruebas.

Para ello he utilizado la tarjeta que me ofrecieron en el curso, la Digium TDM410P y que nunca se llego a probar por problemas de tiempo (solo se explico por encima la idea de configuracion y varios de los atributos mas comunes).  Esta tarjeta trae dos modulos, uno Verde (FXS para conectar un telefono por ejemplo analogico) y una FXO (para conectar una fuente, una linea analogica de la PSTN, una extension de una centralita)

Como introduccion, comentar que en Asterisk, el mundo analogico se integra a traves de los modulos Dahdi, Dahdi-Linux-Complete fue el paquete que instale y que estaba compuesto por dos subpaquetes como comente en su dia

Por otro lado, hay que saber que Dahdi digamos que tiene dos formas de comunicacion: Una directamente con el sistema, con el Kernel de Linux, añadiendo los modulos y drivers de las tarjetas, y la configuracion especifica. La carga de modulos se especifica en el fichero /etc/dahdi/modules y los parametros de configuracion de las tarjetas en el Kernel en el fichero /etc/dahdi/system.conf

Concretamente en el fichero modules, el modulo que nos interesa seria el correspondiente a las tarjetas TDM410P, el wctdm24xxp. El resto los podriamos eliminar porque no vamos a usarlos eventualmente

Para la configuracion de la tarjeta, en el fichero system.conf  he utilizado lo siguiente, comentado, la explicacion sobre cada elemento:

# Puerto 1 tarjeta Analogica = Modulo FXS VERDE
fxoks=1
# Puerto 4 tarjeta Analogica = Modulo FXO ROJO
fxsks=4
loadzone=es
defaultzone=es
# Canceladores de Eco Software
echocanceller=mg2,1
echocanceller=mg2,4

Por otro lado, seria necesaria la configuracion del fichero que “intercomunica” los modulos de la tarjeta con nuestro sistema Asterisk. Esto se registra en el fichero /etc/asterisk/chan_dahdi.conf (Canal Dahdi, equivalente en este caso al Canal SIP que vimos con anterioridad).

Pero antes de esto estuve investigando a ver si realmente la tarjeta estaba totalmente operativa. Hay un comando, dahdi_tools que muestra el estado de la tarjeta y de sus modulos por encima, y pude observar como aparecia la Wildcard TDM410 correctamente.

Pero por otro lado, observe que conectando un telefono al puerto FXS, este no recibia ningun tipo de corriente. Entonces cai en la cuenta que era necesario aportarle corriente a la tarjeta TDM a traves de un conector Molex que integra la placa. Asi, hice la conexion oportuna y volvi a arrancar el sistema.

Y aqui empezó lo malo del dia: el telefono seguia sin recibir corriente. Dos de los LEDS de la tarjeta parecian encendidos indicando, que los modulos estaban operativos. Investigando un poco en los mensajes del Kernel durante el inicio (Comando: dmesg) encontre la siguiente Salida en relacion a la tarjeta

dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.3.0.1
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
wctdm24xxp 0000:05:08.0: PCI INT A -> Link[APC3] -> GSI 18 (level,
low) -> IRQ 18
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: Port 1: FAILED FXS (FCC)
wctdm24xxp 0000:05:08.0: Port 2: Not installed
wctdm24xxp 0000:05:08.0: Port 3: Not installed
wctdm24xxp 0000:05:08.0: Port 4: Installed — AUTO FXO (FCC mode)

Aqui pude obsevar como exactamente, el puerto FXS no estaba recibiendo corriente. Investigando por el mundo Google, encontre, que podia ser causa de problemas en el conector Molex, que no estuviera recibiendo la corriente adecuada. Tenia yo la sensacion que esto no iba a ser cierto, ya que en esa misma maquina, otros Molex en otros dipositivos estaban funcionando perfectamente, y al conectar esos mismos Molex en la tarjeta seguian dando el mismo error.

Ademas para no desistir en el intento, probe varias combinaciones en los canales de la tarjeta, con los modulos, poniendo el FXS en practicamente los 4 canales, y lo mismo el FXO. El FXO daba el simbolo de correcto mientras que el FXS en todos los slots daba el mismo error.

Aun asi, todavia quedaban pruebas. Necesitaba comprobar que en el conector macho de la tarjeta, se estaba recibiendo la corriente necesaria para su fucionamiento (12V). Asi que me hice con un voltimetro para comprobar que efectivamente lo recibia perfectamente como se puede observar en las fotos siguientes:

Siguiendo en la insistencia, podia ser un problema (que dudaba en grandisima consideracion vista la ultima prueba), de falta de potencia de la fuente de alimentacion. Pero no queria desistir, y necesitaba -probarlo- todo. Asi que busque una fuente con 100W adicionales (la que hay montada es una Levicom 85+ Bronze de 350W que estoy seguro que le sobra potencia a patadas). Me hice con una fuente de 460W la conecte al equipo como puede observarse en la foto siguiente, y haciendo la misma prueba con el voltimetro que antes, se podia observar que llegaba la corriente adecuada:

Por esto, y en conclusion, me doy por vencido en este primer Asalto ya que no he conseguido configurar un Telefono Analogico a la centralita.

Proximamente, intentare configurar el Puerto FXO que parece ser que si funciona, para recibir como entrada una linea analogica que proviene de una centralita. De alguna forma quiero tratar de integrar esa centralita a traves de una de sus extensiones, con mi Centralita Asterisk, para ver si puedo emitir llamadas a otras extensiones de esa centralita, y ver si puedo recibir llamadas que vengan de esa centralita, en mi sistema y tratarlas, quien sabe, con una mini-operadora de pruebas.

Ademas esta prueba, me servira para comprobar si la tarjeta Digium esta en buenas condiciones, y plantear tramitar en Garantia el pequeño modulo verde FXS que estos problemas me ha dado.

Si se os ocurre cualquier idea que no haya probado aun, con el modulo FXS y que quiza se me haya escapado y pueda resolver mi problema, no dudeis en comentarlo, seria ampliamente agradecido por mi parte.

El dia del Protocolo SIP: Parte 2

Tras el pasado dia haciendo las configuraciones en el archivo de configuracion sip.conf del SIP CHAN ahora procedemos a conectar al sevidor Asterisk los 4 elementos que comentabamos.

En primer lugar, el gran telefono IP Polycom SoundPoint 331, segun el documento de TFOT comenta que la configuracion via administrador web resulta compleja, pero a mi no me lo parecio tanto.

Realmente solo tenemos que configurar con la interfaz del propio telefono, la direccion IP, y los parametros basicos de conexion TCP/IP. Acto seguido conectamos al telefono a traves de su interfaz web con la IP que le hayamos asignado (es conveniente que fuera estatica por si en un futuro necesitamos gestionarlo, o en otro caso asignarle un hostname y poder gestionarlo con nuestro DNS).

Los parametros de acceso por defecto en este tipo de telefonos Polycom son: Usuario “Polycom” y contraseña “456”. Es un poco innecesario que cuente como configure el telefono puesto que hay muchos telefonos diferentes SIP. Voy a comentar la idea en general, y luego nos servira para configurar los otros terminales disponibles.

Primero hay que configurar los parametros SIP. En este caso suelen ser el Outbound Proxy y el Dominio de conexion que son la direccion Ip de nuestro servidor Asterisk, asi mismo como el Puerto que suele ser el 5060 a no ser que por motivos de seguridad hayamos decidido cambiarlo.

Tambien en este caso en el telefono Polycom hay que configurarle las lineas que ofrece, se podrian configurar dos servidores diferentes, con los datos de conexion SIP, es decir el nombre de usuario y contraseña que especificamos antes en el fichero sip.conf y el servidor Asterisk con su puerto correspondiente. Tambien existe una opcion en el Polycom de intercambiar la tecla del segundo servidor (linea 2) para prepararlo como acceso directo al buzon de voz, o incluso otras funciones (Aunque la tecla auxiliar pone “Messages” esta pensado para esto).

En segundo lugar voy adelante con la configuración de un cliente SIP para Linux. En este caso el cliente por defecto que trae el sistema Gnome es Ekiga. Tampoco posee grandes funcionalidades, pero es suficiente como para establecer una conexion SIP a nuestro servidor Asterisk, y su configuracion resulta a priori, extremadamente sencilla. Una nota curiosa que nos comentaron durante el curso en relacion al Ekiga utilizandolo (caso extraño), en el propio servidor donde esta instalada la maquina Asterisk, es que por defecto, realiza la escucha en el Puerto 5060, justamente el mismo puerto SIP que utiliza Asterisk como escucha. Esto provoca una pequeña incompatibilidad que es necesario cambiar, forzando el cambio sea al sistema Asterisk (en el contexto general del sip.conf que comentamos el otro dia, el atributo port=), o cambiandolo en las configuraciones de gnome (comando: gconftool-2 -t integer -s /apps/ekiga/protocols/sip/listen_port 5070).

La cuenta SIP se configura desde Edit > Accounts >> Add.
En nombre ponemos lo que queramos
Protocolo: SIP
Registrar: IP del servidor Asterisk
User: Usuario que hayamos asignado a la extension que deseamos configurar
Password: La contraseña que asignamos

Asimismo resulta sencillo configurar otros softphone para otros sistemas como Windows, el elegido SJ-Phone. Se puede descargar desde la web: http://www.sjlabs.com/sjp.html

Tambien existe un completo manual para Windows: http://www.sjphone.org/doc/SJphone_User_Guide.pdf

Considerar que este softphone tambien sirve para otros sistemas tipo Windows Mobile (Windows CE) y la configuracion resulta igual de sencilla.

En la opciones del programa, la pestaña Profiles (Perfiles), Agregamos uno nuevo del tipo Calls through SIP Proxy. Ahi realmente hace falta configurar poco para que funcione. En Initialization, es interesante picar todas las tres cajas de las dos primeras opciones (Account y PassworD). En la pestaña SIP Proxy solo hace falta rellenar en la mayoria de los casos Domain/Realm con nuestro servidor Asterisk, y opcionalmente el puerto con el formato IP:Puerto. Acto seguido, al guardar la configuracion, e intentar conectar, un cuadro de dialogo aparecera solicitando usuario y contraseña. Aqui es cuando nos validamos con el usuario y la contraseña de la extension configurada en el sip.conf a la que pretendemos acceder.

Finalmente el ejemplo de configuracion de un softphone para Android, el elegido, el famoso SIPDroid que tampoco tiene gran misterio. En el programa, accedermos a Settings > SIP Account Settings.
En Authorization Username, el usuario de la extension y en Password mas de lo mismo
En Server or Proxy, la direccion IP del servidor Asterisk.

El resto probablemente dejandolo como esta sera suficiente, quiza cambiar el puerto SIP del servidor Asterisk si es que es diferente.

Una vez configuradas todas las extensiones, voy a poner aqui un fichero extensions.conf de ejemplo con el que podriamos realizar las primeras llamadas entre extensiones. Proximamente me adentrare mas en el fichero extensions.conf que es el lugar donde se configura el Plan de Marcacion, o DialPlan como comunmente suele llamarse. Este podria considerarse, el cerebro del Asterisk. Es importante manejarse bien en este fichero porque lo aqui puesto, dependera del 90% del exito de nuestro sistema y las posibilidades que a este podramos otorgarle.

El ejemplo sencillo para nuestras nuevas extensiones, ext1000 (Polycom), 1001 (Ekiga), 1002 (SJPhone) y 1003 (SIPDroid). Todavia no me centrare en los contextos, y atributos especificos

[general]
static=yes
writeprotect=no
clearglobals=no
[globals]
POLYCOM => SIP/ext1000
EKIGA => SIP/ext1001
SJPHONE => SIP/ext1002
SIPDROID => SIP/ext1003
[extensiones]
exten => s,1,NoOp()
exten => s,n,WaitExten(8)
exten => 1000,1,NoOp()
exten => 1000,n,Answer
exten => 1000,n,Dial(${POLYCOM})
exten => 1000,n,Hangup
exten => 1001,1,NoOp()
exten => 1001,n,Answer
exten => 1001,n,Dial(${EKIGA})
exten => 1001,n,Hangup
exten => 1002,1,NoOp()
exten => 1002,n,Answer
exten => 1002,n,Dial(${SJPHONE})
exten => 1002,n,Hangup
exten => 1003,1,NoOp()
exten => 1003,n,Answer
exten => 1003,n,Dial(${SIPDROID})
exten => 1003,n,Hangup
Con esto podremos realizar llamadas sencillas marcando una u otra extension, desde una hacia otra sin problemas. Esto es todo por hoy. Estoy dudando cual sera el proximo paso, configuracion de extensiones analogicas con el canal DAHDI o si empezar las primeras andanzas y pruebas con el mundo de los DialPlan. Cualquiera de las dos igual de importante y prioritaria, sera cuanto antes!

Primeros Pasos: Eligiendo un Servidor

Visto lo visto, creo que ya llego el momento de empezar a meterle mano al tema.

Quiza lo logico seria plantear, un servidor cualquiera de pruebas, y hacer experimentos para dar los primeros pasos.

Pero me gustaria ir un poco mas alla. La primera “practica” va a ser montar un pequeño servidor de Produccion que cumpla una funcion muy especifica: Servidor de FAX y un pequeño Callcenter para dar soporte a mi empresa a nivel IT a traves de la VoIP y las lineas analogicas que poseo.

Para ello cuento con lo siguiente:

Un Semi-Servidor con los siguientes componentes

– Procesador Opteron 170 (equivalente al AMD Athlon X2 4200+) socket 939
– 4 x 1 Gb DDR-SDRAM 400Mhz UDIMMs
– 2 x HDD SATA 7200 320Gb en RAID 1

Aparte tiene una tarjeta Digium Wildcard B410P con 1 puerto FXO y 1 puerto FXS

Tambien estoy empezando a barajar un pequeño servidor para dar servicio de produccion a baja escala (del orden de 20 extensiones, con un maximo de 10 llamadas simultaneas).

Entre los equipos barajados me he ido a las gamas Dell, el mas bajo de gama con Fuente Redundante (que realmente es lo unico especial que posee un servidor frente a un equipo MIY) seria el PowerEdge R410, que ademas posee dos sockets, y una placa con opcion a poner memorias Registradas (lo que viene a ser una placa de servidor propiamente dicha).

2 x Intel Xeon E5504
2 x 2Gb DDR3 1333 Ghz RDIMMs
2 x HDD SATA 7200 250Gb en RAID 1 con la controladora PERC S100
Y la Fuente Redundante

Hacen un total de 1480 euros + IVA

La ventaja es que solo es de 1U, porque luego por 2U podemos irnos a otros servidores tipo R510 que con una configuracion equivalente se van al orden de los 1510 euros y contando con la inclusion controladoras HotSwap PERC i6

Una gama aun mas alta, ya con discos SAS vendria a costar del orden de los 1750 euros, para el caso del R610 y finalmente el resto de las gamas enrackables se van a los 2000 euros directamente para configuraciones equivalentes, y tambien quiza, con procesadores AMD Opteron, que realmente no se si son una buena configuracion para trabajar con el sistema Asterisk.

Mi conclusion: No merece la pena gastarse el dinero que cuesta un servidor si no vamos a tener las prestaciones especiales que ofrece una placa de servidor y todo lo que le rodea (posibilidad de fuentes redundantes, memorias registradas, dos o cuatro sockets, hotswaps, controladoras RAID de alta gama, etc). Hoy en dia por menos de 1000 euros podemos tener un equipo del nivel de un servidor. Mas curioso aun, los servidores en modo torre, no aportan un precio mejorado a mayores prestaciones, si bien, no requieren de rack, en caso de poseerlo, es hasta un mayor inconveniente de espacio y desorden.

Por tanto el mejor servidor entre todos los valorados de gama baja en Dell es el R510, con la inconveniencia de que para el tipo de servidor por mi planteado, le sobra gran cantidad potencia.

Quiza seria mas interesante, tener un servidor de bajo nivel incluso MIY con opcion de registrar todos los terminales en un servidor mayor redundante, a traves de comunicaciones de datos, en caso de averia.

Seguire dandole vueltas a esto. De momento me pongo manos a la obra con el servidor que plantee al inicio.