/
The Real Time Transport Protocol (RTP) The Real Time Transport Protocol (RTP)

The Real Time Transport Protocol (RTP) - PowerPoint Presentation

myesha-ticknor
myesha-ticknor . @myesha-ticknor
Follow
427 views
Uploaded On 2018-03-16

The Real Time Transport Protocol (RTP) - PPT Presentation

Jonathan Rosenberg Chief Scientist Talk Overview RTP Functions The Big Picture RTP Services RTCP Services Scaling RTCP Aggregation RTP What is it Real Time Transport Protocol RFC 1889 product of avt working group ID: 652902

rtcp rtp time packet rtp rtcp packet time data packets group real payload users header size audio multicast send format control transport

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "The Real Time Transport Protocol (RTP)" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

The Real Time Transport Protocol (RTP)

Jonathan Rosenberg

Chief ScientistSlide2

Talk OverviewRTP FunctionsThe Big PictureRTP ServicesRTCP ServicesScaling RTCPAggregationSlide3

RTP: What is it?Real Time Transport ProtocolRFC 1889product of avt working group1996 proposed standard2000 draft standard (new rfc)What does it doe2e transport of real time mediaoptimized for multicast (Mbone)provides sequencing, timing, framing, loss detection

provides feedback on reception qualityWhat does it do (cont)provides information on group membersprovides data to correlate audio and video and other mediaFeaturesScales to huge multicast groups (millions)

Works with any codecneed payload format for each codecFlexibleSlide4

RTP: What isn’t it?Doesn’t guarantee quality of servicedoesn’t reserve network resourcesdoesn’t guarantee no loss or bounded delaycan work with QoS protocols (RSVP)Doesn’t provide signalingother protocols must be used to set up RTP (like SIP or H.323)

Not a specific protocol typeDoes not run directly ontop of IPRuns ontop of UDPNo fixed port numberSlide5

RTP StackIP

UDP

RTP

RTCPSlide6

Big Picture: RTP, SDP and SIPEnd

User

EndUser

Proxy

Proxy

IP Network

SIP w/ SDP

C=IN IP4 123.1.2.3

m=audio RTP/AVP 1122 0 1

m=video RTP/AVP 1130 98

a=rtpmap:98 h263

RTPSlide7

RTP Components: Data + ControlData aka RTPvery confusingAlways on an even UDP portProvidessequencingtimingframingcontent labelingUser idenfitication

Control = Real Time Control Protocol (RTCP)Same address as data, but one higher portProvidesreception qualitysender statisticsparticipant information (multicast - Mbone)synchronization informationSlide8

Real Time Data TransportOriginator breaks stream into packets (segmentation)application layer framing (ALF)!!!Packets sent; network may lose, delay, reorder packetsMust, at receiver:reorderrecoverresegmentrescynchronizeclock synchronization!

RTP Source

RTP Sink

RTP

PacketsSlide9

Transport SystemSourceDigitize Audio from mikeSilence SuppressionEcho cancellationCompress AudioG.711: 64 kbpsG.729: 8 kbpsG.723.1: 5.3/6.3 kbpsPacketize Audio in RTP

SendSinkReceive packetsUn-packetizedecompresscomfort noise generationreorder

recover lossjitter bufferA/D conversion to speakersSlide10

Jitter BufferPackets delayed differentlyMust play them out periodicallyPackets may arrive after designated playout time -> lossInsert extra delay to compensateMay need to adapt this amount

time

pktsSlide11

RTP Packet Header

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Slide12

RTP Header FieldsVersion: 2P: indicates padding (for encryption)X: extension bitCSRC count: for mixers (later)M: Marker Bit: indicates framingaudio codecs: first packet in talkspurtvideo: last packet in frame

Payload Type: indicates encodingin RTP packet allows changes per-packetUseful for:adaptationDTMF codecsilence codecsSN: defines ordering of packetsTimestamp: when packet was generatedSSRC: identifier

CSRC: list of mixed usersSlide13

RTP TimestampTick units are dependent on codecFor speech: 125 microseconds (standard 8 khz sampling rate)For video: 90 KhZFor audio: 44.1 KhZ (CD rate)Gaps in TS, but not in SN mean silenceInitial value random for security

