Planet e-ghost

11 de marzo, 2010

saghul

Building Telephony Systems with OpenSIPS 1.6

Hoy os voy a comentar la impresión que me he llevado tras leer el libro “Building Telephony Systems with OpenSIPS 1.6” de Flavio E. Goncalves. Si Manwe si, ya se que para ti esto no cuenta como libro pero bueno. ;)

Al igual que la versión anterior (Building Telephony Systems with OpenSER) la idea del libro es introducir al lector en la configuración de OpenSIPS e ir avanzando poco a poco e ir integrando más servicios.

Aunque saber algo SIP es más que recomendable, el libro comienza con una introducción a SIP, y a lo largo de los capítulos se muestran capturas con ngrep, para poder entender como afecta la configuración de OpenSIPS a los mensajes SIP y su procesamiento.

La estructura es muy acertada, ya que se comienza con una configuración muy básica sin tan siquiera autenticación, para terminar con una configuración que incluye autenticación en MySQL, tratamiento de NAT, accounting en RADIUS, …

He resumido mucho, así que os recomiendo que si queréis empezar a aprender OpenSIPS os lo compréis (no es caro) y lo pongáis en vuestra mesita de noche, justo al lado del RFC3261. ;)

643cc7cfopengfx

11 de marzo, 2010 21:58

Paradise City

Real Castañazo

Foto de As.com Me van a perdonar los madridistas y los no futboleros, pero no me resisto a comentar la eliminación del equipo merengón de la Champions League, la antigua Copa de Europa, la competición donde el Real deposita todas sus esperanzas al ser el equipo más laureado de la historia del torneo. Y es que esto [...]

11 de marzo, 2010 11:21

Iker Perez de Albeniz

Usar/Crear Filtros para las plantillas de django/Google App Engine

Una de los temas mas interesante en Google App Engine es la posibilidad de usar plantillas. En la página de GAE existen ejemplos sencillos de cómo utilizar plantillas.El problema empieza cuando dentro de esas plantillas quieres hacer tratamiento de los datos para mostrar los datos correctamente. En esta articulo intentaremos explicar como usar esos filtros y como crear propios.

Como habéis podido ver en el ejemplo de la pagina de GAE, la forma de mostrar un valor en la plantilla es usando la sintaxis {{ variable }}. En la mayoría de los casos dichas variables serán de tipo string o integer por lo que su visualización no tendrá mayor problema. Pero por ejemplo en el caso de variables tipo datetime u otro tipo de objeto propio, el sistema de plantillas no es capaz de mostrar el contenido de dichas variables, ya que solo es capaz de mostrar valores tipo string o integer.

Para los tipos de datos mas comunes existen ya filtros por defecto como es el caso de los valores datetime. La forma de aplicar un filtro es la siguiente:

{{variable|filtro}}

Y en algunos casos:

{{variable|filtro:argumento}}

En el caso de los valores datetime que hemos comentado antes, para mostrar un valor de fecha deberemos usar el filtro date de la siguiente manera:

{{mydatevar|date:"j"}}

Esto seria equivalente a ejecutar una función date(mydatevar,”j”) y lo que estoy haciendo es mostrar el día del mes (código %j) similar a como se hace en otros lenguajes de programación.

Aquí podéis encontrar un listado con los principales filtros predeterminados en django

El problema es cuando estas funciones no son suficientes para hacer lo que nosotros queremos, o queremos tratar tipos de objetos poco comunes o propios.

Por ejemplo imaginemos que queremos tenemos un libro de visitas donde los usuarios puede escribir entradas, e indican su dirección de correo. Pero no queremos que esa dirección de correo sea visible para que no pueda ser rastreada por spammers, por lo que optamos por mostrar solo los 5 primeros caracteres de el nombre de usuario de la cuenta de correo mas tres puntos suspensivos (algo parecido a lo que se hace en las listas de distribución). Es decir para estoesunaprueba@gmail.com nos generara una dirección del tipo estoe…@gmail.com.

Por tanto nuestra función en python seria algo así como:

def securemail (mail):
        return mail.split(‘@’)[0][:5]+”…@”+ mail.split(‘@’)[1]

Es decir, dividimos la dirección en usuario y dominio con la función split y el carácter @, y generamos una nueva dirección con los primeros 5 caracteres de el usuario mas tres puntos suspensivos la arroba y el dominio.

Para poder usar esta función en nuestras plantillas haremos lo siguiente. Crearemos un script customfilters.py donde guardaremos todas nuestros filtros. Dicho script tendrá la siguiente forma

from google.appengine.ext import webapp
from datetime import datetime
 
register = webapp.template.create_template_register()
 
def securemail (mail):
        return mail.split(‘@’)[0][:5]+”…@”+ mail.split(‘@’)[1]
               
register.filter(securemail)

Para importar los filtros en nuestra aplicación añadiremos la siguiente sentencia justo después de los imports.

webapp.template.register_template_library(‘customfilters’)

De esta forma podremos usar nuestro filtro de la siguiente manera:

{{mail|securemail}}

Imaginemos que damos la opción al usuario que la función securemail muestre su cuenta de dos modos, uno, el por defecto que es el funcionamiento explicado anteriormente, y otro, que hace que solo se muestre el usuario sin el dominio. Por tanto deberemos definir un parámetro en la función para poder elegir el tipo de ofuscación. La función en este caso nos quedaría así:

def securemail (mail,default=true):
        if default:
                return mail.split(‘@’)[0][:5]+”…@”+ mail.split(‘@’)[1]
        else:
                return mail.split(‘@’)[0]

Por tanto si la variable mail tomara el valor estoesunaprueba@gmail.com este seria el resultado para las diferentes expresiones:

{{mail|securemail}} #estoe…@gmail.com
{{mail|securemail:true}} #estoe…@gmail.com
{{mail|securemail:false}} #estoesunaprueba

De esta forma podemos controlar y procesar la información a mostrar en nuestra plantilla cuando esta se trata de un objeto no string (o integer).

11 de marzo, 2010 11:17

10 de marzo, 2010

loretahur

