Need of RTP• Real-time multimedia applications – Video teleconferencing – Internet Telephony (VoIP) – Internet audio, video streaming
Real time multimedia applicationrequirements – Sequencing – to report PDU loss – to report PDU reordering – to perform out-of-order decoding – Time stamping and Buffering – for play out – for jitter and delay calculation – Payload type identification – for media interpretation – Error concealment – – covers up errors from lost PDU by using redundancy in most-adjacent-frame
Real time multimedia applicationrequirements – Rate control – – Sender reduces sending rate adaptively to network congestion – Quality of Service (QoS) feedback – – From receiver to sender for operation adjustment
Limitations of TCP• TCP is not used because- • TCP does retransmissions unbounded delays • No provision for time stampings(slow and noisy walks ) • TCP does not support multicast • TCP congestion control (slow-start) unsuitable for real-time transport
RTP & RTCP Overview• Standardized packet format for delivering audio and video over IP networks.• Used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web- based push-to-talk features.• RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams.
RTP & RTCP Overview• RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number.• RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facility for jitter compensation and detection of out of sequence arrival in data, that are common during transmissions on an IP network.• RTP supports data transfer to multiple destinations through IP multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.
Protocol stack for multimediaservices RTSP TCP (till now)
RTP Packets• Consist of RTP header, optional payload headers and the payload itself RTP overhead = 12 bytes• IP+UDP+RTP overhead = 20+8+12 = 40 bytes• It is advisable to keep coded slice sizes as close to, but never bigger than, the MTU size (largest size of a packet that can be transmitted without being split/recombined on the transport and network layer)
RTP Packets• Reasons are as follows :- • It optimizes the payload/header overhead relationship • Minimizes the loss probability of a (fragmented) coded slice due to the loss of a single fragment on the network/transport layer and the resulting discarding of all other fragments belonging to the coded slice. • MTU sizes:- • ~1500 bytes for wireline IP links (max. size of an Ethernet packet) • ~100 bytes in wireless environments
RTP packet example• DVD quality video transmission:- • 30 frames/s, 720x480 resolution, 3 bytes per pixel • 31,104,000 bytes/s raw rate • 311,040 bytes/s compressed data rate (100x compression) • MTU = 1500 bytes:- • 311,040/1460 = 213 packets/s > 319,500 bytes/s (required throughput including overhead) • MTU = 100 bytes:- • 311,040/60 = 5184 packets/s -> 518,400 bytes/s (required throughput)
RTP HeaderRTP header contains the following:- • Sequence number • used for packet-loss detection• Timestamp • Timing information • synchronization of media streams• Payload type • Identifies the media codec of the payload
RTP HeaderRTP header contains the following:-• Marker Bit • Detecting the end of a group of related packets• source identifiers • Contributing and Synchronizing
SIP SESSION• RTP session is sending and receiving of RTP data by a group of participants • For each participant, a session is a pair of transport addresses used to communicate with the group• If multiple media types are communicated by the group, the transmission of each medium constitutes a session.
RTP Synchronization Source• Synchronization Source :- • Each source of RTP PDUs Identified by a unique ,randomly chosen 32-bit ID (the SSRC).• A host generating multiple streams within a single RTP must use a different SSRC per stream
RTP PDU Header Incremented by oneSampling instant of first data octet for each RTP PDU: multiple PDUs can have sametimestamp PDU loss Payload detection not necessarily monotonic typeused to synchronize different Restore PDU sequencemedia streams Identifies synchronization (used by mixer) source Identifies contributing sources
Example – Mixers and Translators• Mixers:- • RTP-level entity that receives streams of RTP data packets from one or more sources and combines them into a single stream. • Mixer is like a new RTP-level source to the receivers. • Mixer can re-synchronize the incoming stream and generates its own timing info.• Translator • Forwards RTP packets from different sources separately. • Translator is more transparent. Receivers can identify individual sources even though packets pass through the same translator and carry the translator’s network source address.
Translators and Mixers• The real distinction between mixers and translators:- • SSRC identifier is not changed at a translator, but is changed at a mixer. • They both use a different transport address (network address + port) at the output side.• Multiple data packets can be combined into one.• Uses of translators and mixers:- • Go-through firewalls • Transcoding for low-bandwidth links • Adding or removing encryption • Emulating multicast address with one or more unicast addresses.
MixersA mixer will typically have to define synchronization relationshipsbetween streams. Sources that are mixed together become contributing sources (CSRC) Mixer itself appears as a new source having a new SSRC
TranslatorsAn intermediate system that… Connects two or more networks Multicasting through a firewall Modifies stream encoding, changing the stream’s timing Transparent to participants SSRC’s remain intactend system 1 from ES1: SSRC=6 from ES1: SSRC=6 from ES2: SSRC=23 transl.1 transl.2 from ES2: SSRC=23 authorized tunnelend system 2 firewall from ES1: SSRC=6 from ES2: SSRC=23
RTCP• The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets.• The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP.• It is recommended that the fraction of the session bandwidth allocated to the RTCP is 5%.• The primary function of this protocol is to provide feedback on the quality of the data distribution.• RTCP
RTP Control Protocol (RTCP) RTCP specifies report PDUs exchangedbetween sources and destinations ofmultimedia information receiver reception report sender report source description report Reports contain statistics such as thenumber of RTP-PDUs sent, number ofRTP-PDUs lost, inter-arrival jitter Used by application to modify sendertransmission rates and for diagnosticspurposes
RTCP PACKETS• SR – sender report, for transmission and reception statistics from participants that are active senders• RR - Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources• SDES - Source description items, including CNAME (Canonical Name – RTP source identifier)• BYE - Indicates end of participation• APP - Application specific functions
Conclusions• RTP provides powerful instruments for adaptive video transmission.• Potential applications include wireless links.• Optimization can be done within the frames of the protocol specification (loosely defined packet sizes and RTCP communication• frequency)