Quarta-feira, 16 de Junho de 2010
Contexto

Um dos principais objectivos deste trabalho é reproduzir publicidade ao utilizador baseado em contexto.

A nossa aplicação contém uma lista de empresas, com várias palavras chave. Cada empresa pode ter várias publicidades, tendo a possibilidade de escolha de horário de preferencia para o seu anuncio. Por exemplo, anuncio de uma pizzaria, têm mais impacto nas horas de almoço e jantar. 

Para seleccionar a publicidade ao utilizador foram considerados as seguintes informações:

De modo a fazer-se uma selecção aleatória, considerou-se os factores acima descrito, tendo em consideração em primeiro lugar uma lista de publicidades ordenadas por distância, apenas para a hora desejada, incluindo-se também publicidades relacionadas com SMS anteriores. Baseado nesta lista efectou-se uma selecção aleatória, permitindo assim que o utilizador não ouça sempre a mesma publicidade.

 Para aceder à distância do utilizador, realizou-se um pedido por webservice ao serviço de geolocalização (ServiceLocation) [1, 2] utilizando o identificador do telefone (Conseguido através do parsing do endereço SIP, exemplo, 915555555@open-ims.test). Desta forma, sabemos o numero de telefone do utilizador, tendo acesso à sua localização.

Por fim, para fornecer a publicidade ao Call Centerdisponibilizou-se através de um pedido HTTP, o anuncio, sendo parametro obrigatório o endereço SIP do utilizador.

[1] - http://smartad.blogs.ua.sapo.pt/1480.html

[2] - http://smartad.blogs.ua.sapo.pt/1160.html




Terça-feira, 15 de Junho de 2010
CallCenter

Como explicado no primeiro post deste blogue, um dos objectivos deste projecto é, ao iniciar uma chamada, reproduzir publicidade enquanto se espera que o destinatário da chamada atenda. Isto foi alterado, na medida em que, ao ser iniciada uma chamada é reproduzida publicidade, mas só quando a publicidade acaba é que a chamada é redireccionada para o destinatário.


Para implementar o CallCenter foi usado o SailFin [1] para interagir com as mensagens SIP [2]. O OpenIMS teve também de ser configurado para comunicar com o SailFin [4].

Para exemplificar o funcionamento do CallCenter suponhamos que a Alice quer ligar ao Bob. O SIP Client da Alice envia um Invite para o Bob que é redireccionado pelo OpenIMS para o SailFin. No SailFin, este Invite, é processado por um Sip Servlet que começa por contactar, através de um Web Service, a aplicação principal para saber qual a publicidade a reproduzir. Depois, é enviado uma SIP Message com o nome da publicidade para o MediaGateway seguida do Invite da Alice, com o destino alterado para o endereço SIP do MediaGateway. Ao receber este Invite, o MediaGateway, estabelece uma chamada com a Alice onde é reproduzida a publicidade. Quando a publicidade acaba, o MediaGateway envia um Bye. Este é apanhado pelo SailFin que envia um Refer [3] à Alice para transferir a chamada actualmente estabelecida com o MediaGateway para o Bob. Ao receber este Refer, a Alice envia um novo Invite para o Bob. A partir deste momento, segue-se um fluxo típico SIP, onde o Bob aceita, ou não, a chamada.

 

[1] SailFin

[2] RFC 3261

[3] RFC 3515

[4] http://ictbackyard.com/archives/tag/openims



Quinta-feira, 3 de Junho de 2010
Ligação entre Sofia-Sip cli e OpenIMS

O Sofia-Sip cli é um cliente de Sip IMS desenvolvido através das bibliotecas Sofia-Sip. Como não possui interface gráfica e a dimensão do código-fonte não é excessiva, torna-o o candidato ideal para desenvolver um MediaGateway.


