Here is a link – http://bit.ly/5OprRc – to my recent presentation on the work – A SIP-based Hybrid Architecture for HTTP Session Mobility. I began the presentation with a definition of Rich Internet Applications (RIAs) and how richer they can be. Thereafter, I presented my current work and how it is different from my previous work. Towards the end of the presentation, I showed some interesting results on the performance of the proxy (the Mobicents Converged Application Server). In addition, I compared my work with the Google Wave like I did in one of my previous post, and finally mentioned further tests I would be carrying out in the next couple of weeks.
Archive for Technologies (Mobicents, Mozilla, e.t.c.)
Projects Videos
I was thinking that it would be a great idea to make available videos of my projects. Below are two videos; the first video is an interaction between two instances of the Mozilla firefox, while the second video shows how the proxy functions. Some of the things demonstrated here are Web session transfer blocking and session handoff between two browsers. The proxy keeps log of SIP INVITE and SIP MESSAGE requests and actions taken on them based on user’s settings.
The TransferHTTP Clients Interaction (15MB)
The TransferHTTP Proxy (2.8MB)
The TransferHTTP Proxy Interface: Web Session Mobility Tracking and Pick-up
A lot of work has been done to implement the proxy for the proposed hybrid-based architectural scheme for HTTP Session Mobility. I blogged about the proxy some weeks ago. Here are the blog posts on the proxy [1, 2]. I referred to the services the proxy offers as control services. The services include Web forwarding and Web blocking. Today, I am pleased to introduce the proxy User Interface (UI). Below is a screenshot of the proxy UI.
The TransferHTTP Proxy Interface
The TransferHTTP proxy interface shows the SIP URIs of two Web browsers interacting with each other. In addition, It indicates the SIP Method in use, the time of the interaction, the status or action taken by the proxy and the referred URL.The interaction refers to a content sharing or session handoff between any two Web browsers. It could also be a multimedia session between the two Web browsers. The referred URL is the Web address the initiator of the content sharing or session handoff wants the other person to visit. The status or action taken by the proxy could be forbidden(i.e. blocked) or proxied (i.e. sent). When the status is “proxied,” it means that a message is sent to the intended destination as specified by the initiator or a message is forwarded to another Personal Computer (PC) as specified by the intended recipient.
Currently, the proxy blocks requests from sip:blocked-sender@127.0.0.1 and sip:blocked-sender@testdomain.com. On the other hand, it forwards requests meant for sip:receiver@127.0.0.1/sip:receiver@testdomain.com to sip:forward-receiver@127.0.0.1/sip:forward-receiver@testdomain.com. All other requests are proxied to their intended destinations. Requests, here, refer to SIP MESSAGE and SIP INVITE methods from a Web browser that has the TransferHTTP extension installed.While content sharing and session handoff in the extension use the SIP MESSAGE method to transfer session, make a call in the extension uses the SIP INVITE method to set up a multimedia session.
The Web address of the proxy is http://137.158.125.245:8080/session-blocking-app/. I am currently working on the Web session pick-up feature.With the pick-up feature, a registered user would be able to view all interactions and could reload URL(s) on his PC. The feature comes handy when a user wants to reload a URL that was sent to him in the past. In addition, the feature will be useful when a request is sent to a PC, but the PC is off at that time. With the proxy being able to report all delivery errors, a user would be able to pick-up a session transfer request from a number of requests when he switches on his PC and logs in to the proxy.
