Archive for Ph.D Project

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)

Leave a Comment

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

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.126.21: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.

Leave a Comment

The Web Forwarding and Blocking Service

Here is a link to my presentation at the last CoE-Telkom Industry Seminar, which took place here at the University of Cape Town. It was at the presentation that I was asked about the Google Wave, which I blogged on some days ago.

Leave a Comment

A Comparison of The Google Wave and TransferHTTP

Below is an excerpt of my recent paper. I was asked about The Google Wave during an Industry seminar here at the UCT. I checked it out and found it related to my work [1, 2], so I decided to write a paper on it. I never knew that Google was also thinking in the same direction – improving the online experience through user-generated services or converged services.

The Excerpt:

Table 1 shows the comparison of our work with the Google Wave. Google Wave, which is currently under development, is a new tool for communication and collaboration on the web. It uses an open protocol [1, 2], so anyone can build their own wave system. The Google Wave API allows developers to use and enhance Google Wave through two primary types of development, namely Extensions and Embed.

Comparison of the Google Wave with TransferHTTP

Comparison of Google Wave and TransferHTTP

The extensions (also called the Robots API) can be developed using the Java Client Library, Python Client Library, or Gadgets API, while the embed, which is embedded into a Web application, is always written in JavaScript.
The Google Wave and TransferHTTP provide the same services, though over different architectures. While Google Wave API is used to develop applications that reside on a Web server, TransferHTTP APIs are used to develop applications that reside at the client end. For example, the Click-to-dial in Google wave [3] requires the server to set up a call session, while in TransferHTTP, the client sets up the call session. In Google Wave, the robot in the Web server is responsible for the signalling, while in TransferHTTP, the SIP stack in the Web browser does the signalling.
The Extensible Messaging and Presence Protocol (XMPP) stack [4] in the Google Wave resides at the server, and its APIs are written for third-parties to help them develop converged applications. The Google team has separated the signalling (HTTP and XMPP) in a bid to maintain the current Web architecture. Hence, it could be referred to as a server-based architectural framework for service creation. In our work, a SIP stack is integrated into a Web browser to provide similar services. It was found out that the integration of a SIP stack into a Web browser does not impede its performance [5], thereby making our work a viable approach to create converged services. We provide a hybrid-based architectural framework in which services could be rendered from the client using our API. In addition, a number of services could be rendered from the proxy. These services could be called control services based on what they do. While the proxy services could be developed using the Mobicents SIP Servlets and JAIN SLEE APIs, the client services could be developed using our TransferHTTP extension API.
In summary, irrespective of the technologies or programming languages used in the Google Wave and TransferHTTP, the difference between them is that the Google Wave only has a stack (an XMPP stack) in its server, thereby making it a server-based architectural framework for service creation, while TransferHTTP has a stack (a SIP stack) both in its client and proxy, thereby making it a hybrid-based architectural framework for service creation.

References:

  1. The Wave Protocol, http://www.waveprotocol.org, July 5, 2009.
  2. The Google Wave Project, http://wave.google.com, July 5, 2009.
  3. The Google Wave Click-to-dial, http://googlewavedev.blogspot.com/2009/06/twiliobot-bringing-phone-conversations.html, July 31, 2009.
  4. P. Saint-Andre, Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” IETF RFC 3920, October 2004.
  5. Michael Adeyeye (2008), A SIP Integrated Web Browser for HTTP Session Mobility and Multimedia Services, Unpublished Master’s thesis, University of Cape Town, South Africa.

Comments (1)

A new feature in the TransferHTTP client – Stream to Call Service

The TransferHTTP 1.4 Web browser extension will soon be released. There is a likelihood that it will run in Firefox 3.x. I would like to have some testers to help test the extension before being released. However, the new feature in the client is “Stream to Call.” With Stream to Call, a caller could stream a media to a callee in place of a call. It is required that a call session is setup first before a Stream to Call option is chosen, as shown in Figure 1. Figure 2 shows the SIP signalling involved in streaming a media to another web browser.

The Stream to Call Option in TransferHTTP extension

The SIP Signalling of the Stream to Call Service

Figure 2. The SIP Signalling of the Stream to Call Service

In order to distinguish the client services from the proxy services, the URL http://transferhttp.mozdev.org will contain only the TransferHTTP extension files (installer and documentation), while the URL http://transferhttp.berlios.de will contain only the TransferHTTP control services.

Leave a Comment

TransferHTTP Control Services are here

The control services are Web session mobility blocking and forwarding services. With these services, you could block a session transfer request sent to you. In addition, you could forward (or redirect) a session transfer request to another PC. Go to http://transferhttp.berlios.de for  more information. There are endless possibilities to what one could do with the TransferHTTP extension and its SIP Servlet application. Quoting Mulligan, “there is no ‘well-defined end-point’ for these technologies. “  Technologies here refer to the Internet, Telecommunications and their frameworks and applications, such as the IP Multimedia Subsystem and Skype. TransferHTTP Web browser extension and its SIP Servlet application are currently being extended to support more services.

