Mobile Internet WebRTC and Related Technologies.docx

Mobile Internet WebRTC and Related Technologies.docx

《Mobile Internet WebRTC and Related Technologies.docx》由会员分享，可在线阅读，更多相关《Mobile Internet WebRTC and Related Technologies.docx（6页珍藏版）》请在冰豆网上搜索。

MobileInternetWebRTCandRelatedTechnologies

MobileInternetWebRTCandRelatedTechnologies

　　Abstract

　　ThispaperdescribesanimproveddesignforWebRTCtechnology.Withthisdesign，WebRTCcommunicationatclientside，serverside，andbetweenthesetwosidesisimproved.HTML5WebSocket，medianegotiationandsynthesis，networkaddresstranslator（NAT）/firewalltraversal，SessionInitiationProtocol（SIP）signalinginteraction，andP2Pcommunicationsecurityareallusedinthisimproveddesign.Thissolutionsolvescross-browserrunningproblemofWebRTCapplications，reducesrelianceonclient-sideprocessingcapability，andreducesbandwidthconsumption.Withthisdesign，WebRTCalsobecomemorescalable.

　　Keywords

　　WebRTCtechnology；applicationmodel；runningacrossbrowsers；extension

　　1Introduction

　　WebReal-TimeCommunication（WebRTC）[1]isareal-timeaudioandvideocommunicationtechnologybasedonWebbrowsers.ItenablesdeveloperstousesimpleWebtechnologiestoquicklyandeasilydeveloprich，real-timeonlinemultimediaapplicationswithoutinstallinganyplug-ins.

　　AsnetworkbandwidthandWebbrowserscontinuetoimprove，WebRTCwillhaveahugeimpactontraditionalreal-timecommunication，anditisgraduallybecomingamainstreamreal-timecommunicationtechnology.GooglehasprovidedWebRTCsupportinitsnewversionofChromeontheAndroidplatform.ItispredictedthatatleastonebillionterminalswillsupportWebRTCin2013.InaninvestigationresultsbyCTI[2]，aconvergedcommunicationsforuminChina，87%ofthetelecomcompaniesinthesurveyareconsideringmakingWebRTCpartoftheirproductstrategies；86.9%ofthesecompaniessaythatWebRTCisasignificantpartoftheiroverallproductstrategies；and49%ofthesecompaniesintendtodeployWebRTCsolutionswithinayear.

　　WebRTCisdevelopedbyGlobalIPSolutionCorporation，whichwasacquiredbyGooglein2010.Afterthisacquisition，GoogledecidedtoopenWebRTCtechnologytothepublic.BoththeWorldWideWebConsortium（W3C）andInternetEngineeringTaskForce（IETF）haveformedWebRTCstandardizationgroups，andWebRTCstandardsarebeingsupportedbymoreandmoremanufacturerswithintheindustry.

　　Comparedwithtraditionalcommunicationtechnologies，WebRTChasthefollowingadvantages：

　　?

Itiseasytouse，andplug-insordifferentplatformclientapplicationsdonotneedtobeinstalled.

　　?

Itprovidesaconsistentuserexperience.

　　?

Itcanbequicklyandeasilyupgradedattheserverside.　　?

OnthebasisofWebRTC，webinstantcommunicationservicescanbedevelopedwithJavaScriptorHTML.

　　?

Itcanrunacrossoperatingsystems，whichmeansthatdevelopersdonotneedtodevelopdifferentapplicationversionsfordifferentoperatingsystem.

　　?

Developerscanfocusonservicesratherthanmediaprocessing.

　　2WebRTCStandardProgress

　　W3CandIETFareresponsiblefordevelopingWebRTCstandards，butthesegroupshaveadifferenttarget.

　　TheW3CWebRTCworkinggroupaimsatdefiningclient-sideJavascriptAPIs.WiththeseAPIs，Webapplicationscancompletepoint-to-pointorpoint-to-multipointreal-timecommunicationbetweenbrowsers.KeymembersoftheW3CWebRTCworkinggroupareWebbrowservendors，suchasGoogle，Mozilla，andOpera.

　　TheIETFRTC-Webworkinggroupdefinesreal-timecommunicationprotocolsandmediaformatsbetweenbrowsers.Thatis，itfocusesonmediacodecs，networktransmission，NetworkAddressTranslator（NAT）/firewalltraversal，security，privacy，etc.KeymembersofIETFRTC-WebareMicrosoft，Google，Skype，Yahoo！

，Cisco，andFT（Orange）.

　　Initially，WebRTCstandardshavethreetypesofAPIs：

NetWorkStream，RTCPeerConnection，andDataChannel.NetWorkStreamAPIisusedforusermediaacquisition；RTCPeerConnectionAPIisusedtoestablishconnectivitybetweenbrowsers；andDataChannelAPIisusedtotransmituserdataexceptvideoandaudiostreamfromcameraormicrophone.BothNetWorkStreamAPIandRTCPeerConnectionAPIweredevelopedearlierthanDataChannelAPIandareusedmorewidely.NetWorkStreamAPIisindependentfromWebRTCstandardinrecentversion.

　　AsWebRTCstandardsmature，theyarebeingsupportedbymoreandmoremodernbrowsers（Table1）.

　　ToverifytheeffectivenessofWebRTCinWebinstantcommunication，browservendorsGoogleandMozillaandthirdparties，suchasMobicents[3]（aVoIPmiddlewareplatformprovideracquiredbyRedHat），Livecome[4]（acommunicationservicesolutionprovider），andsomeWebdevelopers，havedevelopedtheirownWebRTCdemos.EachoftheseWebRTCdemoscanbeexperiencedwithacameraandamicrophoneinWebRTC-supportedbrowsers.

