The Internet Multimedia Conferencing Architecture

2020-11-01 来源：易榕旅网

InternetEngineeringTaskForceINTERNET-DRAFT

M.Handley/J.Crowcroft/C.Bormann

UCL/UCL/Bremen

22Feb1996

TheInternetMultimediaConferencingArchitecture

Abstract

ThisdocumentprovidesanoverviewofmultimediaconferencingontheInternet.Theprotocolsmentionedareallspeciﬁedelsewhereasinternet-draftsorRFCs.EachRFCgivesdetailsoftheprotocolitself,howitworksandwhatitdoes.Thisdocumentattemptstoprovidethereaderwithanoverviewofhowthecom-ponentsﬁttogetherandofsomeoftheassumptionsmade,aswellassomestatementofdirectionforthosecomponentsstillinanascentstage.

ThisdocumentisaproductoftheMultipartyMultimediaSessionControl(MMUSIC)workinggroupoftheInternetEngineeringTaskForce.Commentsaresolicitedandshouldbeaddressedtotheworkinggroup’smailinglistatconfctrl@isi.eduand/ortheauthors.

StatusofthisMemo

ThisdocumentisanInternet-Draft.Internet-DraftsareworkingdocumentsoftheInternetEngineeringTaskForce(IETF),itsareas,anditsworkinggroups.Notethatothergroupsmayalsodistributeworkingdocu-mentsasInternet-Drafts.

Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonthsandmaybeupdated,replaced,orobsoletedbyotherdocumentsatanytime.ItisinappropriatetouseInternet-Draftsasreferencematerialortocitethemotherthanas“workinprogress.”

TolearnthecurrentstatusofanyInternet-Draft,pleasecheckthe“1id-abstracts.txt”listingcontainedintheInternet-DraftsShadowDirectoriesonftp.is.co.za(Africa),nic.nordu.net(Europe),munnari.oz.au(PaciﬁcRim),ds.internic.net(USEastCoast),orftp.isi.edu(USWestCoast).Distributionofthisdocumentisunlimited.

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

1Introduction

Inconjunctionwithcomputers,theterm“conferencing”isoftenusedintwodifferentways:ﬁrstly,torefertobulletinboardsandmailliststyleasynchronousexchangesofmessagesbetweenmultipleusers;secondly,torefertosynchronousorso-called“real-time”conferencing,includingaudio,video,sharedwhiteboardsandotherapplications.Thisdocumentisaboutthearchitectureforthislatterapplication,intheInternet.Thereareotherinfrastructuresforconferencingintheworld:POTS(PlainOldTelephoneSystem)networksoftenprovidevoiceconferencingandphone-bridges,whiletheISDNprovidesH.320[2]forsmall,strictlyorganisedvideo-telephonyconferencing.

ThearchitecturethathasevolvedintheInternetisfarmoregeneralaswellasbeingscalabletoverylargegroups,andpermitstheopenintroductionofnewmediaandnewapplicationsastheyaredevised.Thedeterminingfactorsofaconferencingarchitecturearecommunicationin(possiblylarge)groupsofhu-mansandreal-timedeliveryofinformation.IntheInternet,thisissupportedatanumberoflevels.Theremainderofthissectionprovidesanoverviewofthissupport,andtherestofthedocumentdescribeseachaspectinmoredetail.

Inaconference,informationmustbedistributedtoalltheconferenceparticipants.Earlyconferencingsys-temsusedafan-outofdatastreams,e.g.,oneconnectionbetweeneachpairofparticipants,whichmeansthatthesameinformationmustcrosssomenetworksmorethanonce.TheInternetarchitectureusesthemoreef-ﬁcientapproachofmulticastingtheinformationtoallparticipants(section2).

Multimediaconferencesrequirereal-timedeliveryofatleasttheaudioandvideoinformationstreamsusedintheconference.InanISDNcontext,ﬁxedratecircuitsareallocatedforthispurpose—whethertheirbandwidthisrequiredatanyparticularinstanceornot.Ontheotherhand,thetraditionalInternetservicemodel(“besteffort”)cannotmakethenecessaryqualityofserviceavailableincongestednetworks.NewservicemodelsarebeingdeﬁnedintheInternettogetherwithprotocolstoreservecapacityinamoreﬂexiblewaythanthatavailablewithcircuitswitching(section3).

Inadatagramnetwork,multimediainformationmustbetransmittedinpackets,someofwhichmaybede-layedmorethanothers.Inorderthataudioandvideostreamsbeplayedoutattherecipientinthecorrecttiming,informationmustbetransmittedthatallowstherecipienttoreconstitutethetiming.Atransportpro-tocolwiththespeciﬁcfunctionsneededforthishasbeendeﬁned(section4).

