Esta última vez, al migrar una BD que estaba en 5.0 a la versión 5.1, las tablas mysql.user y mysql.db no eran compatibles, por lo que había que conseguir los grant’s. La solución la verdad es que no es bastante compleja, pero encontré un script que me ahorró media horilla de haber estado jugando con el CLI de mysql, y nuestro amigo sed

La solución es bastante sencilla y pasa por concatenar la salida de un show grants para cada uno de los usuarios de la tabla mysql.user. Es una función de BASH a la que sólo hay que pasar como parámetros los mismos que le pasaríamos al CLI de Mysql:

mygrants()

{

	mysql -B -N $@ -e “SELECT DISTINCT CONCAT(

		‘SHOW GRANTS FOR ”’, user, ”’@”’, host, ”’;’

		) AS query FROM mysql.user” |

	mysql $@ |

	sed ’s/(GRANT .*)/1;/;s/^(Grants for .*)/## 1 ##/;/##/{x;p;x;}’

}

Simplemente para sacar los grants del host local usando el usuario administrador de la BD y como password pwd, llamaríamos a la función desde cualquier script BASH tal que así:

mygrants --host=localhost --user=root --password=pwd

Es una tontadica, pero hace ilusión ver el nombre de uno en el app_originate.c

Bueno, y dejándonos de tanta autofelación, tengo 7 posts más en los borradores pendientes de publicar, así que voy a intentar ir sacando un rato cada semana o dos semanas para ir dando un poco de vida a esto.

http://www.asteriskguru.org/tools/audio_conversion.php

Sin embargo, cuando tenemos que convertir un número elevado de ficheros, puede convertirse en una tarea tediosa. Es por ello, que usando curl he creado un sencillo script que convierte desde consola los ficheros haciendo una llamada a la web tal y como la haría un navegador. El código del script es el siguiente:

#!/bin/bash

filename=`echo $1 | cut -d’.’ -f1`
codec=`echo $1 | cut -d’.’ -f2`

curl -o $filename.$2 -Finput_codec=$codec -Foutput_codec=$2 -F_is_submitted=1

-FMAX_FILE_SIZE=104857600 -Ffile=@$1

http://www.asteriskguru.org/tools /audio_conversion.php

Es algo muy sencillito (no se pueden usar nombres de fichero con más de un ‘.’), pero funciona bien. La forma de usarlo es pasando como primer parámetro el nombre del fichero origen (la extensión debe coincidir con el códec en el que está), y como segundo parámetro el códec de destino.

Veremos en qué queda todo esto, pero me imagino que en poco tiempo, será complicado interoperar con clientes que utilicen el protocolo que implemente Cisco en sus soluciones. algo que utiliza la empresa americana para obligar a todo el mundo a usar sus sistemas para poder trabajar con sitios donde ya tienen Cisco.

Esperemos que me equivoque, y dentro de poco vea alguna actualización del firmware de los magníficos teléfonos IP Linksys que permita usar Jabber desde ellos para aprovecharnos de res_jabber en nuestros Asterisk, o para poder controlar también la presencia (o el estado) mediante dicho protocolo.

Como hay por Internet bastante ejemplos de como acceder al AMI desde scripts BASH o desde lenguajes interpretados tipo PHP o python, he decidido preparar un pequeño ejemplo para acceder desde Java. Para ello es necesario utilizar la librería asterisk-java (que también se puede usar para hacer AGI’s), de cuya documentación he modificado ligeramente uno de sus ejemplos para adaptarlo a un uso mucho más útil en la vida real.

En primer lugar tendremos que habilitar el AMI, para lo que es necesario editar el fichero manager.conf en nustro /etc/asterisk poniendo enabled a yes en la zona general, y añadiendo un usuario tal que así:

[general]
enabled=yes

[admin]
write=system,call,log,verbose,command,agent,user
read=system,call,log,verbose,command,agent,user
secret=admin

Con el usuario creado recargamos la configuración de nuestro Asterisk, y ya podemos empezar a acceder desde nuestro programa en Java. Para conseguir lo que queremos, hemos hecho que sólo se tengan en cuenta los eventos de tipo Dial, y una vez obtenidos sacamos por pantalla el CallerId y el canal de destino. El código resultante sería el siguiente:

