El Terror a las Pantallas Negras

Posted on 03/09/2010 by SirLouen

Hoy tenia ganas de escribir sobre algo relacionado a este mundo pero que no demasiado tiene que ver con el mundo Asterisk en particular.

Como bien dice el titulo de este mensaje, hoy estuve reflexionando sobre el terror a las pantallas negras. Es decir, el miedo a las shells, consolas, etc. Desde tiempos inmemoriables, trabajar con sistemas tipo Windows, las pantallas negras se han asociado a problemas en el sistema, o momentos de arranque. Pero… y si durante el arranque nunca se llegaba a pasar de esa pantalla negra? En el mundo de la administracion de sistemas, para el usuario comun seria asi como “Mi ordenador no enciende, se me queda en la pantalla negra”.

Pero ahora este mensaje lo percibo desde el punto de vista del administrador de sistemas, especialmente el administrador Linux, que debe lidiar diariamente con pantallas negras por todas partes. Pero personalmente sigo sufriendo un poco del momento “Windows” y el estress de ¿ahora que hacer sin mi gestor de ventanas?.

Por un lado creo que es motivacion de que se pierde la puerta a la informacion absoluta: Internet (aunque existan alternativas tipo Lynx, son demasiado odiosas para ser ciertas).

Hoy por ejemplo, en en una de mis estaciones de trabajo, he querido actualizar el Kernel para obtener una nueva funcionalidad (OpenVZ funcionando sobre un kernel 2.6.32) y tras la actualizacion, al reiniciar, mil errores varios (faltaban las nuevas cabeceras del Kernel en el area de compilacion) y tras una carga de mas del triple de lo normal, el sistema de ventanas no arrancaba.

Pero pensando en frio, la solucion llego rauda:

1. Arrancar la shell, editar el fichero xorg.conf para utilizar un driver sencillo, el “Vesa” por ejemplo es infalible. Ademas en la Sub Seccion del Driver de Pantalla, colocar una resolucion fiable, “1280×1024″ para tener las cosas mas claras (Mode “1280×1024″)

2. Iniciar las X, “startx”

3. Ahora si arrancan, es momento de acceder al navegador para descargar algo que pueda solucionar la vida. En mi caso, analizando el error del arranque del gestor anterior, observe que daba un problema al intentar cargar el driver fglrx de la grafica ATI. Esto probablemente fuera, porque aun no estaba “cargado” en el nuevo Kernel.

4. Aprovecho y me bajo el ultimo driver propietario de ATI y lo instalo. Una de las instalaciones mas sencillas del sistema. Una cosa curiosa es que he observado que debo ejecutarlo en modo shell con un superusuario. Algo asi como:
# sudo su -
# sh driver_ati_utlimo.run
He probado en otras ocasiones a instalar con la GUI integrada en el propio sistema de ventanas y parece que no ejecuta por alguna razon, exactamente la misma operacion.

5. Finalmente volver a reeditar el fichero xorg.conf para que apunte al nuevo recien cargado driver fglrx y reiniciar el Equipo para comprobar…

Que arrancan las X en Alta Definicion. Vaya por dios.

Escribo esto un poco como auto-reflexion, para recordarme a mi mismo que en esos momentos que llega la pantalla negra y pienso “ha llegado el momento de formatear”, realmente no es tan critico y existe una salida no muy compleja a apenas unos pocos golpes de teclado.

Tambien escribo esto para no olvidar que este Blog esta diseñado para empezar desde 0, y mejorar la curva de aprendizaje concretamente del sistema Asterisk, pero sinergicamente del sistema base: Linux. Esto no es un tutorial, pero si una aproximacion de una idea de como saber actuar en estos momentos de Terror. Aunque la verdad que estos casos trabajando con Asterisk no deberian de ocurrir demasiado, a no ser que tengamos una Estacion de Trabajo y de Pruebas con Asterisk en Debian, y requiramos la interfaz grafica por ejemplo, como comente en uno de los primer mensajes, para correr un SIP Phone tipo Ekiga.

Posted in Basicos, Linux | Tagged , , , , , , , , | Comentarios desactivados

Una Nueva Maquina para el Sistema