Thehumansparticipatinginaconferencegenerallyneedtohaveaspeciﬁcideaofthecontextinwhichtheconferenceishappening,whichcanbeformalizedasaconferencepolicy.Someconferencesareessentiallycrowdsgatheredaroundanattraction,whileothershaveveryformalguidelinesonwhomaytakepart(listenin)andwhomayspeakatwhichpoint.Inanycase,initiallytheparticipantsmustﬁndeachother,i.e.establishcommunicationrelationships(conferencesetup,section5).Duringtheconference,someconferencecontrolinformationisexchangedtoimplementaconferencepolicyoratleasttoinformthecrowdofwhoispresent(section6).

Inaddition,securitymeasuresmayberequiredtoactuallyenforcetheconferencepolicy,e.g.tocontrolwhoislisteningandtoauthenticatecontributionsasactuallyoriginatingfromaspeciﬁcperson.IntheInternet,M.Handley/J.Crowcroft/C.Bormann

[Page2]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

thereislittletendencytorelyonthetraditional“security”ofdistributionofferede.g.&bythephonesystem.Instead,cryptographicmethodsareusedforencryptionandauthentication,whichneedtobesupportedbyadditionalconferencesetupandcontrolmechanisms(section7).

ThepresentversionofthisdocumentdoesnotyetdescribethearchitecturalconsiderationsunderlyingtheconferencingapplicationsotherthanaudioandvideothathaveevolvedintheInternet,e.g.Imm,Wb[1],Nt.

ConferenceControlRSVP

Audio

Video

SharedTools

Session Directory

SDP

SDAP

HTTP

SMTP

RTP and RTCP

UDP

TCP

Integrated Services Forwarding

Figure1:Internetmultimediaconferencingprotocolstacks

Theprotocolstacksforinternetmultimediaconferencingareshowninﬁgure1.Mostoftheprotocolsarenotdeeplylayeredunlikemanyprotocolstacks,butratherareusedalongsideeachothertoproduceacompleteconference.

2MulticastTrafﬁcDistribution

IPmulticastenablesefﬁcientmany-to-manydatagramdistribution.Itisoneofthebasicbuildingblocksoftheinternetmultimediaconferencingarchitecture.Formostconferencingpurposes,unicastisviewedasbeingaspecialcaseofmulticastrouting.

2.1MulticastServiceModel

TheIPmulticastservicemodelisasfollows:

Senderssenddatagramstotheaddressofamulticastgroup.Receiversexpressaninterestin(join)certainmulticastgroups.

Multicastroutersconspiretodelivermulticastgroupaddresseddatagramsfromthesenderstothere-ceivers.

[Page3]

M.Handley/J.Crowcroft/C.Bormann

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

Theimportantfactorhereisthatsendersdonothavetoknowwhothereceiversareinordertobeabletosendtothem.Infact,inmostsituations,nosinglepointinthenetworkneedstoknowwhoallthereceiversare,anditisthisthatmakesIPmulticastscalabletoverylargegroups.Inaddition,receiversdonotneedtoknowwhothesendersareinordertobeabletoreceivetrafﬁcfromthem,andthissolvesmanyconferencesetupandresourcelocationproblemswithoutneedingexplicitmachinery.

Therearemanymulticastroutingprotocols[3],[4],[5],[6]butallofthemsatisfytheaboveservicemodel.Theydifferintheirmechanismsandinhowtheyscalewiththenumberofsendersandgroups.

WithinasingleLAN,groupmembershipisexpressedbyIGMP[7].IGMPversion3allowsreceiverstoex-pressaninterestinonlyreceivingsomeofthesenderstoaparticularmulticastgroup.EarlierversionsofIGMPonlyallowareceivertorequesttoreceiveallthesourcessendingtoamulticastgroup.

2.2AddressAllocation

Howdoesanapplicationchooseamulticastaddresstouse?

Intheabsenceofanyotherinformation,wecanbootstrapamulticastapplicationbyusingwell-knownmul-ticastaddresses.Routing(unicastandmulticast)andgroupmembershipprotocols[7]candojustthat.How-ever,thisisnotthebestwayofmanagingapplicationsofwhichthereismorethanoneinstanceatanyonetime.

Forthese,weneedamechanismforallocatinggroupaddressesdynamically,andadirectoryservicewhichcanholdtheseallocationstogetherwithsomekey(sessioninformationforexample—seelater),sothatuserscanlookuptheaddressassociatedwiththeapplication.Theaddressallocationanddirectoryfunctionsshouldbedistributedtoscalewell.

