Michael Adeyeye (Ph.D)

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.