Existe no entanto algumas questões quanto a ligação com o Open IMS:



  1. O método de autenticação por omissão no OpenIMS é AKAv1-MD5, é necessário alterar o ficheiro scscf.cfg para utilizar MD5.

  2. O Sofia-Sip não possui nenhuma tag P-Visited-Network-ID, que é requerida pelo OpenIMS. No entanto é possível construir esta tag manualmente e envia-lo no registo do Sofia-Sip.

  3. O username utilizado pelo OpenIMS é do tipo bob@open-ims.test, por outro lado o username utilizado pelo SofiaSip cli é apenas bob, na fase de autenticação é necessário indicar o username completo.


Corrigindo este pequenos erros no Sofia-Sip cli é possível liga-lo correctamente ao OpenIMS.


Outro aspecto relevante, nenhuma das stack multimedia fornecidas pelo Sofia-Sip cli parecem funcionar correctamente. É aconselhavel criar uma pipeline com o gstreamer onde se insere um ficheiro de áudio/vídeo e são produzidos pacotes rpt para um determinado destino.


 


Estou de momento a criar a pipeline que lê um ficheiro do tipo mp3 e envia o stream para o cliente IMS.




Quarta-feira, 2 de Junho de 2010
Integração

De modo a testar a parte do projecto relativa à procura de empresas através de sms, foi feito um teste de integração em que se juntou o daemon de geolocalização, o servidor de geolocalização, o sms gateway e ainda o servidor SMS Center.


O daemon de geolocalização registou as suas coordenadas actuais junto do servidor de geolocalização, e mais tarde foi enviada uma sms com a palavra "Restaurante" para o número de telemovel associado ao sms Gateway. O sms Gateway ao receber a mensagem evocou o servidor SMS Center, e este após obter a localização do cliente, realizou uma consulta usando o serviço de mapas do google para encontrar restaurantes perto do local onde o utilizador se encontrava.


O teste foi bem sucedido, sendo que em resposta à sms enviada, foi recebida uma sms contendo alguns dos restaurantes perto do local onde nos encontrávamos, tal como se pode observar pela imagem seguinte.



 


Alguns dos melhoramentos a fazer é corrigir o problema dos caracteres, assim como formatar os resultados de uma forma melhor.




Terça-feira, 18 de Maio de 2010
Servidor SMS Center

O servidor SMSC (SMS Center) tem como objectivo responder aos SMSs recebidos pelo Kannel. Por exemplo, uma pessoa ao enviar um SMS com a palavra “Restaurante” recebe um SMS com uma lista de restaurantes próximos desta.


Sempre que o Kannel recebe um SMS, envia um pedido HTTP GET a este servidor, com o conteúdo da mensagem e o número de telefone do remetente. A resposta a este pedido é enviada automaticamente, por SMS, pelo Kannel.


O servidor SMSC, ao receber o pedido GET, contacta primeiro o servidor de geolocalização para obter as coordenadas (latitude e longitude), do telemóvel que enviou o SMS, com base no número de telefone deste. De seguida, é feita uma pesquisa na nossa base de dados de empresas, tendo em conta o conteúdo da mensagem e a proximidade geográfica. Caso esta pesquisa devolva poucos resultados, é feita uma pesquisa no Google Local Search, para completar a primeira pesquisa. No final, os resultados da pesquisa são devolvidos na resposta ao pedido.


 




MediaGateway

Um componente necessário para substituir o sinal de espera por publicidade sonora é o MediaGateway. Neste caso esta a ser construido a partir do sofia-sip cli, que por sua vez acenta sobre as bibliotecas sofia-sip.


De forma simplificada trata-se de um sip client que aceita qualquer chamada e envia um stream de audio predefinido pelo sistema. O stream de audio sera gerado pelo GStreamer.


O principal problemas do sofia-sip cli é a sua idade, necessita de várias correcções no código apenas para se connectar correctamente ao OpenIMS. Felizmente isso ja funciona correctamente, falta conseguir enviar o strem de audio.


 





Quarta-feira, 5 de Maio de 2010
Servidor: Geo-localização

 Uma vez conseguida a solução do dispositivo móvel que localiza o utilizador foi necessário criar um servidor que guarde a localização de todos os utilizadores de forma persistente.