Addressallocationschemesshouldavoidclashes,hencesomekindofhashfunctionsuggestsitselfforform-inginitial“random”valuesfortheaddress.Furthermore,boththeaddressallocationsystemandthedirectoryservicecantakeadvantageofthebaselinemulticastmechanismbyadvertisingconferencesthroughmulti-castmessagesonawell-knownaddress,andusingthistoinformotherdirectoryserverstoremoveclashesandinformapplicationsoftheallocation.

3InternetServiceModels

Traditionallytheinternethasprovidedbest-effortdeliveryofdatagramtrafﬁcfromsenderstoreceivers.Noguaranteesaremaderegardingwhenorifadatagramwillbedeliveredtoareceiver,howeverdatagramsarenormallyonlydroppedwhenarouterexceedsaqueuesizelimitduetocongestion.Thebest-effortinternetservicemodeldoesnotassumeFIFOqueuing,althoughmanyroutershaveimplementedthis.

Withbest-effortservice,ifalinkisnotcongested,queueswillnotbuildatrouters,datagramswillnotbediscardedinrouters,anddelayswillconsistofserialisationdelaysateachhoppluspropagationdelays.WithM.Handley/J.Crowcroft/C.Bormann

[Page4]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

sufﬁcientlyfastlinkspeeds,serialisationdelaysareinsigniﬁcantcomparedtopropagationdelays.Ifalinkiscongested,withbest-effortservicequeuingdelayswillstarttoinﬂuenceend-to-enddelays,andpacketswillstarttobelostasqueuesizelimitsareexceeded.

3.1Non-besteffortservice

Real-timeinternettrafﬁcisdeﬁnedasdatagramsthataredelaysensitive.Itcouldbearguedthatalldatagramsaredelaysensitivetosomeextent,butforthesepurposeswereferonlytodatagramswhereexceedinganend-to-enddelayboundofafewhundredmillisecondsrendersthedatagramsuselessforthepurposetheywereintended.Forthepurposesofthisdeﬁnition,TCPtrafﬁcisnormallynotconsideredtobereal-timetrafﬁc,althoughtheremaybeexceptionstothisrule.

Oncongestedlinks,best-effortservicequeuingdelayswilladverselyaffectreal-timetrafﬁc.Thisdoesnotmeanthatbest-effortservicecannotsupportreal-timetrafﬁc—merelythatcongestedbest-effortlinksseri-ouslydegradetheserviceprovided.Forsuchcongestedlinks,abetter-that-best-effortserviceisdesirable.Toachievethis,theservicemodeloftherouterscanbemodiﬁed.Ataminimum,FIFOqueuingcanbereplacedbypacketforwardingstrategiesthatdiscriminatedifferent“ﬂows”oftrafﬁc.Theideaofaﬂowisverygeneral.Aﬂowmightconsistof“allmarketingsitewebtrafﬁc”,or“allﬁleservertrafﬁctoandfromtellermachines”or“alltrafﬁcfromtheCEOslaptopwhereveritis”.Ontheotherhand,aﬂowmightconsistofaparticularsequenceofpacketsfromanapplicationinaparticularmachinetoapeerapplicationinanotherparticularmachinebetweenspeciﬁctimesofaspeciﬁcday.

FlowsaretypicallyidentiﬁableintheInternetbythetuple:sourcemachine,destinationmachine,sourceport,destinationport,protocolanyofwhichcouldbe“ANY”(wildcarded).

Inthemulticastcase,thedestinationisthegroup,andcanbeusedtoprovideefﬁcientaggregation.Flowidentiﬁcationiscalledclassiﬁcationandaclass(whichcancontainoneormoreﬂows)hasanassociatedservicemodelapplied.Thiscandefaulttobesteffort.

Throughnetworkmanagement,wecanimagineestablishingclassesoflonglivedﬂows—enterprisenet-works(“Intranets”)oftenenforcetrafﬁcpoliciesthatdistinguishprioritieswhichcanbeusedtodiscriminateinfavorofmoreimportanttrafﬁcintheeventofoverload(thoughinanunderloadednetwork,theeffectofsuchpolicieswillbeinvisible,andmayincurnoload/workinrouters).

Therouterservicemodeltoprovidesuchclasseswithdifferenttreatmentcanbeassimpleasapriorityqueu-ingsystem,oritcanbemoreelaborate.

Althoughbest-effortservicescansupportreal-timetrafﬁc,classifyingreal-timetrafﬁcseparatelyfromnon-real-timetrafﬁcandgivingreal-timetrafﬁcprioritytreatmentensuresthatreal-timetrafﬁcseesminimumdelays.Non-real-timeTCPtrafﬁctendstobeelasticinitsbandwidthrequirements,andwillthentendtoﬁllanyremainingbandwidth.