import java.io.IOException;

import org.asteriskjava.manager.AuthenticationFailedException;
import org.asteriskjava.manager.ManagerConnection;
import org.asteriskjava.manager.ManagerConnectionFactory;
import org.asteriskjava.manager.ManagerEventListener;
import org.asteriskjava.manager.TimeoutException;
import org.asteriskjava.manager.action.StatusAction;
import org.asteriskjava.manager.event.ManagerEvent;
import org.asteriskjava.manager.event.DialEvent;

public class DialEvents implements ManagerEventListener
{
private ManagerConnection managerConnection;

public DialEvents() throws IOException
{
ManagerConnectionFactory factory = new ManagerConnectionFactory(
“1.2.3.4″, “admin”, “admin”);

this.managerConnection = factory.createManagerConnection();
}

public void run() throws IOException, AuthenticationFailedException,
TimeoutException, InterruptedException
{
// register for events
managerConnection.addEventListener(this);

// connect to Asterisk and log in
managerConnection.login();

// request channel state
managerConnection.sendAction(new StatusAction());

// wait 10 seconds for events to come in
Thread.sleep(60000);

// and finally log off and disconnect
managerConnection.logoff();
}

public void onManagerEvent(ManagerEvent event)
{
// just print received events
if(event instanceof DialEvent) {
DialEvent de = (DialEvent) event;
System.out.println(de.getCallerId() + ” llamando a ” + de.getDestination());
}
}

public static void main(String[] args) throws Exception
{
DialEvents helloEvents;

dialEvents = new DialEvents();
dialEvents.run();

}
}

Sólo nos queda compilar, ejecutar el programa y empezar a monitorizar las llamadas que se realizan en nuestra centralita:

$ java DialEvents

19-sep-2008 17:50:01 org.asteriskjava.manager.internal.ManagerConnectionImpl connect
INFO: Connecting to 192.168.2.99:5038
19-sep-2008 17:50:02 org.asteriskjava.manager.internal.ManagerConnectionImpl setProtocolIdentifier
INFO: Connected via Asterisk Call Manager/1.0
19-sep-2008 17:50:02 org.asteriskjava.manager.internal.ManagerConnectionImpl doLogin
INFO: Successfully logged in
19-sep-2008 17:50:02 org.asteriskjava.manager.internal.ManagerConnectionImpl doLogin
INFO: Determined Asterisk version: Asterisk 1.4
119 llamando a SIP/110-082121e8

Una vez que tenemos estos datos dentro de nuestro programa en Java, ya podemos proceder a realizar cualquier cosa que se nos ocurra, desde simplemente mostrarlos como hacemos aquí, hasta llegar a niveles de CTI y comunícarselo a otros programas en Java para que actualicen con la información que se crea relevante conocer sobre el llamante.

Bueno, y de momento eso es todo, tengo varios artículos en el tintero sobre varias cosas, a ver si tengo algo de tiempo para ir escribiéndolos.

Es por ello, que aprovechando la base de datos SQLite que tenemos enlazada con nuestro Asterisk, podemos aprovechar y crear una tabla que simule los Agentes de Asterisk:

CREATE TABLE queue_agent_table(
uniqueid integer not null primary key autoincrement,
membername varchar(40),
queue_name varchar(128),
interface varchar(128),
penalty INT(11),
UNIQUE (queue_name, interface)
);

Suponiendo que tenemos una cola llamada Pruebas, para añadirle un agente que sea un usuario SIP llamado ‘agente’, simplemente añadiríamos lo siguiente:

