计算机网络英文版课件：Chapter7 Multimedia Communication over IPV4 Network

Chapter7:MultimediaCommunicationoverIPV4NetworkPrinciplesclassifymultimediaapplicationsidentifynetworkservicesapplicationsneedmakingthebestofbesteffortserviceProtocolsandArchitectures

specificprotocolsforbest-effort17:MultimediaNetworkingMMNetworkingApplicationsFundamentalcharacteristics:typicallydelay

sensitiveend-to-enddelaydelayjitter

losstolerant:infrequentlossescauseminorglitchesantithesisofdata,whicharelossintolerantbutdelaytolerant.ClassesofMMapplications:1)storedstreaming2)livestreaming3)interactive,real-timeJitteristhevariabilityofpacketdelayswithinthesamepacketstream27:MultimediaNetworkingStreamingStoredMultimediaStoredstreaming:mediastoredatsourcetransmittedtoclientstreaming:clientplayoutbeginsbeforealldatahasarrivedtimingconstraintforstill-to-betransmitteddata:intimeforplayout37:MultimediaNetworkingStreamingStoredMultimedia:

Whatisit?1.videorecorded2.videosent3.videoreceived,playedoutatclientCumulativedatastreaming:atthistime,clientplayingoutearlypartofvideo,whileserverstillsendinglaterpartofvideonetworkdelaytime47:MultimediaNetworkingStreamingStoredMultimedia:InteractivityVCR-likefunctionality:clientcanpause,rewind,FF,pushsliderbar10secinitialdelayOK1-2secuntilcommandeffectOKtimingconstraintforstill-to-betransmitteddata:intimeforplayout57:MultimediaNetworkingStreamingLiveMultimediaExamples:InternetradiotalkshowlivesportingeventStreaming(aswithstreamingstoredmultimedia)playbackbufferplaybackcanlagtensofsecondsaftertransmissionstillhavetimingconstraintInteractivityfastforwardimpossiblerewind,pausepossible!67:MultimediaNetworkingReal-TimeInteractiveMultimediaend-enddelayrequirements:audio:<150msecgood,<400msecOKincludesapplication-level(packetization)andnetworkdelayshigherdelaysnoticeable,impairinteractivitysessioninitializationhowdoescalleeadvertiseitsIPaddress,portnumber,encodingalgorithms?applications:IPtelephony,videoconference,distributedinteractiveworlds77:MultimediaNetworkingMultimediaOverToday’sInternetTCP/UDP/IP:“best-effortservice”noguaranteesondelay,lossToday’sInternetmultimediaapplicationsuseapplication-leveltechniquestomitigate(asbestpossible)effectsofdelay,lossButyousaidmultimediaappsrequiresQoSandlevelofperformancetobeeffective!???????????87:MultimediaNetworkingAboutaudiocompressionanalogsignalsampledandquantizedatconstantratetelephone:64kbpsCDmusic:1.4MbpsMP3:96,128,160kbpsInternettelephony:5.3kbpsandupreceiverconvertsbitsbacktoanalogsignal:somequalityreductionBeforeaudiocanbetransmittedoveracomputernetwork,itmustbedigitizedandcompressedAudiocompressionPCM:samplingrate:8Kspsand8bit/sampleGSM:13Kbps；G.729:8KbpsG.723.1:5.3~6.4Kbps97:MultimediaNetworkingAboutvideocompressionvideo:sequenceofimagesdisplayedatconstantratee.g.24images/secdigitalimage:arrayofpixelseachpixelrepresentedbybitsRedundancyspatial(withinimage)temporal(fromoneimagetonext)Beforevideocanbetransmittedoveracomputernetwork,itmustbedigitizedandcompressed1024*1024RGBresultsin3MBofstoragewithoutcompressionVideocompressionMPEG-XMPEG1(CD-ROM)1.5MbpsMPEG2(DVD)3-6MbpsMPEG4(oftenusedinInternet,<1Mbps)H.26XH.261H.263H.263+,H.263++H.264Research:layered(scalable)videoadaptlayerstoavailablebandwidth107:MultimediaNetworkingStreamingStoredMultimedia:QoScontrolapplication-levelstreamingtechniquesformakingthebestoutofbesteffortservice:client-sidebufferinguseofUDPversusTCPmultipleencodingsofmultimediaLosscontrol