References

Leave a Comment

TransferHTTP 1.3 is out!!!

TransferHTTP is my Web browser extension for the Mozilla Firefox. A number of bugs have been fixed in this new version. No more frequent crash. YES! Below are some of the new features.

  • It now works in a client-server model.
  • It also reports most of the SIP Response/error messages, such as 404 (Not found) and 408 (Request Timeout).

Those are some of the newly added features; go download and install it from http://transferhttp.mozdev.org I hope to update the extension for Firefox 3.x soon. Lest I forget, I blogged on the extension here last year

Leave a Comment

The Ph.D Seminar

One of the easy ways to earn a Ph.D is to continue with one’s previous work, and that is what I am doing. I had my Ph.D seminar yesterday. It was not a bad one!! At the end of the day, I was asked few questions. One of them was “Is the work more of Web or telecommunications?” The answer was it was more of Web. The work explores a new way of improving the online experience by introducing a controllable web session mobility service. Taking a look at the service abstractions in my methodology, it could also be called a policy-based access control to web session mobility service in order to avoid system misuse. For more information, read through the slides.

Leave a Comment

ICCCN rejects my paper for publication

The paper was titled “Converged Services in the Web-browsing Context” and was submitted to ICCCN 2009 Track on Internet Services, Systems and Applications (ISSA).ICCCN stands for International Conference on Computer Communications and Networks. With no hard feelings, I accepted the reviewers’ comments. In the academic world, we don’t expect our papers (ideas) to always be accepted. I am glad the ideas seem feasible though.

Below are the reviewers’ comments
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

======= TPC Review 1 =======

> *** Recommendation: Your overall rating.
Likely Reject   (top 50% but not in top 35%, needs more work) (2)

> *** Contributions: What are the major issues addressed in the paper? Do you
consider them important? Comment on the degree of novelty, creativity, impact, and
technical depth in the paper.

An architecture for shared web browsing.

> *** Strengths: What are the major reasons to accept the paper? [Be brief.]

The studied topic is important. The proposed architecture gives some nice ideas on
how to design shared browsing services.

> *** Weakness: What are the most important reasons NOT to accept the paper? [Be
brief.]

An implementation is needed to assess the benefits of the architecture

> *** Detailed Comments: Please provide detailed comments that will be helpful to
the TPC for assessing the paper. Also provide feedback to the authors.

The ideas presented in the paper are nicely presented and show a lot of promise.
However, the benefits of the design are not easily concluded from the paper. In
addition, an implementation is necessary for the reader to assess the benefits of he
proposed ideas. The authors need to motivate their design choices.

======= TPC Review 2 =======

> *** Recommendation: Your overall rating.
Likely Reject   (top 50% but not in top 35%, needs more work) (2)

> *** Contributions: What are the major issues addressed in the paper? Do you
consider them important? Comment on the degree of novelty, creativity, impact, and
technical depth in the paper.

The paper looks at converged services looking at allowing traveling web connections.

> *** Strengths: What are the major reasons to accept the paper? [Be brief.]

The paper describes the technical details of the approach in reasonable detail with
regards to most of the underlying messages.

> *** Weakness: What are the most important reasons NOT to accept the paper? [Be
brief.]

The paper does not really have any sort of performance results and is difficult to
follow.  One would have a difficult time reproducing the results despite the paper
being well under the page limit.

> *** Detailed Comments: Please provide detailed comments that will be helpful to
the TPC for assessing the paper. Also provide feedback to the authors.

Intriguing paper with regards to converging web services across multiple devices.
While the topic is interesting, the paper itself is not especially clear.  The paper
needs to do a better job of cleanly delineating where the contribution of the work
is and placing the overall work in the proper context.

Critically, the work falls short in that several details are left quite vague.
While one could focus on just the mechanism, the paper does not really go into much
detail of Section VI, the implementation.  It has a few cursory details which seems
to consist of tada, we did it.  Beyond the earlier discussion, this is what is
interesting to the reviewer.

Were there implementation details that were tricky?  Were there lessons learned that
others could draw upon?  Is the code freely available for download? Are there any
performance results for the work, even just simply demonstrating that it indeed does
work (latency of switching off, etc.)?

As there is plenty of space left over, the authors should take full advantage of the
space to clearly show their work and what they have accomplished.  As it stands now,
there is still a fair amount of work for someone trying to build on their work to
continue forward.

======= TPC Review 3 =======