M.Handley/J.Crowcroft/C.Bormann[Page5]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

WecouldimagineafutureInternetwithsufﬁcientcapacitytocarryalloftheworld’stelephonytrafﬁc.Sincethisisarelativelymodestcapacityrequirement,itmightbesimplertoestablish“POTS”asastaticclasswhichisgivensomefractionofthecapacityoverall,andthenwithinthebackboneofthenetworknoindividualcallneedbegivenanallocation(i.e.wewouldnolongerneedthecallsetup/teardownthatwasneededinthelegacyPOTSwhichwasonlypresentduetounder-provisioningoftrunks,andtoallowthetrunkexchangestheoptionofcallblocking).Thevisionisofanetworkthatisengineeredwithcapacityforalloftheaverageloadsourcestosendallthetime.

3.2Reservations

Forﬂowsthatmaytakeasigniﬁcantfractionofthenetwork(i.e.are“special”andcan’tjustbelumpedunderastaticclass),weneedamoredynamicwayofestablishingtheseclassiﬁcations.Intheshortterm,thisappliestoanymultimediacallssincetheInternetislargelyunder-provisionedatthetimeofwriting.RSVPisbeingstandardisedforjustthispurpose.Itprovidesﬂowidentiﬁcationandclassiﬁcation.HostsandapplicationsaremodiﬁedtospeakRSVPclientlanguage,androutersspeakRSVP.

Sincemosttrafﬁcrequiringreservationsisdeliveredtogroups(e.g.TV),itisnaturalforthereceivertomaketherequestforareservationforaﬂow.Thishastheaddedadvantagethatdifferentreceiverscanmakehet-erogeneousrequestsforcapacityfromthesamesource.ThusRSVPcanaccommodatemonochrome,colorandHDTVreceiversfromasinglesource.

Againtheroutersconspiretodelivertherightﬂowstotherightlocations.RSVPaccommodatesthewildcardingnotedabove.

3.3AdmissionControl

Ifanetworkisprovisionedsuchthatithasexcesscapacityforallthereal-timeﬂowsusingit,asimpleprior-ityclassiﬁcationensuresthatreal-timetrafﬁcisminimallydelayed.However,ifanetworkisinsufﬁcientlyprovisionedforthetrafﬁcinareal-timetrafﬁcclass,thenreal-timetrafﬁcwillbequeued,anddelaysandpacketlosswillresult.Thusinanunder-provisionednetwork,eitherallreal-timeﬂowswillsuffer,orsomeofthemmustbegivenpriority.

RSVPprovidesamechanismbywhichanadmissioncontrolrequestcanbemade,andifsufﬁcientcapacityremainsintherequestedtrafﬁcclass,thenareservationforthatcapacitycanbeputinplace.

Ifinsufﬁcientcapacityremains,theadmissionrequestwillberefused,butthetrafﬁcwillstillbeforwardedwiththedefaultserviceforthattrafﬁc’strafﬁcclass.Inmanycasesevenanadmissionrequestthatfailedatoneormorerouterscanstillsupplyacceptablequalityasitmayhavesucceededininstallingareservationinalltheroutersthatweresufferingcongestion.Thisisbecauseotherreservationsmaynotbefullyutilisingtheirreservedcapacityinthoserouterswherethereservationfailed.

M.Handley/J.Crowcroft/C.Bormann[Page6]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

3.4Billing

Ifareservationinvolvessettingasideresourcesforaﬂow,thiswilltieupresourcessothatotherreservationsmaynotsucceed,anddependingonwhethertheﬂowﬁllsthereservation,othertrafﬁcispreventedfromusingthenetwork.Clearlysomenegativefeedbackisrequiredinordertopreventpointlessreservationsfromdenyingservicetootherusers.Thisfeedbackistypicallyintheformofbilling.Forreal-timenon-besteffortmulticasttrafﬁcthatisnotreserved,thisnegativefeedbackisprovidedintheformoflossduetocongestionofatrafﬁcclass,anditisnotclearthatusagebasedbillingisrequired.

Billingrequiresthattheusermakingthereservationisproperlyauthenticatedsothatthecorrectusercanbecharged.Billingforreservationsintroducesalevelofcomplexitytotheinternetthathasnottypicallybeenexperiencedwithnon-reservedtrafﬁc,andrequiresnetworkproviderstohavereciprocalusage-basedbillingarrangementsfortrafﬁccarriedbetweenthem.Italsorequiresmechanismswherebysomefractionofthebillforalinkreservationcanbechargedtoeachofthedownstreammulticastreceivers.

4TransportProtocols