jitterremovaldecompressionerrorconcealmentgraphicaluserinterfacecontrolsforinteractivityMediaPlayer117:MultimediaNetworkingInternetmultimedia:simplestapproachaudio,videonotstreamed:downloadandplaybackno,“pipelining,”longdelaysuntilplayout!audioorvideostoredinfilefilestransferredasHTTPobjectreceivedinentiretyatclientthenpassedtoplayer127:MultimediaNetworkingInternetmultimedia:streamingapproachbrowserGETs

metafilebrowserlaunchesplayer,passingmetafileplayercontactsserverserverstreamsaudio/videotoplayer137:MultimediaNetworkingStreamingfromastreamingserverallowsfornon-HTTPprotocolbetweenserver,mediaplayerUDPorTCP147:MultimediaNetworking

constantbitratevideotransmissionCumulativedatatimevariablenetworkdelayclientvideoreception

constantbitratevideoplayoutatclientclientplayoutdelaybufferedvideoStreamingMultimedia:ClientBufferingclient-sidebuffering,playoutdelaycompensatefornetwork-addeddelay,delayjitter157:MultimediaNetworkingStreamingMultimedia:ClientBufferingclient-sidebuffering,playoutdelaycompensatefornetwork-addeddelay,delayjitterbufferedvideovariablefillrate,x(t)constantdrainrate,d167:MultimediaNetworkingStreamingMultimedia:UDPorTCP?UDPserversendsatrateappropriateforclient(oblivioustonetworkcongestion!)oftensendrate=encodingrate=constantratethen,fillrate=constantrate-packetlossshortplayoutdelay(2-5seconds)toremovenetworkjittererrorrecover:timepermittingTCPsendatmaximumpossiblerateunderTCPfillratefluctuatesduetoTCPcongestioncontrollargerplayoutdelay:smoothTCPdeliveryrateHTTP/TCPpassesmoreeasilythroughfirewalls177:MultimediaNetworkingStreamingMultimedia:clientrate(s)Q:howtohandledifferentclientreceiveratecapabilities?28.8Kbpsdialup100MbpsEthernetA:serverstores,transmitsmultiplecopiesofvideo,encodedatdifferentrates1.5Mbpsencoding28.8Kbpsencoding187:MultimediaNetworkingUserControlofStreamingMedia:RTSPHTTPdoesnottargetmultimediacontentnocommandsforfastforward,etc.RTSP:RFC2326client-serverapplicationlayerprotocolusercontrol:rewind,fastforward,pause,resume,repositioning,etc…Whatitdoesn’tdo:doesn’tdefinehowaudio/videoisencapsulatedforstreamingovernetworkdoesn’trestricthowstreamedmediaistransported(UDPorTCPpossible)doesn’tspecifyhowmediaplayerbuffersaudio/video197:MultimediaNetworkingRTSP:outofbandcontrolFTPusesan“out-of-band”controlchannel:filetransferredoveroneTCPconnection.controlinfo(directorychanges,filedeletion,rename)sentoverseparateTCPconnection“out-of-band”,“in-band”channelsusedifferentportnumbersRTSPmessagesalsosentout-of-band:RTSPcontrolmessagesusedifferentportnumbersthanmediastream:out-of-band.port554mediastreamisconsidered“in-band”.207:MultimediaNetworkingRTSPOperation217:MultimediaNetworkingReal-timeinteractiveapplicationsPC-2-PCphoneSkypePC-2-phoneDialpadNet2phoneSkypevideoconferencewithwebcamsSkypePolycom

GoingtonowlookataPC-2-PCInternetphoneexampleindetail227:MultimediaNetworkingInteractiveMultimedia:InternetPhoneIntroduceInternetPhonebywayofanexample

speaker’saudio:alternatingtalkspurts,silentperiods.64kbpsduringtalkspurtpktsgeneratedonlyduringtalkspurts20msecchunksat8Kbytes/sec:160bytesdataapplication-layerheaderaddedtoeachchunk.chunk+headerencapsulatedintoUDPsegment.applicationsendsUDPsegmentintosocketevery20msecduringtalkspurt237:MultimediaNetworkingInternetPhone:PacketLossandDelaynetworkloss:IPdatagramlostduetonetworkcongestion(routerbufferoverflow)delayloss:IPdatagramarrivestoolateforplayoutatreceiverdelays:processing,queueinginnetwork;end-system(sender,receiver)delaystypicalmaximumtolerabledelay:400mslosstolerance:dependingonvoiceencoding,lossesconcealed,packetlossratesbetween1%and10%canbetolerated.247:MultimediaNetworking

constantbitratetransmissionCumulativedatatimevariablenetworkdelay(jitter)clientreception

