signicant403forbidden

ConvergedmultimediaservicesinemergingWeb2.
0sessionmobilityscenariosMichaelAdeyeyeNecoVenturaLucaFoschiniPublishedonline:29October2011TheAuthor(s)2011.
ThisarticleispublishedwithopenaccessatSpringerlink.
comAbstractTheincreasingrequestforconvergedmulti-mediaserviceshavemotivatedrelevantstandardizationefforts,suchastheSessionInitiationProtocol(SIP)tosupportsessioncontrol,mobility,andinteroperabilityinall-IPnextgenerationwirelessnetworks.
NotwithstandingthecentralroleofSIPinnovelconvergedmultimedia,thepotentialofSIP-basedservicecompositionforthedevel-opmentofnewclassesofWeb2.
0servicesabletointer-operatewithexistingHTTP-basedservicesisstillwidelyunexplored.
ThepaperproposesanoriginalsolutiontoimproveonlineuserexperiencebyintegratingaSIPstackintotheWebbrowser,thusenablingtheexecutionofnovelSIP-basedapplicationsdirectlyattheclientendpoint.
Inparticular,ourbrowserextensioncoordinateswithournovelSIP-basedConvergedApplicationServertoenablesessionmobilityandpreventabusesoftheservicesavail-ableintheclient.
ExperimentalresultsshowthatourSIP-basedsolutionisfeasibleinmostcommonInternetdeploymentscenariosandenablessessionmobilitywithlimitedmanagementcost.
KeywordsCommunicationsystemsignalingSIPWorldWideWeb—MashupsBrowsersSessiontransfer1IntroductionTheconvergenceoftheInternet,broadcasting,andtele-communicationshasresultedinnovelconvergedmulti-mediaservicesintheWorldWideWebcommunityandpavedthewaytoanewrichresearcheldcharacterizedbyseveraldifferenttechnologicalpossibilities,serviceopportunities,andbusinessmodels,oftenreferredtoasWeb2.
0.
ThisnovelscenariohasbeenenabledbytheeverincreasingdiffusionofnewWeb-relatedinnovativetech-nologiesincludingnewbrowsers(e.
g.
,MozillaFirefoxandGoogleChrome),standardizedclient-sidescriptinglan-guages(e.
g.
,JavaScript),originalcommunicationmodels(e.
g.
,AsynchronousJavaScriptXML-AJAX),andnovelextensionsviabrowser-specicApplicationProgramInterfaces(APIs).
AgoodexampleistheMozillaCom-munity,whichhasover1,800,000,000extensionsdown-loadedfortheMozillaFirefoxbrowser[1].
DespitethegreatpotentialstemmingfromtheWeb2.
0service-provisioningscenario,oneofthemostchallengingopenissuesinsupportingconvergedmultimediaservicesissessionmanagement.
Broadlyspeaking,sessionmanage-mentisthecapacitytodynamicallyadapt,modify,andmaintainactivetheservicesessionstatenotwithstandingtheseveralpossiblechangesintheservicedeliveryenvi-ronment,suchas:usermobilitybetweendifferentwirelessaccesspoints;possiblequalitylevelvariationsduetoconnectiontechnologychange;andexecutingenvironmentmodicationsduetoapplicationoraccessterminalchange,denedassessionmobility.
ByfocusingonsessionmobilityforWeb2.
0,variousresearchworksinthelastdecadehaveexploredHTTPsessionmobilityamongdif-ferenthostsandbrowsers[2–4].
However,despitetheirpotential,noneoftheaboveHTTPsessionmobilitysolu-tionshaspenetratedintothemobilemultimediamarket,M.
AdeyeyeDepartmentofInformationTechnology,CapePeninsulaUniversityofTechnology,CapeTown8000,SouthAfricae-mail:adeyeyem@cput.
ac.
zaN.
VenturaDepartmentofElectricalEngineering,UniversityofCapeTown,CapeTown,SouthAfricae-mail:neco@crg.
ee.
uct.
ac.
zaL.
Foschini(&)DEIS,Universita`diBologna,Bologna,Italye-mail:luca.
foschini@unibo.
it123WirelessNetw(2012)18:185–197DOI10.
1007/s11276-011-0394-zprimarilybecauseofthelackofwidelyacceptedsessioncontrolstandardsandconsequentlyduetothelimitedpossibilitiestointegratethosesolutionsintofully-convergedWeb2.
0servicesmeltingtogetherInternetandtelecommunicationsworlds.
Thepapertacklestheaboveissuesbyproposinganovelsolutionwiththreeoriginalcorecontributions.
First,itenablesopenandinteroperablesessionmanagementattheclient-side(Webbrowser)byadoptinganapplication-layerapproachbasedontheSessionInitiationProtocol(SIP)andSIPoverlayinfrastructureforsessioncontrolinnextgen-erationfully-convergedwirelessnetworks.
Second,itpro-posesanovelSIP-basedHTTPsessionmobilityapproachthatenhancestheWeb2.
0userexperienceandpreventspossibleabusesoftheservicesavailablethroughtheintro-ductionofournovelConvergedApplicationServer(CAS)tocontrolHTTPsessionmobilitybetweenbrowsers.
Third,itshowshowourenhancedSIP-enabledWebbrowsernotonlysupportssessionmobility,butalsoenablesthecreationofnewWeb2.
0servicesandservicemashups.
Ourworkisfullycompliantandseamlesslyintegrateswithstandardandwidelydiffusedtechnologies.
TheproposedHTTPsessionmobilityextension,calledTransferHTTP,hasbeenimple-mentedasaSIP-stack-basedextensionthatleveragestheOpenSourcePackageMozillaFirefox.
Inaddition,theMobicentsCommunicationsPlatform[5],anopenplatformthataimstodriveconvergence,hasbeenadoptedtorealizeCAScomponentforsessioncontrol.
Theproposedcom-ponents,partofourwiderprojectonSIP-basedsessionmanagement,arepubliclyavailableforwirelesspractitio-nersandtheSIPcommunity1[6–8].
Thepaperstructureisasfollows.
First,wegivetheneededbackgroundaboutSIPandthenwepresenttheapplicationscenarioandthemaindesignguidelinesofourdistributedarchitecture.
Then,wedetailsourSIP-basedWebsessionblocking/forwardingmanagementsolutionandprotocols,whilewegiveimplementationdetailsandsomeseminalperformanceresultsaboutTransferHTTPextensionandCAS.
Afterwards,wepresenttherelatedwork,byespeciallyfocusingontheveryrecentGoogleWaveproject,andwediscussourAPI.
Finally,remarksandfutureworkdirectionsendthepaper.
2SIPbackgroundSIPisanapplicationprotocolthatallowsservicestopar-ticipateinsessioninitiationandmanagement.
SIPsupportsdifferentkindsofmobility,namelysessionmobility,per-sonalmobility,terminalmobilityandservicemobility[9].
ThissectionbrieyintroducestheneededbackgroundmaterialaboutSIP.
SIPallowsthecreation,modication,andterminationofservicesessionsindependentlyoftheunderlyingdata-linklayertechnologiesandtransportprotocols.
SIPhasbeenwidelyappliedtovoiceandvideocall/conferenceservicesoverthetraditionalInternet.
Recently,SIPhasgainedwidespreadacceptancealsointhemobileworldasthecontrolprotocolforconvergedcommunicationsoverall-IPnetworks(seethethirdGenerationPartnershipProject—3GPP—andtheIPMultimediaSubsystem—IMS—[10]).
TheSIPinfrastructureishighlyopenandexible,andoffersfacilitiestoservicedevelopers.
Infact,SIPnotonlydenesprotocolsandmessagesforsessionsignaling,butalsoproposesawiderframework,e.
g.
,fordecentralizedproxy-basedsessionmanagement,endpointlocalization,andpresencedetection.
ThecoreentitiesoftheSIPinfra-structureareuseragents(UAs),registrationandlocationservers,proxies,back-to-backuseragents(B2BUAs),andre-directservers.
AUAisaSIPendpointthatcontrolssessionsetupandmediatransfer;eachUAisidentiedbyauniqueHTTP-likeUniformResourceIdentier(URI),e.
g.
,sip:user@domain.
Theregistrationserverisanamingser-vicethatreceivesregisterrequestsbyUAsandisabletoresolvecurrentUAlocations;itinteractswiththelocationservertostorecorrespondencesbetweenUASIPURIsandtheircurrentendpoints.
EachsessionordialogissetupbetweentwoUAs,andSIPdistinguishestworoles:therequestingUAClient(UAC)andthetargetUAServer(UAS).
Re-directservers,proxies,andB2BUAcontributetolocateSIPendpointsandtorouteSIPmessages.
Re-directserversandproxiesrepresentthecoreSIProutinginfrastructure,buttheyhavelimitedpossibilitiestochangeongoingdialogsandSIPmessages(theycanneithergen-eratenewSIPrequestsnorchangemessagecontent,e.
g.
,modifyingmediaendpoints).
B2BUAs,instead,arelogicalentitieswithbothUACandUAScapabilitiesthathavefullcontrolovertraversingdialogsandSIPmessages.
Conse-quently,SIPproxiesonlyparticipatetomessagerouting(andnottomediadelivery),whileB2BUAs,giventheirUAcapabilitiesandtheirabilitytochangeSIPmessagescontent,canpotentiallyparticipatealsotomultimediacontenttransport/adaptationbysplittingclient-to-serverdirectmediapaths.
Finally,SIPdenesasetofprotocolsandmessages,suchasINVITE,REGISTER,REFER,MESSAGE,OK,andACK,tocontrolsessions;SIPmakesnoassumptionontransportlayer,butusuallyemploysUDP.
MoredetailsaboutSIPprotocolandmessagescanbefoundin[10].
Moreover,SIPcanbeeasilyextendedtosupportsessionmobility;forinstance,UACcanusetheREFERmessagetoredirectthesessioncontrolowandspecicMESSAGEpayloadstomoveongoingsessionstate.
1AdditionalinformationandtheprototypecodeofourTransfer-HTTPextensionareavailableat:http://www.
transferhttp.
mozdev.
org.
186WirelessNetw(2012)18:185–1971233ApplicationscenarioanddistributedarchitectureWhensurngtheWeb,thetwoprominentwaysofsharinginformationoraskingafriendtoviewthesameWebpageareferrerisviewingare,currently:usingathirdpartysoft-ware(InstantMessengers,suchasGTALKandYahooMessenger)andsendingtheURLinanemail.
However,boththosealternativesareerror-prone,non-automated,andtime-consumingforthenalusers.
Therefore,sessionmobilityhasbeenwidelyrecognizedinthelastyearsasacorefacilitytoenablenewWeb2.
0browsinginformationsharingexperiences[6,7].
Inthispaper,wedenesessionmobilityasthefacilitythatenablesautomaticmovementofexistingWebsessionsbetweentwobrowsers,typicallyrunningondifferenthosts.
Wedistinguishtwomaintypesofsessionmobility:contentsharingandsessiontransfer.
ContentsharingisdenedastheabilitytosimultaneouslyviewthesameWebpageontwobrowsersatthesametime,bytypicallytransferringonlytheWebpageUniversalResourceLocator(URL).
SessiontransferisdenedastheabilitytomovethewholeWebsession,includingnotonlytheWebpageURLbutalsoallneededsessiondata(cookies,sessiontokens,andvisitedURLs).
AnexampleofcontentsharingisAlicereferringBobtovisitthesamenewsWebsitethatsheisbrowsing:inthiscase,shewouldonlywanttosendtheURL.
Anexampleofsessiontransfer,instead,ismovingaWebemailsessionbetweentwoPersonalComputers(PCs)withthenalgoalofcontinuingtocheckemails,withthesameviewofread/unread/cancelledmessages,etc.
,withouthavingtosigninagain.
Sincecontentsharingandsessiontransferarecriticaloperations,potentiallypronetosecurityproblemssuchasmalicioususersactingasmen-in-the-middlebetweentwointeractingpartiesorpossibleabusesofservicesofferedbythebrowsers,weintroducedtwofacilities—Websessionblock-ingandWebsessionforwarding—attheproxyofthesystemtocontroltheinteractionbetweenthebrowsers.
Thesearestandardfacilitiesintelecommunications,wherephonecallscanbeblocked,forwardedorscreened.
Afacilityorservicecanbedenedasavalue-addedfunctionalityprovidedbyanetworktoitsusers[11].
Althoughcallblocking,callfor-warding,andsimilarfacilitiesarespecictotelecommuni-cations,theyarefeasibleintheWeb-browsingcontextowingtotheinteractionsbetweentwoormorebrowsers.
Topreventpotentialsecuritythreatstypicalofend-to-enddirectinteractions(suchasdirectend-to-endsessionredirectionbasedonstandardSIPREFERmessageonly),weclaimtherelevanceofproxy-basedsolutions,whereatrustedproxyentityisinterposedamongthetwointeractingbrowserstomediateandgranttheirinteractions.
Followingthismaindesignguideline,weproposethedistributedarchitectureshowninFig.
1;wedeneourarchitectureashybrid-basedbecauseitisbasedbothonaninfrastructure(proxy)andaclient-sidepartsanditintegratesdifferentprotocols(namelySIPandHTTP).
Fig.
1Thehybrid-basedarchitecturewithallmaininteractionsWirelessNetw(2012)18:185–197187123Theinteractionisbetweenbrowsers,enhancedwithSIPcapabilitiesandactingasSIPUACs,andaSIPB2BUA(proxy)thatcoordinatesbrowser-to-browserinteractionsandenforcesWebsessionblockingorforwarding(viaSIP,continuousarrowsinFig.
1).
Oncesessionstatehasbeenmovedtothedestinationbrowser,itcanrebindtheongoingsessionbyinteractingwiththelocalHTTPproxyserver(viaHTTP,dashedarrowsinFig.
1);Fig.
1reportsthreesignicantusecases.
Intherstone,UserA(UAC-1withSIPURIsip:kamil@uct.
ac.
za)whoisatwork,transfershisWebsessiontohisbrowser(UAC-2withSIPURIsip:kamil@claremont.
co.
za)runningonhisdesktopathome(interactions2–3inFig.
1),whileinthesecondone,UserArefersUserB(UAC-3withSIPURIsip:clin-ton@uwc.
ac.
za)tothesameWebpageheisviewing(interaction4inFig.
1).
Intheabovetwousecases,theproxyallowstherequiredsessionmobilityrequestbyforwardingit.
Inthethirdone,instead,UserAhassettheSIPB2BUAtoblockallrequestsfromUserB(interaction5inFig.
1).
Inthiscase,ournegrainedsessioncontrolpermitstodeneandenforceasymmetricsessionblocking/forwarding:UserAcanreferUserBtoviewthesameWebpage,butUserBcannotreferUserA.
Finally,asbetterexplainedinSect.
5.
2,theproxyprovidesasetofWebpagesforaccesscontrolpoliciesconguration(viaHTTP,interaction6inFig.
1).
4SIP-basedwebsessionblocking/forwardingmanagementInordertoenablesessionmobility(eithercontentsharingorsessiontransfer),weproposetoextendtheWebbrowserbyaddingournewWebsessiontransfer/receiptfunctions.
Figure2showsthedataowdiagrams—DFD—ofsessionmobilitytransfer/receipt,respectively,atorigin(Fig.
2a)anddestination(Fig.
2b)browsers.
Weonlyrequireuserstoentertheirinformation,suchasSIPusernameandpasswordusedbyUACtoregisterintotheSIPinfra-structure,andthedestinationSIPB2BUAaddress(seethetwoarrowsenteringthebrowserfromtheleftsideinFig.
2a).
TheSIPB2BUAaddressisconguredonce,atcongurationtime;theuserinformation,instead,arerequiredfromtheuseratbrowseractivationtimeandcanbesavedamonguserpasswords.
TheWebsessiontransfer/receiptfunctionsareimple-mentedbyourSIPUACbrowserextension,calledTrans-ferHTTP,thatinteractswithournewSIPB2BUA,calledConvergedApplicationServer(CAS),tomanagesessionstateblocking/forwarding.
Theoriginbrowser(seeFig.
2a)interactslocallywithTransferHTTPbypassingtoittheSIPuserinformationandthedestinationSIPaddress,onceatactivationtime,andthenongoingsessiondataandURLsforeachrequiredsessiontransfer.
TransferHTTPprocessessessiontransferrequestsandemitsSIPMESSAGEwithsessioninformationtoCAS.
Afterwards,CASchecksthesessionmobilityrequestagainstdestinationuser'sacces-sibilitypolicies,andthenforwardstheSIPMESSAGEtoTransferHTTPextensionatthedestinationbrowserthat,initsturn,generatesalocalnoticationtothebrowser(seeFig.
2b).
Ifthenoticationisaccepted,thesessiondatawillbeforwardedtothebrowserandthesessionwillbere-establishedbypullingneededresourcesfromtheInternet.
Figure3showstheproposedSIP-basedWebsessionblockingandforwardingprotocolsandmessageexchanges.
Afteraninitialregistrationphase(steps2–3and5–6inFig.
3)duringwhichTransferHTTPcomponents(SIPUACs)registertoCAS(actingalsoasSIPlocation/regis-trationserverinourinfrastructure);then,subsequentSIPmessageexchangestransverseCAS(SIPB2BUA).
Foreachcontentsharingorsessionstatetransferrequest,realizedbothasspecicSIPMESSAGEsencapsulatingallneededsessionstateinformation,CASenforcesaccesspoliciesbyeitherblockingorforwardingtherequesttowardsdestinationTransferHTTP(steps7–9).
Then,forcontentsharing,theHTTPRequest/ResponsewillbebetweentheWebserverandUAC1(step12a)aswellastheWebserverandUAC2(step12b).
Insessiontransfer,instead,theHTTPRequest/ResponsewillonlybebetweentheWebserverandUAC2(onlystep12b).
Finally,whenusersdecidetoclosetheirbrowsers,SIPUACsde-register(steps13–16).
Fig.
2Websessiontransfer/receiptatorigin(a)anddestination(b)browsers188WirelessNetw(2012)18:185–197123ByfocusingonexchangedSIPmessages,thesessiondataofaWebsessiontransferrequestissentinanXMLformatusingtheSIPMESSAGEmethod[7],anditcouldconsistofaURL,cookiesandsessiontokensdependingonthekindofrequest.
Asregardssessionblocking,whenCASdetectsanunauthorizedsessionmobilityrequest,itrespondstotheSIPMESSAGEwitha''Forbidden(403)''response,notiedtotheuserasawarningmessageinbrowserstatusbar.
Toconclude,letusstressthattheavailabilityofaSIPstackintegratedwithintheclientbrowserreallyenablesnewconvergedWeb2.
0serviceprovisioningscenarios.
Forinstance,ourTrasferHTTPextensionnotonlyenablessessionmobility,butalsopermitstoinitiateSIP-basedVoiceoverIP(VoIP).
Moreover,withourextension,browserscantakedifferentSIProlesandactnotonlyasUAC,butalsoasUASsabletodeliverSIP-basedservicesrequiredbyotherexternalSIPUACs.
Therefore,westronglybelievethatourTransferHTTP,togetherwiththeavailabilityofnewmediaprocessingandplayingcapabilitiesinnextgenerationWebbrowsers,makespossiblenewinnovativeSIP-basedservicemashupscenarios.
Forinstance,thelatestversionofTransferHTTPsupportsahighlydynamicmultimediastreamsharingservice,called''StreamMediatoCall'',thatpermitsuserstousetheirWebbrowserasastreamingserver,thusmakingavailabletheirmultimediacontentsasvideo/audiostreamsdeliverabletoauthorizedbuddies.
5ImplementationandperformanceresultsThissectionrstbrieysketchessomeimplementationdetailsaboutournovelTransferHTTPextensionandCASSIPB2BUAcomponent;andthen,itpresentsexperimentalresultsaimedtoevaluatethecostoftheproposedsessionmobilitymanagementsolution.
5.
1TransferHTTPbrowserextensionTransferHTTPhasbeenrealizedasanextensionforMozillaFirefoxWebbrowser.
TheservicesavailableintheTransferHTTPextensionincludenotonlycontentsharingandsessiontransfer,originallypresentedinthispaper,butalsoVoIP(''Makeacall''),andmultimediacontentsharing(''StreamMediatoCall'').
Oursessionmobilityfacilityconsistsoftwomainparts:aSIPstackandourTransferHTTPextension.
TheSIPFig.
3ThemessageexchangebetweenWebclientsWirelessNetw(2012)18:185–197189123stackusedinthisimplementationisthePJSIP[12],whichisanOpenSourceprojectandsmallfootprintmultimediacommunicationlibrarieswritteninC.
Wecreatedasharedlibrary(1.
7MBinsize)fromtheSIPstackandthesharedlibraryinteractswiththeTransferHTTPextensionviaaCrossPlatformComponentObjectModel(XPCOM).
Inparticular,weaddedourextensionasanewXPCOMwiththecontractid''@ngportal.
com/SIPStack/SIPStackInit;1''intotheexistingXPCOMsinthebrowser[13].
AsregardsourTransferHTTPextension,ithasbeenrealizedatopbuilt-ininterfacesinMozillaFirefoxversion2.
0–3.
5thatincludensIPref,nsICookie/nsICookieMana-ger/nsICookieManager2,nsIThread,nsIPasswordManager/nsILoginManager,nsIIOService,nsIPromptService,nsITi-mer,nsIObserver;inaddition,itmakesavailableanewinterface,named''ImyStack''toexposesTransferHTTPfunctions.
Theunderlyingimplementation,writteninC,isscriptableanddeveloperscanuseJavaScripttoinvokeitsfunctions.
Inparticular,TransferHTTPAPIexposessignalingfunctions,typicallyavailableintele-communicationsframeworks,tocreateinnovativeappli-cationsattheclientside.
Forinstance,ourAPImakesitpossibletocreateapplicationsthatcanusetheinstantmessagingandpresencefeaturesinSIP[14].
TheTransferHTTPclientAPIcurrentlyexposestheSIPREGISTERmethodsothatabrowsercanregisterwithaSIPnetwork.
ItalsoexposestheSIPMESSAGEmethodtosendmessagesorchatandtheSIPINVITEmethodtomakecallsbetweentwobrowsers.
UsingtheTransfer-HTTPAPI,itwaseasytoimplementtheHTTPsessionmobilityservicepresentedinthispaper.
Otherservices,suchasStreamMediatoCalltobroadcastmediaarealsobasedonthesameAPIs.
Ourextensionalsooffersagraphicaluserinterface,showninFig.
4.
Inparticular,TransferHTTPaddsanewmenutothemenubarinthebrowseranda''Preferences''submenutoletuserseditcongurationparameters.
ThesettingsincludetheSIPproxyaddress/portnumberandtheSIPusername.
Figure4showsthenewmenuandallavailableoptionsinthestatusbar.
The''Makeacall''optionenablesausertomakeaVoIPcalltoanother,andthe''StreamMediatoCall''oneenablesausertostreammediatoanotheruser.
Otheroptions,namely''RegisterClient'',''De-registerClient'',and''AcceptSession,''areusedtoregistertoaSIPRegistrar,de-registertheclientandacceptaWebsessiontransferrequestsenttothebrowser,oncecontrolledandforwardedbyCAS.
ToenjoythefullpotentialofTransferHTTP,developersareadvisedtoFig.
4Theclientfeaturesanduserinterface190WirelessNetw(2012)18:185–197123developXMLUserInterfaceLanguage(XUL)-basedapplications.
XULwasthelanguageusedtodeveloptheMozillaFirefoxuserinterface.
Hence,aXUL-basedapplicationdevelopedbyanyinteresteduserwillbeabletousetheAPIsintheWebbrowserandourextension.
VariousversionsofTransferHTTPextensionareavail-able.
Version1.
2wasmeantforPeer-to-Peerinteraction,version1.
3workedinaclient–serverenvironment,andcurrentversion1.
4supportsalsoVoIPandournoveltheStreamMediatoCallservice.
Thebrowserextension,developedfortheMozillaFirefoxopensourcebrowser,ispubliclyavailableundertheMozillaPublicLicense(MPL).
WehopeWeb2.
0andSIPresearchpractitionerswillcontinuetoextendtheAPIandcreatingmoreinnovativeuser-generatedservices[13].
5.
2CASSIPB2BUAcomponentTheMobicentsCommunicationsPlatformwasusedtoimplementCAS[5].
MobicentsisanopenJava-basedplatformthatenablescreation,deploymentandmanage-mentofservicesandapplicationsthatintegratevoice,videoanddataacrossarangeofInternetProtocol(IP)andcommunicationsnetworkbymultipledevices.
Itimple-mentsanddeliversbothcompetingandinteroperablepro-grammingmodels—JavaAPIsforintegratednetworks(JAIN)servicelogicexecutionenvironment(SLEE),andSIPservlets—todevelopWebandVoIPapplicationsthatworktogether.
CASimplementsWebsessionblockingandforwarding.
AlthoughapplicationscouldbedevelopedusingeitherJAINSLEEorSIPservletsintheMobicentsPlatform,thecurrentimplementationisbasedontheMobicentsSIPservletsprogrammingmodel[15].
WhentheproxyreceivesaSIPrequest,theapplicationrouter(AR),astandardcomponentpartoftheSIPservletsmodel,iscalledbytheMobicentscontainer.
WhenarequestaddressedtoCASarrives,ARselectsourSIPservletapplication—imple-mentingCASsessioncontrollogicforincomingSIPREGISTERandMESSAGErequests—toprocessit.
CASoffersalsoaWebuserinterface(notshownhere)withthreemainpages.
The''SessionTrackingandPickup''pagelogsallsessiontransferrequests,callsetuprequests,andactionstakenonthem.
Foreachsessiontransfer,itprovidesthesourceSIPaddress,thedestinationSIPaddress,theSIPmethod,date,actiontaken(alsoknownasstatus)andthereferredURLinthecaseofasessiontransferrequest.
The''MyAccount''pageenablesausertosetaccesspolicies;informationavailablehereincludesSIPURIswiththeirlog-indetailsandpolicies.
Usingthispage,itispossibletoinstructCASabouthowtohandlecontentsharingandsessiontransferrequests.
Finally,the''BuddyList''pagecontainsalistofhiscontacts;userscanaddnewcontactsandchecktheirBuddyListpagetoseeiftheircontactsareonlineorofine.
5.
3PerformanceresultsWehavethoroughlytestedandevaluatedtheperformanceofourSIP-basedsessionmobilitysolutionbydeployingitinareal-worldtestbed:TransferHTTPextensionrunsatseveralLinuxclientlaptopsequippedwithMozillaFirefoxandthesharedlibrarydevelopedfromPJSIP[12],whileCASSIPservletsexecuteonastandardWindowsXPboxwith3GHzPentium4processorsand1,024MBRAM.
AsoutlinedinSect.
5.
1,theintegrationoftheSIPstackintotheMozillaFirefoxbrowserwasachievedinaloosely-coupledapproachviaXPCOM[13].
Reportedexperimentalresultsfocusonsessionblock-ing/forwardingfunctionsneededtoenablebothourcontentsharingandsessiontransferusecases.
Thereportedeval-uationisaimedbothtoconrmthefeasibilityofthepro-posedapproachandtoinspecttheeffectivenessandtheefciencyofCAS,thatisthecoreandthemostloadedsessioncontrolcomponent,andofTransferHTTP,thatexecutesattheclientsideandthushastobealsocarefullyassessed.
Wehavecollectedfourmainperformanceresults:(1)preliminaryresultsaboutadditionaldelayduetoCASinterpositioninthebrowser-to-browserpath;(2)CASmemoryconsumptionandprocessingdelayunderdifferentloadconditions;(3)CASperformancesundersystemoverload;(4)TransferHTTPmemoryconsumptionattheclientside.
TherstsetofexperimentswasaimedtopreliminarilyassessthelatencyintroducedbyCAS.
Wemeasureditforbothsend/forwardandblock/forbidrequestsandwefocusedonthedelayofMESSAGErequestswithoutcon-sideringTransferHTTPregistrationtimebecausethereg-istrationphaseoccursonlyonce(atuserlogin)anddoesnotaffectuser-perceiveddelaysatruntime.
Inaddition,werepeatedourexperimentundertwodifferentdeployments:inthelocaldeployment,thetwoclients(browsers)andCAShavebeenalldeployedwithinalocalIntranet(a100MbpsEthernet);intheInternetdeployment,wedeployedthetwoclientsattheUniversityofBologna(Italy)andtheCASattheUniversityofCapeTown(SouthAfrica).
Theresultsforthisrsttesthavebeencollectedfarfromoverloadconditions.
Inthelocaldeployment,thelatencyintroducedbyCAStoblock/forbidtherequestisalwayslessthanonesecond(approx.
0.
017s),whileittakeslongertimeforCAStoprocessasend/forwardrequest(approx.
0.
128s).
IntheInternetdeployment,instead,wemeasuredadelayofabout0.
512stoblock/forbidarequestand0.
655stosent/forwardarequestduetobothincreasednetworklatencyandrelativelyfrequentSIPrequestre-transmissionscausedbypacketlossesalongWirelessNetw(2012)18:185–197191123thepath.
Allabovemeasurementshaveexhibitedalimitedvariance,under5%formorethanonehundredruns.
However,theperformanceofthesystemcouldsigni-cantlyimprovewithafasterInternetconnection,especiallygiventherelativelybadconditionsofthenetworktrunksthroughoutAfrica.
ThesecondsetofexperimentsfocusesonCASduringnormalloadconditions.
Table1reportsnumberoffor-biddenandtimed-outresponses,totalnumberofresponses(forbiddenplustimed-outresponses),memoryutilization,CPUusage,andaveragetimeofarequest,fordifferentincrementalloads,goingfrom20messagesto600mes-sagessentataconstantrateof1message-per-second(mps).
TocollecttheseperformanceresultsweusedtheSIPptrafcgenerator,byfocusingmainlyonblock/forbidrequestsbecause,inarealdeployment,weexpecttheyarethemostnumerousones[16].
Werepeatedtheexperimentseveraltimesforeachnumberofrequests:inTable1wereportmeanvaluesand,foreachvalue,itsvarianceinbrackets;asreported,allresultsshowalimitedvariance.
StartingfromCPUusage,CASexecutionimposesalim-itedCPUload,alwaysbelow25%evenforthehighestnumberofrequests(600requests).
Asforthememory,italsoshowedgoodperformances;attheconstantrate,thememoryneededtofullltheincreasingnumberofrequestsisalwaysbelow1.
2MB.
Asforforbiddenandtimed-outresponses,alsoforsakeofcomparisonwithourthirdsetofexperiments,weplotthenumberof(correctly)fullledforbiddenresponses(dashed-and-dottedlineandy-axisontheleftinFig.
5)andthenumberoftimed-outresponses(solidlineandy-axisontheright)againstthetotalnumberofrequests(seeFig.
5).
ForbiddenresponsesgraphislinearandthatdemonstratesthatCASisabletocorrectlyfulll(almost)allreceivedblock/forbidrequests,whilethefewtime-outsthatspo-radicallyoccurareindependentofthenumberofrequests(seeFig.
5).
Finally,letusstressthattheresultspresentedherearebasedonthetechnicalspecicationsoftheWindowsXPboxesCASwasdeployedon;inparticular,todemonstratethewidefeasibilityofoursolution,wetestedCASinastandarddeploymentscenariowithnot-so-powerfulhard-wareandbyusingstandardandnon-optimizedcongura-tionsbothforhostbackgroundservicesandfortheMobicentsserver.
Weobservedthatthetotaltimerequired,memoryconsumption,andCPUusagesignicantlydrop-pedwhenCASwasdeployedandtestedonahighper-formancePC(aCore2DuoPC).
ThethirdsetofexperimentspointsouttheCASscala-bilityandcorrectnessunderheavy-loadcondition.
TostressCAS,ineachtestrunwegeneratedandsenttoCASseveralnon-authorizedsessionmobilityrequeststobeblocked.
Inparticular,weheavilyloadedCASbyusingthepjsip-perfSIPtrafcgeneratorastheperformancemeasurementtool.
Pjsip-perfexecutedattheclienthost,sendsburstsofSIPTable1CASperformanceundernormalloadconditionsNoofrequestsNoofforbiddenresponsesNooftimeoutresponsesTotalresponsesMemoryconsumption(KB)CPUusage(%)2020(0.
58)0(0)20(0)1,036(13.
05)21(0.
58)4032(0.
58)8(2.
08)40(0)875(12.
09)21(1)6059(1)1(1)60(0)900(15.
82)21(0.
58)10098(0.
58)2(0.
58)100(0)580(12.
58)24(2.
08)120120(0.
58)0(0.
58)120(0)700(13.
23)21(2.
02)150149(0.
58)1(0.
58)150(0)500(7.
64)24(1)200198(1)2(1)200(0)1,100(28.
34)24(1.
73)250246(2.
08)4(1)250(0)448(9.
87)24(0.
58)300297(2.
02)3(1.
15)300(0)1,200(13.
10)24(2.
33)400397(2.
52)3(1)400(0)520(10)21(1)500494(2.
33)6(2)500(0)1,150(11.
45)24(1.
15)600598(3.
05)2(0.
58)600(0)1,006(19.
78)24(1)No.
ofrequests,fullled/timeout/totalresponses,memory,andCPUusageFig.
5CASrequestversusresponseperformancegraphundernormalloadconditions192WirelessNetw(2012)18:185–197123MESSAGEmessages,goingfrom20to600messages-per-burst,attheveryhighandchallengingfrequencyrateof677mps[17].
TheresultingaverageresponsetimeofCASvariedfrom10,558to48,557ms,andtheaveragenumberofSIPresponsemessageswasmorethantheaveragenumberofSIPrequests.
Forexample,when250SIPMESSAGErequestsweresent,thenumberofSIPresponseswas276.
ThereasonwhythenumberofresponsesishigherthanthenumberofrequestsisthatSIPsupportsmultipleresponsestoarequest.
TheresponseswereSIP403ForbiddenandSIP408RequestTimeout(formessagesthattimed-outatCASduetothedelaycausedbyexcessiveoverload).
Figure6showsCASbehaviorunderheavy-loadcondi-tions(thesametypeofgraphshowninFig.
5fornormalloadconditionswiththeonlydifferencethatthereisoneonlyy-axisontheleft).
WeobservedthatCASoptimumperformanceisreachedataround100SIPMESSAGErequests:atthispoint,CAScanstillgenerateequalnumberofcorrectSIPresponses(SIP403Forbidden).
ThenumberofSIP408Timeoutgraduallyincreasesasthenumberofrequestsincreased,startingfrom99SIPMESSAGErequests,thusshowinghowCASperformancedegradesundersystemoverload.
Testresultsalsoshowthattheservercouldnotblockallrequests:CASwasabletorespondtoanaveragenumberof73requests(outofthe600requests)inlessthantheresponsetimeoutsetattheclient(whichwas32s),whileanaverageof531requestsexpiredattheclientduetotimeout(seeFig.
6).
Inanycase,requestswerequeuedatCASthatgeneratedrespon-seslateronasseenfromourtestlogs;thatletusexcludememory(MobicentsSIPmessagequeuelength)asapos-sibleCASbottleneck.
Hence,webelievethatCASbot-tleneckisthenumberofJavathreadsdevotedtoCASservletexecutioninMobicents.
TocompletelyassesstheCAScomponentundersystemoverloadconditions,wealsocollectedmemoryconsump-tion.
AsFig.
7shows,CASmemoryconsumptiongradu-allyincreasedasthenumberofSIPMESSAGErequestsintheburstincreases.
Thereasonisthatthenumberofthreadsrequiredtoprocesstherequestsincreases;hence,thereisanincrementinthememoryrequiredtoprocesstherequests.
Inparticular,ourexperimentassessedCASmemoryusageunderdifferentworkingconditions.
Firstofall,weexperimentallyveriedthatourCAScomponent—whichhasbeenrealizedasaJava-basedMobicentsSIPservletapplication—canoccupytwomainruntimeexecu-tionstatesthatwecallidleandnon-idle.
InordertoreducethememoryconsumptiononthePC,CASgoesintotheidlestatewhenever,foracertaintimeperiod,thereisnoSIPmessagetorespondto;inthatcase,ittakessometimeforCAStorespondtoeveryrstsubsequentrequest(duetoservletre-activation).
Inidlestate,CASmemoryusage,collectedbyusingthesystemperformancemonitor(WindowsTaskManager),isapproximately206MBoutofthe1GBRAMintheWindowsbox.
Inthenon-idlestate,CASmemorycon-sumptionincreasedbyapproximately2.
12MBwhenaburstof20SIPMESSAGEmessageswassenttoitandby13MBwhenaburstof600SIPMESSAGEmessageswassenttoit(seeFig.
7),whileatitsoptimumperformance,around100SIPMESSAGErequests,itsmemorycon-sumptionincreaseis5.
5MB.
Finally,weobservedthatCASCPUusagewasalwaysat100%duringtheentiresystemoverloadtest.
Ourfourth(andlast)setofexperimentsevaluatedthecostofrunningourlightweightTransferHTTPextensionattheclientside.
Weusedthestandardsystemmonitoringtool,availableonUbuntuoperatingsystem,toviewcurrentprocessesandtogatherthememoryconsumptiondata.
Duringthetests,thebrowserwasusedtobrowsetheInternetandtomoveongoingsession(byusingbothcon-tentsharingandsessiontransferfacilities);VoIPandStreamMediatoCallserviceshavealsobeeninvokedduringthetestruns.
Table2showsthebrowser'smemoryconsumptiontest.
TheSIPstackexecutionasabackgroundservicecausedaverycontainedandlowbrowser'smemoryconsumptionincrease(TransferHTTPoverhead)of5.
83MBonaverage.
Fig.
6CASrequestversusresponseperformancegraphunderoverloadconditionsFig.
7CASmemoryconsumptiongraphWirelessNetw(2012)18:185–197193123Findingsshowedalsothatthebrowserneithercrashednorfroze,evenwhenrunningtheSIPstackasabackgroundserviceforverylong-runtestsupto4h.
6RelatedworkanddiscussionThissectionoverviewsmainrelatedworkandongoingeffortsonsessionmobilityandcomparesthem,mostespeciallytherecentGoogleWaveproposalwithoursolution.
Inaddition,wediscussthebenetsofourapproachbysummarizingourmaintechnicalcontributions.
6.
1RelatedworkHTTPsessionmobilityhasbeencarriedoutusingdifferentschemes,namelyclient-based,server-basedandproxy-basedarchitecturalschemes[2–4].
Aclient-basedarchi-tecturalschemerequiresmodifyingtheuseragentclient(UAC)andaserver-basedarchitecturalschemerequiresmodifyingtheuseragentserver(UAS).
UACandUAS,here,refertoaWebbrowserandWebserver,respectively.
Insomecases,aProxycanbeplacedalongthecommu-nicationpathoftheclientandtheserver.
Thisiscalledaproxy-basedarchitecturalscheme.
Whiletheproxy-basedarchitecturalscheme[2]violatestheHTTP1.
1securityduringitsimplementation,theclient-basedarchitecturalscheme[4]requiresarepositoryserver,whichremainsidlewhenthewebclientisinuse.
Thatis,itdoesnotactasawebcacheorasessiontracker.
Inaddition,itcanonlyworkwhenawebsessionhasnotexpired,andtheuseofarepositoryserverdoesnotmakeitanintrinsicclient-basedarchitecturalscheme.
However,itisworthmentioningthatmostresearchonmobilityfocusesonterminalorhostmobility.
ExamplesincludeJanetal.
[18],Snoerenetal.
[19],Atiquzzamanetal.
[20,21]andStewartetal.
[22].
Intermsofpersonalmobility,approachesthathavebeenusedincludeDiStefanoetal.
[23],Roussopoulosetal.
[24],Appenzelleretal.
[25],Liscanoetal.
[26],Hermanetal.
[27],Raati-kainen[28]andBagrodiaetal.
[29].
TheseprojectsaddressproblemsrelatedtoMobileIPandusingmiddlewareformobilenetworks,tomentionafew.
AnotherareathatiscurrentlyexploredisMediaInde-pendentHandover(MIH)betweenheterogeneousnetworks.
TheIEEE802.
21workinggroupisdesigningaframeworkthatallowsmobileterminalstogetinformationaboutnearbynetworksbeforeperformingahandover.
SomeoftheworksthathaveexploredMIHareSilvanaandSchulzrinne[30],LampropoulousandPassas[31]andTsagkaropoulosetal.
[32].
WhatdistinguishesourproposalfromthosementionedaboveisthatitaddressesHTTPsessionmobility,whilethosementionedaboveaddressterminalmobility.
Inaddition,ourproposaladdressesHTTPsessionmobilityattheapplicationlayer,whilethosementionedaboveaddressterminalmobilitynotonlyintheapplicationlayer,butalsootherOSIlayers.
ProjectsthattookadvantageofSIPextensibilityincludeworkbyShachametal.
[33]andtheAkogrimoproject[34].
WhileShachametal.
'swork[33]exten-sivelyexploressessionmobilityissues,alsorelatedtotheuseoftheSIPREFERmessage,theAkogrimoproject[34]involvesembeddingWebservicedatainasessiondescriptionprotocol(SDP).
AlthoughtheREFERmethodisastandardizedmechanismtoredirecttheongoingses-sionbetweenanoldandanewsessionSIPendpoint,itsusealonedoesnotcoverthemorecomplexcontentsharingandsessiontransferproblems.
Totackletheseissues,inanexpiredIETFInternetdraft[35],twoapproacheswereidentiedfortransferringURLbetweentwoWebbrowsers.
TherstapproachwasbysendingtheURLviaaSIPMESSAGEmethod:thisapproachiswhatthisworkisbasedon.
ThesecondapproachwasbyusingSIPNOTIFYmethod.
ThatapproachwasdescribedasawayofachievingconferencemodelofWebbrowsing,wherebyabrowsercouldbenotiedwhenaWebpage,onanotherbrowser,haschanged.
Althoughtheapproa-cheswerenotstandardized,theyshoweddifferentwaysofachievingWebshareusingSIPMESSAGEandNOTIFYmethods.
AnotherprojectthatexploitstheSIPextensibilityandverysimilartothisresearchwascarriedoutbyMunk-ongpitakhunetal.
[36].
Intheproject,aSIPstackisalsointegratedintoaWebbrowser,andaSIPMESSAGEmethodisusedtotransfersessiondataaswell.
Althoughitisverysimilartoourproposal,theproject,likeotherrelatedworkonHTTPsessionmobility,onlyaddressessessiontransferandnotcontentsharing.
Inaddition,intermsofthesignaling,twowebbrowsershavetoestab-lishacallsessionusingaSIPINVITEmethodbeforeasessionhandoffcantakeplace.
Hence,thatapproachintroducesunnecessaryoverheadsinthesignalinganditisnotclearifusersneedtobeinvolvedinamultimediasession,suchasvoicecall,beforesessionhandoffcantakeplace.
Finally,implementationdetailsabout[36]arelimitedandnosoftwareisavailabletoconrmtheirndings.
Table2WebbrowsermemoryconsumptiontestBeginning2h4hWithoutSIPstackintegration11.
311.
611.
9WithSIPstackintegration16.
71718.
6MemoryconsumptionexpressedinMB194WirelessNetw(2012)18:185–1971236.
2Discussingemergingweb2.
0modelsandtools:parlay,Googlewave,andTransferHTTPTheneedforOpenAPIsisgreatlyincreasing[14,37,38].
TheAPIsareneededforuser-generatedservices.
AlthoughthereareAPIs,suchasGoogleAPIsandParlay-XAPIs,fordevelopingWeb2.
0applicationsandbasicWebserviceAPIsforaccesstocircuit-switched,packet-switched,andIMSnetworks,theyfallshortofenablinginnovativecon-vergedapplicationsorservicesfromusers.
OpenstandardAPIsaredesirableforintroducingnewservicesbecausetheymaketheseparationbetweentheapplicationandtheplatformexplicit.
Theyallowapplica-tionportabilityandallowthefunctionsoftheplatformtobeusedbymultipleapplicationseasily.
APIsareapplica-tion-centric,whileprotocolsarenetwork-centric.
APIsallowprogrammerstofocusonthelogicalowofappli-cationsusingonlythenecessaryfunctionsprovidedbytheplatform,ratherthanconcerningthemselveswithlow-leveldetailsofmessagesthatmustowacrossthenetwork.
Asaresult,awell-denedAPIallowstheapplicationpro-grammertoworkatahigherlevelofabstractionthanthatoftheprotocol[39].
TheSIPAPIreectstheSIPprotocolfairlyclosely[40,41].
ItisusefulforsituationswheretheapplicationisrathersimpleandwheretheunderlyingnetworkisanIPnetwork.
However,theSIPAPIisatalowerlevelofabstractionthanthecallcontrolAPIs,suchasJAINandParlayAPIs.
Asaresult,itofferstheprogrammernergrainedcontrolandbetterperformancethancallcontrolAPIs.
Anotheropenmessagingandpresenceprotocolthatiswidelyusedisextensiblemessagingandpresenceprotocol(XMPP)[42].
ItsAPIshavebeenusedtodevelopXMPPclientssuchastheGoogleTalkandPidgin.
Itisgainingwideacceptanceinthesoftwareindustry,whereitisbeingusedtodevelopcommunicationandcollaborativetools.
ExamplesofsharedapplicationsbuiltwithXMPParesharedwhiteboardandchessboard[43].
AnotherworkthatiscurrentlyexploitingXMPPistheGoogleWave.
TheGoogleWaveprojectcurrentlylookspromisingforapplicationdevelopersbutitisstilllimitedinfunctionality.
TheParlay-XAPIsarealreadyclaimedtohaveverylim-itedfunctionality[37].
Thereasonisthattheyarenotdesignedtohandlethedatamodelfortheentireserviceorsignalingintelecommunications.
Table3showsthecomparisonofourworkwiththeGoogleWave.
GoogleWaveusestheopenXMPPproto-col,soanyonecanbuildtheirownWavesystem[44,45].
TheGoogleWaveAPIallowsdeveloperstouseandenhanceGoogleWavethroughtwoprimarytypesofdevelopment,namelyExtensionsandEmbed.
TheExten-sionsrepresenttheserverside,whiletheEmbedrepresentstheclientside.
Theextensions(alsocalledtheRobotsAPI)canbedevelopedusingtheJavaClientLibrary,PythonClientLibrary,orGadgetsAPI,whiletheembed,whichisembeddedintoaWebapplication,isalwayswritteninJavaScript.
TheGoogleWaveandTransferHTTPprovidethesameservices,thoughoverdifferentarchitectures.
WhileGoogleWaveAPIisusedtodevelopapplicationsthatresideonaWebserver,TransferHTTPAPIsareusedtodevelopapplicationsthatresideattheclientend.
Forexample,theClick-to-dialinGoogleWave[46]requirestheservertosetupacallsession,whileinTransferHTTP,theclientsetsupthecallsession.
InGoogleWave,therobotintheWebserverisresponsibleforinitiatingthesignaling,whileinTransferHTTP,theSIPstackinthebrowserexecutesthesignalingdirectly.
Fromaratherimplementationpointofview,theXMPPstackintheGoogleWaveresidesattheserver,anditsAPIsarewrittenforthird-partiestohelpthemdevelopcon-vergedapplications[42].
TheGoogleteamhasseparatedthesignaling(HTTPandXMPP)inabidtomaintainthecurrentWebarchitecture.
Hence,itcouldbereferredtoasaserver-basedarchitecturalframeworkforservicecreation.
Inourwork,theSIPstackisintegratedintoabrowsertoprovidesimilarservices.
Aswedemonstrated,theinte-grationofaSIPstackintothebrowserdoesnotimpedeitsperformance(seeTable2),therebymakingourworkaviableapproachtocreateconvergedservices.
Inparticular,weprovideahybrid-basedarchitecturalframeworkinwhichservicesareprovidedbyboththeclient,usingourAPI(TransferHTTPextension),andtheproxy,usingtheCAScomponenttopreventtheabuseoftheservicesofferedbytheclient.
Hence,proxiescanparticipatetosessioncontrolsotofacilitateinteractionsbetweenthebrowsers.
WhiletheproxyservicescanbedevelopedusingtheMobicentsSIPServletsandJAINSLEEAPIs,theclientservicescanbedevelopedusingourTransferHTTPextensionAPI.
Insummary,irrespectiveofthetechnologiesorpro-gramminglanguagesusedintheGoogleWaveandTransferHTTP,thedifferencebetweenthemisthattheGoogleWaveonlyhasastack(anXMPPstack)initsserver,therebymakingitaserver-basedarchitecturalframeworkforservicecreation.
TransferHTTP,instead,hasastack(aSIPstack)initsbothclientandproxy,Table3ComparisonofGooglewaveandTransferHTTPCASGooglewaveTransferHTTPCASTechnologiesClientHTMLandJavaScriptXULandJavaScriptServerPython/Java/GadgetJava(HTTP/SIPServlet)ArchitectureServer-basedHybrid-basedProtocolWave(XMPPextension)SIPWirelessNetw(2012)18:185–197195123therebymakingitamorepowerfulhybrid-basedarchitec-turalframeworkforservicecreation.
7ConclusionWehaveshowntheHTTPsessionmobilityservicesavailableinourbrowserextensionandproxyserver.
TheseconvergedservicesmixHTTPandSIPprotocolstoenhanceWeb2.
0userexperience.
Servicesintheproxy,calledcontrolservices,preventabuseoftheclientservices.
Inaddition,examplesofnovelSIP-basedWeb2.
0servicemashups,includingalsoVoIPandstreammediatocallservicearediscussed.
PerformanceresultsobtainedfromTransferHTTPandCASshowedthattheservicesattheclientandproxyarenotmemoryintensiveunderbothlowtrafcandsystemoverloadconditions.
TheyalsoprovethatourreferencesystemcanbeprovisionedwithoutnecessarilyusinghighperformancePCs.
Currently,thereisnoagreementonwhatthefutureInternettechnologywilllooklike.
ItishoweverratherclearthattheonlineexperiencecanonlybeimprovedwhenthereareadditionalprotocolsthatHTTPcouldinteractwith.
Infact,althoughtheapproachestoimplementtheservicesmightvary,theconvergenceofInternet,telecommunica-tions,andbroadcastingwillenablethecreationofmulti-protocolapplicationsservicesthatwerenotpossiblebefore.
Theobtainedpromisingresultsarestimulatingfurtherresearchactivities.
Ontheonehand,wearedesigninganewTransferHTTPversionabletosupportnewemergingsessionprotocols,suchasIMS.
Ontheotherhand,weareextensivelyevaluatingandtuningtheperformanceofourCAScomponentoverwide-scaleemulatedenvironments.
OpenAccessThisarticleisdistributedunderthetermsoftheCreativeCommonsAttributionNoncommercialLicensewhichper-mitsanynoncommercialuse,distribution,andreproductioninanymedium,providedtheoriginalauthor(s)andsourcearecredited.
References1.
MozillaAdd-on.
(2011).
https://www.
addons.
mozilla.
org/.
Acce-ssedMarch2011.
2.
Canfora,G.
,DiSanto,G.
,Venturi,G.
,Zimeo,E.
,&Zito,M.
V.
(2005).
Proxy-basedHandoffofwebsessionsforusermobility.
InProceedingsofInternationalconferenceonmobileandubiq-uitoussystems:Networkingandservices(MobiQuitous'05).
doi:10.
1109/MOBIQUITOUS.
2005.
50.
3.
Hsieh,M.
-D.
,Wang,T.
-P.
,Tsai,C.
-S.
,&Tseng,C.
-C.
(2006).
StatefulsessionhandoffformobileWWW.
InformationSciences,ElsevierSciencePress,176(9),1241–1265.
4.
Song,H.
(2002).
Browsersessionpreservationandmigration.
InPostersessionofworldwideweb(WWW).
ISBN:1-880672-20-0.
5.
TheMobicentsOpenSourceSLEEandSIPServer.
(2011).
http://www.
mobicents.
org/index.
html.
AccessedMarch2011.
6.
Adeyeye,M.
,Ventura,N.
,&Humphrey,D.
(2009).
MappingthirdpartycallcontrolandsessionhandoffinSIPmobilitytocontentsharingandsessionhandoffintheweb-browsingcontext.
InProceedingsofIEEEwirelesscommunicationsandnetworkingconference(WCNC).
doi:10.
1109/WCNC.
2009.
4917800.
7.
Adeyeye,M.
(2008).
ASIPintegratedwebbrowserforHTTPsessionmobilityandmultimediaservices.
UnpublishedMaster'sthesis,UniversityofCapeTown,SouthAfrica.
8.
Adeyeye,M.
,Ventura,N.
,&Humphrey,D.
(2009).
ASIP-basedwebsessionmigrationservice.
InProceedingsofthe5thwebInternationalconferenceonwebinformationsystemsandtechnologies(WEBIST).
9.
Rosenberg,J.
,Schulzrinne,H.
,Camarillo,G.
,Johnston,A.
,Peterson,J.
,Sparks,R.
,etal.
(2002).
SIP:Sessioninitiationprotocol.
IETFRFC3261.
10.
Camarillo,G.
,&Garca-Martn,M.
-A.
(2005).
The3GIPmul-timediasubsystem(IMS).
WestSussex,England:Wiley.
11.
Gurbani,V.
K.
,&Sun,X.
-H.
(2004).
Terminatingtelephonyservicesontheinternet.
IEEE/ACMTransactionsonNetworking,12(4),571–581.
12.
ThePJSIPStack.
(2011).
http://www.
pjsip.
org.
Accessed3March2011.
13.
TheTransferHTTPWebbrowserExtension.
(2008).
http://www.
transferhttp.
mozdev.
org.
AccessedMarch2011.
14.
Schonwalder,J.
,Fouquet,M.
,&Rodosek,G.
D.
(2009).
FutureInternet=ContentServicesManagement.
IEEECommu-nicationsMagazine,47(5),27–33.
15.
MobicentsSIPServletsServerUserGuide.
(2011).
http://www.
hudson.
jboss.
org/hudson/view/Mobicents/job/MobicentsBooks/lastSuccessfulBuild/artifact/sip-servlets/index.
html.
AccessedMarch2011.
16.
SIPpTestTool.
(2009).
http://www.
sipp.
sourceforge.
net.
AccessedMarch2011.
17.
PJSIP-PERFTestTool.
(2009).
http://www.
pjsip.
org/pjsip/docs/html/page_pjsip_perf_c.
htm.
AccessedMarch2011.
18.
Jan,R.
(1999).
EnhancingsurvivabilityofmobileInternetaccessusingmobileIPwithlocationregisters.
InProceedingsofIEEEINFOCOMM,vol.
1,pp.
3–11.
19.
Snoeren,A.
C.
,&Balakrishnan,H.
(2000).
Anend-to-endapproachtohostmobility.
InProceedingsofACMMOBICOM.
doi:10.
1145/345910.
345938.
20.
Atiquzzaman,M.
,Fu,S.
,&Ivancic,W.
(2004).
TraSH-SN:Atransportlayerseamlesshandoffschemeforspacenetworks.
InProceedingsoffourthearthsciencetechnologyconference(ESTC).
doi:10.
1.
1.
74.
1729.
21.
Fu,S.
,&Attiquzzaman,M.
(2004).
SCTP:Stateoftheartinresearch,products,andtechnicalchallenges.
IEEECommunica-tionsMagazine,42(4),64–76.
22.
Stewart,R.
,&Metz,C.
(2001).
SCTP:NewtransportprotocolforTCP/IP.
IEEEInternetComputing,5(6),64–69.
23.
DiStefano,A.
,&Santoro,C.
(2000).
NetChaser:Agentsupportforpersonalmobility.
IEEEInternetComputing,4(2),74–79.
24.
Roussopoulos,M.
,Maniatis,P.
,Swierk,E.
,Lai,K.
,Appenzeller,G.
,&Baker,M.
(1999).
Person-levelroutinginthemobilepeoplearchitecture.
InProceedingsofUSENIXSymposiumonInternetTechnologiesandSystems,vol.
1,pp165–176.
25.
Maniatis,P.
,Roussopoulos,M.
,Swierk,E.
,Lai,K.
,Appenzeller,G.
,Zhao,X.
,etal.
(1999).
Themobilepeoplearchitecture.
ACMSIGMOBILEMobileComputingandCommunicationsReview,3(3),36–42.
196WirelessNetw(2012)18:185–19712326.
Liscano,R.
,Impey,R.
,Qinxin,Y.
,&Abu-Hakima,S.
(1997).
Integratingmulti-modalmessagesacrossheterogeneousNet-works.
InProceedingsofENM-97,inconjunctionwithIEEEICC'97.
doi:10.
1109/ENM.
1997.
596869.
27.
Rao,C.
H.
H.
,Chen,Y.
-F.
R.
,Chang,D.
-F.
,&Chen,M.
-F.
(2001).
iMobile:Aproxy-basedplatformformobileservices.
InProceedingsoftherstworkshoponwirelessmobileinternet.
doi:10.
1145/381472.
381483.
28.
Raatikainen,K.
(2001).
Middlewareforfuturemobilenetworks.
InProceedingsofIEEEInt.
Conf.
on3Gwirelessandbeyond.
ISSN:152902592.
29.
Bagrodia,R.
,Bhattacharyya,S.
,Cheng,F.
,Gerding,S.
,Glazer,G.
,Guy,R.
,etal.
(2003).
iMASH:Interactivemobileapplicationsessionhandoff.
InProceedingsoftheACMInternationalcon-ferenceonmobilesystems,applications,andservices(MobiSys).
doi:10.
1145/1066116.
1066124.
30.
GrecoPolito,S.
,&Schulzrinne,H.
(2008).
SIPand802.
21forservicemobilityandpro-activeauthentication.
InProceedingsoftheCommunicationNetworksandServicesResearchConf.
(CNSR).
doi:10.
1109/CNSR.
2008.
61.
31.
Lampropoulos,G.
,&Passas,N.
(2008).
Media-independenthandoverforseamlessserviceprovisioninheterogeneousnet-works.
IEEECommunicationMagazine,46(1),64–71.
32.
Tsagkaropoulos,M.
,Politis,I.
,Kotsopoulos,S.
,&Dagiuklas,T.
(2009).
Enhancedverticalhandoverbasedon802.
21frameworkforreal-timevideostreaming.
InProceedingsofthe5thInter-nationalmobilemultimediacommunicationsconference(MOBI-MEDIA'09).
doi:10.
4108/ICST.
MOBIMEDIA2009.
7347.
33.
Shacham,R.
,Schulzrinne,H.
,Thakolsri,S.
,&Kellerer,W.
(2007).
Ubiquitousdevicepersonalizationanduse:ThenextgenerationofIPmultimediacommunications.
ACMTransactiononMultimediaComputing,CommunicationsandApplications,3(2),1–20.
34.
TheAkogrimoProject.
(2011).
http://www.
mobilegrids.
org.
AccessedMarch2011.
35.
Wu,X.
,&Schulzrinne,H.
(2001).
UseSIPMESSAGEmethodforsharedwebbrowsing.
http://www3.
tools.
ietf.
org/id/draft-wu-sipping-Webshare-00.
txt.
Accessed14Nov2001.
36.
Munkongpitakkun,W.
,Kamolphiwong,S.
,&Sae-Wong,S.
(2007).
EnhancedwebsessionmobilitybasedonSIP.
InPro-ceedingsofthe4thInt.
conferenceonmobiletechnology,appli-cationsandsystems(mobility).
doi:10.
1145/1378063.
1378119.
37.
Mulligan,C.
E.
A.
(2009).
OpenAPIstandardizationfortheNGNplatform.
IEEECommunicationsMagazine,47(5),108–113.
38.
Krechmer,K.
(2009).
Openstandards:Acallforchange.
IEEECommunicationsMagazine,47(5),88–94.
39.
Jain,R.
,Bakker,J.
,&Anjum,F.
(2005).
Programmingcon-vergednetworks:CallcontrolinJava,XML,andParlay/OSA(1sted.
).
Canada:Wiley.
40.
Bhat,R.
R.
,&Tait,D.
(2001).
JAVAAPIsforintegratednet-works.
InT.
Jespen(Ed.
),Javaintelecommunications:Solutionsfornextgenerationnetworks(p.
193).
NewYork:Wiley.
41.
SunMicrosystems,JAINSIPRelease1.
1Specication.
(2006).
http://www.
jcp.
org/en/jsr/detailid=32.
AccessedMarch2011.
42.
Saint-Andre,P.
(2004).
Extensiblemessagingandpresencepro-tocol(XMPP):Core.
IETFRFC3920.
43.
WebSharingandRichDraw.
(2007).
http://www.
hyperstruct.
net/2007/2/24/xml-sync-islands-let-the-Web-sharing-begin.
AccessedMarch2011.
44.
TheWaveProtocol.
(2009).
http://www.
waveprotocol.
org.
AccessedMarch2011.
45.
TheGoogleWaveProject.
(2009).
http://www.
wave.
google.
org.
AccessedMarch2011.
46.
TheGoogleWaveClick-to-dial.
(2009).
http://www.
googlewavedev.
blogspot.
com/2009/06/twiliobot-bringing-phone-conversations.
html.
AccessedMarch2011.
AuthorBiographiesMichaelAdeyeyeisaResearchFellowattheCapePeninsulaUniversityofTechnology,SouthAfricaandaResearchAssociateattheUniversityofCapeTown,SouthAfrica,whereheearnedhissecondMasterandPh.
D.
degrees.
HisresearchinterestsincludeWebandmultimediaservicemobilitytechnologiesandcontextawareness,multimodalandmulti-channelaccess,Web2.
0andmobileapplications,andNextGenerationNetwork(NGN)applicationsandservices.
HeisaMemberoftheIEEE.
NecoVenturaistheHeadoftheCentreforBroadbandNet-worksandtheDirectoroftheCommunicationsResearchGroupintheDepartmentofElectricalEngineeringattheUniversityofCapeTown(UCT),SouthAfrica.
Hiscur-rentresearchinterestsarecen-teredonNextGenerationarchitectures,infrastructures,specicallyinQoSandmobilitysupportacrossheterogeneousnetworks.
HeisaMemberofIEEE.
LucaFoschiniisaResearchFellowattheUniversityofBologna,Italy.
In2007,hereceivedaPh.
D.
degreeincomputerscienceengineeringfromUniversityofBologna.
Hisresearchinterestsincludedis-tributedsystemsandsolutionsforpervasivecomputingenvi-ronments,systemandservicemanagement,context-awareservicesandadaptivemulti-media,andmobileagent-basedmiddlewaresolutions.
HeisaMemberofIEEEandACM.
WirelessNetw(2012)18:185–197197123