De las Ondas a la Red: febrero 2010

Aquí van los audios de los programas correspondientes al mes de febrero de la sección De las Ondas a la Red en Hoy por Hoy Bilbao. Un mes corto pero intenso ;-)

01-02-2010: Aitor García Rey analiza Irekia

Aitor García Rey, de Linking Paths, analiza Irekia, la nueva plataforma lanzada por el Gobierno Vasco que busca la participación ciudadana y el open government.

08-02-2010: Plootu, guías turísticas a la carta

En esta ocasión contamos con los creadores de Plootu: Alex Dolara e Iñigo Atutxa. En Plootu trabajan con las oficinas de turismo para ofrecer al usuario la posibilidad de generar guías de viaje personalizadas y disponibles en formato PDF para imprimir o visualizar desde cualquier dispositivo portátil.

15-02-2010: I Jornada Ciudades, ciudadanía e Internet

El pasado 20 de febrero se celebró en la Universidad de Deusto la jornada “Ciudades, ciudadanía e Internet” de la mano de la plataforma “Colabora en Nuestras Ciudades“, que se dedica a facilitar el empoderamiento de la ciudadanía en la gestión de las capitales, ciudades y pueblos de la la CAV. Jose Antonio del Moral nos presenta el evento.

» Anteriores programas

email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

10 de marzo, 2010 00:10

09 de marzo, 2010

Paradise City

F1 2010: Pretemporada

Bueno, bueno, bueno… un año más y el post clásico acerca de cómo, desde mi óptica de aficionado, veo la temporada. Ya se sabe que una cosa es lo que yo piense, y otra, cómo venga la dada la temporada. Porque si se repite la jugada del año pasado con un outsider que reinterpreta las [...]

09 de marzo, 2010 17:57

Erdi Lurra

Donde están mis 15 euros?

Como todo buen viciado que se precie, hoy es el día de lanzamiento del Final Fantasy XIII. Una superproducción en toda regla, con 5 años de desarrollo incluído. Pero como consumidor, no puedo sino quejarme por los precios de distribución. Es decir, en españa, cañí de pandereta y llena de aprobetxategis -que diría Mr. Reverte- 64,95€ [...]

09 de marzo, 2010 16:08

07 de marzo, 2010

loretahur

Identidad digital – III Cita GetxoBlog

Ayer sábado estuve en la III Cita GetxoBlog, en un lugar precioso como es la fonoteca de la Escuela de Música “Andrés Isasi” de Las Arenas y con un ambiente envidiable (es facilísimo hablar cuando se está tan a gusto).

Aquí dejo la presentación utilizada así como la grabación de la charla hecha por Mikel. ¡Muchas gracias por la invitación!

Identidad Digital
Más presentaciones de Lorena Fernández.

email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

07 de marzo, 2010 21:29

Paradise City

Dinamismo

¿Qué vas a hacer dentro de N días? Y no lo sé. Últimamente es la pregunta que más me repiten y para la que menos respuesta tengo. En vista de la decisión tomada en su momento, mi vida se ha convertido en ir dando tumbos de un lado para otro y poca cosa más puedo hacer [...]

07 de marzo, 2010 08:12

05 de marzo, 2010

Paradise City

Y Poner la Cama

Todos lo hemos oído y lo hemos visto. La campaña ha llegado a todo el mundo. Y, realmente, la base es buena: Si todos ponemos de nuestra parte, la cosa solo puede mejorar. Pero claro, uno, que ya está de vuelta de todo en el tema de campañas virales de Internet, ha profundizado. Y escandalizado, encuentro [...]

05 de marzo, 2010 19:28

Iker Perez de Albeniz

Consulta tu PageRank de Google con Python

A todos los que os interese el SEO seguramente habréis consultado alguna vez el PageRank de vuestra pagina. La forma mas sencilla de obtenerlo es instalando la ToolBar de Google en vuestro navegador. Pero seguramente si queréis realizar un seguimiento de vuestra pagina a lo largo del tiempo necesitareis automatizar un proceso que consulte el PageRank. La API de acceso al PageRank de google no es abierta, pero googleando un poco (o con Wireshark) es posible obtener el modo de consultar este dato. Parece que Google no le interesa que consultemos este dato, por lo que modifica la API bastante a menudo. En este artículo, te muestro una implementación en Python de un cliente para consultar el PageRank de una pagina, usando la API mas actual.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# GPL (C) 2010 Iker Perez de Albeniz
# ported in Python from the Php code by HM2K (http://www.hm2k.com/projects/pagerank)
# http://www.ikeralbeniz.net/2010/03/05/contulta-tu-pagerank-de-google-con-python/

import sys
import urllib
 
from urllib import urlencode
from pprint import pprint

def strToNum(Str, Check, Magic):
        Int32Unit = 4294967296
        length = len(Str);
        for i in range(0,length):
            Check *= Magic;
            if (Check >= Int32Unit):
                Check = (Check – Int32Unit * int(Check/Int32Unit))
                if Check < -2147483648:
                    Check = Check + Int32Unit
                   
            Check += ord(Str[i])
        return Check
   
def hashURL(string):
        check1 = strToNum(string, 0×1505, 0×21)
        check2 = strToNum(string, 0, 0×1003F)
 
        check1 >>= 2
        check1 = ((check1 >> 4) & 0×3FFFFC0 ) | (check1 & 0×3F)
        check1 = ((check1 >> 4) & 0×3FFC00 ) | (check1 & 0×3FF)
        check1 = ((check1 >> 4) & 0×3C000 ) | (check1 & 0×3FFF)
 
        T1 = ((((check1 & 0×3C0) << 4) | (check1 & 0×3C)) <<2 ) | (check2 & 0xF0F )
        T2 = ((((check1 & 0xFFFFC000) << 4) | (check1 & 0×3C00)) << 0xA) | (check2 & 0xF0F0000 )
 
        return (T1 | T2);
   
