Chapter7

MultimediaNetworkingAnoteontheuseofthesepptslides:We’remakingtheseslidesfreelyavailabletoall(faculty,students,readers).They’reinPowerPointformsoyoucanadd,modify,anddeleteslides(includingthisone)andslidecontenttosuityourneeds.Theyobviouslyrepresentalotofworkonourpart.Inreturnforuse,weonlyaskthefollowing:Ifyouusetheseslides(e.g.,inaclass)insubstantiallyunalteredform,thatyoumentiontheirsource(afterall,we’dlikepeopletouseourbook!)Ifyoupostanyslidesinsubstantiallyunalteredformonawwwsite,thatyounotethattheyareadaptedfrom(orperhapsidenticalto)ourslides,andnoteourcopyrightofthismaterial.Thanksandenjoy!JFK/KWRAllmaterialcopyright1996-2009J.FKuroseandK.W.Ross,AllRightsReservedComputerNetworking:ATopDownApproach

5thedition.

JimKurose,KeithRoss

Addison-Wesley,April2009.

17:MultimediaNetworkingMultimediaandQualityofService:Whatisit?multimediaapplications:networkaudioandvideo(“continuousmedia”)networkprovidesapplicationwithlevelofperformanceneededforapplicationtofunction.QoS27:MultimediaNetworkingChapter7:goalsPrinciplesclassifymultimediaapplicationsidentifynetworkservicesapplicationsneedmakingthebestofbesteffortserviceProtocolsandArchitectures

specificprotocolsforbest-effortmechanismsforprovidingQoSarchitecturesforQoS37:MultimediaNetworkingChapter7outline7.1multimedianetworkingapplications7.2streamingstoredaudioandvideo7.3makingthebestoutofbesteffortservice7.4protocolsforreal-timeinteractiveapplications

RTP,RTCP,SIP7.5providingmultipleclassesofservice7.6providingQoSguarantees47:MultimediaNetworkingMMNetworkingApplicationsFundamentalcharacteristics:typicallydelay

sensitiveend-to-enddelaydelayjitter

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

Whatisit?1.videorecorded2.videosent3.videoreceived,playedoutatclientCumulativedatastreaming:atthistime,clientplayingoutearlypartofvideo,whileserverstillsendinglaterpartofvideonetworkdelaytime77:MultimediaNetworkingStreamingStoredMultimedia:InteractivityVCR-likefunctionality:clientcanpause,rewind,FF,pushsliderbar10secinitialdelayOK1-2secuntilcommandeffectOKtimingconstraintforstill-to-betransmitteddata:intimeforplayout87:MultimediaNetworkingStreamingLiveMultimediaExamples:InternetradiotalkshowlivesportingeventStreaming(aswithstreamingstoredmultimedia)playbackbufferplaybackcanlagtensofsecondsaftertransmissionstillhavetimingconstraintInteractivityfastforwardimpossiblerewind,pausepossible!97:MultimediaNetworkingReal-TimeInteractiveMultimediaend-enddelayrequirements:audio:<150msecgood,<400msecOKincludesapplication-level(packetization)andnetworkdelayshigherdelaysnoticeable,impairinteractivitysessioninitializationhowdoescalleeadvertiseitsIPaddress,portnumber,encodingalgorithms?applications:IPtelephony,videoconference,distributedinteractiveworlds107:MultimediaNetworkingMultimediaOverToday’sInternetTCP/UDP/IP:“best-effortservice”noguaranteesondelay,lossToday’sInternetmultimediaapplicationsuseapplication-leveltechniquestomitigate(asbestpossible)effectsofdelay,lossButyousaidmultimediaappsrequiresQoSandlevelofperformancetobeeffective!???????????117:MultimediaNetworkingHowshouldtheInternetevolvetobettersupportmultimedia?Integratedservicesphilosophy:

