26 ago 2011

How to Implement a ‘Click to Call’ On your Elastix based TD Phone System

How to Implement a ‘Click to Call’ On your Elastix based TD Phone System

It seems everyone is talking about Click-to-Call functionality these days. A small application running on your main landing web
page allowing you potential customers provide their phone number and in return receive a FREE call from one of your reps. True, there are service providers out there that will be happy to take your hard earn money for such a service. However, it
is very easy to implement on ANY of our Elastix based TD phone systems and save that money. The following steps will explain how to do that:

Step 1 – using a terminal application (I like PuttY) SSH into your TD Phone System and log in as admin.

Step 2 – Issue the following commands – These will install and Unzip the needed script.

cd /tmp
wgethttp://downloads.voipjots.com/scripts/click-to-call.zip
unzip click-to-call.zip
mv click-to-call.php /var/www/html/click-to-call.php
rm click-to-call.zip

Step 3 – Issue the following commands – In order to edit the script.

cd /var/www/html
nano -w click-to-call.php

Step 4 – Modifying the script

find the line $strChannel = “IAX2/250″; and replace it with the extension you want to use for this application (usually the
extn where your rep is seating) we will use extn 150, a sip extn for this example $strChannel = “SIP/150″

find the line $strSecret = “amp111″; and replace it with $strSecret = “elastix456″;

save the file by hitting the Cntrl+X combination

Step 5 – in your favorite web browser put http://YOUR SYSTEMIP ADDRESS/click-to-call.php

You will get the following result

Insert your cell phone number and click the ‘call us button’ in return extn 150 will ring. As soon as you pick the call on extn 150
the TD phone System will dial out your cell phone number and your cell phone will ring connecting you to extn 150

It is that easy saving money using the TD Phone System

Script en Perl para hacer llamadas y enviar SMS utilizando Google Voice

Script en Perl para hacer llamadas y enviar SMS utilizando Google Voice


Este es un interesante artículo acerca de como interactuar con Google Voive por medio de scripts escritos en Perl para realizar una llamada, cancelar una llamada, y enviar un mensaje SMS con facilidad. Esto es ideal para personas que quieren enviar mensajes SMS de alertas.

El artículo original en inglés lo puedes leer aquí

Para poder utilizar este script, antes hay que descargarlo. A continuación, edite el nombre de usuario, contraseña y número de variables por defecto en la parte superior de la secuencia de comandos. Instale los módulos de perl que falten. Sin embargo, si ejecuta el script, éste le dirá qué es lo que falta.

Cómo utilizar gratis el Text-to-Speech de Google, en español

Articulo publicado originalmente en http://www.sinologic.net/blog/2010-03/como-utilizar-gratis-text-to-speech-google-espanol/ por Elio rojano

Como usuario de Google, siempre me ha gustado mucho la filosofía de esta empresa que crea servicios gratuitos y funcionales para sus usuarios sin obtener prácticamente nada a cambio salvo ver algo de publicidad de una forma poco intrusiva y en mucho casos, interesante. El diseño cuidado de todas las páginas que desarrolla y el cuidado y simplicidad con que crea cualquier servicio es algo que me hace sospechar que por cada programador que trabaja en Google, deben tener a diez psicólogos que los asesoran para obtener servicios útiles, sencillos de manejar y atractivos. Uno de esos servicios es el traductor de idiomas, no es que sea perfecto, pero he de reconocer que ayuda en muchos casos donde el idioma es un problema.

El traductor de idiomas de Google recientemente ha modificado su aspecto y no únicamente eso, si no que ha incorporado una característica que permite a alguien que quiere traducir una frase, poder escucharla para así aprender cómo se pronuncia, algo que desde un punto de vista objetivo tampoco es imprescindible, pero sí bastante interesante.

Lo que sí es interesante es que aprovechando esta característica de transformar una palabra o una frase a audio para poder escucharla, se puede conseguir que Google nos lea un texto cualquiera si sabemos cómo.

Vamos a ver cómo se hace…

La pega es que esta característica únicamente funciona a través de un navegador, ya que aprovecha el soporte HTML5 de los navegadores actuales (Internet Explorer < 9 no sirve), para generar dicho audio y poder escucharlo sin necesidad de utilizar otras herramientas.