insert into queue_member_table(queue_name,interface,penalty) values(’Pruebas’,'SIP/agente’,1);

Ahora, para permitir la conexión/desconexión a más de 1 cola, es necesario recorrer varias filas de una consulta la tabla creada, por lo que la manera más cómoda es usar un AGI. Para ello creamos el programa queue-loginout.php (que dejaremos en el directorio /var/lib/asterisk/agi-bin) y que contendrá lo siguiente:

#!/usr/bin/php -q
<?php
require(”/var/www/db.php”);

$dbfile = “/var/lib/asterisk/asteriskdb-sqlite.db”;

$results = execute_query($dbfile, “select queue_name,penalty from queue_agent_table where interface=’SIP/$argv[2]‘”);

$stdout = fopen(’php://stdout’, ‘w’);

for($i = 0; $i < count($results); $i ++) {
$name = $results[$i]['queue_name'];
$pen = $results[$i]['penalty'];

if($argv[1] == “login”) {
fputs($stdout,”EXEC AddQueueMember $name|SIP/$argv[2]|$pen
“);
} else if($argv[1] == “logout”) {
fputs($stdout,”EXEC RemoveQueueMember $name|SIP/$argv[2]
“);
} else if($argv[1] == “pause”) {
fputs($stdout,”EXEC PauseQueueMember $name|SIP/$argv[2]
“);
} else if($argv[1] == “unpause”) {
fputs($stdout,”EXEC UnpauseQueueMember $name|SIP/$argv[2]
“);
}
}
fflush($stdout);
?>

El script de AGI recibe dos argumentos, el primero es la operación que se quiere realizar, y el segundo el nombre del usuario SIP. El fichero que se incluye simplemente tiene unas funciones de ayuda para hacer consultas a la BD.

Ahora simplemente nos quedaría hacer uso de este script de AGI desde nuestro dialplan. Para ello podemos crear por ejemplo la extensión *10 que es la que gestionará todo lo relacionado con las colas de llamadas (en el ejemplo lo único que hacemos es saltar a un contexto, donde se recupera el usuario SIP que hace la llamada, y se espera un número del 1 al 4 que es el que indica la operación a hacer):

exten => *10,1,Goto(queue-loginout,s,1)

[queue-loginout]
exten => s,1,Set(foo=${CUT(CHANNEL,,1)})
exten => s,n,Set(username=${CUT(foo,/,2)})
exten => s,n,Read(opt,,1)
exten => s,n,Goto(${opt},1)

exten => 1,1,AGI(queue-loginout.php,login,${username})
exten => 1,n,Hangup

exten => 2,1,AGI(queue-loginout.php,logout,${username})
exten => 2,n,Hangup

exten => 3,1,AGI(queue-loginout.php,pause,${username})
exten => 3,n,Hangup

exten => 4,1,AGI(queue-loginout.php,unpause,${username})
exten => 4,n,Hangup

Para poder acceder a una BD externa desde Asterisk mediante ODBC, necesitamos tener cargado el módulo res_odbc.so que se configura mediante el fichero /etc/asterisk/res_odbc.conf

Si hemos creado una entrada en /etc/odbc.ini con el nombre asteriskdb-sqlite, podemos usar esto poniendo otra entrada en el fichero res_odbc.conf tal que así:

[asteriskdb]
enabled => yes
dsn => asteriskdb-sqlite

A partir de aquí ya podemos empezar a usar desde Asterisk nuestra BD SQLite.

Como ejemplo, vamos a ver como enlazarla para ser usada desde el CDR y desde Realtime, para ello tenemos un fichero sql con las tablas necesarias preparadas para SQLite aquí.

Una vez creada la estructura de la base de datos, vamos a enlazar en primer lugar el CDR, para ello únicamente tenemos que editar el fichero /etc/asterisk/cdr_odbc.conf y añadir lo siguiente:

[global]
dsn=asteriskdb-sqlite
table=cdr

A partir de esto, los detalles de las llamadas de nuestra centralita se irán almacenando en la tabla cdr de nuestra base de datos SQLite.

Ahora, vamos a hacer que la configuración de usuarios SIP, conferencias, buzones de voz y colas de llamadas, estén en el resto de tablas que hemos creado en nuestra base de datos. Para ello, editaremos el fichero /etc/asterisk/extconfig.conf y lo dejaremos tal que así:

[settings]
sipusers => odbc,asteriskdb,sip_buddies
sippeers => odbc,asteriskdb,sip_buddies
voicemail => odbc,asteriskdb,voicemail_users
meetme => odbc,asteriskdb,meetme
queues => odbc,asteriskdb,queue_table
queue_members => odbc,asteriskdb,queue_member_table

Para probar que esto funciona, podemos añadir un usuario SIP a nuestra tabla:

sqlite> insert into sip_buddies(name,secret) values(’prueba’,'prueba’);

Y comprobamos que existe desde el CLI:

CLI> sip show peer prueba load

* Name : prueba
Realtime peer: No
Secret : <Set>
MD5Secret : <Not set>
Context : default
Subscr.Cont. : internal
Language : es
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Callgroup :
Pickupgroup :
Mailbox :
VM Extension : asterisk
LastMsgsSent : 32767/65535
Call limit : 0
Dynamic : No
Callerid : “” <>
MaxCallBR : 384 kbps
Expire : -1
Insecure : no
Nat : RFC3581
ACL : No
T38 pt UDPTL : No
CanReinvite : Yes
PromiscRedir : No
User=Phone : No
Video Support: No
Trust RPID : No
Send RPID : No
Subscriptions: Yes
Overlap dial : Yes
DTMFmode : rfc2833
LastMsg : 0
ToHost :
Addr->IP : (Unspecified) Port 0
Defaddr->IP : 0.0.0.0 Port 0
Def. Username:
SIP Options : (none)
Codecs : 0×3f1fff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|g726aal2|g722|jpeg|png|h261|h263|h263p|h264)
Codec Order : (none)
Auto-Framing: No
Status : UNKNOWN
Useragent :
Reg. Contact :

Y de momento esto es todo.

Para el que aún no haya oído hablar de él, y si está leyendo este blog será raro, se trata de un portátil ultramóvil (que mal suena la traducción de UMPC :-D) de bajo coste (menos de 300€) y con la posibilidad de comprarlo con Linux. Además, lleva un disco SSD (de estado sólido, como las memorias de las cámaras de fotos) lo que mejora los tiempos de acceso al mismo.

La primera y grata impresión en cuanto lo enciendes, es lo rápido que puedes empezar a trabajar con él. Acostumbrado a tiempos de arranque mucho más elevados, prácticamente parece que esté más en standby que apagado. No me he puesto a cronométrarlo, pero por ahí se comenta que está en torno a 15 segundos. Esto se debe fundamentalmente a su disco SSD.

El sistema operativo que ejecuta la versión de Linux se trata de Xandros y carga un entorno gráfico muy orientado a personas que puede que no se hayan acercado a Linux en su vida. En primer lugar, ese me parece uno de los puntos fuertes, la facilidad y usabilidad para un usuario novel de su interfaz gráfico, todo muy bien ordenado y a golpe de como mucho un par de clicks.

Una vez cargado el entorno, la primera prueba era obligada, conociendo sus especificaciones técnicas (menos de 1GHz de velocidad de procesador y 512MB de RAM), había que probar como se desenvolvía ejecutando OpenOffice. Una nueva sorpresa derivada de su disco SSD, el programa se abre más rápido que lo que lo hace en otros equipos con mucho más procesador y memoria.

Este entorno gráfico es posible cambiarlo por un KDE estándar para los usuarios que lo prefieran. En mi caso preferí no hacer cambios pero no es demasiado complicado de hacer, aunque para ello deberemos hacer uso del terminal (que está accesible mediante la combinación Ctrl+Alt+T).

La interacción con el dispositivo, en líneas generales no es mala, aunque habría detalles mejorables tanto del teclado (¿dónde se ha visto que la tecla grande del Shift sea la de la izquierda y no la de la derecha?) como del touchpad, que no es del todo preciso en todas las ocasiones.

Otra de las sorpresas fue la webcam integrada, sobre la que no tenía muchas expectativas, y que sin embargo daba bastante buena calidad de imagen (mejor que webcams USB de precio medio), y que además viene perfectamente configurada para empezar a usarla sin saber nada de kernels y módulos de Linux ni cosas así. Aunque no sea un usuario de este tipo de dispositivos, sí que creo que es un punto a favor si busca el mercado de gente que usa el ordenador básicamente para navegar, leer el correo y chatear.

Desde el punto de vista de la conectividad, algo básico en un dispositivo así, no conseguí conectarlo a redes inalámbricas protegidas con WPA2 ni WPA. Con WEP no pude probar. Esto es algo que se debería mejorar de manera urgente.

Respecto a la autonomía de la batería, Asus dice que son unas 3 horas, aunque como en todos estos dispositivos, la cosa depende de si empezamos a usar la tarjeta wifi, o conectamos un monitor externo al puerto VGA.

Y empecemos con las cosas que creo que harían de este dispositivo una solución aún mucho mejor (de hecho alguna de ellas se han incorporado en el hermano mayor, que a saber cuando llegar a España). En primer lugar se echa en falta conectividad Bluetooth, básica por ejemplo para conectar con un móvil 3G y tener acceso a Internet allí donde no haya redes Wifi disponibles.

Otra cosa que debería mejorar es la resolución máxima de la tarjeta gráfica, ya que aunque para la pantalla integrada es suficiente, en cuanto conectas la salida a un monitor externo, el 1024×768 que da se queda corto en la mayoría de monitores que hay hoy en el mercado, lo que es un verdadero problema al tener que usarlos a una resolución no nativa, lo que provoca la consiguiente pérdida de calidad de imagen.

El disco incluido de 4GB se queda un pelín corto, tal vez con uno de 8GB sería más que suficiente para la mayoría de usos que se pueden hacer de este portátil. Sí, tenemos el lector de tarjetas, pero veo más eso como una forma de poder pasar nuestras fotos desde cámaras digitales que como un almacenamiento real.

Pocas pegas más se le pueden poner a este dispositivo, y más teniendo en cuenta el precio por el que podemos tenerlo. Desde mi punto de vista es perfecto como dispositivo para acceder a Internet desde cualquier sitio y sobretodo para situaciones donde la movilidad es muy importante, como por ejemplo poderte mover por un CPD con cierta soltura. En definitica, que se trata de un soplo de aire fresco para los que pensábamos que el mercado de portátiles se estaba desmadrando con la tendencia hacia lo que yo llamo “portables” o “ordenadores de sobremesa plegables”.

Como base para futuros artículos donde hablaré de como aprovechar lo aprendido aquí, y como quiero empezar muy poco a poco para no hacer artículos especialmente farragosos, a continuación explicaré como conectar mediante unixODBC (el middleware equivalente en Linux al famoso ODBC de Windows) a una BD SQLite.

SQLite es un sistema gestor de BD que requiere muy poco espacio en disco, y que es muy simple de utilizar, ya que las BD son directamente un fichero. Por su simplicidad, son perfectas para su uso en sistemas empotrados o appliances.

Para instalar ambos paquetes, en Ubuntu lo podemos hacer directamente con nuestro querido apt-get (en otras distribuciones podrá variar el nombre del paquete, pero seguro que estarán disponibles ambos también):

# apt-get install sqlite3 libsqliteodbc unixodbc

Una vez instalados ambos paquetes, y la librería que permite el acceso a SQLite desde unixODBC, tenemos que configurar el uso de dicha librería. Para ello, en unixODBC se usa el fichero /etc/odbcinst.ini en el que añadiremos los dos siguientes bloques:

[SQLite]
Description = SQLite ODBC Driver
Driver = /usr/lib/odbc/libsqliteodbc.so
Setup = /usr/lib/odbc/libsqliteodbc.so
UsageCount = 1

[SQLite3]
Description = SQLite3 ODBC Driver
Driver = /usr/lib/odbc/libsqlite3odbc.so
Setup = /usr/lib/odbc/libsqlite3odbc.so
UsageCount = 1

Una vez hecho esto, ya podemos crear nuestra primera BD, para ello simplemente crearemos el fichero vacío:

# touch /tmp/mibd

Para configurar el acceso a esta BD, usaremos el fichero /etc/odbc.ini donde pondremos los siguiente (el valor entre corchetes es el DSN que utilizaremos para conectarnos):

[mibd-sqlite]
Description = My SQLite test database
Driver = SQLite3
Database = /tmp/mibd
Timeout = 2000

Para probar que tenemos acceso a nuestra BD, podemos probar con lo siguiente:

# isql midb-sqlite

Que nos devolverá un prompt donde podremos escribir nuestras consulta SQL al servidor.

El control de acceso y autorización es tan sencillo como el control de permisos y de usuario del fichero que contiene la BD. Así que a jugar con chmod y chown.

Por el momento nada más, a disfrutar de esta magnífica solución para almacenamiento de datos.

Para empezar la primera ha sido con el wordpress, que yo creía que sería más sencillo montarlo en castellano, y preparado para multiusuario, pero ya he podido ver que no es así. De momento la interfaz se queda en inglés, y cuando tenga un rato traduciré el tema que he usado a nuestro idioma.