def checkHash(hashnum):
        checkByte = 0;
        flag = 0;
 
        HashStr = ‘%s’ % hashnum
        length = len(HashStr)
 
        for i in range(0,length):
            Re = int(HashStr[(length – 1)-i])
            if (1 == (flag % 2)):
                Re += Re
                Re = int((Re / 10) + (Re % 10))

            checkByte += int(Re)
            flag = flag + 1

        checkByte %= 10
        if (0 != checkByte):
            checkByte = 10 – checkByte
            if (1 == (flag % 2) ):
                if (1 == (checkByte % 2)):
                    checkByte += 9
               
                checkByte >>= 1
        return ‘7%s%s’ %(checkByte,HashStr)

def getCh(url):
    return checkHash(hashURL(url))

def main():
   
    response = "Error: No URL defined.\nUsage: googrng.py <url> [[proxyuser:proxypass@]proxyhost:poxyport]"
    if len(sys.argv) > 1:
        myurl = sys.argv[1]
        url = "http://toolbarqueries.google.es/search?features=Rank&sourceid=navclient-ff&client=navclient-auto-ff&googleip=O;208.117.235.17;97&iqrn=8VdB&querytime=4P&orig=0X557&swwk=-1&ch=%s&q=info:%s" %(getCh(myurl),urllib.quote_plus(myurl))
        if len(sys.argv) > 2:
                proxies = {‘http’: ‘http://’+sys.argv[1]}
                f = urllib.urlopen(url, proxies=proxies)
        else:
                f = urllib.urlopen(url)
        response = f.read()
        f.close()
    print response

if __name__ == "__main__":
    main()

05 de marzo, 2010 07:56

loretahur

La Ventana “Digital” de JoHari

El sábado estaré en la tercera edición de GetxoBlog hablando de Identidad Digital: sus ventajas e inconvenientes (espero no caer en el alarmismo que últimamente impregna esto…). Será a las 17:00 en la Fonoteca de la Escuela de Música “Andrés Isasi” de Las Arenas (Getxo).

A pesar de que a muchos les ha dado por satanizar a las herramientas en todo este proceso de ombliguismo y aireo de intimidades, me temo que ellas no tienen la culpa ;-) . No es tanto analizar esto como los cambios en comportamientos y la forma en que interaccionamos y nos comunicamos. Por eso me voy más a tierras de la psicología (donde soy una extrajera, así que espero no profanar muchas tumbas…) que a tierras tecnológicas. Y la ventana de JoHari me viene de perlas para ilustrarlo.

Esta teoría fue expuesta por Joseph Luft y Harry Ingham, dos investigadores estadounidenses, allá por 1955. Se trata de un modelo que muestra nuestras interrelaciones desde dos prismas: cómo y cuánto nos exponemos a los demás y cómo y cuánto nos conocemos nosotros mismos.

Vemos que hay cuatro cristales en esta ventana:

En este caso me voy a centrar en las dos primeras áreas, que son las que más están evolucionando. Si bien la zona I (abierta) antes crecía al mismo ritmo que la confianza (es decir, contra más conocías a alguien, más exponías de ti a esa persona), hoy en día esa zona está canibalizando a la II (oculta) sin casi necesidad de un contacto previo. Nos gusta mostrarnos, hablar de nosotros mismos (o como diría un buen amigo, escuchar cómo suena nuestra voz). Pocas cosas quedan en ese segundo cuadrante y casi siempre son cosas que nos avergüenzan o no queremos que se sepan por el “qué dirán”.

Pudiera parecer que tener una gran zona abierta es positivo porque somos más y más transparentes (analizando este término en su vertiente de franqueza y honradez). Sin embargo, desde mi opinión más personal, también veo que esto debilita los lazos de nuestras relaciones. Una persona que de buenas a primeras me cuenta sus intimidades no está reservando nada para cuando yo demuestre que efectivamente soy merecedora de esas intimidades (ya os digo que es una percepción totalmente personal).

Otra cuestión interesante es la fractura relacional que se produce entre personas de diferentes generaciones que tienen ventanas muy distintas: una con una zona abierta excesivamente amplia frente a otra que no funciona de la misma manera, juega con una clara desventaja ante esta asimetría. Pongamos un ejemplo muy típico en esto de las redes sociales: una entrevista de trabajo. Se habla de que en el futuro, los jóvenes que vayan en busca de empleo se tendrán que enfrentar a la temible lupa de Google. Esto ahora puede ser un problema si el empleador tiene una ventana de JoHari compensada (zona I y II similares) y el candidato una ventana descompensada (zona I inusitadamente grande). Pero en un futuro, esto cada vez se dará menos: tanto el empleador como el empleado tendrán una ventana similar.

Está claro que las nuevas tecnologías ayudan a reducir la zona II porque ayudan a comunicar. Pero no son las que encendieron la mecha (aunque sirvan de catalizador). Para todos aquellos que dicen que esta extimidad viene de la mano de las redes sociales virtuales, sólo un dato: el reality show Gran Hermano nació en 1997. Facebook lo hizo en 2004.

email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

05 de marzo, 2010 00:14

04 de marzo, 2010

saghul

OpenSIPS estrena diseño

Y no es que hayan cambiado el CSS de la web. OpenSIPS va a ser reescrito por completo a partir del diseño que fue publicado hace unos días.

OpenSIPS tiene ya más de 7 años, tiempo en el que ta tecnología ha ido cambiado y han ido surgiendo necesidades y problemas que antes no había. Intuyo que no habrá sido fácil decidir reescribirlo, ya que supone mucho esfuerzo, pero seguramente sea lo mejor para un futuro.

El nuevo diseño se basa en el patrón reactor asíncrono, gracias al cual no habrá problemas de bloqueo entre los procesos de OpenSIPS, algo que actualmente si que puede suceder al hacer operaciones como consultas a BBDD, etc. Además, habrá dos importantes partes: el core y el routing engine.

new_design-routing-internal

new_design-routing-external

Otro importante cambio con respecto al diseño actual es la posibilidad de utilizar varios routing engines con un solo core, de manera que cada routing engine implemente un funcionamiento diferente, pero un único core se encargue del procesamiento SIP a bajo nivel.