> *** Recommendation: Your overall rating.
Likely Reject   (top 50% but not in top 35%, needs more work) (2)

> *** Contributions: What are the major issues addressed in the paper? Do you
consider them important? Comment on the degree of novelty, creativity, impact, and
technical depth in the paper.

This paper proposes an implementation plan of internet-based telecommunication-style
communication services including content sharing and session handoff. As documents
of 3GPP adn 3GPP2 show, such features will be important in future web-based
communication services. The service abstracts are presented by event sequence
diagrams and associated explnations.

> *** Strengths: What are the major reasons to accept the paper? [Be brief.]

If implemented, it seems to provide a reference system upon which many research
projects could be performed including the issues of content sharing and session
handoff.

> *** Weakness: What are the most important reasons NOT to accept the paper? [Be
brief.]

The implementation plan alone, as presented in htis paper, cannot be a research
paper at major conferences. Experiences with an implementation and deployment may be
necessary to consider this paper for a conference.

> *** Detailed Comments: Please provide detailed comments that will be helpful to
the TPC for assessing the paper. Also provide feedback to the authors.

An analysis report addressing the performance of such a system would make this paper
much stronger. Or, a report of possible implementation problems would help too.

Leave a Comment

The Ph.D Idea – Emerging Converged Services in the Web-browsing Context

My provisional Ph.D proposal lately got accepted at the WEBIST 2009 Doctoral Consortium. The acceptance of this proposal now makes it two papers that I will be presenting at the conference. The other paper is a regular paper, which was accepted weeks back, and it will be presented for 20minutes. The Ph.D proposal will be presented for 30minutes.I would not be able to make the whole proposal available to all for now. It is an idea under development. However, I am happy to give a summary of the proposal.

Provisional Title
Emerging Converged Services in the Web-browsing Context

Introduction
I mentioned the Set and Core Features in Telecommunications, mobility types in the NGN, existing Web Session Mobility solutions in the market, namely Mozilla Weave and Google Browser Sync, and my previous work – Integrating SIP into a Web browser.

State-of-art/Related Work
Here, I discussed related work carried out in the academic environment and the Industry. Related academic work include Vijay Gurbani and Jonathan Lennox’s research work. Vijay’s work is on crossover services originating on the Internet and the PSTN, and smart spaces in the Telecommunication domain. Jonathan Lennox, in his research work titled “Services for Internet Telephony,” develops new ways of generating telephony services over the Internet. I also mentioned related Industry work – The Mozilla Weave, The Apache CouchDB Project and The Google Browser Sync (Please note that Google Corporation no longer supports the Google Browser Sync). In addition, I explained the underlying technologies for each project and the correlation between the academic work and the Industry work. Below is an excerpt from the related work column.

“These telephony services intrinsically use SIP , while the Mozilla Weave and the Apache CouchDB allow users to share their data and intrinsically use HTTP . All works are some of the services available on the Internet. Our previous research work explored the use of SIP to migrate web sessions or share user data and provide multimedia services between two or more Web browsers without the need for a third-party tool. It has emerged as a result of convergence in the Internet and Telecommunication, in a bid to improve the Web browsing experience. This further work now explores new services emerging for the interaction between two or more Web browsers. The services are derived from the telecommunication context, more specifically, features in phones and core of the networks.”

Stage of Research
First, I mentioned that an extended Web browser architecture that integrates a SIP stack has been proposed and implemented. Second, a new service, referred to as content sharing and session handoff between Web browsers, has also been provided to improve the Web-browsing experience. I also mentioned that the integration of a SIP stack into a Web browser has now made it possible for Web browsers to act as SIP clients, thereby setting up multimedia session between two or more users. Most notably, Web browsers now have unique SIP addresses to interact with one another like PCs, which have unique Media Access Control (MAC) or IP addresses [5]. Lastly, I mentioned that although a hybrid-based architecture was proposed in the previous work, only the client side of the architecture has been implemented and evaluated.

The Research Problem
Findings should that the service (content sharing and session handoff), when widely used, would result in unsolicited or unwanted requests among the users. This anomaly would result into spamming among the users. To alleviate the problem, a user should be able to manage requests; for example, he/she should be able to set policies to block unwanted request or redirect request to another PC. In another sense, a user could have more than one request at a time and would want to choose what request should be first fulfilled. A number of these cases already exist in the telecommunication world and there are solutions. The ability to make Web browsers interact with one another like mobile phones makes it feasible for Web browsers to have similar services found in the telecommunication world in the web domain. The primary goal of this research work is to provide these services or solutions in the Web-browsing context.

