I was wondering if anyone might be interested in this software localization project - http://www.africanlocalisation.net/call-applications-language-teams-2010. You could forward the blog-post to anyone you think might (also) be interested.
And I am more than happy to work with anyone, who is interested in the project.
The last had not been heard from the IPTComm ’10 TPC, when they wrote me that my paper was rejected. I was surprised this evening to read that my paper has been accepted for presentation as an “Industry Talk.” That’s not bad. The Industrial Talks papers highlight innovative solutions and their impact and benefits for the community. This means that my work is one of those innovative solutions out there. Great!!! But I am not sure I would want to register the paper under that session. Below is the mail I got from the TPC.
| From: | davids{at}iit.edu |
| Subject: | [IPTComm'10] Your paper #1569296037 (Quality of Experience of the HTTP Session Mobility Service) |
| Date: | Fri, May 28, 2010 6:25 pm |
| To: | “Michael O. Adeyeye” <micadeyeye{@}crg.ee.uct.ac.za> |
|
Dear Mr. Adeyeye: On behalf of the Technical Program Committee, we are delighted to inform you that The TPC selected 24% papers from this year’s submission as “Full papers” and Your paper has been chosen as an “Industry Talk.” Congratulations on your At least one author of each accepted talk must register for the conference by June We look forward to welcoming you in Munich, Germany. Sincerely, Carol Davids and Saverio Niccolini Vijay K. Gurbani and Gonzalo Camarillo |
|
Below are the comments I got from the Tridentcom 2010 TPC members who reviewed my paper. I noticed that some visitors do read a similar past post – ICCCN rejects my paper for publication. So, I decided to share this review too.
Review #1
Science: 3 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Originality: 3 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Structure and Language: 3 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
References, State-of-the-art: 2 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Scope: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)Comments for the Author/s?
The paper presents a SIP based extension to web browsing. While this reviewer acknowledges a great amount of work involved to build up the proposed system, the resulting capabilities gained by it differs little from other solutions. Authors are encouraged to include more references to other technologies that enable the implemented capabilities such as content sharing and/or session transfers, and clarify differences from other existing solutions.Candidate for Best Paper: No
Review #2
Science: 3 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Originality: 3 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Structure and Language: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
References, State-of-the-art: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Scope: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)Comments for the Author/s?
The paper proposes a solution to improve online user experience by integrating a SIP stack into the Web browser, thus enabling the execution of novel SIP-based applications directly at the client endpoint. The authors show how the browser extension coordinates with SIP-based Converged Application Server to enable session mobility and prevent abuses of the services available in the client. Besides that, examples of novel SIP-based Web 2.0 service mash-ups, including VoIP and stream media call service are discussed.
The authors discuss a relevant topic of research nowadays, and propose a good solution to manage multimedia services in Web 2.0 scenarios. They clearly introduce related aspects and show SIP background. They use application scenarios to detail the proposed architecture, examine the implementation insights, and show performance results. At last, they compare their solution with Google Wave project.
A suggestion to improve the paper is to justify why TransferHTTP memory consumption, CAS memory consumption under low traffic conditions and CAS performance under system overload were chosen as main performance parameters.Candidate for Best Paper: No
Review #3
Science: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Originality: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Structure and Language: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
References, State-of-the-art: 4 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)
Scope: 2 ([1] Strong Reject, [2] Weak Reject, [3] Weak Accept, [4] Strong Accept)Comments for the Author/s?
Interesting paper. But though experimental results are discussed, this paper is not about testbeds. Would be much more at place at a SIP related conference.
Investigating the performance impact of a CAS on a Mobicents platform has limited value. When performance matters, other platform technologies may be used instead (i.e. there are various SIP based platforms). Mobicents is more about flexibility.Candidate for Best Paper: No
One question you might want to ask is “what successes have I made so far?”
One of the reasons I am posting my reviews on my blog is to encourage other students not to fear having their papers rejected. Another reason is not to stop trying or pushing their ideas through.
Below is a correspondence between Benny Prijono, the developer of the C Language SIP stack – PJSIP, and me. I sought his permission before publishing this e-mail.
From: “Benny Prijono” <bennylp{at}pjsip.org> Subject: Re: PJSIP in the Mozilla Firefox Web Browser Date: Fri, March 12, 2010 3:21 pm To: “Adeyeye Oluwasegun Michael” <micadeyeye{at}crg.ee.uct.ac.za> Cc: support{at}teluu.com
Hi Adeyeye, Wow, another strange usage of SIP.We'll add the link asap, thanks for the info. Cheers Benny On Fri, Mar 12, 2010 at 7:49 PM, Adeyeye Oluwasegun Michael <micadeyeye{at}crg.ee.uct.ac.za> wrote: > Hi Benny, > You might want to share this on your site - Integrating PJSIP into the > Mozilla Firefox Web Browser. The browser extension is called TransferHTTP, > and it available at http://transferhttp.mozdev.org. > > I have a demo of the work here - > http://www.ngportal.com/research/transferhttpclients.ogg > > The extension is used to move web sessions, set-up a voice call and stream > media between two PCs. > > Regards, > Michael. >
Benny now lists my work on his site as one of the works (Open Source Projects) that used PJSIP. See http://www.pjsip.org/apps.htm
I was at the Shuttleworth Foundation last Friday to receive my mesh potatoes (MP) from Steve. I unpacked the telephone equipments some days ago and thought I could easily set them up. I fiddled with the equipments for some hours before I could get them to work. It was awesome to see the MPs connect to each other via the wi-fi link. I am currently exploring the tracking feature (Afrimesh) and the billing mechanism (A2Billing) for the MPs. In addition, I am thinking of carrying out some benchmark tests (using SIPp/IMS bench SIPp). I hope to make some contributions before the next Village Telco workshop. Check here for my previous post on the Village Telco Project.
My Mesh Potatoes (The Village Telco Project)
I have seen people, most especially academics, ask me the following questions.
1) Why can’t I implement session mobility using Mobile IP or Media Independent Handover (MIH)?
2) Who needs session mobility?
3) Why did you choose to use SIP?
Having done an extensive literature review and got a number of papers (in a journal and conf. proceedings), I can now say that my answers to the questions have always been right. Once again, these are my answers:
1) My work is an “application layer solution” for HTTP/Web session mobility. I don’t work at the lower layer(s) of the OSI layers. Mobile IP and MIH have been used to achieve terminal mobility at the lower OSI layers. My work involves moving web sessions between PCs, but not moving terminals (mobile nodes) between access points. That is what Mobile IP and MIH can help you achieve, and it’s called terminal mobility.
2) The work offers solutions to problems faced by the regular Internet users. I explained what the problems are using two use case scenarios here. Most of us (the regular Internet users) often do one of these things: 1) send a URL to a friend in an e-mail or through the Instant Messaging (IM) service when we want him/her to take a look at what we are viewing online; 2) save a URL in our e-mail/diary with the intention of continuing with what we are doing somewhere else. Interestingly, many software companies, such as Mozilla and Google, are introducing new products/services to address the problems. Examples are the Mozilla Weave and the outdated/de-supported Google Browser Sync. What I have done in my work is to make a person send a URL from one browser (or PC) to the other without using a third-party service like IM or e-mail.
3) It’s obvious that HTTP without being extended can’t deliver the services desired in this present day. That’s why it’s been patched to provide the services. Mozilla Weave was once using WEBDAV (an extension to HTTP). In another sense, cool tools like AJAX, Restful APIs have been introduced in order to provide those new services – Rich Internet Applications. HTTP User Agent (UA) can either be a client or a server, but not both. Hence, it had to been extended to do both. The case is different in SIP in which its UA is both a client and a server. Software firms are now relying on protocols like SIP and XMPP to offer some appealing services. An example is the Google Wave, which uses XMPP (Draft Protocol Specs here). I also chose to use SIP in my project in order to gain the instant messaging and presence capabilities in SIP.
I am happy to answer other related questions or provide more information on the work.
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.
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 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:
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.
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.
I read an article online on the Localization (L10n) of the Microsoft OS Vista into three prominent Nigerian languages – Yoruba, Hausa, and Igbo. This is awesome. I was wondering if any tertiary institutions in Nigeria helped in accomplishing the task. I look forward to some students taking up the idea (L10n of FOSS, such as Apache, CUPS, Firefox, GNOME, KDE, OpenOffice.org, Thunderbird, X Window System) into those languages as their projects. I am happy to help out.