fundamentalchangesinInternetsothatappscanreserveend-to-endbandwidthrequiresnew,complexsoftwareinhosts&routersLaissez-fairenomajorchangesmorebandwidthwhenneededcontentdistribution,application-layermulticastapplicationlayerDifferentiatedservicesphilosophy:fewerchangestoInternetinfrastructure,yetprovide1stand2ndclassserviceWhat’syouropinion?127:MultimediaNetworkingAfewwordsaboutaudiocompressionanalogsignalsampledatconstantratetelephone:8,000samples/secCDmusic:44,100samples/seceachsamplequantized,i.e.,roundede.g.,28=256possiblequantizedvalueseachquantizedvaluerepresentedbybits8bitsfor256valuesexample:8,000samples/sec,256quantizedvalues-->64,000bpsreceiverconvertsbitsbacktoanalogsignal:somequalityreductionExampleratesCD:1.411MbpsMP3:96,128,160kbpsInternettelephony:5.3kbpsandup137:MultimediaNetworkingAfewwordsaboutvideocompressionvideo:sequenceofimagesdisplayedatconstantratee.g.24images/secdigitalimage:arrayofpixelseachpixelrepresentedbybitsredundancyspatial(withinimage)temporal(fromoneimagetonext)Examples:MPEG1(CD-ROM)1.5MbpsMPEG2(DVD)3-6MbpsMPEG4(oftenusedinInternet,<1Mbps)Research:layered(scalable)videoadaptlayerstoavailablebandwidth147:MultimediaNetworkingChapter7outline7.1multimedianetworkingapplications7.2streamingstoredaudioandvideo7.3makingthebestoutofbesteffortservice7.4protocolsforreal-timeinteractiveapplications

RTP,RTCP,SIP7.5providingmultipleclassesofservice7.6providingQoSguarantees157:MultimediaNetworkingStreamingStoredMultimediaapplication-levelstreamingtechniquesformakingthebestoutofbesteffortservice:client-sidebufferinguseofUDPversusTCPmultipleencodingsofmultimedia

jitterremovaldecompressionerrorconcealmentgraphicaluserinterface

w/controlsforinteractivityMediaPlayer167:MultimediaNetworkingInternetmultimedia:simplestapproachaudio,videonotstreamed:no,“pipelining,”longdelaysuntilplayout!audioorvideostoredinfilefilestransferredasHTTPobjectreceivedinentiretyatclientthenpassedtoplayer177:MultimediaNetworkingInternetmultimedia:streamingapproachbrowserGETs

metafilebrowserlaunchesplayer,passingmetafileplayercontactsserverserverstreamsaudio/videotoplayer187:MultimediaNetworkingStreamingfromastreamingserverallowsfornon-HTTPprotocolbetweenserver,mediaplayerUDPorTCPforstep(3),moreshortly197:MultimediaNetworking

constantbitratevideotransmissionCumulativedatatimevariablenetworkdelayclientvideoreception

constantbitratevideoplayoutatclientclientplayoutdelaybufferedvideoStreamingMultimedia:ClientBufferingclient-sidebuffering,playoutdelaycompensatefornetwork-addeddelay,delayjitter207:MultimediaNetworkingStreamingMultimedia:ClientBufferingclient-sidebuffering,playoutdelaycompensatefornetwork-addeddelay,delayjitterbufferedvideovariablefillrate,x(t)constantdrainrate,d217:MultimediaNetworkingStreamingMultimedia:UDPorTCP?UDPserversendsatrateappropriateforclient(oblivioustonetworkcongestion!)oftensendrate=encodingrate=constantratethen,fillrate=constantrate-packetlossshortplayoutdelay(2-5seconds)toremovenetworkjittererrorrecover:timepermittingTCPsendatmaximumpossiblerateunderTCPfillratefluctuatesduetoTCPcongestioncontrollargerplayoutdelay:smoothTCPdeliveryrateHTTP/TCPpassesmoreeasilythroughfirewalls227:MultimediaNetworkingStreamingMultimedia:clientrate(s)Q:howtohandledifferentclientreceiveratecapabilities?28.8Kbpsdialup100MbpsEthernetA:serverstores,transmitsmultiplecopiesofvideo,encodedatdifferentrates1.5Mbpsencoding28.8Kbpsencoding237:MultimediaNetworkingUserControlofStreamingMedia:RTSPHTTPdoesnottargetmultimediacontentnocommandsforfastforward,etc.RTSP:RFC2326client-serverapplicationlayerprotocolusercontrol:rewind,fastforward,pause,resume,repositioning,etc…Whatitdoesn’tdo:doesn’tdefinehowaudio/videoisencapsulatedforstreamingovernetworkdoesn’trestricthowstreamedmediaistransported(UDPorTCPpossible)doesn’tspecifyhowmediaplayerbuffersaudio/video247: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”.257:MultimediaNetworkingRTSPExampleScenario:metafilecommunicatedtowebbrowserbrowserlaunchesplayerplayersetsupanRTSPcontrolconnection,dataconnectiontostreamingserver267:MultimediaNetworkingMetafileExample<title>Twister</title><session><grouplanguage=enlipsync>