So-calledreal-timedeliveryoftrafﬁcrequireslittleinthewayoftransportprotocol.Inparticular,real-timetrafﬁcthatissentovermorethantrivialdistancesisnotretransmittable.

4.1SeparateFlowsforeachMediaStream

Withpacketmultimediadatathereisnoneedforthedifferentmediacomprisingaconferencetobecarriedinthesamepackets.Infactitsimpliﬁesreceiversifdifferentmediastreamsarecarriedinseparateﬂows(i.e.,separatetransportportsand/orseparatemulticastgroups).Thisalsoallowsthedifferentmediatobegivendifferentqualityofservice.Forexample,undercongestion,aroutermightpreferentiallydropvideopacketsoveraudiopackets.Inaddition,somesitesmaynotwishtoreceiveallthemediaﬂows.Forexample,asitewithaslowaccesslinkmaybeabletoparticipateinaconferenceusingonlyaudioandawhiteboardwhereasothersitesinthesameconferencemayalsosendandreceivevideo.

4.2ReceiverAdaptation

Best-efforttrafﬁcisdelayedbyqueuesinroutersbetweenthesenderandthereceivers.Evenreservedprioritytrafﬁcmayseesmalltransientqueuesinrouters,andsopacketscomprisingaﬂowwillbedelayedfordifferenttimes.Suchdelayvarianceisknownasjitter.

Real-timeapplicationssuchasaudioandvideoneedtobeabletobufferreal-timedataatthereceiverforsufﬁcienttimetoremovethejitteraddedbythenetworkandrecovertheoriginaltimingrelationshipsbetweenthemediadata.Inordertoknowhowlongtobufferfor,eachpacketmustcarryatimestampwhichgivesthetimeatthesenderwhenthedatawascaptured.Notethatforaudioandvideodatatimingrecovery,itisM.Handley/J.Crowcroft/C.Bormann

[Page7]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

notnecessarytoknowtheabsolutetimethatthedatawascapturedatthesender,onlythetimerelativetotheotherdatapackets.

4.3Synchronisation

Asaudioandvideoﬂowswillreceivedifferingjitterandpossiblydifferingqualityofservice,audioandvideothatweregrabbedatthesametimeatthesendermaynotarriveatthereceiveratthesametime.Atthereceiver,eachﬂowwillneedaplayoutbuffertoremovenetworkjitter.Inter-ﬂowsynchronisationcanbeperformedbyadaptingtheseplayoutbufferssothatsamples/framesthatoriginatedatthesametimeareplayedoutatthesametime.Thisrequiresthatthetimebaseofdifferentﬂowsfromthesamesendercanberelatedatthereceivers,e.g.bymakingavailabletheabsolutetimesatwhicheachofthemwascaptured.

4.4RTP

Thetransportprotocolforreal-timeﬂowsisRTP[8].Thisprovidesastandardformatpacketheaderwhichgivesmediaspeciﬁctimestampdata,aswellaspayloadformatinformationandsequencenumberingamongstotherthings.RTPisnormallycarriedusingUDP.Itdoesnotprovideorrequireanyconnectionsetup,nordoesitprovideanyenhancedreliabilityoverUDP.ForRTPtoprovideausefulmediaﬂow,theremustbesufﬁcientcapacityintherelevanttrafﬁcclasstoaccommodatethetrafﬁc.HowthiscapacityisensuredisindependentofRTP.

EveryoriginalRTPsourceisidentiﬁedbyasourceidentiﬁer,andthissourceidiscarriedineverypacket.RTPallowsﬂowsfromseveralsourcestobemixedingatewaystoprovideasingleresultingﬂow.Whenthishappens,eachmixedpacketcontainsthesourceidsofallthecontributingsources.

RTPmediatimestampunitsareﬂowspeciﬁc—theyareinunitsthatareappropriatetothemediaﬂow.Forexample,8kHzsampledPCMencodedaudiohasatimestampclockrateof8kHz.Thismeansthatinter-ﬂowsynchronisationisnotpossiblefromtheRTPtimestampsalone.

EachRTPﬂowissupplementedbyReal-TimeControlProtocol(RTCP)packets.ThereareanumberofdifferentRTCPpackettypes.RTCPpacketsprovidetherelationshipbetweentherealtimeclockatasenderandtheRTPmediatimestamps,andprovidetextualinformationtoidentifyasenderinaconferencefromthesourceid.

4.5ConferenceMembershipandReceptionFeedback