Posted on 01/09/2010 by SirLouen

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://10000horas.com/asterisk/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://10000horas.com/asterisk/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/

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.

Posted in Hardware, Introduccion | Tagged , , , , , , , | Comentarios desactivados

Introduciendo un Proveedor SIP: Parte 1

Posted on 26/08/2010 by SirLouen

Tras el duro combate sufrido estos ultimos dias con la tarjeta TDM410P, al final resulto no funcionar tampoco el modulo FXO asi que decidi tramitar la tarjeta en Garantia y que resultase lo que fuera.

Pero esto no ha impedido que siga trabajando por otra corriente. Esta vez, seguimos con el mundo SIP, y en este caso utilizando un llamado “SIP Trunk”, o lo que realmente viene a ser, un proveedor SIP de VoIP para llamar a la red PSTN y GSM a traves del mismo, con las extensiones de nuestra centralita Asterisk.

En este caso, lo que realmente me resulto algo complejo fue la eleccion del proveedor en cuestion. Tras analizar varios, conclui que el precio estaba estrictamente relacionado a la calidad del servicio. Por ejemplo, uno de los proveedores mas famosos, VozTelecom, tiene un servidor SIP ubicado en la direccion voztele.com. Desde mi servidor obtengo una latencia de entre 25-30ms, una latencia extraordinaria. Pero el coste de la llamada a fijos nacionales para estas fechas en la que estoy escribiendo este mensaje, es de 2 centimos/minuto, una tarifa un 25% mas alta que cualquier otro proveedor que ronda los 1,5 centimos/minuto.

Pero no solo estaba interesado en el servicio de llamadas externas, sino lo que verdaderamente me interesaba era el servicio de llamadas Entrantes. El coste de un DDI (Numero Geografico Nacional) segun la pagina web, es de 4 euros, no esta nada mal desde luego, pero combinado con el otro precio saliente no me resulto demasiado atractivo.

Luego di con otros operadores varios nacionales, ADAM, Telsome, … hasta al final encontrar uno ubicado en Malaga llamado Netelip con tarifas bastante competitivas. El principal problema: Una latencia media de unos 80ms, comparado con VozTelecom, bastante mala latencia. Pero eventualmente el coste por minuto era relativamente barato y el DDI se podia conseguir desde 2 euros un numero geografico virtual (que comieza por 851 pero al llamante le tarifica como una llamada nacional cualquiera). Los numeros geograficos provinciales si resultaban mas caros, y encima no ofrecian numeros de este tipo para mi provincia. Tampoco me importaba gran cosa, y con el DDI 851 podria ir tirando para realizar las primeras pruebas.

Ahora ya elegido el proveedor, tocaba configurarlo en mi central.

Por un lado como es corriente, lo primero seria configurar el chan sip desde el fichero sip.conf

En el contexto general creamos una regla para registrar el servidor SIP en nuestro sistema con las credenciales ofrecidas por el Operador IP:

[general]
register => usuario_del_proveedor_ip:contraseña_del_proveedor@direccion_del_proveedor/ddi
Ejemplo
register => sirlouen:1234@sip.netelip.com/851123456
Por otro lado necesitariamos crear un contexto para la informacion especifica de este “dispositivo virtual” SIP, la mayoria de los atributos ya los vimos el otro dia en el otro mensaje sobre SIP
[netelip]
type=friend
username=sirlouen
context=operadorip
host=sip.netelip.com
canreinvite=no
secret=1234
nat = yes
fromdomain=sip.netelip.com
disallow=all
allow=alaw
dtmfmode=inband
insecure=port,invite
fromuser=sirlouen
Lo unico asi en detalle, comentar que es necesario que sea de tipo friend por el hecho que debe recibir y enviar llamadas.
Tambien el parametro nat, debe ser yes por el hecho de que en este caso salimos por el Router para este peer.
En este caso los codecs y el dtmfmode son muy importantes ya que van a definir la calidad de la conexion de voz sobre Internet, que ya de por si tiene un gran handicap comparado a la comunicacion via red local. He elegido el codec alaw que no es que sea grandioso, y seguramente deberia cambiarlo proximamente, ya que la tasa de transferencia es bastante elevada, del orden de los 80kb/s incluyendo las cabeceras… una verdadera burrada, aun con calidad, para trabajar en el mundo de internet.
Por otro lado, el dtmfmode es muy sensible ya que al no trabajar en local, los tonos se confunden facilmente. Habia probado con el modo rfc2833 igual que en local, pero tuve problemas con la marcacion, por ejemplo del numero 1, ya que en la consola podia ver como trataba de transferirme con la regla del dialplan “11″ (como dos marcaciones del 1). Tambien probe con el modo info que no es demasiado util en este caso. Al final con inband es con el modo que mejores resultados he conseguido. Tambien quiero comentar, que en el contexto general, puse el atributo “relaxdtmf=yes” que ayuda a que las marcaciones dtmf no sean tran estrictas, y que trate de interpretar la marcacion lo mejor que pueda aunque no tenga demasiada calidad.
Finalmente el atributo insecure=port,invite es una configuracion muy tipica en estos casos, ignora el puerto de entrada y tampoco pide invitacion del mensaje INVITE (mensajes que se trasmiten durante la comunicacion convencional)

