Asterisk con Websockets para WebRTC y probando SIPML5

ATENCIÓN: Este artículo ya no es útil puesto que Chrome en su versión 35 en adelante ha pasado su sistema de encriptación para WebRTC de SDES a SRTP/DTLS como estaba planificado desde principios de Enero 2014. Este articulo definía el metodo para montar un sistema Asterisk basado en este sistema. Cuando salga la resolución definitiva en Asterisk creare otro articulo para explicar como configurar con Asterisk este sistema

Volviendo a la carga con Artículos sobre Asterisk, voy a explicar algo que aunque ya está algo visto, ha sido parte de mi experiencia y como viendo haciendo hasta ahora intento explicarlo con el mayor número de detalles

Hay que considerar que en este momento estoy trabajando con la versión CERT de Asterisk concretamente la versión 11.6-cert1

webrtc asterisk

Preparando la instalación del Sistema Asterisk para WebRTC

En primer lugar, sería conveniente tener soporte para el códec OPUS que es una de las claves que WebRTC utilizan de forma nativa y quizá sea de las principales ventajas de su uso.

Si no tenemos autoconf necesitamos instalarlo y también hará falta libtool y pkg-config

# apt-get install autoconf libtool pkg-config

ATENCIÓN (Con Asterisk  >11.6) si compilamos con soporte OPUS habrá un problema de AUDIO (Issue en Git de Meetecho: https://github.com/meetecho/asterisk-opus/issues/6). Por eso este paso de instalación de Opus en este tipo de versiones, seria conveniente saltárselo de momento a partir de aquí:

Para ello lo podemos descargar desde el repositorio GIT de este proyecto. Tenemos que descargar este fichero en el directorio raíz donde esta el código de Asterisk listo para ser compilado.

#wget https://raw.github.com/meetecho/asterisk-opus/master/asterisk_opus+vp8.diff

Desde ahí lanzamos el parche

# patch -p1 -u < asterisk_opus+vp8.diff

Y a continuación preparamos el sistema para que pueda instalarse el códec OPUS:

# ./bootstrap.sh

En mi caso, trabajando con Ubuntu Server 12.04, me hace falta instalar la librería Opus en el sistema, que no viene en los repositorios de Ubuntu por defecto:

# apt-get install python-software-properties
# add-apt-repository ppa:ubuntu-sdk-team/ppa
# apt-get update
# apt-get install libopus-dev

Después de instalar el códec OPUS pasamos a instalar el resto de las dependencias para su funcionamiento

También nos hará falta la librería libsrtp0-dev para gestionar la encriptación de las conexiones WebRTC y las librerias de Universally Unique Identifier, uuid-dev (este último es específico la versión 11 de Asterisk y su no instalación provocaría problemas en la comunicación con ICE, y aunque la llamada entraría en el sistema, no se escucharía nada por una cuestión de RTP) . Podemos instalarlas directamente desde los repositorios del sistema:

# apt-get install libsrtp0-dev libsrtp0 uuid-dev

Con todo preparado realizamos la instalación de Asterisk

# ./configure --with-crypto --with-ssl --with-srtp=/usr/lib

Finalmente seleccionamos el códec Opus y Formato VP8 con make menuselect (Codec Translators -> códec_opus y Format Interpreters -> format_vp8)

Por otro lado, para instalar nuestro sistema websockets en Asterisk primero deberemos instalar el Recurso HTTP Websocket. Esto se realiza durante la instalación de Asterisk (make menuselect) en la sección Resource Modules, y cuyo nombre es res_http_websocket

También se recomienda por cuestiones de calidad, seleccionar los paquetes musicales tanto los mensajes de Asterisk como los de Music On Hold en formato SLN16 (CORE-SOUNDS-ES-SLN16, MOH-OPSOUND-SLN16 y EXTRA-SOUNDS-EN-SLN16)

Y ya podemos compilar Asterisk con todo el soporte necesario

# make && make install

Configurando Asterisk y Websockets

A partir de aquí ya tenemos el sistema preparado para ser configurado simplemente. En primer lugar configurador el servidor HTTP de Asterisk desde el fichero http.conf

[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088

A continuación pasamos a configurar el soporte ICE y STUN en el fichero RTP.conf para ello añadimos las líneas dentro de la etiqueta [general]

icesupport=true
stunaddr=stun.l.google.com:19302

Finalmente pasamos a configurar un peer SIP para que soporte la comunicación con WebSockets. En el fichero sip.conf dentro de la etiqueta [general]:

allowguest=no
udpbindaddr=0.0.0.0:5060

Y creamos una extensión con los siguientes parámetros

[extension1]
secret=miclavesecreta
transport=udp,wss,ws
encryption=yes
avpf=yes
icesupport=yes
directmedia=no
host=dynamic
nat=force_rport,comedia
qualify=yes // opcional
type=friend
context=phones

Con todo esto solo necesitaremos configurar en nuestro servidor Web un softphone basado en WebRTC y que soporte WebSockets (esto es opcional, si tenemos publicado el servidor SIP el webphone RTC se conectaría directamente, los websockets serían utiles en caso que definieramos en el sip.conf un nombre al dominio (con la propiedad realm) y conectáramos a este realm a traves de una conexión con Websockets (otra de las claves principales de WebRTC junto al Codec OPUS). Por ejemplo,supongamos la dirección pública de nuestro servidor es 123.123.123.123 y hemos abierto el puerto 8088 (del servidor HTTP de Asterisk para habilitar los Websockets). Configuramos en el fichero sip.conf,

[general]
realm=10000horas.com

Ahora en el softphone configuramos (por ejemplo SIPML5, aunque pongo otras opciones más adelante):

Private Entity: la extensión usada, en este caso extension1
Publc Entity: sip:extension1@10000horas.com
Password: la_password_de_la_extension
Realm: 10000horas.com

Y en el apartado “Expert” debemos configurar la dirección a la que apunta el Websocket. Usando comunicación Websockets sin encriptar:

Websocket Server URL: ws://123.123.123.123:8088/ws

Así estableceríamos la conexión en vez de directamente al servidor SIP, lo haríamos gracias al servidor WebSocket, lo que es bastante provechoso y podríamos llegar a incrementar la seguridad del sistema (considerando que tener el Puerto 5060 a libre albedrío es peligroso, aunque no todos opinan lo mismo)

Disponemos de varias opciones entre las más populares SIPML5 y JsSIP. De todas formas si tenemos el servidor delante de un firewall o hemos gestionado los puertos correspondientes podríamos hacer una prueba desde cada uno de los sistemas:

SIPML5: http://sipml5.org/call.htm
JsSIP: http://tryit.jssip.net/

Espero que os haya servido, os recomiendo el cliente de escritorio Phoner Lite (http://phonerlite.de/index_en.htm) si queréis hacer pruebas ya que es de los pocos Softphones que dispone del códec OPUS por defecto.

Montando un Sistema Asterisk Autonomo I

Durante el curso de Asterisk Advanced, una de las cuestiones que surgieron con los compañeros, era el tema de la “practicidad” eventual que podia surgir a la hora de decidir montar una interfaz grafica a pesar de que muchos hayan criticado, es el simple hecho que otorga un “sistema” para que manos inexpertas (bajo nuestra aprobacion y previamente formados), puedan tomar el control de nuestro Asterisk sin nuestra supervision constante.

Evidentemente surgen algunas inconveniencias, que son inevitables en este tipo de situaciones, pero en las manos adecuadas, pueden ser mas pros que contras (por ejemplo explicandole a un equipo tecnico o IT funcionalidades basicas de Asterisk como crear nuevas extensiones para poder cursar llamadas. De esto se trata la idea de montar un sistema Autonomo (al menos autonomamente de nuestra persona).

Un paso mas alla, viendo el sistema RealTime de Asterisk, se me ocurrio la -evidente- idea de crear una micro interfaz grafica (por ejemplo basada en web con PHP como sera el caso que exponga a continuacion), para gestionar esos aspectos de Asterisk especificos, y poder definitivamente, tomando esto como ejemplo generico, poder obviar todas esas interfaces graficas (ejemplo FreePBX) para siempre.

Lo que me planteo de ejemplo ahora: Activar RealTime para los “peers” SIP de nuestro Asterisk y crear la interfaz grafica web en PHP para Crear y Borrar estas extensiones (La funcion de editar seria Borrar y volver a crear para este ejemplo sencillo, aunque realmente no seria nada dificil de implementar)

Como ya comente en su momento en otro mensaje, el montaje de un sistema RealTime es verdaderamente secuencial, es mas ya lo hicimos en las practicas durante Asterisk Advanced en detalle.

En primer lugar, obviamente necesitamos tener instalado un sistema de gestion de bases de datos como MySQL, tambien un servidor web como Apache, y los modulos de PHP para el mismo. En este caso, como ya vimos antes, LAMP es lo ideal. Asi que ejecutamos tasksel y lo instalamos (LAMP Server, Ubuntu/Debian)

Tambien necesitamos las librerias de ODBC puesto que vamos a utilizarlas con Asterisk:

# aptitude install unixodbc libmyodbc

En segundo lugar, configuramos la base de datos y la tabla donde volcar los usuarios SIP:

– Creamos un fichero por ejemplo en /tmp/ llamado por ejemplo sip_buddies.sql con esta informacion (se puede encontrar mas informa acerca de la tabla asociada a los peers SIP  aqui). Atencion al ultimo campo que coloreo en Rojo. Muy importante que lo agreguéis manualmente para lo que vamos a tratar de hacer a continuacion

CREATE TABLE `sip_buddies` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(80) NOT NULL default ”,
`host` varchar(31) NOT NULL default ”,
`nat` varchar(5) NOT NULL default ‘no’,
`type` enum(‘user’,’peer’,’friend’) NOT NULL default ‘friend’,
`accountcode` varchar(20) default NULL,
`amaflags` varchar(13) default NULL,
`call-limit` smallint(5) unsigned default NULL,
`callgroup` varchar(10) default NULL,
`callerid` varchar(80) default NULL,
`cancallforward` char(3) default ‘yes’,
`canreinvite` char(3) default ‘yes’,
`context` varchar(80) default NULL,
`defaultip` varchar(15) default NULL,
`dtmfmode` varchar(7) default NULL,
`fromuser` varchar(80) default NULL,
`fromdomain` varchar(80) default NULL,
`insecure` varchar(4) default NULL,
`language` char(2) default NULL,
`mailbox` varchar(50) default NULL,
`md5secret` varchar(80) default NULL,
`deny` varchar(95) default NULL,
`permit` varchar(95) default NULL,
`mask` varchar(95) default NULL,
`musiconhold` varchar(100) default NULL,
`pickupgroup` varchar(10) default NULL,
`qualify` char(3) default NULL,
`regexten` varchar(80) default NULL,
`restrictcid` char(3) default NULL,
`rtptimeout` char(3) default NULL,
`rtpholdtimeout` char(3) default NULL,
`secret` varchar(80) default NULL,
`setvar` varchar(100) default NULL,
`disallow` varchar(100) default ‘all’,
`allow` varchar(100) default ‘g729;ilbc;gsm;ulaw;alaw’,
`fullcontact` varchar(80) NOT NULL default ”,
`ipaddr` varchar(15) NOT NULL default ”,
`port` smallint(5) unsigned NOT NULL default ‘0’,
`regserver` varchar(100) default NULL,
`regseconds` int(11) NOT NULL default ‘0’,
`lastms` int(11) NOT NULL default ‘0’,
`username` varchar(80) NOT NULL default ”,
`defaultuser` varchar(80) NOT NULL default ”,
`subscribecontext` varchar(80) default NULL,
`useragent` varchar(20) default NULL,
`useradmin`  int(1) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`),
KEY `name_2` (`name`)
) ENGINE=MyISAM ROW_FORMAT=DYNAMIC;

#mysql -p
Entramos con nuestra password
mysql> create database asterisk;
mysql> use asterisk;
mysql> source /tmp/sip_buddies.sql

En tercer lugar vamos a configurar los ficheros basicos de Asterisk para poder trabajar con el conector ODBC

/etc/asterisk/extconfig.conf

[settings]
sippeers => odbc,asterisk ,sip_buddies

/etc/asterisk/res_odbc.conf

[asterisk]
enabled => yes
pre-connect => yes
dsn => asterisk
username => root
password => (el password que le pusimos al usuario de la base de datos mysql root durante la configuracion de LAMP)

/etc/odbc.ini

[asterisk]
Description = ODBC para MySQL
Driver = MySQL
Server = localhost
Database = asterisk
Socket = /var/run/mysqld/mysqld.sock

/etc/odbcinst.ini

[MySQL]
Description = MySQL ODBC MyODBC Driver
Driver = /usr/lib/odbc/libmyodbc.so
Setup = /usr/lib/odbc/libodbcmyS.so

Con esto vamos al CLI de Asterisk
# asterisk -r
CLI> odbc show

Y si vemos “Connected: Yes” entonces ya esta preparado

En cuarto lugar vamos a configurar los usuarios SIP:

Para ello creamos un fichero temporal por ejemplo /tmp/usuarios_sip_buddies.sql con la siguiente info:

INSERT INTO sip_buddies (`name`, `host`, `nat`, `type`, `cancallforward`, `canreinvite`, `context`, `md5secret`, `qualify`, `disallow`, `allow`, `fullcontact`, `ipaddr`, `port`, `regseconds`, `lastms`, `username`, `defaultuser`)
VALUES (‘ext10’, ‘dynamic’, ‘no’, ‘friend’, ‘yes’, ‘yes’, ‘extensiones’, ‘e8a325cb599ad4b6eb95d79aa4506ed2’, ‘yes’, ‘all’, ‘g729;ilbc;gsm;ulaw;alaw’, ”, ”, ‘0’,’0′, ‘0’, ”, ”)

Importante, el ultimo valor a 1, y la clave sera 1234 en formato md5 evidentemente se deberia cambiar.

Ahora como antes lo ejecutamos desde el interfaz de comandos de MySQL

#mysql -p
mysql> use asterisk;
mysql> source /etc/usuarios_sip_buddies.sql

Finalmente necesitamos editar el fichero sip.conf con una configuracion minima. Por ejemplo:

/etc/asterisk/sip.conf

[general]
language = es

Desde este mismo momento ya tenemos el usuario sip ext10 con la clave 1234 listo para funcionar. Podemos probarlo con cualquier telefono SIP.

Puede parecer muchisima historia comparado a configurar un fichero sip.conf, pero con la practica y unas plantillas, esta gestion se realiza en 5 minutos y ahora viene la “potencia”.

El script PHP:

Voy a crear un solo fichero PHP al estilo monolitico para que funcione y nada mas. Evidentemente sera bastante mejorable y ya esta en nuestras manos con unos conocimientos basicos de programacion PHP (y obviamente adaptable a cualquier otro lenguaje de programacion con el que nos sintamos mas comodos)

Lo primero vamos a crear algunos directorios dentro del lugar donde tengamos publicado el servidor web apache, por defecto /var/www
# cd /var/www
# mkdir asterisk
# cd asterisk
# mkdir sip
# cd sip

Ahora vamos a crear un fichero index.php con el siguiente contenido:

 <?php

// Conexion a la base de Datos

$base = "asterisk";
$host = "localhost";
$user = "root";
$password = "nuestra_contraseña_sql";
$conexion = mysql_connect($host,$user,$password);
$result = mysql_select_db($base,$conexion) or die ("Error en la Conexion a BD");

session_start();

// Si no estamos logeados

if (!$_SESSION['login'])
{
 if(isset($_POST['loginsubmit']))
 {
 $usuario = $_POST['usuario'];
 $password = $_POST['password'];

 if((!$usuario) || (!$password))
 {
 echo "Error 1<br>";
 exit();
 }
 $password = $usuario.":asterisk:".$password;
 $password = md5($password);
 $query = mysql_query("SELECT * FROM sip_buddies WHERE name='$usuario' AND md5secret = '$password' AND useradmin = '1'");
 if (mysql_num_rows($query) > 0)
 {
 session_register('login');
 $_SESSION['login'] = '1';
 }
 else
 echo "Error 2<br><br>";

 echo "<a href='index.php'>Home</a>";
 }
 else
 {
 echo "<form method='post' action='?'>";
 echo "Usuario: <input name='usuario' type='text'><br>";
 echo "Contrase&ntilde;a: <input name='password' type='password'><br>";
 echo "<input type='submit' name='loginsubmit'>";
 echo "</form>";
 }

}
// Si ya estamos logeados

else
{
 // Salida del Sistema
 if(isset($_REQUEST['exit']))
 {
 session_destroy();

 if(!session_is_registered('login'))
 echo "<a href='index.php'>Home</a>";

 }
 // Insercion de un nuevo Registro
 elseif(isset($_POST['insertsubmit']))
 {
 $sipuser = $_POST['sipuser'];
 $sippass = $_POST['sippass'];
 $sippass = $sipuser.":asterisk:".$sippass;
 $sippass = md5($sippass);
 $query = mysql_query("INSERT INTO sip_buddies (`name`, `host`, `nat`, `type`, `cancallforward`, `canreinvite`, `context`, 
 `md5secret`, `qualify`, `disallow`, `allow`, `fullcontact`, `ipaddr`, `port`, `regseconds`, `lastms`, `username`, `defaultuser`) 
 VALUES ('$sipuser', 'dynamic', 'no', 'friend', 'yes', 'yes', 'extensiones', '$sippass', 'yes', 'all', 'g729;ilbc;gsm;ulaw;alaw', '', '', 
 '0','0', '0', '', '')");

 echo "<a href='index.php'>Home</a><br>";
 echo "<a href='index.php?exit'>Exit</a>";
 }
 // Borrado de un Registro
 elseif(isset($_POST['deletesubmit']))
 {
 $sipid = $_POST['sipid'];
 $query = mysql_query("DELETE FROM sip_buddies WHERE id = '$sipid'");

 echo "<a href='index.php'>Home</a><br>";
 echo "<a href='index.php?exit'>Exit</a>";
 }
 // Formularios de Insercion y Borrado
 else
 {
 echo "Insertar Registro:<br>"; 
 echo "<p><form method='post' action='?'>";
 echo "Usuario: <input name='sipuser' type='text'><br>";
 echo "Contrase&ntilde;a: <input name='sippass' type='password'><br>";
 echo "<input type='submit' name='insertsubmit' value='Insertar'>";
 echo "</form></p>";

 echo "<table border='1'>";
 echo "<tr><td colspan ='2' align='center'>SIP Peers Activos</td></tr>";
 echo "<tr><td>Usuario</td><td>Borrar</td></tr>"; 

 $query = mysql_query("SELECT * FROM sip_buddies WHERE type = 'friend'");
 $rows = mysql_num_rows($query);
 for ($i=0;$i<$rows;$i++)
 {
 $sippeersarray = mysql_fetch_array($query);
 $sipuser = $sippeersarray['name'];
 $sipid = $sippeersarray['id'];

 echo "<tr>";
 echo "<td>".$sipuser."</td>";
 echo "<td>";
 echo "<form method='post' action='?'>";
 echo "<input type=hidden name='sipid' value='$sipid'>";
 echo "<input type=submit name='deletesubmit' value='Borrar'>";
 echo "</form>";
 echo "</td>"; 
 echo "</tr>";

 } 
 echo "</table>"; 
 echo "<a href='index.php?exit'>Exit</a>";

 }
}

?>

Y eso es todo, ahora podemos acceder a traves de un navegador a la direccion:

http://ip_nuestro_servidor_asterisk/asterisk/sip/

Y aparecera para introducir un usuario y contraseña. Siguiendo el ejemplo seria Usuario: ext10,  Contraseña: 1234

Asi accederiamos a la micro interfaz para Crear y Borrar extensiones.

Evidentemente este codigo tiene bastantes deficiencias “tecnicas”, por ejemplo se podria intentar realizar una tecnica de Inyeccion de Codigo SQL para logearnos como el usuario administrador por las “bravas”, y ya conociendo la estructura, hasta darnos de alta un usuario Administrador para acceder siempre. Pero la idea basica era poder ejemplificar lo que queria mostrar con este articulo, que con solo seguir unos pasos de 5 minutos o menos, y tener este script PHP listo para ser “insertado” en el servidor web, tendriamos una interfaz totalmente Autonoma para nuestro cliente, equivalente a la que “instalamos” en mensajes anteriores, para la gestion de salas de conferencias MeetMe.

Ademas esta claro este codigo se podria mejorar para añadir la posibilidad de editar extensiones, o incluso configurar mas parametros de las extensiones (o tener dos interfaces, una de administrador para nosotros mismos, y otra para los usuarios), asi no tendriamos que andar “trasteando” directamente en el interfaz MySQL si modificamos regularmente las extensiones.

Con esto, ya empiezan a haber motivos para poder ir planteandonos dar un primer paso y dar fin a las interfaces graficas de Asterisk!.

Tengo que reconocer que este mensaje me ha llevado componerlo mas tiempo del previsto originalmente. Toda mejora al codigo, o sugerencia como siempre, sera ampliamente agradecida a traves de los comentarios.

Como conseguir llamadas al minimo precio via SIP

Ya sabeis que una de las famosas ventajas del mundo SIP es la posibilidad de conseguir llamadas muy baratas gracias a los diversos proveedores SIP que hay en el mercado.

La dificultad radica la mayor parte del tiempo, en localizar ese proveedor SIP que ofrezca en un momento determinado la mejor tarifa.

Resulta que existe una web, que mantiene bastante actualizadas, las mejores tarifas, para muchos proveedores SIP, para practicamente todos los paises y todos los tipos de llamadas a los mismos (a moviles y a fijos).

Lo interesante de todo esto, es la posibilidad de configurar multiples proveedores y a la vez enrutar las llamadas segun el destino de las mismas por uno o por otro en funcion de nuestra necesidad.

La pagina web de la que estamos hablando es: http://backsla.sh/betamax

Si observais en el momento en que escribo este mensaje, el mejor operador es EasyVOIP. No todos los proveedores de la lista ofrecen la posibilidad de conectarse via SIP a los servicios, (por ejemplo CheapVOIP no lo permite, solo llamadas a traves de su dialer). En este caso Easy VOIP ofrece llamadas a operadores moviles en España a solo 0,04 dolares el minuto sin establecimiento de llamada (del orden de los 0,03 centimos de euro). No existe ni un solo operador en España que ofrezca este nivel de competitividad. Ni siquiera existe una tarifa plana que pueda competir, lo mas cercano, las tarifas Leon de Orange que son las menos restrictivas a nivel de tiempos. Los OMV (Operadores Moviles Virtuales) al cursar llamadas a traves de los operadores principales (Orange, Movistar, Vodafone o Yoigo), todos imponen el establecimiento de llamada, que para llamadas relativamente cortas (menos de 15 minutos), supone un sobrecoste excesivo (por tanto entramos en restricciones).

Luego hay tarifas baratas, por tramos horarios, numeros preferidos, etc, etc, pero igual entramos en restricciones. Todo esto lo podemos sintetizar en un operador SIP. Hoy en dia con las conexiones a Internet, es practicamente despreciable la baja calidad de la señal (latencias de entre 50 a 70ms con un jitter inferior a 10ms), y por simultaneidad de canales precisamente es el caudal simetrico ya empieza a sobrar (es relativamente facil conseguir caudales de 2Mbits simetricos). Pongamos uno de los peores casos, el codec ULAW G.711, 64kbits/s duplex. En 2 Mbits simetricos tenemos accesible un “troncal” de 32 llamadas simultaneas, podria decirse, semejante a un Primario E1.

Pero si decidimos gastarnos un dinerillo en unas cuantas licencias G.729 (algo muy interesante sinceramente, ya que reducimos gracias a la compresion, hasta 4 veces el caudal de ULAW), es decir 8 kbits/s, por tanto tendriamos acceso a un “troncal” de hasta 128 llamadas simultaneas, o lo mas clasico en estos casos, dedicar, 512kbits simetricos al trafico VoIP para conseguir ese “primario de voz”, mediante politicas QoS, y tener accesible el resto del caudal para aplicativos internos de la empresa en segundo o tercer nivel.  Una licencia G.729 para un canal concurrente, vale solo 10 dolares. Si hablamos de 32, 320 dolares al cambio poco menos de 250 euros es una suma totalmente asumible, mas considerando, que es lo que puede llegar a valer un Primario E1, para una PYME durante solo 1 mes de uso (y descontando el trafico).

Y lo mas interesante, se que proveedores SIP como EasyVOIP soportan este codec.

Como ya comente en entradas anteriores, nos encontramos un gran problema que lidiar: el trafico entrante. Necesitamos proveedores que nos permitan tener DID y trafico entrante sin pedir “nada a cambio” (o que curses llamadas obligatoriamente a traves de ellos). Esta tarea aun no la tengo resuelta, puesto que sobre todo en el ambito casero lo que es a quien va principalmente orientados estos proveedores SIP, lo primordial es llamar barato, pero todos “tenemos” una linea movil a los que ser llamados, o una linea fija de Telefonica…

Netelip sigue ofreciendo servicios de llamadas de bastante bajo nivel. Telsome, tambien tiene unas tarifas aceptables, pero la calidad es intermedia. Llama la atencion que hasta EasyVOIP operador extranjero ofrece mejor calidad que estas dos operadores IP Españolas. Asi que VozTelecom sigue siendo la mejor opcion todavia aun a costa de ser un poco caros.

VozTele ofrecia dos canales entrante por 9 euros al mes, y luego cada DID por 4 euros aparte. Esto es una configuracion ejemplo: 4 DID + 2 canales entrantes = 25 euros al mes. Por ejemplo un proveedor mundial de DID, DIDWW ofrece un canal entrante por cada DID contratado, peor servicio, por 5 euros de SETUP y 5 euros al mes. 5 x 4 = 20 euros. En este caso nos ahorrariamos 5 euros pero con inferior servicio.

Evidentemente, es totalmente “injusto” que cursemos llamadas por un operador externo del que las recibimos ya que no ofrecemos la oportunidad de “ganar” al segundo. Por eso todavia estas soluciones mixtas para mi criterio son una asignatura pendiente.

Vuelvo a dejar abierto este tema por si alguien tiene ideas mejores, o propuestas para poder entrar a ser planteadas. Desde luego aun teniendo estas dos soluciones separadas siguen siendo de resultado mucho mas baratas que “quedarse” en la PSTN o en los operadores moviles. De hecho podrian conseguirse telefonos moviles para llamadas entrantes a coste 0 (por ejemplo con OMV) e introducirlos en nuestra PBX a traves de un enlace movil o un modem 3G que permita funciones de Voz (como hicieron en las “practicas” los de chan_sebi).

Proxy Movil

Y justamente de esta idea, se me ocurre diseñar un “Proxy Movil” aprovechando las tarifas corporativas (llamadas a numeros internos de la empresa ilimitadas, a coste 0, con “tarifas planas para este proposito, de solo 3 euros”. Dado que realmente consumir 1000 minutos que es lo que ofrecen la mayoria de las tarifas planas es bastante complejo, ¿Que ocurriria si utilizaramos varias de estas lineas de 1000 minutos unidas, para tener una suma pongamos de 5000 minutos, a repartir entre 25 lineas corporativas?

Asi a desglose economico:

30 (+9 tracks entrantes) x 3 euros = 117 euros
9000 minutos x 0,03 centimos (EasyVOIP) = 270 euros
Total = 387 euros al mes

Son 300 minutos por linea. La tarifa plana mas barata, no baja de 20 euros, Leon 24 , 300 minutos por 24 euros al mes = 30 x 24 = 720 euros al mes.

Ahorro de mas de 300 euros al mes por aplicar esta filosofia. Y las posibilidades que ofrece son muy amplias (por ejemplo, coste nulo para llamadas salientes, por ejemplo, alguien nos llama a nuestra PBX a la operadora, y la operadora quiere transferir a uno de esos 30 telefonos de la empresa, al cursarse por uno de los 9 tracks, saldria gratuita la llamada, y podriamos aplicar FailOver). El unico problema: el contrario, en la llamada entrante, si el track esta ocupado no se me ocurre aplicar un metodo de failover al siguiente track puesto que la llamada se cursa contra la operadora, a no ser que se aplique un sistema de desvio de llamada “si comunica” rotativo entre todos las lineas del track. Curioso experimento

Advanced Asterisk. Days 4 y 5

Ya entrando en la recta final, continuamos con el tema de ayer de conexiones de tarjeteria y PSTN.

Primero van los conceptos teoricos sobre los tipos de sistemas digitales de telefonia Americanos (T1), Europeos (E1), las señalizaciones, los canales, servicios implementados como RDSI (ISDN), codificacion de las señales… realmente son temas que para un caso en concreto de uso hay que tenerlos claros.

Un ejemplo practico seria la interconexion duplex entre una centralita Asterisk y una Alcatel con tarjeteria en ambos lados. Para la comunicación de mensajes a nivel de servicios digitales, se implementa un protocolo de señalización llamado Q.931, pero mas concretamente de un protocolo variante especifico para esta funcionalidad de interconexión de centralitas, llamado Q.SIG.

Ahora vamos a la parte practica de configuracion, hay que considerar que existen dos tipos de configuraciones, la especifica para Estados Unidos y otra para Europa, en este caso voy a intentar de ir planteando las dos, porque cara a Digium la que se utiliza es la EEUU, pero para nuestros casos practicos seguramente sea la Europea.

Configuracion del /etc/dahdi/system.conf

Primero tenemos que configurar cada uno de los puertos

span = <numero_del_puerto>,<fuente_de_sincronizacion>,<line_built_out>,

Ejemplo americano:

span = 1,1,0,esf,b8zs

Ejemplo europeo:

span = 1,1,0,ccs,hdb3,crc4
– El 1 primero, es el numero del canal

– El 1 es para ser receptor de la fuente, y el 0 para ser el emisor
– El siguiente 0, es para no amplificar la señal si los cables son normales, o 1 si son demasiado largos (el cable que nos llega del operador esta en una ubicación muy apartada de donde esta nuestro equipo)
– ESF/CCS, las señalizaciones, americana y europea respectivamente
– B8ZS, y HDB3 son las codificaciones
– Finalmente CRC4, el sistema de control de errores

Luego se configuran, los bchan (canales de datos) y el dchan (canal de señalizacion)

bchan = 1-23
dchan = 24

– En modo americano

bchan = 1-15,17-31

dchan = 16

– En modo europeo

Y luego el loadzone = es/us y defaultzone=es/us es especialmente importante cuando se tratan de tarjetas digitales.

En el fichero /etc/dahdi/modules, hay que levantar el modulo especifico de la tarjeta de T1/E1 llamado wcte12x (primario con 1 puerto T1/E1 o wct4xxp (2 o 4 puertos T1/E1), y si hablamos de puertos BRI seria el modulo wcb4xxp

Finalmente se configura el chan_dahdi.conf muy parecido a las tarjetas analogicas Podemos empezar a amplicar elsistema de “contextos” para este fichero de configuracion.

[channels]

[Primarios]
callerid=asreceived
contexto=llamadas_entrantes
signaling= //Aqui va la configuracion especifica de los primarios, hay opciones como pri_cpe (si recibimos de un operador) o pri_net (si somos los emisores de la señal)
switchtype = //Otro especifico, teoricamente existen multiples tipos de primarios, la red National, la red de AT&T en estados unidos, o la unificada de Europa EuroISDN, los valores posibles, “national”, “euroisdn”, etc. Y en el caso que estemos interconectando dos centralitas, por ejemplo a la Alcatel que hablabamos antes, pues aquí se pone “qsig”
dahdichan=1-23 //los canales de datos que antes configuramos en el system.conf, caso Americano
dahdichan=1-15,17-31 //los canales caso Europeo
group = 1 //esto es practico para no tener que estar definiendo un canal en el extensions.conf para cada canal, se utiliza un “generico” que se aplica al “grupo de canales”, y se define como gX (siendo X el numero del grupo). Para este ejemplo una opcion seria: DAHDI/g1

Ademas un tema importante de los grupos es que se pueden configurar los mecanismos de selección de canal dentro del grupo. Se pueden aplicar distintas tecnicas de selección, como la secuencial empezando por el canal primero, por el final, metodo round-robin, etc. Esto se configura, al configurar el tipo de grupo en el extensions.conf. Antes puse DAHDI/g1, pero podria ser G1, r1 y R1 (la r es el metodo Round Robin)

Una gran diferencia con respecto a las lineas analogicas, es que las llamadas no entran a la extension start del dialplan, sino entran al telefono (DID) al que es llamado por tanto en el dialplan la extension “entrante” se define con el numero del DID

Ejemplos:

exten => 919191919,1,Dial(SIP/mitelefono)

exten => 929292929,1,Dial(SIP/tutelefono)

Pero esto ya lo vimos cuando trabajabamos con el Gateway de puertos BRI, Epygi, que tenia un mecanismo muy similar aunque se configurara externamente.

– Fax en Asterisk

A raiz de la version 1.8 mejoro bastante el soporte “nativo” para FAX con respecto a las versiones anteriores, tanto a nivel Passthrough por el protocolo T.38, como utilizando la maquina Asterisk como gestora de FAX. Pero realmente para esto segundo, el soporte de FAX por Asterisk es limitado o de pago si queremos utilizarlo en produccion. Aquí hay una explicacion detallada del tema

En nuestro caso ya explicamos como tener un sistema completo y libre utilizando Hylafax con el IAXModem bastante efectivo. A raiz del mensaje de Enesoluciones (ahora Fundacion Guadalux) pense que el sistema nuevo de Asterisk sustituiria el Hylafax brutalmente, pero parece que no va a ser asi de momento,por el tema este de las licencias de pago que hablaba (aunque al parecer Digium ofrece una unica licencia gratuita para solo 1 llamada concurrente, que seguramente en muchas instalaciones para PYMES sea suficiente).

– Asterisk Database (AstDB)

Asterisk implementa un sistema de bases de datos muy sencillo para almacenar informacion relativamente poco compleja. Es mas comodo que tener que andar trabajando con conectores ODBC y demas historias siempre y cuando busquemos aplicaciones concretas donde haga falta almacenar valores y acceder a ellos facilmente, pero especificamente del propio sistema de configuracion de Asterisk (ejemplo las Listas Negras de llamantes, familia blacklist)

Las funciones de lectura y escritura son extremadamente sencillas (totalmente integradas en el sistema Asterisk). Basicamente son usos de la aplicación Set y manejo de variables pero con la funcion DB() cubriendo esta nueva “variable”.

La variable esta compuesta por familia/clave/valor por ejemplo users/mitelefono/SIP/mitelefono

En este caso la clave mitelefono dentro de la familia, users, tendra el valor SIP/mitelefono (que por ejemplo es el canal SIP que utiliza nuestro telefono SIP).

Ejemplos:

Asignar a un registro de la base de datos: Set(DB(users/mitelefono)=’SIP/mitelefono’)

Consultar el registro: ${DB(users/mitelefono)}

Con todo esto parece que podemos “recortar” en variables globales dentro de los ficheros de configuracion basicamente. A lo mejor seria interesante montar algo serio que utilice esto a mayor escala como lo que comentaba esto de los Blacklist, aunque realmente tampoco tendra mucho misterio, algunas lineas. Me lo apunto como futura practica.

– Ultimo dia. 5: Seguridad en Asterisk

Para finalizar, y dar cierre al Asteirsk Advanced, el ultimo dia se trataron multiples temas relacionados con la seguridad en Asterisk

Sobre este tema tengo que hacer un comentario: justamente, ahora que estoy bastante desconectado del mundo “tecnologico” a nivel profesional, no tengo tanto acceso como antes a tarjeterias, equipos de trabajo y demas historias que me hacian el mundo facil en el progreso Asterisk.  Pero concretamente acerca de la seguridad en Asterisk, supuestamente el sistema mas “peligroso” en el que montar un Asterisk es abierto a Internet. Por ello en las proximas entradas, voy a estar focalizando en esta idea, ya que mi forma de “progresar” de ahora en adelante va a ser montando una maquina Asterisk en Casa y ofreciendo servicios concretos a individuales, a mi empresa (de forma altruista) y a otras empresa que quiza pudieran interesarme por el potencial (¿patrocinio o algo asi?) que pudieran ofrecerme (especialmente por los recursos economicos que pudieran aportar al tema).

El tema de seguridad en Asterisk tomaba dos perspectivas: el tipo de securizacion que habia que tomar en consideracion por niveles de “inseguridad” (desde el montaje de una maquina aislada de la red, hasta el montaje de una maquina publicado a internet), y por otro lado, todos la securizacion de todos los componentes del sistema (desde los accesos a la propia maquina hardware, pasando por el sistema operativo, hasta el mismo dialplan).

– Conclusiones y Consideraciones Finales sobre el Curso

Como comentaba el segundo dia debo determinar y concluir que el curso ha satisfecho mis expectativas, ya que realmente el interes de hacer un curso de este calibre, no ha suele ser tanto, la cantidad de informacion recibida, sino la posibilidad de “expandir” conceptos acerca de la especialidad en concreto que viene a tratarse, a traves de los profesores y los compañeros. Hay que considerar que el precio realmente no cubre solo las horas de enseñanza, sino tambien las horas de “relacion”. Es cierto que para “conectar” con otros individuales especialistas o no especialistas en un sector, no es realmente necesario hacer un curso, y que para el aprendizaje por ese precio se podrian llegar a conseguir incluso, horas de enseñanza particulares por internet pactando con algun profesional un precio por hora (algun dCAP) sin excesiva dificultad. Pero mas alla de estas dos posibilidades, y la primera en particular, tambien hay que considerar que el perfil de alumno que va a un curso de este tipo, no suele ser de “Lurker” ya que al costar (bastante) dinero, suelen ser o aportes profesionales (empresas que quieren formar a sus trabajadores especialistas), o aportes personales (autonomos o como yo esta vez, especialmente interesados en el sector).

Proxima parada: Examen dCAP. No se donde sera, pero desde hoy ya toca empezar a practicar y estudiar como el que mas. Segun parece, por los alumnos que se presentaron, el nivel del examen practico ha aumentado a practicamente al doble de dificultad que las ultimas convocatorias, y sobre el teorico no pude enterarme, ya que tuvimos que irnos a comer porque el examen se alargaba demasiado.

Asterisk Advanced. Day 1

Primer dia del Asterisk Advanced. Se han visto por lo general temas basicos introductorios del sistema. Todo aquel que hubiera realizado un Fast Start, puede sobrellevar este dia sin despeinarse. Muchos conceptos teoricos sobre Asterisk, curiosidades, producto Digium y alguna terminologia basica en lo referente al protocolo SIP. Nada que merezca por mi parte la pena destacar.

Configurar una extension, un pequeño IVR (como ya hemos visto en anteriores entradas de este blog), y una comunicacion con un proveedor SIP. Me hubiera gustando poder volver a escribir un buen articulo en representacion al dia de hoy, pero no hay suficiente material interesante, que no haya sido visto hasta la fecha.

Solo una cosa tengo que reconocer. Estos meses de inactividad me han hecho olvidar gran parte del sistema de configuracion, y porque no decirlo, esta clase me ha servido para poner un poco al dia mi actividad mental asteriskera, para volver un poco a la carga.

Seguiremos informando!

Conquistando el Dialplan I. Aplicaciones Asterisk: Voicemail

Como ya sabemos, el Dialplan, plan de marcación, es el esqueleto en esencia de Asterisk. A partir de este se abre el sin fin de posibilidades que nos ofrece este sistema.

Solo el que conoce lo que ofrece el Dialplan al 100%, es aquel que realmente conoce Asterisk de verdad. Por ello, las series de documentación sobre Dialplan serán mensajes mas cortitos pero no por ello menos interesantes  y que ayudaran a organizar mejor la información.

Realmente ya vimos parte del potencial del Dialplan, con la creación de una operadora automática de coste cero, ahora vamos a ver las funciones de Buzón de Voz para nuestras extensiones. Aquí básicamente hay dos actores principales. La Aplicación Voicemail, y el fichero voicemail.conf

El fichero voicemail.conf puede llegar a ser todo lo complejo que deseemos en función de nuestras necesidades, pero voy a comentar un caso práctico en el que podemos ver diversa funcionalidad que podemos llegar alcanzar. Como la mayoría de los ficheros de Asterisk, se divide en contextos, como casi siempre, general, suele ser el genérico que afecta a todos los contextos por igual.

[general]
format=wav
//Formato de las grabaciones para el buzon de voz. Se admiten otros formatos como gsm.
serveremail=direccion@queenvia.com
//Direccion del remitente de los envios
attach=yes
// Para enviar el fichero adjunto en los emails con el audio
delete=yes
// Para permitir la opción de borrado del mensaje de voz local en el servidor una vez enviado por correo eletronico
maxmsg=100
// Maximo numero de mensajes permitidos en la bandeja local por buzon
maxsecs=180
// Maximos segundos por mensaje
minsecs=2
// Minimos segundos por mensaje para desechar los mensajes vacios o casi vacios
skipms=3000
// Opciones del mensaje de audio, para indexarlo cara a desplazamientos X ms adelante o detrás cuando sea reproducido en el pc del destinatario
maxsilence=10

// Silencio máximo permitido, esto es importante cara a poder desconectar la llamada en caso de silencio antes de cumplir el máximo posible caso 180 segundos (en nuestro ejemplo)
silencethreshold=128
// Este es el umbral de audio para el que consideramos que es un silencio, de aquí podemos ir mas abajo o mas arriba en función de nuestra necesidad, no hay un valor “ideal”
maxlogins=3
// Intentos de acceso a voicemail, en caso de sobrepasarlos, Asterisk desconectara al usuario de su cuenta SIP/IAX
emailsubject=Nuevo Mensaje de ${VM_CALLERID}
emailbody=Buenos días ${VM_NAME},\n\nHemos recibido un mensaje en su buzon de voz…
// Esto seria el asunto y el cuerpo del mensaje email. Aquí se pueden aprovechar variables para poder formatear el correo y mostrar datos quizá interesantes para el destinatario. Algunas de estas variables de ejemplo:
${VM_CALLERID}: El numero identificador del llamante (el número de teléfono)
${VM_NAME}: El nombre del dueño del buzon (lo definiremos más adelante)
${VM_DUR}: Duracion del mensaje
${VM_DATE}: Fecha y hora de recogida del mensaje
Mas variables pueden encontrarse aquí: en su correspondiente sección (tampoco son muchas más)
emaildateformat=%A, %B %d, %Y at %r
// Formato de la fecha para el email. Para la variable VM_DATE. Consultar el manual de date para mas información (# man date)

Con esto tenemos más que suficiente para componer mensajes para el buzon de voz y enviarlos por email. Ahora vienen los contextos. Como siempre, si es [default] es el genérico, y luego los contextos específicos. En principio vamos a poner uno genérico y uno especifico.
[default]
1234 => 5678,Buzon de Ejemplo,ejemplo@buzones.com
– En primer lugar, el número del buzón, luego lo utilizaremos en el Dialplan para la aplicación Voicemail así referirnos a este buzón
– En segundo lugar, la contraseña para acceder al buzón. Tendremos que crear una “extensión” en el Dialplan para que el usuario pueda acceder a su buzón de forma interna. Esto solo es útil si no marcamos la opción de borrado de mensajes del buzón al ser enviados por email
– En tercer lugar, nombre del buzón que luego utilizaremos en variables como VM_NAME
– En cuarto lugar, Email del destinatario de los mensajes de este buzón

Este es un ejemplo muy sencillo, pero a esto podríamos aplicarle un poco mas de complejidad al asunto

[extensiones]
1000 => 9878,Mr. Lenny, lenny@debian.net,,attach=yes|delete=1
– En quinto lugar, iria la dirección del Pager… muy poco utilizado a dia de hoy
– En último lugar, irían opciones especiales. En este caso, decimos que adjunto el mensaje, y lo borre a continuación. Si hemos activado las opciones en el contexto general, ira bien esto.

Si queremos hacer “broadcasting” de mensajes de buzon a varios emails, hay varios métodos pero el que a mi mejor me ha funcionado es hacerlo en combinación a aliases del servidor de correo (en nuestro caso al usar Ubuntu, por defecto, Postfix)

1001 => 8765, Dpto. de Botijos, botijos@nuestroservidor,,attach=yes|delete=1

Nos vamos a /etc/aliases y añadimos
botijos: sr.sanchez@botijoland.com,sr.perez@botijoland.com,sr.alvarez@botijoland.com

Y refrescamos aliases comando: # newaliases

Por ultimo no olvidemos recargar nuestro voicemail.conf #asterisk –rx ‘voicemail reload’

Ahora toca editar nuestro Dialplan para poder utilizar estos buzones recién configurados. Vamos al extensions.conf:

Si queremos por ejemplo hacer que los usuarios puedan dejar mensajes a nuestro contestador tenemos que utilizar la aplicación Voicemail
Ejemplo:

exten => 1000,1,NoOp()
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n,Voicemail(1000@extensiones,u)
// En este caso, ponemos el número del buzón que pusimos antes @ el contexto al que pertenecía, adicionalmente ponemos una opción, para que antes de dar el pitido de “empezar a grabar” diga el mensaje de “en estos momentos no nos encontramos, deje su mensaje después de oír la señal”. Aquí tenemos varias, opciones, en vez de utilizar los mensajes por defecto que se pueden encontrar en la carpeta de sonidos /var/lib/asterisk/sounds/ todos los que empiezan por vm- tienen algo que ver con el buzón de voz y estas opciones. Las opciones posibles son:
sin opciones: se escuchan las instrucciones para dejar el mensaje
s: no se escucha nada (útil si queremos poner mensajes personalizados para cada usuario)
su: mensaje de no disponible
u: mensaje de no disponible + instrucciones
sb: mensaje de ocupado
b: mensaje de ocupado + instrucciones

Con esto también podemos jugar con las aplicaciones Playback y Record, para con la opción “s” crear un buzón acorde a las necesidades de un usuario en concreto

Por otro lado vendría la aplicación destinada a escuchar los mensajes guardados si no pusimos la opción de borrado automático: VoicemailMain. Tiene poca historia:
exten => 10001,1,VoicemailMain(1000@extensiones)
El tema es que a partir de ahí vendría un menú relativamente complejo, editable, y demás. Yo personalmente no lo utilizo ya que la función de envío a correo aparte de que me descarga el disco duro, hoy en día a la mayoría del personal le resulta formidable. Aun así, para aquellos que deseen profundizar, les dejo un enlace al manual por si acaso quieren probarlo. Cualquier consulta acerca de esto, no duden en comentármela!

En principio, con todo esto, ya se podrían componer sistemas de Buzón de voz bastante interesantes. Como ven no es demasiado complejo y existen muchas alternativas y opciones. Yo personalmente opino que las opciones de envío a correo, todavía están muy poco elaboradas, pese a que se ha profundizado en ellas. Yo personalmente no he encontrado opciones por ejemplo, de envío CC o CCO (BCC) para envíos broadcasting (lo cual me resultaría muy interesante). Supongo que sería una cuestión de apoyar programando, al proyecto Asterisk. Quien sabe, a lo mejor más adelante nos animamos a ello.

Conectandonos al mundo Real: El planeta Gateway II

Como comentaba en el ultimo mensaje, hoy tenia la intención de explicar en detalle como se realizaría la configuración en Asterisk, para admitir el Gateway Epygi configurado, y por otro lado, poder presentar la sencillez configuración y manejo los FXS que proporciona el magnifico Gateway Linksys SPA8000.

Por un lado hablando del Epygi, tendríamos que conectarlo via SIP como ya sabemos.

En el fichero sip.conf que ya conocemos de anteriores configuraciones vamos a crear un apartado para el mismo:

[epygi]
host=dirección ip de nuestro gateway
defaultuser=usuario que pusimos en la configuración del sip trunk
secret= la contraseña correspondiente
qualify=yes (para tener monitorizado el elemento)
type=friend (para recibir y emitir llamadas a través del mismo)
context=desde-rdsi (este es el contexto en el dialplan donde las llamadas de las RDSI a través del gateway)

Con esto es suficiente, seguramente podríamos especificar alguna opción de seguridad adicional, pero sobre seguridad en Asterisk ya hablaremos otro dia.

Ahora toca hablar un poco del dialplan, el fichero extensions.conf. Realmente no he dedicado un mensaje especifico a hablar sobre el Dialplan, porque como es un tema tan extenso, prefiero ir introduciéndolo según la necesidad vaya surgiendo, en un mensaje próximo, escribiré un pequeño manual para crear un sencillísimo IVR (Contestador Automatico) para manejar las llamadas que nos entren a través de este Gateway, o cualquier otro operador ip que podamos utilizar.

Como dijimos antes, vamos a utilizar el contexto [desde-rdsi] para todas las llamadas que nos entren por nuestro Gateway.

[desde-rdsi]
exten => 987654321,1,NoOp()
exten => 987654321,n,Answer
exten => 987654321,n,…

Muy sencillo Dialplan. Simplemente como vimos en anteriores mensajes, siguiendo la estructura general de todo Dialplan, pasamos la extensión en primer lugar. La extensión que recibimos es justamente la que nos pasa el Gateway, y como configuramos en la sección ISDN del mismo, enrutaba a la centralita poniendo el teléfono del DID como extensión llamante. Esto quiere decir, que si disponemos de varios DID y los configuramos en la sección que vimos, pues simplemente tendríamos poner poner cada DID como extensión y configurar en el dialplan como querríamos manejar cada caso (mandándolo a una extensión con el comando Dial, o a un grupo de extensiones, o activando el IVR en secuencia por comandos, o toda la potencia en general que nos permite el Plan de Marcacion de Asterisk)

Si todo esto lo hubiera tenido por escrito en el momento que empece a configurar el Gateway seguramente podría haberlo montado en cuestión de 15 minutos sin problemas, porque como puede verse es realmente sencillo de manejar.

Si esto resulto facl, vamos a ver un poco acerca del Linksys, que es todavía aun mas sencillo, aunque viene cargado de opciones, que podríamos editar al gusto, en este mensaje solo vamos a centrarnos en los primeros pasos, echarlo a funcionar, comprobar que todo esta OK, y configurar Asterisk para que reconozca bien cada puerto a voluntad.

En primer lugar, comentar que el aparato tiene 4 modos de uso

–          Usuario Basico

–          Usuario Avanzado

–          Administrador Basico

–          Administrador Avanzado

Todo esto se selecciona desde la interfaz de inicio, arriba a la derecha, Admin, Advanced necesitamos estar para configurar el sistema con lo básico.

En el apartado Router -> WAN Setup configuramos lo básico acerca del sistema de red del equipo.

Direccion IP (Static IP), Mascara de red, y Puerta de Enlace (esto no es muy recomendable usarlo, si no vamos a necesitarlo para nada en particular, ya que podría llegar a exponer nuesto equipo a ataques foráneos), aunque sin esto no podremos utilizar opciones para tener actualizada la hora de los teléfonos como los “NTP Server”, aunque podemos configurarlo a mano, no es una utilidad en principio que nos vaya a resolver la vida en Asterisk.

En el apartado Voice es donde realizaremos toda la conexión con Asterisk.

Uno de los problemas que mas afecto a mi sistema, era el hecho de no poder recibir los DTMF correctamente. Esto se solucionó inmediatamente cambiando un parámetro dentro de Regional:

Con respecto a la interconexión SIP con Asterisk se realiza desde cada una de las Lineas del sistema (L1,L2,L3, etc)

Entrando por ejemplo en la linea 1, L1, en el apartado siguiente:

Tan simple como configurar eso 4 parametros, el servidor Asterisk, el usuario y la contraseña que tendremos en nuestro servidor Asterisk.

Ahora ya solo quedaria registrar esta linea FXS, como una extension (ext10 del ejemplo), en el fichero sip.conf

[ext10](extension,codecs)
callerid=”Extension Analogica”
defaultuser=ext10
secret=contraseñasupersegura
mailbox=10@default

Tan sencillo como con configurar cualquier extension SIP que podamos usar en un terminar IP puro, o en un softphone como vimos hace tiempo

Tras este resumen, tenemos claro, que si manejamos bien todos los mensajes que fuimos recorriendo hasta este, configurar este Gateway no supone ningun inconveniente. De todas formas como siempre podrian surgir inconveniencias, tanto para este como para el Epygi, yo estoy abierto para resolver todos los problemas que pudieran surgiros al respecto, y asi si cabe, engrosar con mas cantidad y calidad, el nivel de informacion que circule en este blog.

Nada mas por hoy. Con tanto componente en funcionamiento, ya solo queda empezar a subir el listo un poco, el proximo dia hablaremos sobre un IVR de ejemplo y tambien hare una gran introduccion al mundo de los CDR (Call detail record, o registro del detalle de llamadas) para poder analizar llamadas guardadas en una base de datos del sistema, e introducire el primer software adjunto al sistema que he conseguido poner en funcionamiento y reporta unos excelentes resultados.

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.

Introduciendo un Proveedor SIP: Parte 1

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 🙂

El dia del Protocolo SIP: Parte 1

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.