IPmulticastallowssourcestosendtoamulticastgroupwithoutbeingareceiverofthatgroup.However,formanyconferencingpurposesitisusefultoknowwhoislisteningtotheconference,andwhetherthemediaﬂowsarereachingreceiversproperly.Accuratelyperformingboththesetasksrestrictsthescalingofthecon-ference.IPmulticastmeansthatno-oneknowstheprecisemembershipofamulticastgroupataspeciﬁctime,andthisinformationcannotbediscovered,astotrytodosowouldcauseanimplosionofmessages,manyofM.Handley/J.Crowcroft/C.Bormann

[Page8]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

whichwouldbelost1.Instead,RTCPprovidesapproximatemembershipinformationthroughperiodicmul-ticastofsessionmessageswhich,inadditiontoinformationabouttherecipient,alsogiveinformationaboutthereceptionqualityatthatreceiver.RTCPsessionmessagesarerestrictedinrate,sothatasaconferencegrows,therateofsessionmessagesremainsconstant,andeachreceiverreportslessoften.AmemberoftheconferencecanneverknowexactlywhoispresentataparticulartimefromRTCPreports,butdoeshaveagoodapproximationtotheconferencemembership.

Receptionqualityinformationisprimarilyintendedfordebuggingpurposes,asdebuggingofIPmulticastproblemsisadifﬁculttask.However,itispossibletousereceptionqualityinformationforrateadaptivesenders,althoughitisnotclearwhetherthisinformationissufﬁcientlytimelytobeabletoadaptfastenoughtotransientcongestion.However,itiscertainlysufﬁcientforVanJacobsoncongestioncontrol[10]styleadaptiontoa“share”ofthecurrentcapacity.

5ConferenceControl

Conferencescomeinmanyshapesandsizes,butthereareonlyreallytwomodelsforconferencecontrol:light-weightsessionsandtightlycoupledconferencing.Forbothmodels,rendezvousmechanismsareneeded.Notethattheconferencecontrolmodelisorthogonaltoissuesofqualityofserviceandnetworkresourcereservation.Notealsothattheissueofconferencecontrolisorthogonaltothemechanismfordiscoveringtheconference.

5.1Light-weightSessions

Light-weightsessionsaremulticastbasedmultimediaconferencesthatlackexplicitsessionmembershipandexplicitconferencecontrolmechanisms.Typicallyalightweightsessionconsistsofanumberofmany-to-manymediastreamssupportedusingRTPandRTCPusingIPmulticast2.Theonlyconferencecontrolin-formationavailableduringthecourseoflight-weightsessionsisthatdistributedintheRTCPsessioninfor-mation,i.e.anapproximatemembershiplistwithsomeattributespermember.

5.2TightlycoupledConferences

TightlycoupledconferencesmayalsobemulticastbasedanduseRTPandRTCP,butinadditiontheyhaveanexplicitconferencemembershipmechanismandmayhaveanexplicitconferencecontrolmechanismthatprovidesfacilitiessuchasﬂoorcontrol.

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

Intheinternetcommunity,nostandardmechanismforperformingtightlycoupledconferencecontrolcur-rentlyexists.Atthetimeofwriting,itseemslikelythataprotocolbasedontheITU’sT.124[11]recommen-dationwillbederivedforinternetusage.

6ConferenceDiscovery

Theretwobasicformsofconferencediscoverymechanism.Thesearesessionadvertisementandsessioninvitation.Sessionadvertisementsareprovidedusingasessiondirectory,andinvitingausertojoinasessionisprovidedusingasessioninvitationprotocol.

6.1SessionDirectories

Therendezvousmechanismforlight-weightsessionsisamulticastbasedsessiondirectory.Thisdistributessessiondescriptions[9]toallthepotentialsessionparticipants.Thesesessiondescriptionsprovideanad-vertisementthatthesessionwillexist,andalsoprovidesufﬁcientinformationincludingmulticastaddresses,ports,mediaformatsandsessiontimessothatareceiverofthesessiondescriptioncanjointhesession.TheprotocolSDP(sessiondescriptionprotocol)describescontentsandformatofthesessiondescriptions.Asdynamicmulticastaddressallocationcanbeoptimisedbyknowingwhichaddressesareinuseatwhichtimes,thesessiondirectoryisanappropriateagenttoperformmulticastaddressallocation.SDAP(sessiondirectoryannouncementprotocol)istheprotocolusedbythesessiondirectoryagents.

Thismechanismcanalsobeappliedtoadvertisedtightlycoupledsessions,andonlyrequiresthatadditionalinformationaboutthemechanismtousetojointhesessionisgiven.

6.2SessionInvitation

Notallsessionsareadvertised,andeventhosethatareadvertisedmayrequireamechanismtoexplicitlyinviteausertojoinasession.Suchamechanismisrequiredregardlessofwhetherthesessionisalightweightsessionoramoretightlycoupledsession,althoughtheinvitationsystemmustspecifythemechanismtobeusedtojointhesession.