Para que Google nos “lea” un texto, tenemos que acceder a una página como esta:

http://translate.google.com/translate_tts?tl=es&q=esto es una prueba

Una vez hayamos escrito esta dirección web en nuestro navegador con soporte de HTML5, veremos una pantalla en negro, y si tenemos los altavoces escucharemos una voz que lee la frase que hemos puesto en negrita.

Nos vamos a “Archivo > Guardar cómo…” y guardamos esta página como, por ejemplo prueba.mpga.

El archivo guardado, aunque tenga extensión mpga, realmente es un mp4 lo que es perfectamente compatible con cualquier aplicación de manipulación de sonidos como el ultra-práctico ‘sox‘.

Convertimos con ‘sox’ el archivo a un formato algo más manejable por nuestro Asterisk:

sox -t mp4 prueba.mpga -t wav prueba.wav

De esta forma, tendremos un nuevo archivo llamado prueba.wav que si lo abrimos con cualquier aplicación como Audacity, podremos ver que es perfectamente reproducible.

No es un TTS profesional, para eso hay otros, pero por lo menos, tendremos un TTS pasivo de una forma fácil, rápido y gratis.

Aquí os dejo el archivo wav que he generado para que escucheis la calidad del audio: prueba.wav

Que lo disfruteis. :D

24 ago 2011

Aumentando la capacidad de Elastix con Kamailio

Esto es una recopilacion de las notas "Elastix and Kamailio Part 1 – Installing" y "Elastix and Kamailio Part 2 – Integrating" que pueden ser encontradas en los link anteriores. No sustituye su lectura debido a que contiene importantes observaciones en los comentarios de cada uno. También se recomienda no realizar esto en una maquina que este en producción, es decir que una empresa dependa de ella para operar.
por favor colocar preguntas y dudas en el articulo original

Elastix and Kamailio Part 1 – Installing

WARNING: DO NOT INSTALL THIS ON A PRODUCTION MACHINE! Some of you may want be wanting to increase the capacity of your Elastix machine. Asterisk generally has issues when you start to put a lot of SIP peers on it. One of the best ways to get around this is to install a proper SIP server and join it with asterisk. This allows you to register all your SIP handsets to the SIP server and make calls through to your asterisk machine.

The Kamailio module for Elastix allows you to easily integrate Elastix with a enterprise SIP server. All SIP handsets register to Kamailio. All internal SIP calls stay within Kamailio however if a call is external then Kamailio will push the call out to asterisk to deal with it.

To install the Kamalio module you first need to create the directory for it to go in. It installs itself from the directory /var/kamailio

mkdir /var/kamailio

Now change to the directory

cd /var/kamailio

Download the kamailio integration file from the MBIT website

wget http://www.mbit.com.au/kamailio-v2.tgz

Untar the file into the directory

tar zxvf kamailio-integration.tgz

In the directory now will be a heap of files you want to execute the script that installs all the modules for you. To run the script execute install_kamailio.sh

./install_kamailio.sh

Soon as it is installed we will move to the next part for configuring Kamailio. The installation can take a while so please be patient. The installation can only be used with Elastix 2.0.

This entry was posted on Friday, November 5th, 2010 at 5:57 pm and is filed under Elastix.

La segunda Parte

Elastix and Kamailio Part 2 – Integrating

This article moves on from Part 1. I have updated the kamailio installation file so you will need to download this and run through Part 1 again. Make sure it all installs correctly.

The first step is to go into the /etc/kamailio.cfg file. In this file is the configuration for kamailio. When calls are between Kamailio extensions the call stays within Kamailio. If the call is to the PSTN then Kamailio sends it to asterisk. In the kamailio.cfg file we need to set a couple of parameters for your system. I have been building my test machine on the IP address 192.168.1.150. You will find 2 places where I have set this IP in the kamailio.cfg. Change these entries to the IP address of your machine using nano.

nano /etc/kamailio.cfg

Then restart Kamailio

service kamailio restart

Make sure kamailio is running

service kamailio status

The next step you need to do is go into freePBX. Under http://yourelastixip/admin is the freePBX interface. Go into module admin and you will find a new module called Kamailio integration. The Kamailio integration basically allows you to register handsets to Kamailio on port 5060. It also sends all external calls through asterisk when you make PSTN calls or voicemail calls. Once you have activated it go into the extensions tab in freePBX.