Hasta ahora, la lógica de OpenSIPS se definía en un fichero cfg en una sintaxis similar a C, pero con el nuevo diseño tendremos dos opciones para definir el funcionamiento de nuestro servidor:

Éste post es solo un resumen del documento que podéis ver aquí. Os recomiendo echarle un vistazo, veremos que tal sale la cosa dentro de unos 12 meses. :)

Si tenéis alguna duda, mañana viernes 5 de Marzo el tema central de la VoIP Users Conference será el diseño de OpenSIPS, y como invitados estarán Bogdan-Andrei Iancu (CEO en Voice-System), Adrian Georgescu (CEO en AG Projects) y Flavio Golcalves (autor de ‘Building Telephony Systems with OpenSIPS 1.6′).

¿Te lo vas a perder?

Por último me gustaría felicitar al equipo de ‘arquitectos’ que ha diseñado el nuevo OpenSIPS: Bogdan Iancu, Anca Vamanu, Andrei Dragus y Dan Pascu, OpenSIPS 2.0, here we go!

04 de marzo, 2010 23:06

Iker Perez de Albeniz

Primeros pasos con Buzz (segunda parte): Un widget de Buzz para Wordpress

En el articulo anterior analizábamos la API de acceso a Buzz. Una vez analizada ya podemos ver como integrar Buzz en nuestra pagina. Para eso vamos a utilizar la API de Google para leer feeds y un script propio que lo que hará es mostrarnos el código HTML de los comentarios en in iframe refrescándolo cada 1 segundo. De este modo es posible crear un widget de Buzz para nuestro wordpress.

Antes de nada hay que tener en cuenta dos aspectos importantes:

var feed = new google.feeds.Feed(“http://buzz.googleapis.com/feeds/111738004311961586383/public/posted”);

sample.html

<html>
        <head>
                <script type="text/javascript" src="http://www.google.com/jsapi?key=ABQIAAAAMGph6fpNzf-ET0oBGVVHJxRpfcICevY5tQgqnPHEJCivekQnPxSD1FOWXFY6-VJtM6TmsT-tOJc9mg"></script>
                <script type="text/javascript" src="buzz.js"></script>
        </head>
        <body>
                <div id="buzz" style="width:300px;background-color:#e1f3fa;">
                        <h1 style="font:20px Verdana;Color:#2193c5;margin:7px;">Iker.perez</h1>
                        <hr style="border: 1px dotted #CCCCCC;margin:5px 7px 0px 7px;">
                        <iframe id="buzz_msg_box" style="margin:0px 7px 0px 7px;border:0px; width:286px; height:450px;background-color:#ffffff;"></iframe>
                        <hr style="border: 1px dotted #CCCCCC;margin:0px 7px 0px 7px;">
                        <img src="buz.png" style="margin: 7px" width="100px">
                </div>
        </body>
</html>

buzz.js

google.load("feeds", "1");
var Editor;
window.onload = function()
{
Editor = document.getElementById(‘buzz_msg_box’).contentWindow.document;
Editor.designMode = "on";

}

function initialize() {
var feed = new google.feeds.Feed("http://buzz.googleapis.com/feeds/111738004311961586383/public/posted");
feed.setNumEntries(20);
feed.load(function(result) {
if (!result.error) {
var alltest = "";
var simplepost = "";
for (var i = 0; i < result.feed.entries.length; i++) {
simplepost = "";
var entry = result.feed.entries[i];

simplepost +’                <div id="message" style="font: 12px Verdana;"><b>+entry.publishedDate.split(" -")[0]+:</b><br/>+entry.content+</div>\r\n’;
simplepost = simplepost +<hr style="border: 1px dotted #CCCCCC;"/>\r\n’;
//entry.title+"<br>"+;
alltest = alltest + simplepost ;

}
Editor.body.innerHTML = alltest;
}
});
}

function reloadComments() {
google.setOnLoadCallback(initialize);
setTimeout(‘reloadComments(),1000);
}

reloadComments();


Ikalbeniz



04 de marzo, 2010 17:11

03 de marzo, 2010

Paradise City

¡Mis soldados y mi hacha!

Llevo una temporada bajona. Tanto, que tras haber comido y consumido el café previo al curso, me ha entrado una inconsciencia rayana en el coma cerebral. Dado que dirigirme a Bilbao a impartir el curso que toca esta semana es una actividad bastante incompatible con el coma, me he dicho que tendría que espabilarme de [...]

03 de marzo, 2010 14:31

02 de marzo, 2010

Alvaro Marín

Euskaltel bloquea el tráfico saliente hacia el puerto 25

Como hace tiempo hizo Telefónica y como podemos ver a través de su centro de seguridad Nemesys, Euskaltel ha pasado a bloquear el tráfico saliente hacia el puerto 25 para alguna de sus redes.
Como dicen en su web:

El objetivo es evitar que los equipos de nuestros clientes puedan ser utilizados sin su consentimiento para envío masivo de SPAM, PHISHING y otras amenazas emergentes a día de hoy en Internet

Parece, no obstante, que el bloqueo se produce solamente a sus redes de IPs dinámicas.

Si por ejemplo, un cliente de Euskaltel tuviese un servicio de correo contratado en una empresa de hosting como puede ser Hostalia, simplemente cambiando el puerto de salida del 25 al 587 (como reza el RFC 2476 – Message Submission) en su cliente de correo, podría seguir usando dicho servicio.

Telefónica ya consiguió en su día salir de los primeros puestos de redes emisoras de spam con esta medida y a pesar de las quejas iniciales, todos nos hemos visto beneficiados por esta medida.

No queda más que decir que bien por Euskaltel y que a ver si el resto de ISPs siguen las mismas políticas.

02 de marzo, 2010 16:59

Software Libre

Buenas noticias desde la CRUE y el Gobierno Vasco

Parece que esta semana empieza con muy buen pie para el Software Libre :-)