Con esto ya quedaria totalmente configurado el peer netelip.

Ya solo quedaria montar las reglas dentro del DialPlan (extensions.conf) para marcacion de tipo nacional, movil a traves de este Proveedor IP y por otro lado, definir el contexto que puse antes “operadorip” para el reconocimiento de las llamadas entrantes, y su manipulacion.

Para esto aprovechare para introducir algunos temas nuevos del DialPlan asi como la creacion de un pequeño IVR (Contestador Automatico, Interactive Voice Response), en otro mensaje proximamente.

Estad atentos :)

Posted in Introduccion, Protocolos | Tagged , , , , | Comentarios desactivados

Combate Analogico: Primer Asalto

Posted on 20/08/2010 by SirLouen

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.

Posted in Hardware, Telefonia Analogica | Tagged , , , , , , | Comentarios desactivados

El dia del Protocolo SIP: Parte 2

Posted on 17/08/2010 by SirLouen

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!
Posted in Hardware, Linux, Softphones | Tagged , , , , , , , | Comentarios desactivados

El dia del Protocolo SIP: Parte 1

Posted on 13/08/2010 by SirLouen

Como suele ser comun pensar, que mejor que empezar las primeras andanzas en funcionamiento usando dispositivos SIP, realmente los menos costosos ya que practicamente estamos rodeados de ellos. Ademas en este caso seran la base de mis pruebas de momento, ya que aun no dispongo de electronica suficiente para probar otros modulos.

Parece ser que Asterisk se divide por canales, segun el canal, llamemosle via de comunicacion, va en funcion del tipo, en este caso, el canal sip, llamado SIP CHAN con su archivo de configuracion sip.conf es el que voy a tratar introductoriamente en el mensaje de hoy.

