ÍNDICE DE LA MEMORIA Índice de la memoria Parte I Memoria...2 Capítulo 1 Introducción...3 1.1 Situación económica del mercado de las Telecomunicaciones...3 1.2 La relevancia en la publicidad...3 1.3 La importancia de la escalabilidad y tolerancia a fallos...5 1.4 El estándar IP Multimedia Subsystem (IMS)...8 Capítulo 2 Estado del Arte... 11 2.1.1 LlamaGratis de Ethervoice... 11 2.1.1.1 Consideraciones Técnicas... 12 2.1.1.2 Conclusión... 13 2.1.2 VoodooVox... 13 2.1.2.1 Consideraciones Técnicas y Conclusión... 14 Capítulo 3 Tecnologías usadas... 15 3.1 Bases de Datos Relacionales... 15 3.1.1 Propiedades ACID... 15 3.1.1.1 Atomicity... 16 3.1.1.2 Consistency... 16 3.1.1.3 Isolation... 17 3.1.1.4 Durability... 18 3.1.2 MySQL... 18 3.1.2.1 MyISAM... 19 3.1.2.1.1 Características... 19 3.1.2.1.2 Conclusión... 20 3.1.2.2 InnoDB... 20 3.1.2.2.1 Características... 21 3.1.2.2.2 Conclusión... 22 I
ÍNDICE DE LA MEMORIA 3.1.3 PostgreSQL... 22 3.1.3.1 Características... 22 3.1.3.2 Conclusión... 23 3.2 Bases de Datos No-Relacionales... 23 3.2.1 Ventajas... 24 3.2.1.1 Escalabilidad Horizontal... 24 3.2.1.2 Sin esquema de datos... 27 3.2.1.3 Latencia... 32 3.2.1.4 Almacenamiento masivo de información y Data Mining... 33 3.2.1.5 Conclusión... 33 3.2.2 Tipos de bases de datos NoSQL... 34 3.2.2.1 Caches de memoria... 34 3.2.2.2 Almacenamiento Key-Value... 34 3.2.2.3 Bases de datos de Grafo... 34 3.2.2.4 Almacén de Documentos... 34 3.2.2.5 Bases de datos columnares... 35 3.2.3 Análisis de bases de datos NoSQL... 35 3.2.3.1 Cassandra... 36 3.2.3.1.1 Modelo de datos... 36 3.2.3.1.2 Escalabilidad... 37 3.2.3.1.3 Consistencia de datos... 38 3.2.3.1.4 Usuarios... 38 3.2.3.2 HBase... 39 3.2.3.2.1 Modelo de datos... 39 3.2.3.2.2 Escalabilidad... 39 3.2.3.2.3 Consistencia de datos... 40 3.2.3.2.4 Usuarios... 40 3.2.3.3 MongoDB... 40 3.2.3.3.1 Modelo de datos... 40 3.2.3.3.2 Escalabilidad... 41 3.2.3.3.3 Consistencia de datos... 42 3.2.3.3.4 Usuarios... 42 3.2.3.4 CouchDB... 43 3.2.3.4.1 Modelo de datos... 43 3.2.3.4.2 Escalabilidad... 44 3.2.3.4.3 Consistencia de datos... 45 3.2.3.5 Memcache... 45 II
ÍNDICE DE LA MEMORIA 3.2.3.5.1 Modelo de datos... 45 3.2.3.5.2 Escalabilidad... 45 3.2.3.5.3 Consistencia de datos... 45 3.2.3.5.4 Usuarios... 46 3.2.3.6 Redis... 46 3.2.3.7 Modelo de datos... 46 3.2.3.8 Escalabilidad... 47 3.2.3.9 Consistencia de datos... 47 3.2.3.10 Usuarios... 47 3.2.3.11 Tokyo Cabinet... 48 3.2.3.11.1 Modelo de datos... 48 3.2.3.11.2 Escalabilidad... 48 3.2.3.11.3 Consistencia de datos... 49 3.2.3.12 Riak... 49 3.2.3.12.1 Modelo de datos... 49 3.2.3.12.2 Escalabilidad... 49 3.2.3.12.3 Consistencia de datos... 50 3.2.3.13 Project Voldemort... 50 3.2.3.13.1 Modelo de datos... 50 3.2.3.13.2 Escalabilidad... 50 3.2.3.13.3 Consistencia de datos... 50 3.3 Proxy SIP... 51 3.4 SIP Media Aplication Server... 52 3.4.1 Servidores SIP Probados... 52 3.4.1.1 Asterisk... 52 3.4.1.2 FreeSWITCH... 53 3.4.1.3 Yate... 53 3.4.1.4 Callweaver... 53 3.4.2 Descripcion de las prueba de capacidad... 54 3.4.3 Objetivos... 54 3.4.4 Equipos y software usado... 59 3.4.5 Prueba de Carga Máxima... 62 3.4.6 Prueba de Carga de Aplicación... 62 3.4.7 Resultados... 63 3.4.7.1 Prueba de Carga Máxima... 63 3.4.7.1.1 Tabla de resultados de comparative de utilizacion de CPU... 63 III
ÍNDICE DE LA MEMORIA 3.4.7.1.2 Tabla de resultados de comparativa de Calidad subjetiva... 64 3.4.7.1.3 Gráfico de resultados de utilización de CPU... 65 3.4.7.1.4 Grafico de resultados de Calidad subjetiva de Llamada... 66 3.4.8 Conclusiones... 67 3.4.8.1 Prueba de Carga Máxima... 67 3.5 Web development framework... 67 3.5.1 Django... 68 3.5.2 Ruby on Rails... 68 3.5.3 Lift... 69 Capítulo 4 Alcance del Proyecto... 70 4.1 Objetivos... 70 4.1.1 Cumplimiento del estándar IMS para Aplication Servers... 70 4.1.1.1 Utilización del protocolo SIP para la recepción de llamadas... 70 4.1.1.2 Utilización de los CODECS G729A, G711 ULaw, G711 ALaw y GSM a través de RTP... 72 4.1.1.3 Utilización de RADIUS o DIAMETER para contabilizar la sesión... 72 4.1.1.4 Conexión por Ethernet... 72 4.1.1.5 Uso de la validación del HSS... 72 4.1.2 Escalabilidad y tolerancia a fallos... 73 4.1.3 Servicio de Publicidad contextual en llamadas... 73 4.2 Justificación... 74 4.3 Metodología... 75 Capítulo 5 Módulos... 77 5.1 Ad Ranking Engine... 81 5.1.1 Modelo Lógico del Ad Ranking Engine... 82 5.1.2 Modelo Físico del Ad Ranking Engine... 85 5.1.3 Diseño del sub-modulo Rank Sorter... 89 5.1.4 Clasificación de Prefijos... 92 5.1.5 Algoritmo de Ranking... 98 5.1.5.1 Ranking Tags... 98 5.1.5.2 Colocando Tags a Llamadas... 99 5.1.5.3 Consulta de Anuncios Disponibles... 100 5.1.5.4 Selección del anuncio a utilizar... 103 5.1.5.5 Procesamiento del anuncio... 103 IV
ÍNDICE DE LA MEMORIA 5.2 Ad Playback Interface... 103 5.2.1 Modelo Lógico de Ad Playback Interface... 103 5.2.1.1 Script AGI Python adwave.py... 105 5.2.2 Modelo Físico del Ad Playback Interface... 106 5.3 Storage Subsystem... 108 5.3.1 Librería Python para acceder a Cassandra... 108 5.3.2 Librería Python para acceder a Redis... 111 5.4 Management, Billing and Reporting... 112 5.4.1 Modelo Lógico del módulo MBR... 112 5.4.2 Modelo Físico del módulo MBR... 114 Capítulo 6 Resultados y análisis de rendimiento... 117 6.1 Análisis de Rendimiento... 117 6.1.1 Tabla de Resultados... 119 6.1.2 Gráfico de resultados... 120 6.1.3 Conclusiones... 121 Capítulo 7 Conclusiones y trabajo futuro... 122 7.1 Conclusiones... 122 7.2 Trabajo Futuro... 123 7.2.1 Data Mining... 123 7.2.2 Interfaz Administrativa... 124 7.2.3 Sistema de Gestión de Servidores Automático... 124 7.2.4 Sistema de aprovisionamiento de Servidores automático... 124 7.3 Problemática... 124 Capítulo 8 Bibliografía... 126 Capítulo 9 Anexos... 129 9.1 Como configurar correctamente el sistema operativo CentOS Linux 5.3 129 9.1.1 Configurar Aceso remoto usando Fabric... 129 9.1.2 Configurar Firewall... 129 9.1.3 Determinar si el CPU es de 64 bits... 129 9.1.4 Corregir problemas con la tarjeta ethernet de Dell... 130 9.1.5 Resolver problemas con clonación... 130 V
ÍNDICE DE LA MEMORIA 9.1.6 Preparar Backups del sistema operativo... 130 9.1.7 Acceder por ssh sin contraseña... 131 9.1.8 Recuperar contraseña root... 131 9.1.9 Actualizar NTP... 131 9.1.10 Benchmarking... 131 9.1.11 Configurar la red... 131 9.1.12 Añadir PAE (Phyisical Address Extension)... 132 9.1.13 Aumentar el limite de descriptores de archivos abiertos... 132 9.1.14 Aumentar el limite de puertos abiertos... 132 9.1.15 Monitoreo... 132 9.1.16 Configurar servidores de correo... 133 9.1.17 Configurar apt... 133 9.1.18 Instalar paquetes Basicos... 133 9.1.19 Instalar herramientas de monitoreo... 133 9.1.20 Instalar ODBC... 134 9.1.21 Modificar el kernel para VoIP... 134 9.2 Instalar PHP... 135 9.3 Instalar MySQL... 135 9.4 Instalar Asterisk 1.6 desde Codigo Fuente... 135 9.4.1 Configurar Asterisk... 137 9.4.1.1 Aumentar limite en RTP.conf... 138 9.4.1.2 Instalar codec G729 codec... 138 9.4.1.2.1 Nelahem... 138 9.4.1.2.2 Xeon 5400 Core 2 duo... 138 9.4.1.2.3 Xeon 5400 Core2 Dual Core 32 bit... 138 9.4.1.2.4 Comprobar que funciona... 138 9.4.2 Instalar Drivers de Sangoma Wanpipe... 138 9.4.2.1 Instalar el firmware mas reciente... 139 9.5 OpenSIPS... 139 9.5.1 Instalar desde Paquetes de distribucion... 140 9.5.2 Instalar OpenSIPS desde el código Fuente... 140 9.5.3 Configurar OpenSIPS... 141 9.5.4 Instalar OpenSIPS control web... 142 9.6 Instalando Java... 143 9.6.1 Instalando MySQL JDBC driver... 143 VI
ÍNDICE DE LA MEMORIA 9.7 Instalando Glassfish... 143 VII
ÍNDICE DE FIGURAS Índice de figuras Ilustración 1...9 Ilustración 2... 10 Ilustración 3... 31 Ilustración 4... 55 Ilustración 5... 56 Ilustración 6... 58 Ilustración 7... 60 Ilustración 8... 79 Ilustración 9... 80 Ilustración 10... 83 Ilustración 11... 86 Ilustración 12... 88 Ilustración 13... 91 Ilustración 14... 94 Ilustración 15... 97 Ilustración 16... 102 Ilustración 17... 104 Ilustración 18... 107 Ilustración 19... 113 Ilustración 20... 115 VIII
Índice de tablas Tabla 1... 64 Tabla 2... 64 Tabla 3... 65 Tabla 4... 66 Tabla 5... 109 Tabla 6... 109 Tabla 7... 110 Tabla 8... 111 Tabla 9... 119 Tabla 10... 120-1 -
Parte I MEMORIA - 2 -
Capítulo 1 INTRODUCCIÓN 1.1 SITUACIÓN ECONÓMICA DEL MERCADO DE LAS TELECOMUNICACIONES La telefonía está en proceso de comoditizacion [GAJJ10]. Al igual que la electricidad o el acceso a internet, las comunicaciones telefónicas dejaran de tener un valor intrínseco. En los últimos 10 años, el precio medio por minuto interprovincial en España ha bajado de 60 céntimos de euro el minuto a pagar una tarifa plana de 10 a 15 euros para poder llamar cualquier número de minutos. Las llamadas a y desde móviles también han sufrido una importante reducción, cayendo casi un 12% en un solo año, del 2008 al 2009. Además, cada vez se regulan y eliminan los nichos lucrativos como el roaming [EURO09]. En un mercado donde el producto vendido es un commodity hay que buscar fuentes alternas de financiación. Al igual que Google, que provee servicios de búsqueda gratuitamente (un servicio commodity ) pero se financia a través de los anuncios que muestran en sus páginas, las empresas de telefonía deben encontrar formas de conseguir ingresos adicionales fuera de su negocio principal. Actualmente las empresas de telefonía móvil están centradas en servicios de valor añadido, como internet, personalización, juegos, música [ECON10]. Una posible fuente de financiación es colocar anuncios en las llamadas telefónicas. 1.2 LA RELEVANCIA EN LA PUBLICIDAD La industria de la publicidad está sufriendo una revolución gracias a internet, y el cambio de modelo es debido a la relevancia de los anuncios [ECON06]. En la - 3 -
publicidad tradicional, los anuncios se mostraban a todos, asumiendo que un grandísimo porcentaje de los impactos publicitarios serian inútiles ya que no tendrían ningún interés para el que lo recibe. La eficacia de los anuncios por internet es mucho mayor, ya que los impactos son medibles, y hay cierta información de la persona que recibe el impacto que te permite mostrar anuncios que tengan más posibilidades de interesarle. Las empresas de telefonía tienen mucha información que permite personalizar los anuncios y de esta forma, hacer que los impactos sean muy valiosos para los anunciantes. De hecho la posibilidad de personalización y por tanto el valor de los anuncios es todavía mayor que la que tiene los anuncios por internet, incluyendo los de Google, ya que Google solo cuenta con el texto de las búsquedas que utilizas para emparejarlo con anuncios. Los operadores de telefonía tienen una cantidad inmensa de datos sobre los usuarios. Para hacer el análisis de dos datos que los operadores de telefonía tienen de sus usuarios y como afectarían estos a la relevancia de los anuncios mostrados, he dividido los datos en dos categorías: Los datos estáticos son aquellos que cambian poco a lo largo del tiempo. Edad, sexo, dirección donde vive, y destinos más llamados son algunos ejemplos de datos estáticos. La relevancia de los datos estáticos para mostrar un anuncio u otro es relativamente constante a lo largo del tiempo, con lo que se puede calcular de antemano. Los datos dinámicos es información efímera, que solamente es validad en el transcurso de una llamada particular. El ejemplo más claro de dato dinámico es el número al que se llama. Sabiendo el número al que se llama, se puede saber en qué país o ciudad se encuentra el destinatario. Otro dato dinámico es la posición en la que se encuentra la persona que llama. Esta posición se consigue triangulando las distintas antenas de telefonía móvil que han usado los clientes para hacer la llamada, o por geo-localización utilizando el GPS que tienen la mayoría de los teléfonos móviles. - 4 -
1.3 LA IMPORTANCIA DE LA ESCALABILIDAD Y TOLERANCIA A FALLOS La escalabilidad es la propiedad de un sistema o proceso que indica su habilidad de procesar volúmenes crecientes de trabajo de forma correcta. La escalabilidad de un sistema no es un valor absoluto, un sistema será escalable si cumple con los requisitos necesarios de rendimiento en cada caso. Estos requisitos dependen del sistema en cuestión pero pueden estar relacionados al número de usuarios que soporta el servicio o las transacciones por segundo. Para servicios de telefonía la escalabilidad se define en términos de llamadas simultáneas. Los equipos de telefonía definen el número máximo de llamadas simultáneas que son capaces de procesar cumpliendo con la calidad de servicio mínima requerida. La calidad de servicio (expresada como QoS Quality of Service [ITU_08]) se mide principalmente en el nivel tolerable del jitter, latencia y calidad subjetiva de voz. Un sistema de telefonía es escalable si puede fácilmente incrementar el número de llamadas por segundo que es capaz de manejar manteniendo el jitter y la latencia bajos y con una calidad de voz aceptable (comúnmente referido como Toll quality (ITU_92)). Los métodos para conseguir escalabilidad en general se puede dividir en dos grandes categorías: escalabilidad horizontal y escalabilidad vertical. La escalabilidad vertical se basa en añadir más potencia de cálculo a una misma máquina. Se consigue añadiendo más procesadores a la máquina, más discos duros o discos duros más rápidos al arraya RAID o añadiendo más memoria al servidor. Es necesario que la aplicación pueda tomar ventaja de este tipo de escalabilidad, por ejemplo las aplicaciones deben ser multihilo para poder utilizar más de un procesador. Este tipo de escalabilidad suele ser fácil de implementar porque solamente requiere comprar equipos más potentes, pero al mismo tiempo puede ser más costosa, ya que el coste de los equipos aumenta de forma exponencial mientras que su rendimiento aumenta de forma lineal. - 5 -
La escalabilidad horizontal se basa en distribuir la aplicación entre varias máquinas. Introduce muchísimas complejidades al diseño software, ya que hay que tomar en cuenta todas las dificultades de los sistemas distribuidos, donde los procesos no tienen acceso a la misma memoria compartida. De esta forma la única manera que los procesos se pueden comunicar es a través de mensajes. La tolerancia a fallos es la propiedad de un sistema de continuar funcionando cuando uno de sus componentes falla. La tolerancia a fallos se suele obtener con redundancia, teniendo componentes que no son utilizados hasta que falla el componente primario. Esta fórmula se le llama cold backup o cold standby porque el componente que esta de respaldo solamente funciona cuando deja de funcionar el sistema primario. También existe el método de tolerancia a fallos de llamado hot standby donde el componente redundante está activamente recibiendo su parte correspondiente del trabajo del sistema, y si falla un componente el trabajo se distribuye entre los demás sistemas. Ambos métodos de redundancia se pueden hacer a nivel de componentes (típicamente referido como redundancia hardware ) o a nivel de sistema, referido como redundancia software. Un array de discos duros en RAID 1 es un ejemplo de hot standby de redundancia hardware, donde si falla un disco duro, el sistema puede seguir funcionando debido a que otro disco duro del array tiene su misma información. La telefonía es un servicio crítico, donde no se toleran fallos de servicio [MUND03]. Los proveedores de equipos de telefonía tienen un requisito mínimo de Five nine s availability (disponibilidad de cinco nueves). Esto quiere decir que sus equipos estarán disponibles a dar servicio el 99.99999% del tiempo. Este nivel de disponibilidad y tolerancia a fallos actualmente obtiene a través del hardware. Los equipos de vendedores de centrales telefónicas tradicionales como Lucent (antiguamente AT&T Equipment Division), Alcatel, Ericsson, Siemens o Cisco utilizan hardware extremadamente especializado y redundante en todos los niveles. Este hardware hecho a medida es extremadamente caro. Los precios mínimos para una central de telefonía básica de poca capacidad rondan los varios millones de dólares. Además de los costes de adquisición, hay que tomar en cuenta los costes de mantenimiento, ya que al ser hardware tan específico - 6 -
solamente técnicos de la casa matriz pueden hacer el mantenimiento necesario, o cambiar las piezas que inevitablemente se estropean. El coste de los equipos necesarios para dar servicios de telefonía es una barrera de entrada importante que hay en el mercado de las telecomunicaciones. Sin embargo, hardware de diseño específico no es la única forma de obtener un diseño redundante. Los avances en la arquitectura de sistemas y diseños de software [HANM07] han hecho surgir muchas empresas y proyectos que utilizan gran cantidad de equipos normales y todo el sistema de redundancia se hace en el software. Una de las empresas más conocidas que utiliza este sistema de escalabilidad y redundancia es Google. Google reparte las consultas que recibe entre muchas maquinas, y cualquiera de ellas puede fallar sin que eso afecte la calidad del servicio. Simplemente reduciría ligeramente la capacidad máxima del sistema. Mientras siempre haya capacidad sobrante, este sistema consigue unos niveles de escalabilidad y redundancia mayor que cualquier sistema basado en hardware o escalabilidad vertical [BARR09]. Este sistema de escalabilidad basado en clústeres de máquinas normales, varias ventajas sobre la escalabilidad basada en hardware especifico. La capacidad de crecimiento es prácticamente ilimitada, y la inversión en hardware es muy baja. Gran parte del software utilizado para crear estos clústeres es software libre de código abierto, con lo que también hay un ahorro en licencias de software. Sin embargo, con este tipo de sistemas, siempre habrá que crear software específico, ya que todavía no está suficientemente extendida la creación de este tipo de sistemas y hay grandes lagunas en el software disponible. Aunque la arquitectura del sistema es conocida y expuesta en proyectos disponibles al público como The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines de los trabajadores de Google Luis André Barroso y Urs Hölzle [BARR09], la inmensa cantidad de máquinas que se llegan a usar. La conocida web social Facebook ha declarado que añade maquinas a nivel de racks completos (gigaom, 2010). La inmensa cantidad de máquinas que se utilizan en este tipo de sistemas crea problemas en algunas de las cosas más sencillas, como - 7 -
gestión de inventario o recolección de logs, que se convierten en problemas debido simplemente al gran volumen de información que procesan. Aunque Facebook y otras grandes empresas del sector han puesto disponibles al público varios proyectos de código abierto que han sido desarrollado para solucionar algunos de estos problemas (véase Scribe, plataforma para recolección de logs masivos, o Cassandra, sistema de gestión de datos escalable), todavía hay muchas requisitos en las que hay que programar o desarrollar soluciones propias, ya que no hay solución en el mercado. 1.4 EL ESTÁNDAR IP MULTIMEDIA SUBSYSTEM (IMS) El estándar IP Multimedia Subsystem (abreviado IMS) es un estándar diseñado por el 3rd Generation Partnership Project (3GPP) para la convergencia de servicios móviles. El 3GPP es una organización creada para unificar los estándares de telefonía móvil 3G, pero que ha evolucionado y en estos momentos crea los reportes y especificaciones técnicas para las futuras tecnologías de telefonía móvil. IMS es su estándar que gestiona la arquitectura global de comunicaciones de un operador de telefonía móvil, utilice este GSM, 3G, LTE o cualquier otra tecnología inalámbrica [BERT07]. - 8 -
El estándar IMS tiene la figura de un Aplication Server 1 (AS) en la red (ver Ilustración 1). El AS permite introducir cualquier servicio en la red de telecomunicaciones del operador, y además, el estándar especifica cómo debe comunicarse con el resto del sistema. Por lo tanto, especifica como enviar la información de sesión, como recibir, procesar y devolver las llamadas, que protocolos usar para la señalización y para la voz, y a que información tendrá acceso el AS para poder proveer sus servicios. Ilustración 1 1 Los Aplication Servers son los encargados de proporcionar servicios de valor añadido a las redes de telefonía regidas por el estándar IMS. Hay más información disponible sobre los Aplication Servers en la sección SIP Media Aplication Server en la página 52. - 9 -
El objetivo de este proyecto es crear un Aplication Server compatible con IMS que permita introducir publicidad en llamadas telefónicas. Esta publicidad debe ser contextual, y debe ser relevante a la información estática y dinámica que se tenga del cliente que hace la llamada. El Aplication Server debe tener una arquitectura escalable y tolerante a fallos, como ya se ha expuesto. En la figura Ilustración 2 se puede observar donde encaja AdWave, como servidor de aplicaciones IMS en un entorno IMS simplificado. Ilustración 2-10 -
Capítulo 2 ESTADO DEL ARTE Actualmente existen pocos proyectos conocidos al público que funcionan de forma parecida a AdWave. Debido a esta situación, se ha optado por buscar los proyectos más parecidos. 2.1.1 LLAMAGRATIS DE ETHERVOICE LlamaGratis de Ethervoice (www.ethervoice.net) es una aplicación de Facebook (www.facebook.com) que permite realizar llamadas desde Facebook de forma gratuita, a cambio de ver un anuncio video antes de realizar la llamada [ETHE08]. LlamaGratis permite realizar llamadas desde la página web. El cliente SIP es un applet de Java [ETHE09] embebido en la aplicación de Facebook. Esto implica que los usuarios deben tener Java instalado para poder usar la aplicación. Generalmente esto no es un problema ya que la mayoría de los usuarios disponen de Java en su ordenador. LlamaGratis tiene varias ventajas cuando es comparado con AdWave Los impactos publicitarios de LlamaGratis incluyen video y audio, mientras que AdWave solamente es capaz de mostrar anuncios de audio. La llamada no se realiza hasta que no se ha visto el video completo en Facebook, garantizando de esta manera el impacto. Los anuncios que incluyen un video suelen ser más caros y más eficaces que los anuncios que solamente incluyen audio, o que únicamente utilizan imágenes estáticas. Al ser una aplicación de Facebook, LlamaGratis tiene acceso a todos los datos personales que el usuario tiene en su perfil, hasta aquellos que ha marcado como privados. Debido a que ha aceptado la aplicación, esta tendrá acceso a toda la información que tiene en Facebook. Típicamente la información que los usuarios tienen en Facebook es verídica (hay un porcentaje muy bajo de usuarios falsos o spam debido al propio mecanismo de Facebook de control. - 11 -
La información contenida en el perfil de Facebook es extremadamente valiosa para los anunciantes y permite hacer que los impactos publicitarios ofrecidos por LlamaGratis sean mucho más apropiados, segmentados y relevantes. LlamaGratis tiene una serie de limitaciones cuando es comparado a AdWave. LlamaGratis funciona únicamente desde el ordenador, ya que requiere una conexión a internet y la capacidad de ejecutar applets Java. AdWave esta diseñado para ser utilizado por un proveedor de telefonía, de esta forma funciona desde cualquier teléfono fijo o móvil, siempre que el operador tenga instalado el servicio AdWave. Aunque el impacto de publicidad por video es mas valioso, los usuarios están acostumbrados a hacer otras cosas en internet mientras pasan los anuncios, ya sea abrir otra pagina de internet y leer el correo, o abrir otra pestaña para visualizar el estado en Facebook. 2.1.1.1 Consideraciones Técnicas Es interesante el uso de un applet java para proporcionar un teléfono SIP a través de la página web. Es muy probable que se haya utilizado jain-sip para programar el applet. Jain-sip es un proyecto open source que proporciona una API de alto nivel para desarrolladores SIP, Creado por Sun Microsystems y disponible en https://jain-sip.dev.java.net/. Actualmente requiere algo de trabajo para poder llegar al nivel de acabado que tiene el applet de LlamaGratis. Debido a que no se manipula la llamada de ninguna manera, el resto del sistema de telefonía es estándar. El sistema de publicidad también es básico, permitiendo segmentar la publicidad por los datos que tiene el usuario en Facebook, pero no permite segmentar la publicidad, es decir solamente acepta una segmentación estatica y no dinámica - 12 -
2.1.1.2 Conclusión LlamaGratis es un producto que ofrece llamadas gratis a usuarios a cambio de mostrarles publicidad, sin embargo no ofrece introducir publicidad en el audio de la llamada telefónica que es el punto fuerte de AdWave. LlamaGratis es un producto diferente con un enfoque diferente que AdWave y por tanto no están en competencia directa. 2.1.2 VOODOOVOX VoodooVox es un sistema que inserta publicidad en las llamadas mientras estas están timbrando. Inserta la publicidad de una forma muy parecida a AdWave. Utiliza un sistema de selección contextual de la publicidad, que muestra publicidad relativa al destino al que se está llamando, al igual que las variables dinámicas de AdWave. Sin embargo, no toma en consideración el número de origen de la persona que llama, ni el resto de la información que podría tener el operador de telefonía sobre el usuario que realiza la llamada. VoodooVox actualmente es utilizado por el operador de llamadas telefónicas IDT. IDT firmó un contrato con VoodooVox para que VoodooVox proporcionase el servicio de insertar publicidad en las llamadas telefónicas de IDT en el año 2007. En el año 2008, VoodooVox tuvo unas ventas de 4 millones de dólares, y fue utilizado para el 30% de las tarjetas prepago vendidas por IDT [CNN_08]. Debido a que cada tarjeta típicamente se utiliza varias veces, el número de llamadas cursadas por VoodooVox por IDT probablemente sea cercano al 5%. VoodooVox asevera que actualmente cursa cerca de 300 millones de llamadas al mes, una cifra muy creíble debido al enorme volumen de llamadas que se manejan en el sector de la telefonía y que cursa IDT en particular. - 13 -
2.1.2.1 Consideraciones Técnicas y Conclusión Aunque la mayoría de las especificaciones de VoodooVox no están disponibles al público, a través de la página web y poniéndose en contacto con los representantes comerciales se puede recopilar gran cantidad de información sobre el producto. VoodooVox es una solución muy completa, que incluye un portal web para gestionar los anuncios. Tiene una visión similar del mercado que AdWave, aunque con una diferencia. Mientras AdWave ha sido enfocado para venderse a proveedores de telefonía para que ellos lo integren y modifiquen, VoodooVox se ha diseñado como un servicio completo que proporciona el servicio de publicidad desde fuera del sistema telefónico del operador. No es compatible con IMS, y por tanto habrá operadores de telefonía que no puedan integrar el servicio a sus plataformas. Proporcionar el servicio de manera externa acarrea otros costes y consideraciones de seguridad Sin embargo, VoodooVox es una solución probada y exitosa, y su éxito prueba que el modelo de negocio de vender publicidad a través de las llamadas telefónicas es factible. - 14 -
Capítulo 3 TECNOLOGÍAS USADAS Para desarrollar el proyecto, he hecho gran uso de proyectos libres de código abierto. Como parte del mismo, se han analizado a un gran número de proyectos de distintas categorías. Este análisis ha sido parte investigación, parte uso y parte benchmarking que permita descubrir las cualidades y utilidad para el proyecto AdWave. En este capitulo se describe el estudio de las tecnologías y las tecnologías utilizxadas en el proyecto. Se han clasificado los proyectos probados en varias categorías: 3.1 BASES DE DATOS RELACIONALES Las bases de datos relacionales son la forma estándar de guardar los datos de la aplicación. Las bases de datos relacionales son muy conocidas y extendidas en el mercado. SQL (Structured Query Language) es un lenguaje establecido, en el que mucha gente sabe trabajar. Hay muchísima información disponible sobre creación de bases de datos, organización de esquemas de datos, normalización, creación de índices y optimización de instalaciones. Las bases de datos relacionales permiten separar la capa de datos de la capa de aplicación. Al cumplir el estándar SQL son intercambiables entre sí (en su mayor parte) y permiten un acceso rápido y fiable a los datos. 3.1.1 PROPIEDADES ACID La mayoría de las bases de datos cumplen con las propiedades ACID (atomicity, consistency, isolation, durability). Estas propiedades garantizan un comportamiento de la base de datos. Estas propiedades son, de hecho, uno de los - 15 -
mayores argumentos a favor de usar una base de datos, ya que aíslan al diseñador del sistema de la complejidad de conseguir que su aplicación cumpla las propiedades ACID, algo que no es sencillo. Una breve descripción de las cuatro propiedades ACID: 3.1.1.1 Atomicity Atomicity garantiza que las transacciones (sean una consulta, o grupos de sentencias SQL) no se puedan subdividir, es decir, se ejecutaran enteramente, o no se ejecutaran. Esto implica que en caso de fallo de hardware, fallo de la base de datos, o fallo de la aplicación, se actualizarán todos los datos o ninguno. Esto impide que la base de datos se corrompa o pierda el sincronismo lógico entre los datos. Como ejemplo, en una aplicación contable se puede ejecutar una transacción que recibe un pago, donde se registra el cobro, y se resta del saldo deudor del cliente. Ambas acciones son una transacción atómica, si se registra el pago, se debería modificar el saldo, y si por alguna razón falla cualquiera de las dos acciones, no se debería aplicar ninguna de las dos, ya que si solamente se incrementa el saldo, este ya no cuadrara con la lista de registros de pagos. Si solamente se registra el pago, el saldo no será real. 3.1.1.2 Consistency Consistency garantiza que la base de datos siempre estará en un estado consistente. De hecho, garantiza que cada transacción lleve a la base de datos de un estado consistente a otro estado consistente. En este caso, consistencia se refiere a la consistencia interna de relación entre tablas, y la consistencia en los datos almacenados. La propiedad de consistencia no permitiría guardar un entero en un campo float, o no permitiría borrar una fila que es referenciada por otra. Esta última forma de consistencia se le llama integridad referencial, y hay tres formas de resolver los conflictos de integridad referencial. Se puede anular la transacción, se puede eliminar todos los registros que referencian el registro a eliminar, o se pueden poner a nulos todas las referencias al registro a eliminar. La mayoría de las bases de datos te permiten elegir en cada caso que acción tomar. - 16 -