constantbitrateplayoutatclientclientplayoutdelaybuffereddataDelayJitterconsiderend-to-enddelaysoftwoconsecutivepackets:differencecanbemoreorlessthan20msec(transmissiontimedifference)257:MultimediaNetworkingInternetPhone:FixedPlayoutDelayreceiverattemptstoplayouteachchunkexactlyqmsecsafterchunkwasgenerated.chunkhastimestampt:playoutchunkatt+q.chunkarrivesaftert+q:dataarrivestoolateforplayout,data“lost”tradeoffinchoosingq:largeq:lesspacketlosssmallq:betterinteractiveexperience267:MultimediaNetworkingFixedPlayoutDelay

sendergeneratespacketsevery20msecduringtalkspurt.firstpacketreceivedattimerfirstplayoutschedule:beginsatpsecondplayoutschedule:beginsatp’277:MultimediaNetworkingAdaptivePlayoutDelay(1)dynamicestimateofaveragedelayatreceiver:whereuisafixedconstant(e.g.,u=.01).Goal:

minimizeplayoutdelay,keepinglatelossratelowApproach:

adaptiveplayoutdelayadjustment:estimatenetworkdelay,adjustplayoutdelayatbeginningofeachtalkspurt.silentperiodscompressedandelongated.chunksstillplayedoutevery20msecduringtalkspurt.287:MultimediaNetworkingAdaptiveplayoutdelay(2)

alsousefultoestimateaveragedeviationofdelay,vi:

estimatesdi,vicalculatedforeveryreceivedpacket(butusedonlyatstartoftalkspurtforfirstpacketintalkspurt,playouttimeis:

whereKispositiveconstantremainingpacketsintalkspurtareplayedoutperiodically297:MultimediaNetworkingAdaptivePlayout(3)Q:Howdoesreceiverdeterminewhetherpacketisfirstinatalkspurt?ifnoloss,receiverlooksatsuccessivetimestamps.differenceofsuccessivestamps>20msec-->talkspurtbegins.withlosspossible,receivermustlookatbothtimestampsandsequencenumbers.differenceofsuccessivestamps>20msecandsequencenumberswithoutgaps-->talkspurtbegins.307:MultimediaNetworkingRecoveryfrompacketloss(1)ForwardErrorCorrection(FEC):simpleschemeforeverygroupofnchunkscreateredundantchunkbyexclusiveOR-ingnoriginalchunkssendoutn+1chunks,increasingbandwidthbyfactor1/n.canreconstructoriginalnchunksifatmostonelostchunkfromn+1chunksplayoutdelay:enoughtimetoreceivealln+1packetstradeoff:increasen,lessbandwidthwasteincreasen,longerplayoutdelayincreasen,higherprobabilitythat2ormorechunkswillbelost317:MultimediaNetworkingRecoveryfrompacketloss(2)2ndFECscheme“piggybacklower

qualitystream”sendlowerresolution

audiostreamas

redundantinformatione.g.,nominal

streamPCMat64kbps

andredundantstream

GSMat13kbps.

wheneverthereisnon-consecutiveloss,

receivercanconcealtheloss.canalsoappend(n-1)stand(n-2)ndlow-bitrate

chunk327:MultimediaNetworkingRecoveryfrompacketloss(3)Interleavingchunksdividedintosmallerunitsforexample,four5msecunitsperchunkpacketcontainssmallunitsfromdifferentchunksifpacketlost,stillhavemostofeverychunknoredundancyoverhead,butincreasesplayoutdelay337:MultimediaNetworkingContentdistributionnetworks(CDNs)Contentreplicationchallengingtostreamlargefiles(e.g.,video)fromsingleoriginserverinrealtimesolution:replicatecontentathundredsofserversthroughoutInternetcontentdownloadedtoCDNserversaheadoftimeplacingcontent“close”touseravoidsimpairments(loss,delay)ofsendingcontentoverlongpathsCDNservertypicallyinedge/accessnetworkoriginserverinNorthAmericaCDNdistributionnodeCDNserverinS.AmericaCDNserverinEuropeCDNserverinAsia347:MultimediaNetworkingContentdistributionnetworks(CDNs)ContentreplicationCDN(e.g.,Akamai)customeristhecontentprovider(e.g.,CNN)CDNreplicatescustomers’contentinCDNservers.whenproviderupdatescontent,CDNupdatesserversoriginserverinNorthAmericaCDNdistributionnodeCDNserverinS.AmericaCDNserverinEuropeCDNserverinAsia357:MultimediaNetworkingCDNexampleoriginserver()distributesHTMLreplaces:

http:///sports.ruth.gifwith

http:////sports/ruth.gifHTTPrequestfor/sports/sports.htmlDNSqueryforHTTPrequestfor//sports/ruth.gif123originserverCDN’sauthoritativeDNSserver

CDNservernearclientCDNcompany()distributesgiffilesusesitsauthoritativeDNSservertorouteredirectrequestsclient367:MultimediaNetworkingMoreaboutCDNsroutingrequestsCDNcreatesa“map”,indicatingdistancesfromleafISPsandCDNnodeswhenqueryarrivesatauthoritativeDNSserver:serverdeterminesISPfromwhichqueryoriginatesuses“map”todeterminebestCDNserverCDNnodescreateapplication-layeroverlaynetwork377:MultimediaNetworkingSummary:InternetMultimedia:bagoftricksuseUDPtoavoidTCPcongestioncontrol(delays)fortime-sensitivetrafficclient-sideadaptiveplayoutdelay:tocompensatefordelayserversidematchesstreambandwidthtoavailableclient-to-serverpathbandwidthchoseamongpre-encodedstreamratesdynamicserverencodingrateerrorrecovery(ontopofUDP)FEC,interleaving,errorconcealmentretransmissions,timepermittingCDN:bringcontentclosertoclients387:MultimediaNetworkingReal-TimeProtocol(RTP)RTPspecifiespacketstructureforpacketscarryingaudio,videodataRFC3550RTPpacketprovides

payloadtypeidentificationpacketsequencenumberingtimestampingRTPrunsinendsystemsRTPpacketsencapsulatedinUDPsegmentsinteroperability:iftwoInternetphoneapplicationsrunRTP,thentheymaybeabletoworktogether397:MultimediaNetworkingRTPrunsontopofUDPRTPlibrariesprovidetransport-layerinterfacethatextendsUDP:portnumbers,IPaddressespayloadtypeidentificationpacketsequencenumberingtime-stamping407:MultimediaNetworkingRTPExampleconsidersending64kbpsPCM-encodedvoiceoverRTP.applicationcollectsencodeddatainchunks,e.g.,every20msec=160bytesinachunk.audiochunk+RTPheaderformRTPpacket,whichisencapsulatedinUDPsegmentRTPheaderindicatestypeofaudioencodingineachpacketsendercanchangeencodingduringconference.RTPheaderalsocontainssequencenumbers,timestamps.417:MultimediaNetworkingRTPandQoSRTPdoesnotprovideanymechanismtoensuretimelydatadeliveryorotherQoSguarantees.RTPencapsulationisonlyseenatendsystems(not)byintermediaterouters.routersprovidingbest-effortservice,makingnospecialefforttoensurethatRTPpacketsarriveatdestinationintimelymatter.

427:MultimediaNetworkingRTPHeaderPayloadType(7bits):Indicatestypeofencodingcurrentlybeing

used.Ifsenderchangesencodinginmiddleofconference,senderinformsreceiverviapayloadtypefield.

Payloadtype0:PCMmu-law,64kbpsPayloadtype3,GSM,13kbpsPayloadtype7,LPC,2.4kbpsPayloadtype26,MotionJPEGPayloadtype31.H.261Payloadtype33,MPEG2videoSequenceNumber(16bits):IncrementsbyoneforeachRTPpacketsent,andmaybeusedtodetectpacketlossandtorestorepacketsequence.437:MultimediaNetworkingRTPHeader(2)Timestampfield(32byteslong):samplinginstantoffirstbyteinthisRTPdatapacketforaudio,timestampclocktypicallyincrementsbyoneforeachsamplingperiod(forexample,each125usecsfor8KHzsamplingclock)ifapplicationgenerateschunksof160encodedsamples,thentimestampincreasesby160foreachRTPpacketwhensourceisactive.Timestampclockcontinuestoincreaseatconstantratewhensourceisinactive.

SSRCfield(32bitslong):

identifiessourceoftRTPstream.EachstreaminRTPsessionshouldhavedistinctSSRC.447:MultimediaNetworkingReal-TimeControlProtocol(RTCP)worksinconjunctionwithRTP.eachparticipantinRTPsessionperiodicallytransmitsRTCPcontrolpacketstoallotherparticipants.eachRTCPpacketcontainssenderand/orreceiverreportsreportstatisticsusefultoapplication:#packetssent,#packetslost,interarrivaljitter,etc.feedbackcanbeusedtocontrolperformancesendermaymodifyitstransmissionsbasedonfeedback457:MultimediaNetworkingRTCP-Continued

eachRTPsession:typicallyasinglemulticastaddress;allRTP/RTCPpacketsbelongingtosessionusemulticastaddress.RTP,RTCPpacketsdistinguishedfromeachotherviadistinctportnumbers.tolimittraffic,eachparticipantreducesRTCPtrafficasnumberofconferenceparticipantsincreases467:MultimediaNetworkingRTCPPacketsReceiverreportpackets:fractionofpacketslost,lastsequencenumber,averageinterarrivaljitterSenderreportpackets:

SSRCofRTPstream,currenttime,numberofpacketssent,numberofbytessentSourcedescriptionpackets:

e-mailaddressofsender,sender'sname,SSRCofassociatedRTPstreamprovidemappingbetweentheSSRCandtheuser/hostname477:MultimediaNetworkingSynchronizationofStreamsRTCPcansynchronizedifferentmediastreamswithinaRTPsessionconsidervideoconferencingappforwhicheachsendergeneratesoneRTPstreamforvideo,oneforaudio.timestampsinRTPpacketstiedtothevideo,audiosamplingclocksnottiedtowall-clocktimeeachRTCPsender-reportpacketcontains(formostrecentlygeneratedpacketinassociatedRTPstream):timestampofRTPpacketwall-clocktimeforwhenpacketwascreated.receiversusesassociationtosynchronizeplayoutofaudio,video487:MultimediaNetworkingRTCPBandwidthScalingRTCPattemptstolimititstrafficto5%ofsessionbandwidth.Example

Supposeonesender,sendingvideoat2Mbps.ThenRTCPattemptstolimititstrafficto100Kbps.RTCPgives75%ofratetoreceivers;remaining25%tosender75kbpsisequallysharedamongreceivers:withRreceivers,eachreceivergetstosendRTCPtrafficat75/Rkbps.sendergetstosendRTCPtrafficat25kbps.

participantdeterminesRTCPpackettransmissionperiodbycalculatingavgRTCPpacketsize(acrossentiresession)anddividingbyallocatedrate

497:MultimediaNetworkingSIP:SessionInitiationProtocol

[RFC3261]SIPlong-termvision:alltelephonecalls,videoconferencecallstakeplaceoverInternetpeopleareidentifiedbynamesore-mailaddresses,ratherthanbyphonenumbersyoucanreachcallee,nomatterwherecalleeroams,nomatterwhatIPdevicecalleeiscurrentlyusing507:MultimediaNetworkingSIPServicesSettingupacall,SIPprovidesmechanisms..forcallertoletcalleeknowshewantstoestablishacallsocaller,calleecanagreeonmediatype,encodingtoendcalldeterminecurrentIPaddressofcallee:mapsmnemonicidentifiertocurrentIPaddresscallmanagement:addnewmediastreamsduringcallchangeencodingduringcallinviteotherstransfer,holdcalls517:MultimediaNetworkingSettingupacalltoknownIPaddress

Alice’sSIPinvitemessageindicatesherportnumber,IPaddress,encodingshepreferstoreceive(PCMulaw)

Bob’s200OKmessageindicateshisportnumber,IPaddress,preferredencoding(GSM)

SIPmessagescanbesentoverTCPorUDP;heresentoverRTP/UDP.

defaultSIPportnumberis5060.527:MultimediaNetworkingSettingupacall(more)codecnegotiation:supposeBobdoesn’thavePCMulawencoder.Bobwillinsteadreplywith606NotAcceptableReply,listinghisencodersAlicecanthensendnewINVITEmessage,advertisingdifferentencoderrejectingacallBobcanrejectwithreplies“busy,”“gone,”“paymentrequired,”“forbidden”mediacanbesentoverRTPorsomeotherprotocol537:MultimediaNetworkingExampleofSIPmessageINVITEsip:bob@SIP/2.0Via:SIP/2.0/UDP4From:sip:alice@To:sip:bob@Call-ID:a2e3a@Content-Type:application/sdpContent-Length:885c=INIP44m=audio38060RTP/AVP0Notes:HTTPmessagesyntaxsdp=sessiondescriptionprotocolCall-IDisuniqueforeverycall.

Herewedon’tknowBob’sIPaddress.IntermediateSIP

serversneeded.

Alicesends,receivesSIPmessagesusingSIPdefaultport506

AlicespecifiesinVia:

headerthatSIPclient

sends,receivesSIPmessagesoverUDP547:MultimediaNetworkingNametranslationanduserlocataioncallerwantstocallcallee,butonlyhascallee’snameore-mailaddress.needtogetIPaddressofcallee’scurrenthost:usermovesaroundDHCPprotocoluserhasdifferentIPdevic