Asusersaremobile,itisimportantthatsuchamechanismiscapableoflocatingandinvitingauserinalocationindependentmanner.Thisrequiresthatanextralevelofindirection(addressing)isrequiredfromthatprovidedbyMMCC[13].Theinvitationmechanismshouldalsoprovideforalternativeresponses,suchasleavingamessageorbeingreferredtoanotheruser,shouldtheinviteduserbeunavailable.

Basedonaprotocolwithmanyofthepropertiesrequired[12],asessioninvitationprotocol(SIP)isbeingdeveloped.

M.Handley/J.Crowcroft/C.Bormann[Page10]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

MulticastAddressAllocation

Session

AdvertisementSessionInvitation

RTP and RTCP flows

Lightweight Session Lifecycle

T.124SessionCreation

Session

AdvertisementSessionInvitation

RTP and RTCP flows

T.124 or other TightlyCoupled Control Protocol

Tightly Coupled Session Lifecycle

Figure2:Internetmultimediaconferencinglifecycles

7Security

Thereisatemptationtobelievethatmulticastisinherentlylessprivatethanunicastcommunicationsincethetrafﬁcvisitssomanymoreplacesinthenetwork.Infact,thisisnotthecaseexceptwithbroadcastandprunetypemulticastroutingprotocols[4].However,IPmulticastdoesmakeitsimpleforahosttoanonymouslyjoinamulticastgroupandreceivetrafﬁcdestinedtothatgroupwithouttheothersenders’andreceivers’knowledge.Iftheapplicationrequirement(conferencepolicy)istocommunicatebetweensomedeﬁnedsetofusers,thenstrictprivacycanonlybeenforcedinanycasethroughadequateend-to-endencryption.RTPspeciﬁesastandardwaytoencryptRTPandRTCPpacketsusingprivatekeyencryptionschemessuchasDES[14].ItalsospeciﬁesastandardmechanismtomanipulateplaintextkeysusingMD5[15]sothattheresultingbitstringcanbeusedasaDESkey.Thisallowssimpleout-of-bandmechanismssuchasprivacy-enhancedmailtobeusedforencryptionkeyexchange.

7.1AuthenticationandKeyDistribution

Keydistributioniscloselytiedtoauthentication.Conferenceorsessiondirectorykeyscanbesecurelydis-tributedusingpublic-keycryptographyonaone-to-onebasis(byemail,adirectoryservice,orbyanexplicitconferencesetupmechanism),butthisisonlyasgoodasthecertiﬁcationmechanismusedtocertifythatakeygivenbyauseristhecorrectpublickeyforthatuser.Suchcertiﬁcationmechanisms[16]arenotspe-ciﬁctoconferencing,andnostandardmechanismsarecurrentlyinuseforconferencingpurposesotherthanM.Handley/J.Crowcroft/C.Bormann

[Page11]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture

User ACreatesConference22Feb1996

SDP/SDAPSDP/SDAPIGMPIGMPIGMPUser B Starts Session DirectorySDP/SDAPUser BReceivesSessionAnnouncementUser AStartsSending

RTPRTCPRTPIGMPIGMPIGMPUser BJoins ConferenceRTPRSVP Path MessageRTCPUser’s AppSends RTCPSession MessageUser’s Applicationmakes reservationRTPRSVPRSVPRTPRTCPQuality ofServiceImprovesFigure3:Joiningalight-weightmultimediasession

PEM[17].

Atthetimeofwriting,nostandardmechanismsforkeydistributionaredeﬁnedfortheconferencesetupandcontrolprotocolsinuse.

Evenwithoutprivacyrequirementsintheconferencepolicy,strongauthenticationofauserisrequiredifmakinganetworkreservationresultsinusagebasedbilling.

7.2EncryptedSessionAnnouncements

SessionDirectoriescanmakeencryptedsessionannouncementsusingprivatekeyencryption,andcarrytheencryptionkeystobeusedforeachoftheconferencemediastreamsinthesession.Whilstthisdoesnotsolvethekeydistributionproblem,itdoesallowasingleconferencetobeannouncedmorethanoncetomorethanonekey-group,whereeachgroupholdsadifferentsessiondirectorykey,sothatthetwogroupscanbebroughttogetherintoasingleconferencewithouthavingtoknoweachother’skeys.M.Handley/J.Crowcroft/C.Bormann

[Page12]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

8Summary

ThisdocumentisanattempttogathertogetherinoneplacethesetofassumptionsbehindthedesignoftheInternetMultimediaconferencingarchitecture,andtheservicesthatareprovidedtosupportit.