El lunes 1 de marzo CENATIC anunció la incorporación del Gobierno Vasco a su patronato. Con esta incorporación, ya son 8 de las 17 comunidades las presentes en el patronato de CENATIC (Centro Nacional de Referencia de Aplicación de las TIC basadas en fuentes abiertas): la Junta de Extremadura, la Junta de Andalucía, el Principado de Asturias, el Gobierno de Aragón, el Gobierno de Cantabria, la Generalitat de Catalunya, el Govern de les Illes Balears, y el Gobierno Vasco; además del Ministerio de Industria, Turismo y Comercio, a través de red.es, y las empresas Atos Origin, Bull, Telefónica y Gpex.

Tal y como indica la nota de prensa, Idoia Mendia, Consejera del Departamento de Justicia y Administración Pública, declaró:

“Para nosotros es una forma de dar cumplimento a un mandato del Parlamento Vasco, que instó a nuestro Gobierno a apostar por las tecnologías libres [...] El Gobierno Vasco mantiene una apuesta decidida por las nuevas tecnologías, y por ir más allá de convencionalismos informáticos, potenciando el desarrollo de una administración electrónica eficiente”.

Buenas intenciones que poco a poco van plasmándose en acciones :-)

Por otro lado, la CRUE (Conferencia de Rectores de Universidades Españolas) ha aprovechado la reunión de la Comisión Sectorial de las Tecnologías de la Información y de la Comunicación (TICs) que se ha celebrado en la Escuela Universitaria de Estudios Empresariales de Bilbao para anunciar su apuesta por impulsar el Software Libre en las universidades españolas.

Como se comenta en IRIS-LIBRE, esta resolución no hace sino avanzar en el mismo camino apuntado años atrás.

Tampoco conviene relajarse, pero no vienen nada mal noticias como éstas de vez en cuando ;-)

02 de marzo, 2010 12:45

01 de marzo, 2010

Paradise City

Atentados Musicales (XX)

Vaya, es raro que todavía no haya aparecido por aquí el rey. Elvis Presley. Hombre, quizás porque es una hemifobia mía. Reconozco que es una voz soul en un cuerpo de un anglosajón. Y que lo hacía muy bien. Pero la imagen que me queda es del personaje fofo, sudoroso y con un horrible gusto [...]

01 de marzo, 2010 11:29

28 de febrero, 2010

saghul

ICE, ¿la solución definitiva al NAT en SIP?

Tras estar varias semanas trabajando en éste tema me he decidido a escribir un (largo) post comentando qué es y cómo funciona esto del ICE, ya que no es algo que se esté utilizando demasiado desafortunadamente.

Introducción

Interactive Connection Establishment (ICE) define un protocolo de actuación gracias al cual dos dispositivos SIP son capaces de mantener una sesión multimedia salvando todas las dificultades que el NAT pueda poner de por medio. Aún se encuentra en estado de draft (la última es la revisión 19), pero está en la cola para obtener un número de RFC.

ICE permite que los dispositivos involucrados en la sesión SIP prueben distintos medios o rutas para comunicarse entre sí y acuerden uno común. Gracias a ICE es posible que dos terminales que se encuentran en la misma LAN envíen el tráfico RTP de manera local, en lugar de utilizar un relay como MediaProxy o RTPProxy, sin realizar ninguna configuración exótica en el servidor. La inteligencia está en los terminales.

¿Cómo funciona?

ICE es un proceso bastante complejo que consta de 9 pasos que intentaré simplificar aquí. Para obtener una información más completa os recomiendo leeros el draft, que aunque es bastante denso describe el mecanismo completo.

Paso 1: Obtención de candidatos

En éste primer paso el llamante obtiene todos los candidados que pueda para posteriormente añadirlos al SDP. Lo habitual es que disponga de dos tipos de candidatos:

Paso 2: Aplicar prioridades

Tras obtener la lista de candidatos se aplican prioridades, de manera que unos candidatos se prefieran frente a otros. Por ejemplo, la especificación indica que un candidato host ha de ser más prioritario que uno de tipo relayed, es decir, se prefiere mandar el audio por la LAN que a través de un servidor externo que encamina nuestro audio, lo cual tiene bastante sentido.

Al finalizar este paso se construye el SDP que será enviado. Veamos un ejemplo:

v=0
o=- 3476345811 3476345811 IN IP4 192.168.99.53
s=sipsimple 0.12.0
c=IN IP4 192.168.99.53
t=0 0
m=audio 60770 RTP/AVP 103 102 9 0 8 117 3 101
a=rtcp:60771 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:3e0cc9fc
a=ice-pwd:19d32c8c
a=candidate:Sc0a86335 1 UDP 1862270975 62.131.6.55 60770 typ srflx raddr 192.168.99.53 rport 48649
a=candidate:Hc0a86335 1 UDP 1694498815 192.168.99.53 48649 typ host
a=candidate:Ha45450a 1 UDP 1694498815 10.69.69.10 48649 typ host
a=candidate:Sc0a86335 2 UDP 1862270974 62.131.6.55 60771 typ srflx raddr 192.168.99.53 rport 48868
a=candidate:Hc0a86335 2 UDP 1694498814 192.168.99.53 48868 typ host
a=candidate:Ha45450a 2 UDP 1694498814 10.69.69.10 48868 typ host
a=sendrecv

Paso 3: Iniciación

En este paso simplemente se envía el INVITE al usuario correspondiente con el SDP creado en el paso 2. SIP atravesará el NAT mediante los mecanismos tradicionales (rport, etc.) por lo que no hay que hacer tratamiento de NAT para el SDP.

Paso 4: Obtención de candidatos (llamado)

Al recibir el INVITE con la oferta en el SDP, el llamado comienza a obtener sus propios candidatos de la misma manera que lo hizo el llamante. Una vez más, lo habitual es obtener candidatos host y server reflexive. Una vez se obtienen los candidatos, se aplican prioridades y se construye el SDP que será enviado.

Paso 5: Información

El llamado responde al INVITE con una respuesta (provisional o definitiva) y en su SDP habrá incluido sus candidatos.