Methodology
Having implemented the client-side of the proposed hybrid architecture, this research work will explore the proxy-side of the architecture. This further research work entails creating new services that could improve the Web-browsing experience. These services would be derived from existing telecommunication services, such as call parking and call pickup in telecommunications. Although the services are peculiar to telecommunications, they are feasible in the Web-browsing context owing to interactions between two or more Web browsers in a way that is similar to how phones operate or interact. An example is the session handoff and content sharing service in the Web-browsing context, which was derived from Session Handoff and Third Party Call Control in SIP, respectively. Figure 2 shows Web Session Mobility Packing and Pickup, which is a derivative of Call Packing and Call Pickup in the telecommunication context. Similarly, Figure 3 shows Web Session Mobility Screening and Blocking, which is a derivative of Call Screening and Call Blocking in the telecommunication context.
These interactions between Web browsers will offer an improved Web-browsing experience for a user or between two or more users, based on the service type that is chosen. However, these interactions or emergent behaviours between the Web browsers could also be achieved via other protocols, which offer interactions, such as Extensible Messaging and Presence Protocol. SIP is preferred to XMPP because it can be used to establish, modify and terminate multimedia sessions.
This is an additional capability of SIP, aside its support for messaging and presence, which is also supported by XMPP. The framework, shown in Figure 1, requires a SIP proxy server. The proxy, which is a Converged Application Server, is needed to achieve some of the emerging services. It is required to administer the services, and some of its roles include blocking or allowing requests between PCs (Call Screening or Blocking in Telephony) and keeping a session alive when a request is made at a time the destination UAC is not reachable (Call Packing or Pickup in Telephony).
While the former role could be achieved via an integration of a policy control mechanism, the latter could be achieved through a session management mechanism. In Figure 2, the SIP proxy server has an auto-store feature in order to provide Web session mobility packing and pickup, while in Figure 3, the SIP proxy server has a policy control mechanism to screen and block session transfers. These services would also be evaluated in order to see if there is a need for them. The evaluation process would require conducting a survey among the regular Internet users.

Objectives
Based on the implementation framework:

  1. To derive and implement new converged services in the Web browsing context, which are mapped from existing telecommunication services. For example, call parking in telecommunication is synonymous to having multiple content sharing requests from two or more users in the Web-browsing context and choosing which one to fulfil first.
  2. To implement a SIP Proxy (a converged Application Server) that co-ordinates the new converged services. It would offer policy control, which entails allowing or blocking requests using criteria, such as a SIP address. In addition, it would offer session management, which entails keeping a session alive when the destination UAC is not reachable. The SIP Proxy, as a converged Application Server with HTTP and SIP endpoints, would provide a User Interface that Web users could use to set their preferences (policies), view their usage of services and manage Web sessions.

Expected Outcome

  1. Developing and deploying a converged Application Server that provides a GUI to administer the new converged services.

References

  1. Luin Dang, Cullen Jennings and David Kelly (2002), Practical VOIP using VOCAL, O’Reilly & Associates, USA, First Edition, pp. 265-272.
  2. Vijay Gurbani (2004), Service Oriented Computing: Enabling Cross-network services between the Internet and the Telecommunications network. Unpublished Ph.D thesis, Illinois Institute of Technology, Illinois, USA.
  3. Jonathan Jonathan (2004), Services for Internet Telephony, Unpublished Ph.D thesis, Columbia University, New York, USA.
  4. Michael Adeyeye, Neco Ventura and David Humphrey (2009), “Mapping Third Party Call Control and Session Handoff in SIP Mobility to Content Sharing and Session Handoff in the Web-browsing Context,” in: Proceedings of IEEE Wireless Communications and Networking Conference (WCNC) 2009, Budapest, April 5-8, 2009 (To be published)
  5. Michael Adeyeye (2008), A SIP Integrated Web Browser for HTTP Session Mobility and Multimedia Services, Unpublished Master’s thesis, University of Cape Town, South Africa.
  6. The TransferHTTP Web browser Extension, http://transferhttp.mozdev.org, September 5, 2008.

Conclusion
Here is the summary of the proposal. In the proposal, I mentioned the possibility of rendering IPTV services over PCs’ Web browsers in a way different from what exists today. Here is an excerpt: “IPTV services for end users include Video on Demand and Live Broadcast. Although it is envisaged that IPTV clients on PCs would be standalone programs, such as IntAct IPTV Client and Irdeto IPTV with PC Client, the integration of SIP in a Web browser makes Web browsers potential IPTV clients. “ Here, I referred to the IMS-based IPTV. Although a comment was made on this idea, which I think was one of the reasons the proposal got accepted, I will be dropping the idea (rendering IPTV services over a Web browser). I would rather focus on providing the emerging converged services, and more specifically, implementing the proxy-side of the hybrid-based scheme. I don’t think I will be exploring again the client-side (Web browser extension) of the project, at least for now.

Your contributions are welcome.

Leave a Comment