A arquitectura global do sistema de geo-localização (representada na figura abaixo) é a seguinte: O dispositivo movel envia as coordenadas da sua localização, juntamente com o seu IMEI, através do protocolo XMPP. Do lado do servidor existe outro cliente XMPP que recebe as mensagens e processa-as, guardando na base de dados. Adicionalmente fornece serviços para terceiras aplicações consultarem a localização de utilizadores através do numero de telemóvel. Note que foi criado também um simulador manual de um HSS (Home Subscriber Server), para fazer o mapeamento entre o IMEI e o numero de telefone.


 


 



 


Posto o problema foi necessário identificar um conjunto de tecnologias que os permitissem implementar. A biblioteca utilizada para o cliente XMPP foi novamente a Smack [1]. Foram estudadas soluções para disponiblizar a localização dos utilizadores a terceiras aplicações, optando-se pela criação de Webservices, utilizando o J2EE. Para guardar a localização dos utilizadores foi utilizado uma base de dados derby, usando o JPA.


Uma dificuldade encontrada, foi a seguinte: como colocar um cliente XMPP a correr permanentemente num projecto que é instalado no Glassfish? A solução passou pela utilização de Enterprise Beans, criando um Singleton especificando para ele correr logo aquando é feita a instalação ( anotações importantes do EnterpriseBeans: @Singleton, @Startup, @PostConstruct)


Após estes e outros problemas com persistência e algumas versões do Glasshfish/J2EE o servidor de geo-localização encontra-se disponivel no nosso repositório, bem como o daemon Android.


 



[1] - www.igniterealtime.org/projects/smack/




Android: Daemon de geo-localização

Um requisito necessário para o funcionamento do SmartAd é saber a localização dos utilizadores num dado momento. Num cenário académico, não temos acesso a essas informações, e portanto o objectivo foi desenvolver uma aplicação que enviasse para um servidor a localização do utilizador. Esta aplicação foi desenvolvida para o sistema operativo Android.

Tomada a primeira decisão, foi necessário identificar o método de comunicação entre o dispositivo móvel e o servidor. A solução utilizada foi o Jabber, protocolo XMPP, pois através do mecanismo publish/subscriber permite processar as mensagens sempre que um utilizador muda de localização. Adicionalmente é um protocolo orientado a texto, e as mensagens trocadas são XML, sendo bastante fácil extender. A biblioteca utilizada para comunicação via XMPP foi a Smack [1] 

 

A primeira dificuldade, foi encontrar a API no Android que permitisse notificar a aplicação sempre que o utilizador mudasse de localização. O Android têm esse suporte ao nivel do sistema operativo, e têm também uma API de alto nível, event-driven, que dispara sempre que o utilizador se move num determinado raio de acção (configuravel) [2] .  

O segundo passo foi fazer a conexão ao servidor Jabber (gmail foi o escolhido). Definiu-se então o tipo de mensagens enviadas pelo daemon para o servidor identificando o telemóvel e a sua localização. Segue-se a mensagem, em formato XML:

 

<geo>

<location>

<latitude> LATITUDE_VALUE </latitude>

<longitude> LONGITUDE_VALUE </longitude>

</location>

<IMEI>IMEI_VALUE</IMEI>

</geo>  

 

Por fim todo este serviço corre como um serviço background, conseguido à custa da extensão da classe Service da API do Android. Como auxilio a esta tarefa foi utilizado um post num blog em [3].

Segue-se a foto da aplicação a titulo ilustrativo: 

 

[1] - www.igniterealtime.org/projects/smack/

[2] - http://developer.android.com/reference/android/location/LocationListener.html

[3] - http://mylifewithandroid.blogspot.com/2008/02/double-life-of-service.html




Terça-feira, 4 de Maio de 2010
SMS Gateway

 

Para SMS Center foi escolhido o software Kannel, que permite o envio/recepção de mensagens, que irá ser necessário para o serviço de procura de empresas.