NOTA: Aunque puede tener sentido enviar la respuesta en una respuesta provisional (18X) SIP no especifica como actuar ante la recepción de múltiples respuestas 18X con SDP, por lo que si encima añadimos ICE al asunto lo mas probable es que no podamos establecer la comunicación. En todas las pruebas que he hecho (y han sido muchas) la negociación ICE no lleva más de 2 segundos, por lo que hacerla tras el 200 OK no es un problema IMHO.

Paso 6: Verificación

Cada agente (llamado y llamante) involucrado en la comunación empareja sus candidatos con los candidatos remotos para formar parejas de candidatos. Éstas parejas serán evaluadas por orden de prioridad descendente por el agente controlador. Por simplificar, diremos que el agente controlador siempre el el llamante (esto puede variar, pero en casos bastante peculiares, que creo que añadirían demasiada confusión al tema).

En éste momento ambos agentes comienzan a realizar pruebas de conectividad cada 20ms. Éstas pruebas se llevan a cabo mediante paquetes especiales STUN que contienen binding requests. El agente remoto contestará con la IP y el puerto desde los que ha recibido dicha binding request y así el agente que ha enviado la petición sabrá que el test ha sido satisfactorio y marcará el candidato como válido.

Si uno de los agentes involucrados en la sesión se encuentra tras un NAT simétrico, esto será detectado al ver la diferencia entre el server reflexive candidate publicado y el origen del binding request que mandará. Entonces se crea un nuevo candidato de tipo peer reflexive, que contiene la IP y puerto donde estará el RTP (los test de conectividad de hacen enviando paquetes STUN a los puertos donde posteriormente habrá RTP). Gracias a esto es posible que un usuario tras NAT simétrico y otro tras un NAT no simétrico hablen entre si con audio de router a router. Increíble, ¿no?

Paso 7: Coordinación

Tras la negociación ambos agentes involucrados en ella han de terminar con un par de candidatos válidos por cada componente. Lo habitual es tener dos componentes por cada stream en el SDP: un componente para el RTP y otro para el RTCP.

El agente controlador (habitualmente el que realiza la llamada) elegirá un candidato. A éste proceso se le llama nominación. Para validar éste candidato se envía otra binding request (STUN) pero en esta ocasión se incluye un flag. Ambos agentes utilizarán el par de candidatos que ha pasado las pruebas de conectividad y que además esté nominado.

Recordemos que todo éste proceso ha sido realizado por los agentes utilizando paquetes STUN entre si, sin ninguna interacción por parte del servidor.

Paso 8: Comunicación

Ahora que ambos agentes saben cómo comunicarse, ya pueden enpezar ha hablar, y tenemos garantizado que habrá audio bidireccional, ya que las pruebas de conectividad se realizan en ambas direcciones.

Paso 9: Confirmación

Aunque toda la negociación ha tenido lugar entre los agentes es posible (y habitual) que haya otros agentes en el medio de la señalización, como por ejemplo proxys. Para que los proxys o las middle-boxes entre el llamado y el llamante estén al tanto de lo sucedido, se enviará un re-INVITE o un UPDATE con el resultado de la negociación en el caso de que el candidato seleccionado no sea el candidato por defecto (las líneas c y m del SDP).

¡Qué way!, esto funciona, ¿no?

Pues, para variar, no. Lo habitual para el tratamiento de NAT consiste en que el proxy modifica el SDP si detecta NAT e indica como origen del RTP y RTCP un servidor que hará las veces de media relay.

Al modificar el SDP, no habrá ningún candidato que corresponda a la IP y puerto de las líneas c y m del SDP, por lo que al recibir un INVITE así el otro extremo nos responderá con ésto en su SDP: a=ice-missmatch. Mal tema. ¡Hay que solucionarlo!

“Arreglando” la negociación ICE con OpenSIPS y MediaProxy

Para solucionar éste problema ha sido necesario modificar OpenSIPS y MediaProxy (los componentes con los que trabajo actualmente, pero lo mismo puede hacerse para Kamailio/SIP-Router y RTPProxy).

Resumiendo un poco (tenéis una explicación más completa aquí) lo que sucederá es que OpenSIPS añadirá un nuevo candidato de tipo relayed cuando modifique el SDP, de manera que corresponda con la IP y puerto de las líneas c y m. MediaProxy es ahora capaz de “dejar pasar” las pruebas de conectividad STUN, por lo que al modificar el INVITE inicial y su correspondiente respuesta habremos “engañado” a los agente insertando un nuevo candidato.

Mediante un parámetro es posible controlar la prioridad del candidato que OpenSIPS insertará, afectando así al resultado de la negociación.

Ahora sí, ¡funciona! puedo hablar con audio P2P en mi LAN aunque fuerce el uso de MediaProxy, porque al detectar una negociación ICE satisfactoria MediaProxy se “quita de en medio”. También he probado ha hablar con audio de router a router entre un NAT simétrico y otro de tipo port restricted. How f*c*i*g cool is that?

¡Quiero probarlo!

No tan rápido vaquero. Nos falta hablar de el tema más importante: los clientes SIP. Sólo conozco tres (en esencia uno) que implemente ICE correctamente. Y cuando digo correctamente es que me he leído el draft, el código y he probado que funciona :) Los clientes SIP con soporte ICE (draft versión 19) son PJSIP, SIPSIMPLE client (su core es PJSIP) y Blink (su core es SIPSIMPLE).

Si alguien descubre o está desarrollando un cliente SIP que cumpla la especificación ICE (draft 19) me encantaría probar la interoperabilidad con él.

Actualmente no hay ninguna versión (release) de OpenSIPS que incluya el parche para “solucionar” el problema de ICE, así que podéis parchear manualmente como se menciona aquí o podéis utilizar el servicio gratuito SIP2SIP, que ya dispone de todo lo necesario (parches para OpenSIPS y última versión de MediaProxy).

Conclusiones

Tras estar un mes con éste tema por fin he podido comprobar que funciona. No obstante, es triste ver que hay muy pocas implementaciones de ICE y que solo una funcione. Es cuanto menos sorprendente que softphones de pago de supuesto prestigio digan que soportan ICE y en el SDP se vea claramente no de la manera correcta.