When adding a Kamailio extension you need to add a custom extension. If you add a SIP extension under freePBX this will simply be an asterisk extension. First add your extension number and display name. The last field required is the Kamailio password. You can scroll down and you will find an extra section called Kamailio services. Make sure it is enabled for the extension and you put in a password, click submit in the freePBX interface and reload freePBX.

The final step is to add a trunk in freePBX. Create a SIP trunk with the trunk name kamailio.

Under the peer details put

port=5060

allow=all

type=friend

context=from-internal

host=”yourelastixip”

canreinvite=nonat

This will allow calls to flow between kamailio and asterisk.

When you are done you should be able to register a phone to Kamailio with the details you put into freepbx.

Troubleshooting

If some of the packages dont install correctly try cleaning up yum

yum clean all

Then run the script again.

If everything installed correctly and you still cant make calls from Kamailio to asterisk try copying the kamailio.cfg from /var/kamailio again to /etc/kamailio. Then edit the IP address that I detailed above. Once this is done restart kamailio and try calling.

This entry was posted on Tuesday, January 25th, 2011 at 7:20 pm and is filed under Elastix.


Recuerden Revisen los comentarios en articulo original y NO lo prueben en producción.

23 ago 2011

Como dimensionar servidor para Elastix® IP PBX

Como dimensionar servidor para Elastix® IP PBX

Guía de referencia para instalaciones de Elastix® IP PBX Versión 1.5.2-2 y +

Nota Inicial: Ante todo aclaro que este instructivo no amerita ser la guía última de referencia sobre instalación de equipos e infraestructura de VoIP, solo es un conjunto de buenas prácticas recogidas por años de experiencia en el mundo de las redes convergentes de Voz, video y datos con alta calidad de servicio y fiabilidad, y no representa más que mi humilde experiencia en dichas áreas y es perfectible de ser mejorada por cada persona que lo considere.

Consideraciones previas: El sistema telefónico actual es uno de los sistemas mas estables que el mundo haya conocido, esto se debe a que esta regulado y homologado completamente en todos los países, existen estándares muy estrictos de calidad y de fabricación de equipos y básicamente a que en su gran mayoría, los equipos están basados en hardware de funciones específicas lo cual los hace extremadamente sólidos.

Al entrar en este cambio de paradigma de la conmutación de paquetes y software PBX que Asterisk® y Elastix® nos han traido entre otros, se hacen necesarios análisis de infraestructuras que antes no se tenían previstos y que son vitales para que la instalación de nuestra central de VoIP tenga una calidad de sonido y una estabilidad similar o superior a la de nuestra antigua y querida Centralita tradicional.

La guía que les presento a continuación se divide en diferentes partes que componen una red convergente base para una infraestructura de VoIP de alta calidad con sus recomendaciones en cada una por separado.

Siguiendo estos lineamientos básicos que no son onerosos si se hacen análisis correctos de costos por incidencias y fallas en nuestro sistema, les aseguro que se pueden reducir los downtimes y fallas comunes en mas de un 90% (según mis estadísticas empíricamente obtenidas).

Ambiente físico de los equipos:

  • Es de sentido común que un servidor, sus equipamientos asociados (gateways, switches, etc.) deben estar almacenados y alojados en lugares adecuados ya que los mismos tienen ventiladores y partes que generan calor y son sensibles a la tierra y otros materiales, por lo tanto deberán estar alojados en lugares frescos (no mas de 22 a 25 grados centígrados) con humedad superior al 40% e inferior al 80% y protegidos del humo, suciedad o gases agresivos con los materiales del mismo.
  • Es mas que obvia la necesidad de tener descargas a tierra en toda la instalación eléctrica.
  • No se debe jamás usar alcohol para limpiar los equipos de telefonía!!!! Esto daña las pantallas de lcd y los plásticos de los mismos. Usar trapos embebidos ligeramente en agua limpia (humedecidos) para su limpieza.
  • ¡Siempre utilizar sistemas de UPS! Los sistemas de energía ininterrumpida hoy día son económicos, de altísima calidad y nos protejen de alteraciones en la calidad de la energía y de cortes o alteraciones de voltaje, las marcas que mas recomiendo por mi experiencia y que soportan administración por software en Gnu/LINUX son Liebert®, APC®, Powerware®, Toshiba® y MGE®.
  • Utilizar protecciones gaseosas para toda conexión a la red pública telefónica.