<switch><tracktype=audioe="PCMU/8000/1"src="rtsp:///twister/audio.en/lofi"><tracktype=audioe="DVI4/16000/2"pt="90DVI4/8000/1"src="rtsp:///twister/audio.en/hifi">

</switch><tracktype="video/jpeg"src="rtsp:///twister/video"></group></session>277:MultimediaNetworkingRTSPOperation287:MultimediaNetworkingRTSPExchangeExample

C:SETUPrtsp:///twister/audioRTSP/1.0Transport:rtp/udp;compression;port=3056;mode=PLAYS:RTSP/1.02001OKSession4231C:PLAYrtsp:///twister/audio.en/lofiRTSP/1.0Session:4231Range:npt=0-C:PAUSErtsp:///twister/audio.en/lofiRTSP/1.0Session:4231Range:npt=37C:TEARDOWNrtsp:///twister/audio.en/lofiRTSP/1.0Session:4231S:2003OK297:MultimediaNetworkingChapter7outline7.1multimedianetworkingapplications7.2streamingstoredaudioandvideo7.3makingthebestoutofbesteffortservice7.4protocolsforreal-timeinteractiveapplications

RTP,RTCP,SIP7.5providingmultipleclassesofservice7.6providingQoSguarantees307:MultimediaNetworkingReal-timeinteractiveapplicationsPC-2-PCphoneSkypePC-2-phoneDialpadNet2phoneSkypevideoconferencewithwebcamsSkypePolycom

GoingtonowlookataPC-2-PCInternetphoneexampleindetail317:MultimediaNetworkingInteractiveMultimedia:InternetPhoneIntroduceInternetPhonebywayofanexample

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

constantbitratetransmissionCumulativedatatimevariablenetworkdelay(jitter)clientreception

constantbitrateplayoutatclientclientplayoutdelaybuffereddataDelayJitterconsiderend-to-enddelaysoftwoconsecutivepackets:differencecanbemoreorlessthan20msec(transmissiontimedifference)347:MultimediaNetworkingInternetPhone:FixedPlayoutDelayreceiverattemptstoplayouteachchunkexactlyqmsecsafterchunkwasgenerated.chunkhastimestampt:playoutchunkatt+q.chunkarrivesaftert+q:dataarrivestoolateforplayout,data“l(fā)ost”tradeoffinchoosingq:largeq:lesspacketlosssmallq:betterinteractiveexperience357:MultimediaNetworkingFixedPlayoutDelay

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

minimizeplayoutdelay,keepinglatelossratelowApproach:

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

alsousefultoestimateaveragedeviationofdelay,vi:

estimatesdi,vicalculatedforeveryreceivedpacket(butusedonlyatstartoftalkspurtforfirstpacketintalkspurt,playouttimeis:

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

qualitystream”sendlowerresolution

audiostreamas

redundantinformatione.g.,nominal

streamPCMat64kbps

andredundantstream

GSMat13kbps.

wheneverthereisnon-consecutiveloss,

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

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

http:///sports.ruth.gifwith

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

CDNservernearclientCDNcompany()distributesgiffilesusesitsauthoritativeDNSservertorouteredirectrequestsclient457:MultimediaNetworkingMoreaboutCDNsroutingrequestsCDNcreatesa“map”,indicatingdistancesfromleafISPsandCDNnodeswhenqueryarrivesatauthoritativeDNSserver:serverdeterminesISPfromwhichqueryoriginatesuses“map”todeterminebestCDNserverCDNnodescreateapplication-layeroverlaynetwork467:MultimediaNetworkingSummary:InternetMultimedia:bagoftricksuseUDPtoavoidTCPcongestioncontrol(delays)fortime-sensitivetrafficclient-sideadaptiveplayoutdelay:tocompensatefordelayserversidematchesstreambandwidthtoavailableclient-to-serverpathbandwidthchoseamongpre-encodedstreamratesdynamicserverencodingrateerrorrecovery(ontopofUDP)FEC,interleaving,errorconcealmentretransmissions,timepermittingCDN:bringcontentclosertoclients477:MultimediaNetworkingChapter7outline7.1multimedianetworkingapplications7.2streamingstoredaudioandvideo7.3makingthebestoutofbesteffortservice7.4protocolsforreal-timeinteractiveapplications

RTP,RTCP,SIP7.5providingmultipleclassesofservice7.6providingQoSguarantees487:MultimediaNetworkingReal-TimeProtocol(RTP)RTPspecifiespacketstructureforpacketscarryingaudio,videodataRFC3550RTPpacketprovides

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

527:MultimediaNetworkingRTPHeaderPayloadType(7bits):Indicatestypeofencodingcurrentlybeing

used.Ifsenderchangesencodinginmiddleofconference,senderinformsreceiverviapayloadtypefield.

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

SSRCfield(32bitslong):

identifiessourceoftRTPstream.EachstreaminRTPsessionshouldhavedistinctSSRC.547:MultimediaNetworkingRTSP/RTPProgrammingAssignmentbuildaserverthatencapsulatesstoredvideoframesintoRTPpacketsgrabvideoframe,addRTPheaders,createUDPsegments,sendsegmentstoUDPsocketincludeseqnumbersandtimestampsclientRTPprovidedforyoualsowriteclientsideofRTSPissueplay/pausecommandsserverRTSPprovidedforyou557:MultimediaNetworkingReal-TimeControlProtocol(RTCP)worksinconjunctionwithRTP.eachparticipantinRTPsessionperiodicallytransmitsRTCPcontrolpacketstoallotherparticipants.eachRTCPpacketcontainssenderand/orreceiverreportsreportstatisticsusefultoapplication:#packetssent,#packetslost,interarrivaljitter,etc.feedbackcanbeusedtocontrolperformancesendermaymodifyitstransmissionsbasedonfeedback567:MultimediaNetworkingRTCP-Continued

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

SSRCofRTPstream,currenttime,numberofpacketssent,numberofbytessentSourcedescriptionpackets:

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

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

participantdeterminesRTCPpackettransmissionperiodbycalculatingavgRTCPpacketsize(acrossentiresession)anddividingbyallocatedrate

607:MultimediaNetworkingSIP:SessionInitiationProtocol

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

Alice’sSIPinvitemessageindicatesherportnumber,IPaddress,encodingshepreferstoreceive(PCMulaw)

Bob’s200OKmessageindicateshisportnumber,IPaddress,preferredencoding(GSM)

SIPmessagescanbesentoverTCPorUDP;heresentoverRTP/UDP.

defaultSIPportnumberis5060.637:MultimediaNetworkingSettingupacall(more)codecnegotiation:supposeBobdoesn’thavePCMulawencoder.Bobwillinsteadreplywith606NotAcceptableReply,listinghisencodersAlicecanthensendnewINVITEmessage,advertisingdifferentencoderrejectingacallBobcanrejectwithreplies“busy,”“gone,”“paymentrequired,”“forbidden”mediacanbesentoverRTPorsomeotherprotocol647: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,receivesSIPmessagesoverUDP657:MultimediaNetworkingNametranslationanduserlocataioncallerwantstocallcallee,butonlyhascallee’snameore-mailaddress.needtogetIPaddressofcallee’scurrenthost:usermovesaroundDHCPprotocoluserhasdifferentIPdevices(PC,PDA,cardevice)resultcanbebasedon:timeofday(work,home)caller(don’twantbosstocallyouathome)statusofcallee(callssenttovoicemailwhencalleeisalreadytalkingtosomeone)ServiceprovidedbySIPservers:SIPregistrarserverSIPproxyserver667:MultimediaNetworkingSIPRegistrarREGISTERsip:SIP/2.0Via:SIP/2.0/UDP9From:sip:bob@To:sip:bob@Expires:3600whenBobstartsSIPclient,clientsendsSIPREGISTERmessagetoBob’sregistrarserver(similarfunctionneededbyInstantMessaging)RegisterMessage:677:MultimediaNetworkingSIPProxyAlicesendsinvitemessagetoherproxyservercontainsaddresssip:bob@proxyresponsibleforroutingSIPmessagestocalleepossiblythroughmultipleproxies.calleesendsresponsebackthroughthesamesetofproxies.proxyreturnsSIPresponsemessagetoAlicecontainsBob’sIPaddressproxyanalogoustolocalDNSserver687:MultimediaNetworkingExampleCallerjim@

withplacesacalltokeith@

(1)JimsendsINVITE

messagetoumassSIP

proxy.(2)Proxyforwards

requesttoupenn

registrarserver.

(3)upennserverreturns

redirectresponse,

indicatingthatitshould

trykeith@eurecom.fr(4)umassproxysendsINVITEtoeurecomregistrar.(5)eurecomregistrarforwardsINVITEto1,whichisrunningkeith’sSIPclient.(6-8)SIPresponsesentback(9)media