Hay que agradecer a Benny Prijono y el equipo de PJSIP el buen trabajo que han realizado al respecto acudiendo en enumerosas ocasiones al SIPit para mejorar su SIP stack.

¡Joder que largo me ha quedado esto! Para más información podéis leer el draft y echarle un ojo a ésta presentación.

Happy ICE skating! ;)

28 de febrero, 2010 11:42

27 de febrero, 2010

loretahur

Cinco lecturas breves (IV)

Tenemos las lecturas breves más frescas oiga: que si un poco de open access por allí, que si unos libros electrónicos por allá. Para grandes y pequeños, éste es su resumen.

Y de regalo a estas cinco lecturas breves, un vídeo hecho por bibliotecarios de la Library University of Technology Sydney al más puro estilo Common Craft: “Library of the future in plain english“.

» Lecturas breves anteriores

email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

27 de febrero, 2010 22:30

De las Ondas a la Red: enero 2010

Aquí van los audios de los programas correspondientes al mes de enero de la sección De las Ondas a la Red en Hoy por Hoy Bilbao.

04-01-2010: Open Data en el Gobierno Vasco con Alberto Ortíz de Zárate

Empezamos el año aclarando ideas sobre Open Data con Alorza, Director de Atención Ciudadana del Gobierno Vasco. Y es que se ha dado el pistoletazo de salida al proyecto de apertura de datos públicos (aún queda mucho camino por recorrer, pero las intenciones son buenas). Me encanta que intente explicar cosas complejas a un nivel bajo para que, como él dijo, lo entiendan nuestras madres :-) .

11-01-2010: Presentación de la página de Hoy por Hoy Bilbao en Facebook

En esta ocasión hablamos de Facebook y presentamos “en sociedad” la página de Hoy por Hoy Bilbao. En ese programa sólo eramos dos los fans. Ahora ya hay más de 700 y la interacción radio-Internet es plena :-) .

18-01-2010: La música e Internet

Aunque muchas gentes del negocio digan lo contrario, Internet está siendo un revulsivo al consumo musical (ya no entro si de formas legales o ilegales… dependerá del ojo que lo mire, seguro). Así que en este programa hablamos de diferentes páginas web en las que encontrar información sobre nuestros grupos musicales, bandas sonoras, etc… así como sitios donde poder escucharlos.

25-01-2010: Presentación de Irekia y acciones en Internet por Haití

Ese mismo lunes era la presentación y apertura de Irekia, la nueva web de Lehendakaritza que tiene el difícil cometido de abrir un diálogo constante y permanente entre el Ejecutivo y la ciudadanía. En próximos programas analizamos sus puntos fuertes y débiles.

También abordamos en esta ocasión diferentes iniciativas gestadas en Internet para ayudar en la catástrofe de Haití:

» Anteriores programas

email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

27 de febrero, 2010 12:07

Paradise City

Prioridades Tácticas

Ocho y media de la mañana y estoy delante del ordenador. Sábado. Toca acabar un proyecto al que llevo mucho tiempo dando largas. El jueves salí de Bilbao a las siete y media para hacer ayer viernes una entrevista en Madrid, que realicé y volví de nuevo a Bilbao con la única intención de terminar [...]

27 de febrero, 2010 07:31

26 de febrero, 2010

saghul

Undervolted Kernel: ahorrando batería en Android

Una de las cosas que a mucha gente le preocupa sobre los teléfonos móviles es la duración de la batería. Teniendo en cuenta que cada vez son capaces de realizar más funciones, las baterías duran menos, aunque éstas hayan mejorado mucho en los últimos años.

Para mejorar la duración de la batería en nuestro terminal Android vamos a ver cómo instalar un undervolted kernel en un Nexus One (si dispones de otro terminal Android busca un undervolted kernel adaptado a él).

El concepto de un undervolted kernel es sencillo: consiste en mantener el procesador trabajando a la velocidad original, pero utilizando menos voltaje para ello. Al utilizar menos voltaje, obtendremos una mayor duración de la batería. Esto no es posible con todos los terminales, pero con el Nexus One al menos si, así que ¡vamos a ello!

Necesitamos tener instalada la ROM CyanogenMod 5.0.3.1, y los pasos a seguir son sencillos: descargar el kernel, flashearlo desde fastboot, reiniciar el terminal y habilitar el módulo de WiFi:

wget http://kmobs.scepterr.info/kernels/zImage33UV.zip
unzip zImage33UV.zip -d uvkernel
(reiniciamos el androide en modo fastboot)
./fastboot flash zimage uvkernel/zImage33UV
./fastboot reboot
(una vez ha arrancado normal)
./adb remount
./adb push uvkernel/b*.ko /system/lib/modules
./adb reboot

Happy undervolting!

26 de febrero, 2010 08:25

24 de febrero, 2010

Antonio Jara

Gajes del oficio

Lo que hay que ver...

24 de febrero, 2010 15:54

Paradise City

Una de Cine: Percy Jackson y el Ladrón del Rayo

Vaya por delante que esta es una peli solo comprensible dentro del ámbito de cine palomitero. Porque no tiene grandes pretensiones, más allá de un reparto de secundarios de campanillas y resultón (Uma Thurman, Pierce Brosnan, Sean Bean,…) y unos efectos bastante potables. Ya digo, que nadie espere nada sesudo ni original, porque el guión lo [...]

24 de febrero, 2010 13:39

22 de febrero, 2010

Erdi Lurra

Santa María

No, nada que ver con la Virgen ni similares. Lee todo el post, y verás por qué. Estoy preparando mi examen de cinturón negro de Vovinam (quién lo iba a decir!) cuando el viernes sufro una mala caída. Golpe fuerte en el talón. El sábado no podía ni apoyar el pie. Como golpe que es, fui ayer [...]

22 de febrero, 2010 10:29

Paradise City

Historias de la Copa

Ya digo que el viernes, en un anticipo de mi cumpleaños, me regalaron una entrada para la segunda jornada de cuartos de final y desde la atalaya que es la fila 25 de una grada de banda, comentar unas historietas. Las aficiones son un ejemplo de cordialidad y saber estar que ya quisieran en otros deportes: [...]