Cálculo de potencias y prestaciones del/de los server/s:

  • Como 1era. Medida se deberá tener en cuenta que la vida útil de un server debe ser tomada en 3 años como media normal hoy día, en condiciones de uso adecuadas y en un ambiente acorde. Tomando eso como base al analizar los requerimientos del cliente es sano asumir como base que como mínimo el sistema podrá crecer un 50% en esos 3 años y calcularemos el sistema a comprar con ese número final según esta pequeña tabla:
  • De 0 a 25 users concurrentes: Server Dual Core de mas de 2ghz, 1 o 2gb ram.
  • De 25 a 100 users concurrentes: Server Quad Core o Dual Dual Core, 2gb a 4gb ram.
  • Mas de 100 users concurrentes: Server Dual Quad Core o superior, 4gb o + de ram.
  • Mas de 500 users concurrentes, Cluster de servers a medida.

Con respecto a estos cálculos uds podrán decir que exagero en las specs pero ya van a ver que cuando el cliente se da cuenta todo lo que puede hacer con su sistema, todo les va a quedar chico rápidamente y a los costos de hardware actuales mas vale que sobre y que no que falte.

Por supuesto ni hablar si se usa compresión de voz, grabaciones, etc, etc, etc….

  • Discos rígidos: Todas las pc y servers de hoy día tienen RAID por hardware así que ni toco el tema de soft raid que es totalmente inutil a menos de que usemos máquinas virtuales. Por muy poco dinero se puede montar RAID-1 (espejado de 2 discos) en cualquier sistema por lo cual será el estandar que recomiendo y en particular no metería menos de 500gb de disco (muy económicos hoy día y con cantidad de espacio para crecer). Si disponemos de mas dinero configurar un RAID- 5 de 4 discos de 500gb nos daría mas margen de maniobra todavía y sería mi decisión a tomar.
  • Tarjetas de red: siempre seleccionar servers que traigan redes gigabit ethernet en lo posible, si traen 2 tarjetas mucho mas adecuado incluso.
  • Redundancia: Siempre sería recomendable tener un server de backup ya sea Pasivo offline o sino activo online con Dundi y alguna herramienta de monitoreo.
  • Marcas y modelos de server recomendadas por su estabilidad, calidad y relación costo/beneficio:
    • Hewlett packard Series ML110/115 – ML150 – DL360
    • Dell Series Poweredge
    • IBM Series X (3200 / 3500)
    • Sun Fire X Series (Opteron y Xeon)
  • Tarjetas de telefonía: Tener mucho cuidado en el modelo de tarjeta a elegir (no equivocarse en el slot). Antes era solamente elegir PCI 3,3Volts o 5Volts ahora esos slots ya son obsoletos y nuestra decisión debe pasar por qué modelo de pci-express elegir (1x, 8x etc.) y que nuestro server lo soporte ya que en el caso de servers blade por su formato se hace dificil elegir tarjetas adecuadas.
  • Sobre marcas de tarjetas muchos quizás no estarán de acuerdo con esta decisión mia de poner estas 2 solamente pero son las únicas con las cuales se que no voy a tener ningún tipo de inconvenientes ni problemas de compatibilidad de hardware o drivers:
    • DIGIUM®
    • SANGOMA®

No se debe olvidar en este item de selección de Tarjetas que la decisión de marca y modelo tambien debe ser tomada por la elección del protocolo de interfaz digital a ser entregado en la tarjeta ya sea E1, T1 y sus protocolos subyacentes ISDN o R2.