　　3WebRTCApplicationModes

　　3.1AddingWebRTCAccesstoTraditionalAudioand

　　VideoServices

　　TelecomoperatorsandsolutionproviderstreatWebRTCasanewaccessmodefortheirtraditionalaudioandvideoservices.Forexample，usersaccessatraditionalcallcenterbasedonwebbrowser，andthebrowserbecomesanewterminalofatraditionalconferencesystem.　　ThedifficultyofthismodeisensuringcompatibilitybetweentheWebRTCandtraditionalapplicationarchitecture.AgatewaydeviceisaddedbetweenWebRTCandthetraditionalapplicationarchitectureinordertocoordinatedifferencesbetweenthem.Forexample，inZTE’sWebRTC-IMSgatewayaccesssolution，theWebRTC-IMSgatewayisresponsibleforsignalingconversion，mediastreamingrelay，andNAT/firewalltraversalmechanismconversionbetweenWebRTCandtraditionalIMSnetworks.

　　Theadvantagesofthissolutionare：

　　?

Abrowseraccessmodeisaddedintraditionalaudio/videoserviceandnobrowser-sideplug-insneedtobedeveloped.Thiswillgreatlyreducesclient-sidework.

　　?

MediaprocessingcapabilitiesofWebRTCarestrengthened，anduserexperienceisimprovedbyreusingMediaServerintraditionalarchitecture.

　　?

Dependencyonclient-sideprocessingcapabilityisreducedandnetworkbandwidthconsumptionarereducedwhenusingWebRTCaccesstraditionalservice.

　　3.2LightweightReal-TimeWebCommunication

　　ThetypicalapplicationscenarioofWebRTCistouseWebRTCstandardJavaScriptAPIstodeveloplightweightWebaudio/videocallsandWebaudio/videoconferencecenters.RepresentativedemoswithintheindustryfieldareMobicentsSIPServlet[5]，Conversat.io[6]（nowrenamedasTalky.io），andChatdemo[7]，etc.

　　Inthisapplicationscenario，almostalldemosadoptadecentralizedideaontheapplicationarchitecturedesign.Itskeypointsisdecomposingmultipartymedianegotiationprocessintomultipleend-to-endnegotiationprocesse，andfunctionslike

　　audio/videoprocessingimplementedintraditionalmediaserveraretransferredtotheclientbrowserside.

　　Onceobtainedmediaformatsandtransmissionprotocolsupportedbybothparties，twobrowserscancommunicatewitheachotherandmediastreamscanbesenttotheothersidedirectlyontherthanrelayedbytheserver.Whenathirdpartyjoinsin，thethird-partyUAshouldinitiatenegotiationswiththeearliertwoparties’UA.Afterthisstep，thefollowingprocessarethesameascommunicationbetweentwoparties.

　　Thissolutionisveryeasyanddonotneedtoconsideringmediaprocessing.However，client-sidemediaprocessingpressurewillbecomeincreasinglyheavier.Inshort，thissolutionlargelydependendonclient-sideprocessingcapabilitiesandthereforecan’tsupportmorethansixusersinavideoconference.　　Toreducedelayinreal-timecommunicationanddecreasebandwidthconsumption，theHTML5workinggrouphasdevelopedaWebSocketcommunicationstandard.HTML5WebSocketdefinesafull-duplexcommunicationchannelthroughasinglesocketontheWebandthussignificantlyimprovesreal-timeWebcommunication.

　　Beforetheclientsideandserversidecancommunicatewitheachother，theyneedtocompleteaWebSockethandshaketoestablishaconnectionbetweenthem.Oncetheconnectionhasbeenestablished，datacanbetransmittedbetweenthetwosidesinbothdirections.Inthisway，whentheserversideupdatesdata，thisdatacanbedirectlypushedtotheclientside，andthereisnoneedtowaitforarequestfromtheclientside.

　　Inverystrongreal-timeapplications，suchasaudioandvideocommunication，HTML5WebSocketcangreatlyimproveperformanceandreducebandwidthconsumptionbyreducingtransmissionpayload.

　　4.3.2MediaNegotiationandSynthesis

　　Inthisimprovement，themedianegotiationstilloccursontheclientsides.Whentherearemultiplepartiesinaconference，themultipartynegotiationprocessneedstobedecomposedintomultipleend-to-endnegotiationprocesses.OptionalnegotiationstrategiesareshowninFig.2andFig.3.

　　Theoretically，afteramultipartymedianegotiationhasended，multipartymediastreamscanbedirectlycommunicatedtoeachother.However，thisapplicationmodecreatessignificantissues.Inafour-partyconference，forexample，eachpartyneedstosendoutthree-waylocalvideostreamsatthesametimeandreceivevideostreamsfromtheotherthreeparties.Inthisway，theclientsidecanonlysupportaverylimitednumberofusers，andahugeamountofnetworkbandwidthisconsumed.

　　Therefore，anMCUisneededontheserversideformediastreamconversion，synthesis，andso.AftertheMCUhasbeenintroducedinthissolution，eachclientonlyneedstosendoutone-waylocalvideostreamsandreceiveone-waysynthesizedvideostreamsfromtheMCU.

　　4.3.3NAT/FirewallTraversal

　　ForWebaudioandvideocommunicationinacross-LANenvironment，NAT/firewalltraversalequipmentisusedtoroutethetransmissionofmediastreams.TheIETF-RTCWebstandardsstipulatethatWebRTCbrowsersneedstosupporttheICEframeworkandtheserversideneedstoprovidethec