Um dos aspectos positivos do Kannel é que este permite enviar as mensagens mesmo por GSM, recorrendo a um telemovel ou uma placa 3G (usando comandos AT).

Inicialmente tentou-se usar um Nokia N80 em conjunto com o kannel para o envio/recepção de SMS, no entanto este modelo, assim como restantes Nokia SERIES 60 V3, não suportam os comandos AT para recepção de mensagens, e assim sendo apenas foi possível proceder ao envio de mensagens. Foram ainda tentados outros telemóveis, mas sem sucesso pois também não suportavam estes comandos, excepto o Nokia 8310, pois como é um telemovel mais antigo ainda disponha destes comandos, o problema é que a ligação série tinha de ser feita por infravermelhos.

Finalmente recorreu-se ao uso de uma placa 3G da Vodafone (Huawei K3565), que permite tanto o envio como recepção de SMS.

 

Para correr o Kannel basta executar o bearerbox (core do gateway) e o smsbox, sendo que é através do smsbox que se enviam as mensagens.

 

Após ter o Kannel a correr, o envido de mensagens é simples, bastando aceder ao endereço

http://smsbox.host.name:13013/cgi-bin/sendsms?
username=foo&password=bar&to=0123456&text=Hello+world

e passando como parametros o username e password (de acordo com o que se encontra nos ficheiros de configuração), o destinatário, e a mensagem a enviar.

 

O processo de recepção de mensagens também é simples, bastando indicar no ficheiro de configuração qual o URL a aceder aquando da recepção de uma SMS, podendo então ser passada a mensagem recebida, assim como o nº de telefone do remetente. O Kannel disponibiliza ainda um mecanismo de filtragem das SMS recebidas, sendo possível enviar a mensagem para um serviço diferente dependendo da palavra inicial enviada na SMS, ou do nº do remetente, mas para o nosso caso isto não foi utilizado.

 

Durante a configuração do Kannel (já usando a placa 3G) surgiu o problema de as mensagens estarem a ser lidas pelo bearerbox, mas estas ficavam em queue e não eram processadas, sendo que aparecia na consola do bearerbox o seguinte warning: "smsbox_list empty!". Para resolver este problema basta comentar a linha smsbox-id = "..." no grupo smsbox.




Aspectos Técnicos

O nosso projecto consiste em diferentes módulos, tal como demonstrado na figura seguinte. Além da aplicação principal irá existir um módulo de geolocalização, que irá ser responsável por guardar a localização actual dos utilizadores, o módulo SMS Center para o envio/recepção de mensagens, o Media Gateway onde irão estar armazenados os anuncios publicitários a passar, e o CallCenter, que irá ser responsável pelo controlo da chamada, de modo a introduzir o anuncio. Para além destes módulos irá ser usado o serviço Google Maps para se obter empresas numa dada localização.

 

Nota: O serviço de geolocalização terá de ser implementado uma vez que não temos acesso à localização dos utilizadores, no entanto, em cenários reais poderia ser obtida a localização dos utilizadores apenas recorrendo à informação mantida pelas operadores.

 

Ao inserir um novo anuncio na nossa aplicação terá de ser especificado um conjunto de regras (ainda não definidas) de modo a poder escolher quais os melhores utilizadores alvo dessa publicidade.

 

 




.mais sobre mim
.pesquisar neste blog
 
.Junho 2010
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3
4
5

6
7
8
9
10
11
12

13
14
17
18
19

20
21
22
23
24
25
26

27
28
29
30


.posts recentes

. Contexto

. CallCenter

. Ligação entre Sofia-Sip c...

. Integração

. Servidor SMS Center

. MediaGateway

. Servidor: Geo-localização

. Android: Daemon de geo-lo...

. SMS Gateway

. Aspectos Técnicos

.arquivos

. Junho 2010

. Maio 2010

.tags

. todas as tags

.participar

. participe neste blog

blogs SAPO
.subscrever feeds