22 de febrero, 2010 08:22

21 de febrero, 2010

loretahur

¿Qué necesitan los desarrolladores de software para montar aplicaciones de colaboración con éxito? A parte, claro está, de dinero…

Y aquí va la segunda presentación que hice en Ciudades, ciudadanía e Internet. Esta vez estaba muy bien acompañada por Aitor García Rey de Linking Paths y Dani Reguera de Tagzania. Fue una mesa muy especial para mí porque hasta ahora nadie nos había preguntado a los desarrolladores de software qué es lo que necesitamos. Así que aquí va una lista de cosas:

Además de cantidades ingentes de cafeína… (y un buen maquillaje/gafas de sol por las mañanas para ocultar nuestras ojeras)

¿Qué necesitan los desarrolladores de software para montar aplicaciones de colaboración con éxito?
Más presentaciones de Lorena Fernández.
email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

21 de febrero, 2010 21:26

Digitalizando las juntas de vecinos

Esta fue la primera de las presentaciones que hice el sábado en la I jornada Ciudades, Ciudadanía e Internet, analizando casos de éxito de aplicaciones para la colaboración ciudadana. No me pude explayar mucho porque teníamos muchas voces que escuchar y poco tiempo (un montón de mesas y público muy participativo, cosa que se agradece enormemente), así que aquí dejo todo lo que me tenía en mente :-) .

No tenemos que entender la participación ciudadana a través de la Red exclusivamente como una vía para que los políticos se comuniquen con nosotros de una manera más directa ni a la inversa. Una pata muy importante es la de organizarnos: lograr ciudades y ciudadanos enredados que prefieran pasar a la acción en vez de esperar que alguien dé el primer paso o les tienda la mano. Ciudades y ciudadanos que no sólo se organicen cuando hay problemas, sino también para compartir experiencias y convivencias.

Cuando pienso en esto, el primer ejemplo que me viene a la cabeza es el de Abla, un pueblo almeriense de unos 1.500 habitantes, muchos de ellos “hackers rurales” que impulsan la innovación desde abajo y no esperan a que sean las administraciones las que enciendan la chispa: redes sociales de vecinos, red wifi gratuita (como colofón a su declaración en 1998 de que el acceso a Internet debe ser un derecho universal de todos los ciudadano), vecinos que se comunican con el alcalde vía Internet, móvil o en persona, y un largo etcétera.

Otro ejemplo de un uso interesante en la Red es el de Fix My Street y su réplica más cercana arreglaMicalle (con un eco más limitado que el de su hermana inglesa). Plataformas en las que denunciar el mal estado de los espacios públicos bajo el slogan “si el ayuntamiento olvida, la comunidad recuerda“. Harina de otro costal será que el ayuntamiento no quiera escuchar… Fix my street nació hace poco más de un año como un proyecto de MySociety, una organización británica no gubernamental dedicada a “crear sitios web que proporcionan a la gente beneficios simples y tangibles en ámbitos cívicos y comunitarios”. En la misma línea está Alertas Urbanas en Cornellá, promovido por la asociación Cornellà Xarxa Ciutadana. Una página web donde localizar cualquier tipo de problema, dificultad, mejora… del barrio de Cornellá. Cuentan con un foro, un wiki y un cafetería on-line.

Si nos gusta más el modelo acción-reacción, podemos hacer algo de guerrilla con Aparcas como el culo, una plataforma desde la que nos podemos imprimir unos carteles-tipo para dejar en los parabrisas de los conductores in-cívicos, informándoles de algo que quizás no habían detectado (¡ejem!) e indicándoles dónde les podrían enseñar a hacerlo mejor. Cuentan con una galería de los horrores.

Y si seguimos con denuncias de espacios públicos: Queremos Jugar es una campaña iniciada por Save The Children donde uno puede mandar o sumarse a una denuncia ya hecha del mal estado de parques y polideportivos, o la falta de estos. El 15 de diciembre finalizó el período de recogida y ahora se está analizando la información para hacérsela llegar a los ayuntamientos correspondientes.

Bajo el slogan “¿Quieres saber algo de tu barrio? Pregúntale a tus vecinos” se presenta Askaro, una plataforma de nueva hornada ideada por triunfadores de las redes sociales (Ubaldo Huerta, creador de Loquo y Eduardo Manchón, creador de Panoramio). La finalidad de esta red es potenciar el blended networking, es decir, que las nuevas tecnologías sean apoyos a la comunicación a pie de calle, sirviendo como un buen repositorio del conocimiento tácito que se mueve en los corrillos del supermercado, el bar del barrio, etc… En esa misma línea de vecindario colaborativo está Neighbors for Neighbors o Meetup (hacer algo, aprender algo, compartir algo, cambiar algo).

Podéis encontrar más casos de éxito en el wiki de Colabora en Nuestras Ciudades.

Conclusiones

Digitalizando las juntas vecinales – Colabora Bilbao
Más presentaciones de Lorena Fernández.
email del.icio.us Facebook Google Bookmarks BarraPunto LinkedIn Technorati Bitacoras.com Wikio FriendFeed Identi.ca Twitter

21 de febrero, 2010 20:43

20 de febrero, 2010

Paradise City

Una Vez al Año…

… cumples años. Y van 31. Ya digo que este último ha sido para olvidar. No el peor, menos mal, pero ha sido una mierda pinchada en un palo. Así que solo queda mirar hacia arriba y adelante. Esperemos que la próxima órbita alrededor del sol (maomenó) sea mejor y que tenga mejores noticias. Así que gracias [...]

20 de febrero, 2010 14:22

19 de febrero, 2010

Paradise City

Talante, Talentos y Deditos

Y es por esto, niños, que siempre hay que mantener los pies en el suelo, ser humilde y no creerse un mesías elegido por Dios que nunca se equivoca. Este es el verdadero rostro de los que gobiernan imponiendo, nunca dialogando. Vergüenza de políticos y de dirigentes.

19 de febrero, 2010 07:52


Última actualización: 11 de marzo, 2010 23:01

Estilo tomado de Planet Jabber