VideoTimestamp represents time at beginning of frameMany packets may have same timestampSpeechTime per packet may varyDepends on packetization: 20-100ms typicalSlide14

Mixers and TranslatorsMixer = Bridgecombines audio from many users into one streamCSRC list indicates users being mixedTranslatorConverts from one format to anotherFor low speed access links

MIXER

TRANSLATORSlide15

RTCP: Real Time Control ProtocolSent by all participantsboth senders and receivers (think multicast)Same address as data, different port (one higher)Several RTCP Packet TypesSender Report (SR): from sendersReceiver Report (RR): by receivers. Indicates reception qualitySource Descriptor (SDES): describes participantBYE: sent when leaving

Sender ReportSSRC of sendernumber of bytes sentnumber of packets sentwall time + RTP timestamp (for correlation)receiver report dataSDES

CNAME of participant (unique)SSRC of participantname, address, emailSlide16

Real Time Control ProtocolReceiver ReportsBlock for each senderPer sender data containsSSRC of senderfraction lost from senderjitter seen fromsenderhighest SN receivedcumulative packets lostDLSR: delay since last SR

LSR: time of last sender reportBYE packetsreason for leavingfor mixers, SSRC of those users leavingSlide17

Compound RTCP PacketsActual UDP packet contains many RTCP packetsAlways starts with SR or RRAlways contains SDESMay contain BYE

UDP Hdr

SR Header

SR Data

SSRC1

RR Data

SSRC2

RR Data

SDES Header

Name

EmailSlide18

RTCP Announcement IntervalRTP used in large multicast groups (possibly thousands)Everyone sends RTCP, even receiversWhen to send RTCP?Possibilities:Every T seconds: RTCP bandwidth linear with group size. Bad!Never: nahhhWith N participants, every N*C seconds

Current RTCP AlgorithmEstimate group size Llisten for other RTCP packetsBuild up table of SSRC/CNAMECompute interval LCC depends on desired RTCP bandwidth and average RTCP packet sizeRandomize by 1/2 to 3/2Send packet, do it againSlide19

Algorithm SubtletiesAlgorithm slightly different for sendersFor senders, L is actually number of other sendersGives much more bandwidth to data sendersParticipants must measure avg. RTCP size on the fly to compute CRTCP defines a minimum interval of 5 secondsFirst packet has minimum interval of 2.5 seconds

speed up knowing who you’re talking toReconsideration Algorithmgroup sizes can be very dynamicSlide20

Reconsideration AlgorithmProblem:Many users join group at same timeEach thinks group size is 1Each sends packet right away!Solution: ReconsiderationDon’t send packet! Check if group size has increased. If so, reschedule packetThat’s conditional reconsiderationUnconditional reconsideration

Always reschedule packetIf group size hasn’t change, random number redrawnTurns out this works much better… long story.BYE ReconsiderationStop everyone from sending BYE if they all leave group at same timeReverse Reconsideration

If people leave, allow users to send packets more frequently right awaySlide21

Payload FormatsEach codec needs a way to be encapsulated in RTPRFC1890 defines mechanisms for many common codecsG.711, G.729, G.723.1, G.722, etc.Some simple videoMore complex codecs have their own payload format documentsMPEGH.263 and H.261

Payload format definesHow to break frame into packetsextra fields needed below main RTP headerHow to recover missing packets (sort of)Slide22

Special Payload FormatsRedundant EncodingsEach packet contains two versions of voiceCurrent frameLow bit rate encoding of previous frameWhen packet is lost, wait for next one!Introduces delayNeeds many codecs at source

FEC Payload Format (RFC2733, issuing tomorrow)Use parity codes (XOR) to protect packetsTake N packets, XOR them, get FEC packetSend FEC packetCan recover if any one of N packets is lostSlide23

Special FormatsAggregationMix many users together in a single packetUseful for gateway to gateway communicationsCan also reduce overheadsCompressed RTPFor dialup links

Don’t send header, just send indexFar side uses index to retrieve header, and then increments certain fields