Figure3showsthetimesequenceinvolvedinsettingupalight-weightsessionbetweentwosites.Inthiscase,siteAcreatesasessionadvertisement,andsometimelaterstartssendingamediastreameventhoughtheremaybenoreceiveratthattime.Sometimelater,siteBjoinsthesession,andstartstoreceivethetrafﬁc.AttheearliestopportunitysiteBalsomakesanRSVPreservationtoensuretheﬂowqualityissatisfactory.

9AcknowledgmentsandAuthorsAddress

AcknowledgmentsareduetotheEnd-to-EndResearchGroup,theInt-serv,RSVP,MMUSICandAVTwork-inggroupsoftheIETF,anddiscussionwithcolleaguesatUCL.Theearliestclearexpositionoftheideasherecanbefoundathttp://www-mice.cs.ucl.ac.uk/mice-old/van/andwaspresentedatACMSIGCOMM1994inLondonbyVanJacobson.

MarkHandley,JonCrowcroft,DepartmentofComputerScienceUniversityCollegeLondonGowerStreet,

LondonWC1E6BTUK

fax+441713871397

Email:m.handley@cs.ucl.ac.uk,j.crowcroft@cs.ucl.ac.ukWeb:http://www.cs.ucl.ac.uk/index.htmlCarstenBormannUniversitaetBremenPostfach330440

D-28334BremenGERMANYfax+494212038097

Email:cabo@informatik.uni-bremen.de

Web:http://www.informatik.uni-bremen.de/cabo

References

[1]“AReliableMulticastFrameworkforLight-weightSessionsandApplicationLevelFraming”S.Floyd,

V.Jacobson,S.McCanne,C-G.Liu,L.ZhangACMSIGCOMM1995,pp342-356M.Handley/J.Crowcroft/C.Bormann

[Page13]

INTERNET-DRAFTTheInternetMultimediaConferencingArchitecture22Feb1996

[2]ITURecommendationH.320

[3]“AnArchitectureforWideAreaMulticastRouting”S.Deering,D.Estrin,D.Farinacci,V.Jacobson,

C-G.Liu,L.WeiACMSIGCOMM1994,LondonOctober1994,ACMCCRVol24,No.4,126-135[4]RFC1075S.Deering,C.Partridge,D.Waitzman,“DistanceVectorMulticastRoutingProtocol”,

11/01/1988.[5]“AnArchitectureforScalableInter-DomainMulticastRouting”,A.Ballardie,P.Francis,J.Crowcroft

ACMSIGCOMM1993,pp85-95[6]RFC1584J.Moy,“MulticastExtensionstoOSPF”,03/24/1994.

[7]SteveDeering“MulticastRoutinginInternetworksandExtendedLANs”,ACMSIGCOMM88,Au-gust1988,pp55-64andHostExtensionsforIPMulticasting,RFC1112[8]H.Schulzrinne,S.Casner,R.FrederickandV.Jacobson“RTP:ATransportProtocolforReal-Time

Applications”InternetDraftdraft-ietf-avt-rtp-08.txt,WorkInProgress,Late1995.[9]M.Handley,V.Jacobson“SDP:SessionDescriptionProtocol”InternetDraftdraft-ietf-mmusic-sdp-01.txt,WorkinProgress,Nov1995.[10]V.Jacobson“CongestionAvoidanceandControl”,ACMSIGCOMM88,August1988[11]ITURecommendationT.124—GenericConferenceControl

[12]Schulzrinne,H.,“PersonalMobilityforMultimediaServicesintheInternet”IMDS’96,March4-6

1996.ftp://ftp.fokus.gmd.de/pub/step/papers/Schu9603:Personal.ps.gz[13]Schooler,E.,ADistributedArchitectureforMultimediaConferenceControl,ISIResearchReport

ISI/RR-91-289,November1991.ftp://ftp.isi.edu/pub/hpcc-papers/mmc/mmcc.ps[14]NationalInstituteofStandardsandTechnology(NIST),“FIPSPublication46-1:DataEncryptionStan-dard”,January22,1988[15]Rivest,R.,“TheMD5Message-DigestAlgorithm”,RFC1321,MITLaboratoryforComputerScience

andRSADataSecurity,Inc.,April1992[16]CCITT(ConsultativeCommitteeonInternationalTelegraphyandTelephony).“Recommendation

X.509:TheDirectory—AuthenticationFramework.”1988.[17]RFC1421J.Linn,“PrivacyEnhancementforInternetElectronicMail:PartI:MessageEncryptionand

AuthenticationProcedures”,Feb1993

M.Handley/J.Crowcroft/C.Bormann[Page14]

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部栏目

The Internet Multimedia Conferencing Architecture