Equipamiento de redes y Switches

  • Es de sentido común que el cableado de red y de equipamiento telefónico tradicional deberá estar en condiciones, sin cables pelados, conectores rj dañados o fallas a la vista como mínimo, lo adecuado sería que exista un cableado estructurado certificado con categoría 5e como mínimo o 6 si es posible.
  • Sería lo adecuado tener todo el cableado y equipamiento ordenado en racks, con patch panels y jacks correctamente instalados en las paredes.
  • Utilizar Switches Gigabit de ser posible en el core de la central e interconectados con los switchs de los teléfonos por los ports de uplink adecuados, por sfp o a traves de backplanes multigiga si lo soportan, usar ingeniería de red en los switches y si lo permiten STP o RSTP.
  • Siempre utilizar Switches de marcas reconocidas que sean administrables como mínimo en capa 2 y que soporten VLANS. (no molesten con este punto hay 3Com® y Allied Telesis® desde U$S200 en 24 ports de 100Mbits, quien ahorra plata aquí en este item directamente no debería implementar una central ip y perdón por mi honestidad brutal).
  • Si se utiliza el mismo Switch para conectar una red Convergente de datos (Windows® o xNIX) con Asterisk® siempre separar el tráfico de las mismas en VLANS para evitar que un ataque o fallas de las PC alteren la calidad de la red de VoIP.
  • Utilizar switches PoE (Power Over Ethernet, Estándar IEEE 802.3af) cada vez que se pueda y los teléfonos y el presupuesto lo permitan.
  • Utilizar UPS en los racks de datos igual que con los servers ya que con las centrales tradicionales solo con alimentar la misma no se cortaba ningún teléfono ahora si no tenemos PoE y se corta la energía se nos cae todo el sistema, cuidado con este punto!!!!
  • Al usar enlaces de internet para extensiones remotas USAR VPN o algún tipo de encriptación o tunelización!!!!! Recuerden el tema de seguridad en voip, la cual hoy día sigue siendo muy rudimentaria.
  • No se olviden de los problemas que puede causar el NAT en conexiones SIP!!!!! Cuidado!!!
  • Tomar en cuenta que al usar enlaces de internet existen requerimientos de calidad de enlaces que no siempre son controlables y que no siempre se tiene la velocidad deseada a todos los destinos por la característica de Best Effort de las redes públicas.

Un ejemplo típico: si tengo un xDSL de 5MBits no tengo 5MBits para voip sino que tengo 5MBits de bajada y la subida seguramente será de 256 o 512KBits lo cual usando un códec como uLaw (g711 ley mu) ocupará 64Kbits mas 24Kbits de encabezados dejándonos con 2 o 4 canales como máximo al mismo tiempo si lo usaramos solo para voip, ni hablar de que tendriamos que tener routers con QoS y administración de ancho de banda para compartir un solo enlace VoIP y datos.

Teléfonos, Gateways y Softphones

  • ¡CUIDADO CON LAS HOMOLOGACIONES DE LA ITU DE CADA PAIS: antes de usar cualquier teléfono o gateway se deben parametrizar correctamente sus tonos de discado, corte, duración de tonos DTMF y flash entre otros!
  • Gateways FXO y FXS: Los que tienen las características de calidad y prestaciones que considero adecuadas son los siguientes:
  • Quintum® todos los modelos
  • Audiocodes® todos los modelos
  • Linksys by Cisco® de 2 ports o más, PAP2T, SPA8000, etc., los 3102 o similares de 1 port no son adecuados para instalaciones serias.
  • Grandstream®, solo los GXX4104 y 8 de 4/8 ports FXO, los FXS no los considero adecuados al día de hoy para aplicaciones profesionales
  • Welltech® Wellgate 3802/04/06 de 2, 4 y 6 ports FXO.
  • HAY que tener cuidado con ESTO: los gateways FXO suelen no soportar las estrategias de rotación de líneas aleatoria o las funciones de selección de llamadas entrantes por DID seleccionables en su firmware y a veces suelen tener problemas con los reconocmientos y paso de CALLER ID a la central…CUIDADO!!!!
  • CUIDADO CON LOS FAXES: Si los gateways no soportan el protocolo T.38 es complicado que puedan pasar correctamente los faxes en todas las ocasiones.
  • No se soportan MODEMS: Por la naturaleza destructiva del muestreo y la ley de nyquist la reconstrucción de señales de modems v92, v90, etc. se hace matemáticamente imposible de forma sostenida por lo cual no funciona la transmisión de datos a alta velocidad en centrales IP.
  • Gateways E1/T1 ISDN Primario o MFC-R2: Solo recomiendo aquí 4 marcas las cuales no requieren de mayor consideración por ser increiblemente potentes y de una calidad extrema y mas que probada mundialmente:
    • Cisco®
    • Audiocodes®
    • Quintum®
    • Redfone®
  • Teléfonos IP y terminales: Los criterios aquí pueden ser variados y con extremas divergencias, en mi caso particular mis marcas favoritas por prestaciones, capacidad de expansión futura, facilidad de creación de repositorios de autoconfiguración y upgrade, calidad de sonido y durabilidad son las siguientes:
    • Polycom®
    • Cisco® y Linksys By Cisco®
    • Snom®
    • Aastra®
    • Grandstream® solo las gamas GXP y GXV
  • Softphones: 1ero hay que saber que los softphones son la opción mas económica para implementar una central IP pero a su vez son la opción profesionalmente menos recomendada y que trae a largo plazo mas inconvenientes.
    ¿Las razones? Simple, dependen de una pc, si se cae la pc se cae la extensión de la central y quizás deje hasta bloqueado el canal, si la pc a usar (en el 90% de los users son máquinas Windows®) se infecta de virus puede meter saturación en los ports del Switch que obviamente debería estar en la misma VLAN de la central lo cual es un problema grave de seguridad y podría afectar el funcionamiento de la misma. Obviamente esto nos da mas razones para usar en un call center o en centrales usando Softphones soluciones 100% basadas en GNU/Linux inmunes a virus y otras cuestiones de seguridad.
    Ahora sabiendo esto mis opciones preferidas en este item son:
    • Zoiper®
    • Ekiga®
    • Xten EyeBeam®
    • Xten Bria Communicator®