Combinando mi aprendizaje a traves del curso, y la lectura del buen libro, The Future of Telephony (una de los mejores bajo mi criterio), cree un fichero sip.conf desde cero, (los archivos de configuracion de Asterisk se encuentran dentro del directorio /etc/asterisk/ como la mayoria de los ficheros de configuracion de Linux. El contenido del mismo a nivel muy basico seria el siguiente, explicado linea por linea:

[general]
language=es

En primer lugar, tenemos los contextos, encuadrados entre corchetes. Concretamente este contexto podria llamarse contexto global ya que afecta por defecto a todo el resto de los contextos.El atributo language se explica por si solo

[extension](!)
type=friend
host=dynamic
dtmfmode=rfc2833
canreinvite=no
nat=no
qualify=yes
context=extensiones_internas
pickupgroup=1
callgroup=1

En este caso ya tenemos mas atributos complejos. En primer lugar el contexto “extension” tiene una peculiaridad y es que al ponerle (!) lo convertimos en plantilla que luego otros contextos podran utilizar para no tener que andar reescribiendo codigo a lo loco

Sobre los atributos, asi enumeradamente:
1. type tenemos tres posibilidades, friend, peer, user, para decidir si hara llamadas, recibira, o ambas. En este caso friend es ambas.
2. En host, dynamic, es un poco una version comoda de decir, que el otro punto que se conecte a asterisk sea el que provea toda la informacion acerca de la conexion
3. Acerca del dtmfmode, tendriamos que hablar del mundo de los Dual Tone Multi Frequency, hay varias opciones, pero la opcion rfc2833 es quiza la mas comun. Hablare en algun momento o quiza cuando llegue mas a la parte de telefonia analogica acerca de los DTMF
4. canreinvite, simplemente especifica, que los telefonos no puedan “reinvitarse” y realizar una comunicacion directa entre ellas sin pasar por asterisk. Esto quiza seria util en sedes remotas, para que pudieran hablar dos extensiones de la misma sede en local. Pero para ello hay mejores opciones aun si cabe que ya veremos en otro momento mas avanzado.
5. Sobre el nat, tiene que ver con las cabeceras del protocolo SIP y la informacion acerca del host que traen. Manteniendolo en no permitimos que estas cabeceras se conserven y se usen.
6. qualifiy sirve para mandar mensajes por el protocolo para confirmar si estan activos los otros puntos. Esto puede generar trafico indeseado en la red, por lo que en sedes remotas, quiza seria interesante desactivarlo
7. pickupgroup y callgroup van en conjunto. Callgroup define un grupo de llamadas dentro de las extensiones. Y pickupgroup define de que callgroup podria ser recogida una llamada con una marcacion especifica definida en otro fichero de configuracion (features.conf se vera mas adelante). En principio nos quedamos con *8 que es el que va por defecto
8. Finalmente el context quiza el atributo mas esencial, hace referencia a que contexto ira a mirar esta extension por defecto dentro del DialPlan (esto requiere mas de un mensaje asi que seguramente sea mañana cuando  escriba el primer DialPlan y una explicacion acerca de este). Dial Plan viene a referirse al plan de marcacion, a “que ocurre” cuando desde un telefono marcamos una combinacion de digitos u otra. Esta es la verdadera programacion del sistema Asterisk

[codecs](!)
disallow=all
allow=gsm
allow=ulaw

Semejante al anterior contexto y bastante explicatorio por si mismo. Bloqueamos todos los codecs y solo damos permiso a los que nos interesan, en este caso el GSM y el ULAW. Conforme voy recorriendo este fichero me voy dando cuenta de la cantidad de cosas que seria interesante explicar en futuros mensajes, porque todo guarda relacion directa con otros fundamentos basicos de la telefonia.

Finalmente los puntos SIP

[ext1000] (extension, codecs)
callerid = “Polycom” <1000>
defaultuser = ext1000
secret = 111111
mailbox = 1000@default

Solo pongo una de ejemplo, porque basicamente el resto son replicas modificando algunos detalles basicos para cada futura extension SIP

Aqui llamamos a las dos plantillas anteriormente creadas, y utilizamos atributos especificos que son:
1. callerid, es el nombre que le aparecera al receptor de la llamada cuando emitamos desde este punto
2. defaultuser y secret son el usuario y contraseña que deberemos utilizar para configurar los puntos SIP
3. mailbox, sera el buzon por defecto para esta extension, para el tema de los buzones de voz.

Y con esto ya tendriamos una configuracion basica preparada para empezar a configurar Terminales, y crear un pequeño DialPlan para cursar llamadas simples entre los mismos.

En la proxima parte seguiremos con mas, explicando acerca de la configuracion de varios tipos de terminales SIP que hemos puesto como ejemplo: Un software para Windows, un software para Linux, otro para un pequeño terminal Android y finalmente un grandioso telefono Polycom que me dieron en el curso.

Posted in Introduccion, Protocolos | Tagged , , , , | Comentarios desactivados

Manos a la Obra con Asterisk

Posted on 09/08/2010 by SirLouen

Por fin, despues de pasar mucho tiempo dando vueltas con el hardware, el software, y tratando de aprender lo maximo para optimizar el resultado hasta donde fuera posible, llego el momento de ponerse los guantes y entrar en serio en el proposito de este blog.

Parece ser que ha llovido un poco desde el primer comentario inaugural de este blog, en el que se comentaba que las dos opciones principales en el mundo Asterisk, a nivel de versiones, eran la 1.4 como robusta (y de ahi el branch Rock Solid Patchset para esta version),y la 1.6 como “novedosa”.

Pues bien, a dia de hoy, por fin podria decir, que la 1.6. subdividida en varias “subversiones”, la 1.6.0 (que pasa a ser la nueva rock solid), la 1.6.2, nueva version bastante estable, y finalmente la nueva version inestable y supernovedosa, 1.8.

Puestos a elegir, en este caso, y sirviendo un poco los propositos de testeo, lo logico hubiera sido aventurarme en la version 1.8. Pero dado que mi curso fue especializado en la version 1.6 y realmente aun me queda mucho camino por recorrer antes de empezar a indagar en las novedades de la ultima version (que seguramente para entonces ya haya salido la version 1.8.0-current y sera muy estable migrar a esa opcion).

Por tanto a la hora de la instalacion del sistema Asterisk los paquetes elegidos seran:

Asterisk 1.6.2
Asterisk Addons 1.6.2 (¿es coincidencia? son los ultimos mas estables)
Libpri 1.4 que es tan estable, y tiene muy pocas intenciones de actualizarse, que ahi quedo
Pack Dahdi Completo (Dahdi Linux + Dahdi Tools)

El metodo de compilacion, instalacion, y en caso del paquete Asterisk y Asterisk Addons, instalacion de los ficheros ejemplo orientativos, se puede encontrar en multiples sitios.

Pero aqui lo interesante es conseguir una manera de que todo instale lo suficientemente “suave” para no andar teniendo problemas a la hora de compilar, y especialmente configurar el “make” con el Autotools, exigiendo dependencias a cada momento.

Esta lista, extraida de varios sitios, entre ellos el curso al que asisti en su dia, son los paquetes necesarios para realizar una instalacion integral de todos los paquetes necesarios:

- Lo basico para compilar

build-essential linux-headers-’uname -r’ flex bison gawk

- Herramientas adicionales del Servidor

ssh unixodbc unixodbc-dev subversion mc pciutils doxygen

- Librerias multiples

libxml2-dev libmysqlclient-dev libcurl4-openssl-dev curl libncurses5-dev libiksemel-dev libspeex-dev libsm1-dev  libssl-dev libvorbis-dev libsnmp-dev libsctp-dev libsctp1 libnewt-dev lksctp-tools

Todo esto se puede instalar directamente sea con yum (CentOS, RedHat), o con aptitude que es en este caso, el sistema que aqui nos trata (Ubuntu Server, Debian).
Con Debian quedaria algo asi:
aptitude install ssh mc pciutils build-essential libxml2-dev libnewt-dev libssl-dev libmysqlclient-dev libcurl4-openssl-dev curl libncurses5-dev libiksemel-dev libspeex-dev libgsm1-dev unixodbc-dev flex bison gawk subversion libvorbis-dev libsnmp-dev libsctp-dev libsctp1 lksctp-tools unixodbc doxygen linux-headers-`uname -r`

Realmente es muy probable que no todo esto vaya a ser necesario en nuestro sistema, pero tampoco es que vayamos a derrochar recursos haciendo esta instalacion, y nos va a quitar a priori de muchos problemas durante la compilacion.

Finalmente tras compilar, instalar, etc los paquetes en el orden siguiente:
1. Libpri
2. Dahdi
3. Asterisk
4. Asterisk-Addons

Comprobamos que la instalacion de asterisk, de momento funciona con el comando

# asterisk -r

Y entraremos en la consola de Asterisk.

De hecho si reiniciamos el servidor, en teoria Asterisk ya deberia estar funcionando en background. Con el comando:

# ps -e | grep asterisk

Deberia aparecer ya la instancia en funcionamiento. Toda lista y preparada para la siguiente fase: La configuracion de algunas primeras extensiones de ejemplo y prueba.

Posted in Introduccion | Tagged , , , | Comentarios desactivados

Primer Sistema Base: Ubuntu Server y Md Raid

Posted on 08/08/2010 by SirLouen

Despues de haber comentado hace unas semanas acerca de la seleccion de Servidor, ahora tocaba la eleccion del Sistema… en este sentido solo habia una cosa clara: El sistema base iria sobre GNU/Linux, el tema a tocar, seria: ¿sobre que distribucion?

Realmente hoy en dia todas las distribuciones son validas, incluso distribuciones basadas en UNIX, desde Open Solaris, incluso distribuciones para dispositivos con un sistema operativo embebido, y cualquier otra distribucion Linux tipo RedHat, OpenSuse y demas.

Pero en el mundo Asterisk tras varias indagaciones y lo aprendido hasta la fecha, las distribuciones mas reconocidas son CentOS y Debian por igual. De todas formas esto no resulta nada nuevo ya que hoy en dia, Centos y Debian se reparten el pastel de los servidores, incluso por encima de Fedora y RedHat Enterprise (se ve que eso de tener casi todo lo de RedHat Enterprisa gratuitamente tira mas que dos carretas… ¿o era otra cosa lo que tiraba mas que dos carretas?).

Debian es para mi personalmente, la distribución que mas he rozado desde mis inicios en el mundo Linux. Coincido con mucha gente decidiendome para todas mis inicios en cualquier sistema basado en Linux por decantarme siempre por Debian. En el ejemplo de la Virtualizacion que puse la semana pasada, KVM alojado en Linux, y adoptado por RedHat, yo lo utilizo personalmente sobre maquinas Debian, concretamente una distribucion basada en esta ultima llamada Proxmox que agrega multiples funcionalidades especificas de la virtualizacion con KVM en si.

Pero realmente, existe una distribución dentro del mundo Debian que simplifica masivamente la vida de configuracion a nivel Hardware. Esta es Ubuntu Server como indica el titulo. Es cierto que a dia de hoy no es una personoficacion de la optimizacion de los recursos del sistema ya que de por si añade un consumo “cabecera” (overhead) a la CPU que no es nada positivo para un sistema especifico con una funcion especifica, como cumplira en este caso lo que aqui estamos tratando, un sistema PBX.

Pero ahora volviendo atras al momento de la decision de configuracion de Hardware me encontraba con una simple cuestion: nuestra maquina de pruebas, tampoco iba a servir como un sistema de proposito especifico y de alto rendimiento. No es mi intencion de servir como Call Center para cubrir 500 llamadas simultaneas. Ademas Asterisk infraescalado, ni aun con un sistema como Ubuntu, seria capaz de soportar esto. Es por esto quiza, por lo que la facilidad de “auto”-configuracion del Hardware en el sistema fue por ultimo mi decision final de utilizar Ubuntu Server como sistema.

Tras instalar Ubuntu Server pude comprobar como practicamente todo el Hardware fue reconocido, y autoconfigurado, desde la Controladora RAID, hasta la VGA en alta resolucion (no es gran cosa, pero personalmente me resulta muy util trabajar en 1920×1080 incluso en consola si el sistema ofrece esta posibilidad como es el caso. Solo le hubiera faltado reconocer la tarjeta Digium B410P (hubiera sido el colmo ya).

La segunda parte quiza mas significativa de la configuracion del sistema fue la del planteamiento de estabilidad del sistema a nivel de Disco Duro. Comente en su dia que disponia de dos discos duros de semejantes caracteristicas, por lo que se veia forzada la necesidad de montar un RAID. Pero tras mucho indagar me di cuenta, que las mayoria de las placas base, a pesar de traer un controlador RAID, realmente no es un controlador puro y dedicado como podrian ser los controladores PERC de Dell. Considero un controlador dedicado, a ese controlador capaz de liberar a la CPU de la carga de realizar todas las tareas para que el RAID se viera satisfecho. En este caso mi intencion era montar un RAID 1.

En general la mayoria de las placas base suelen traer controladores Silicon Image, ATI Nvidia, VIA, etc, pero realmente no dejan de ser controladores de tipo software, gestionados desde la BIOS con solo las caracteristicas basicas para poder proveer de informacion suficiente de como deberia trabajar (pero no capaces de trabajar por si mismos). Esto podria resultar interesante, excepto por una cuestion muy importante: Si esta controladora se averiase (o si la misma placa se averiase), necesitariamos para recomponer ese RAID una controladora Exactamente Igual, o de semejantes caracteristicas, capaz de recomponer eso. Hoy en dia, esto puede resultar excesivamente dificil, ya que la mayoria de las piezas quedan descatalogadas en apenas 2 años, y pese a que continua su produccion, a partir de los 4 años es practicamente imposible conseguir una a no ser que la busquemos a traves de un Broker, o la localicemos de casualidad de Segunda Mano o que la pidamos a la marca BAJO DEMANDA (con un coste 10 veces mas caro de lo que costo originalmente). Esta dependencia al Hardware, para mi me resulta inviable. Si tuvieramos la opcion de tener controladoras especificas como las PERC de Dell que siguen ciertos estandares al menos dentro de la misma marca, y que su produccion se extiende mas alla de los 5 años, ademas de ofrecer un hardware dedicado y liberando a la CPU de esta carga, entonces definitivamente si podria decidir, que merece totalmente la pena.

Entonces, si tengo dos discos duros iguales, y mi intencion es montar un RAID 1 …. ¿cual es la resolucion?

Pues volviendo al titulo, GNU/Linux provee la solucion, Md Raid, con mdadm. El RAID software por excelencia de Linux.

Vamos un poco a la practica. Para configurar esto en un sistema de “bajo calibre” la idea es muy sencilla:

Ubuntu ofrece en el propio instalador la opcion de configurar esto de manera grafica. En cualquier caso, por si a alguien le interesara configurarlo en modo Consola la idea seria la siguiente:

1. Para cada disco tenemos que crear primero una particion de tipo RAID arrancable (exactamente iguales, ocupando el disco completo, y con el flag B de bootable).
Podriamos utilizar una herramienta de particionado tipo cfdisk. Simplemente, toca, crear una nueva particion con new, en Tipo, ponerle fd (Particion Linux Raid), en flag, ponerle bootable, y finalmente “Write” para escribir las modificaciones sobre la particion. Repetir este proceso para el otro disco.

2. En segundo lugar, toca “instalar” el Raid software con mdadm. En el instalador simplemente hay que especificar algunos parametros, como el tipo de raid (1, mirror, espejado, misma informacion en los dos discos duros), el numero de discos involucrados, el numero de discos sobrantes (Spares, como en el sistema JBOD por si acaso) y seleccionar los discos involucaros. Y el sistema raid estara listo en unos segundos.
En el caso shell es quiza aun mas sencillo:
Considerando que los discos son SDA y SDB (sata disk A y sata disk B siendo ambos discos tipo sata, si fuera IDE/PATA, seria hda, y hdb)
mdadm –create /dev/md0 –level=1 –raid-devices=2 /dev/sda1 /dev/sdb1 (el 1 es la particion 1 que creamos anteriomente, una sola particion).
En este caso habremos llamado a nuestro recien creado RAID md0 a nivel de sistema.

3. Acto seguido, toca particionar nuestro recien creado RAID. En este caso, seria como si tuvieramos un solo disco duro. Podriamos directamente particionarlo con ReiserFS, Ext3 o Ext4, o podriamos elegir un formato mas avanzado como LVM2. Yo personalmente soy mas partidario de utilizar LVM a cualquier costa. ¿Porque? Por la opcion de hacer una copia de seguridad del sistema completo utilizando Snapshots.

Recuerden, un RAID1 aunque ayuda al uptime del servidor, ya que aunque haya un error de disco, el sistema seguria en pie, no asegura que la informacion se destruya en un momento determinado (o peor aun, se corrompa). La unica forma de preservar la fiabilidad de la informacion (y de echar marcha atras rapidamente en caso que un dia hagamos algo indebeido), es utilizar las copias de seguridad. Y los snapshots de LVM son la forma idonea de realizarlas sin tener que parar el sistema, y mantener el 100% de Uptime en nuestro sistema.

Eso es todo por hoy. Seguramente haya obviado algunos detalles interesantes. Cualquier sugerencia para explicacion, no dudeis en comentarla!

Extra:

Hoy 30 de Agosto 2010, escribo un pequeño Plus para este Sistema. El metodo de Particionamiento dentro del sistema LVM que yo he seguido

En primer lugar, una particion para el sistema de arranque. Esto no es estrictamente necesario pero, realmente es una buena practica poner el sistema de arranque en un tipo de particion mas sencilla como ext2 que la particion del sistema principal, que en este caso seria ext4. Yo suelo darle bastante cantidad de espacio, del orden de 10 veces mas de lo que necesita. Con 50 Mb es suficiente, pero si en un momento determinado vamos cargando multiples kernels para cualquier asunto, o actualizaciones sucesivas, y no tener la necesidad de ir borrando lo antiguo, suelo poner 512Mb. Con los discos duros de hoy en dia no supone un gasto indebido y me curo en salud

En segundo lugar el espacio Swap. Hay que considerar una cosa: Si tenemos que utilizar el sistema Swap en nuestra maquina Asterisk, vamos a tener SERIOS problemas. Yo personalmente podria 0 Mb. Pero con mi politica de reservar memoria para todo y que en un momento dado, aunque el sistema vaya mal, al menos no vaya a Pique con facilidad, me gusta reservar tanta memoria Swap como memoria RAM disponible haya.

El resto, volumen principal, en ext4 que es el mas nuevecito en estos momentos, y funciona perfectamente. Los sistemas Ubuntu lo permiten y Asterisk funciona perfectamente en este tipo de sistema.

Sabia que podia completar mas este mensaje, y asi lo he hecho.

Posted in Introduccion, Linux | Tagged , , , , , | Comentarios desactivados

Uno de los nuevos grandes Dilemas: Xen o KVM?

Posted on 04/08/2010 by SirLouen

Hace mucho tiempo surgia KVM como nuevo competidor. Tenia serias dificultades para entrar en el mercado dominado por VMWare en el mundo propieatario, y Xen en el mundo opensource. Por otro lado tambien emergian nuevas soluciones como VirtualBox que darian mucho que hablar.

Pero entre lo que mas quiero destacar, fueron los inconvenientes que se extrajeron de la competicion opensource Xen vs KVM:

Claro está, tiene sus inconvenientes

  • necesitas tener un procesador con soporte para virtualización por hardware, como son los procesadores con tecnología AMD-V e Intel-VT
  • no tiene el soport ni el número de seguidores que tiene Xen
  • no tiene el apoyo económico que tiene Xen: Red Hat, Novell, Citrix
  • no tiene el apoyo tecnológico que tiene Xen: Red Hat, Novell, Citrix
  • no tiene interfaces gráficas bonitas y sencillas de usar para configurar y administrarlo

Hoy en dia, todos los procesadores soportan virtualizacion por hardware. A lo mejor maquinas antiguas sufren esto, pero ya es realmente raro mantener un servidor de tal antigüedad con semejantes caracteristicas, y ni siquiera plantearse el hecho de mandarlo a la guerra de las maquinas virtuales con semejante antiguedad

Es curioso como la curva de seguidores, en una balanza, empieza a inclinarse a favor de KVM. Desde la lectura de estas lineas KVM ha superado ampliamente a la comunidad de XEN, de hecho XEN cada vez pierde mas “seguidores” a costa de KVM como puede verse en la mayoria de las estadisticas.

Sobre los apoyos tecnologicos, economicos, y tecnicos, la verdad es que KVM empezo a gozar del apoyo del monstruo de Linux, RedHat, y desde entonces empieza a hacerle frente al todopoderoso VMWare

Y conjunto a esto, tambien han surgido las interfaces graficas para dar un apoyo definitivo e impulso al sistema KVM, con sus bonitas GUIs web y demas.

Hay que decir para terminar que KVM es de los pocos sistemas de virtualizacion que soporta el PCI Passthrough, esto es, la opcion de poder soportar PCIs “raras”, como tarjetas de sonido, o lo que aqui nos atañe, las bienamadas tarjetas del sistema Asterisk. Con esto, Asterisk podria obtener un reloj de sincronizacion puro, y podrian verse las funciones que hasta la fecha eran imposibles o demasiado complejas para verse implementadas directamente en Maquinas Virtuales.

Algun dia hablare porque es mucho mejor tener un Asterisk en las SOHO y PYMEs virtualizando que directamente sobre la maquina

Posted in Virtualizacion | Tagged , , , | Comentarios desactivados

Primeros Pasos: Eligiendo un Servidor

Posted on 22/06/2010 by SirLouen

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.

Posted in Hardware, Introduccion | Tagged , , , , | Comentarios desactivados