Seguridad lógica en la red y los equipos

  • Nuevamente apelo al sentido común, si usan claves del tipo 1234 en los teléfonos, usuarios de interfaces web, logins de switches o los users, se merecen un ataque!!!! Y deberían ser despedidos de la empresa donde trabajan (nuevamente sorry por ser un animal, pero nunca me canso de repetir esto y de seguir viéndolo en instalaciones a cada rato)…la seguridad hoy día lo es todo por tanto segurizar passwords, accesos de red a equipos, claves y users de mas de 7 dígitos y con mayúsculas y números mezclados.
  • Usar VPN o IAX® encriptado en extensiones remotas o interconexiones de centrales.
  • Separen las redes en VLANS para voz y datos.
  • Sistemas de IDS/IPS (intrusion detection system / intrusion prevention system) y monitorización SNMP son siempre bienvenidos en instalaciones de calidad.
  • Siempre tener un equipo de testing por si tenemos una falla o para probar upgrades, ya que una vez en producción un equipo no se puede apagar y cambiar cada 15 minutos y todo cambio debe ser testeado en un equipo gemelo siempre antes de ser implementado y pasado a producción.
  • Tener elaborado un plan de contingencia en caso de fallas graves.
  • Backup automático diario o semanal de la config de las centrales y sus archivos asociados así como un testeo semanal de los mismos en el server de respaldo.
  • Estar atentos a los boletines de seguridad de CentOS, Digium, etc. para saber las vulnerabilidades o bugs que puede tener nuestro sistema sin parchear.
  • Es redundante hablar de lo que les puede pasar si tienen una central en IP pública sin firewall o similar…Si les pasó algo con respecto a esto sin palabras a llorar a otro lado.

NOTA FINAL:Cada usuario y cada implementador de centrales IP es distinto, cada bolsillo es distinto, cada vez que salgamos a ver un nuevo proyecto es un universo nuevo, pero si seguimos una serie de lineamientos base de calidad y profesionalismo podemos llegar a tener instalaciones de alta disponibilidad, de alta performance con una mínima participación nuestra para solucionar los inconvenientes típicos que surjan de las implementaciones.

Siempre recuerden que a mas seguridad, mas calidad y mas servicios le sigue un aumento de precios por lo cual cada solución será un exquisito ballet, o según el punto de vista, una bárbara pelea callejera entre costos y beneficios…

Espero este humilde aporte les sirva a todos para mejorar cada día nuestro nivel profesional y por favor si desean soporte, mas info o consultas específicas les solicitamos hacerlas a través del soporte oficial pago de de nuestra empresa y de Elastix® para seguir apoyando el crecimiento del Software Libre.

post original ubicado en http://www.fenixsolution.com.ar