Multimedia Communications Spring 2006-07 Advances in the Transport - PowerPoint PPT Presentation

CS 584 / CMPE 584 Multimedia Communications Spring 2006-07 Advances in the Transport Layer (RTP) Shahab Baqai LUMS

Outline � Why RTP? � RTP Features � RTP Packet � RTCP � RTCP Reports � Jitter Estimation 2

RTP � provide end-to-end network transport functions � applications transmitting real-time multimedia data � mode of transmission – Unicast – multicast � data transport is monitored by a sister protocol RTCP – allow monitoring of the data delivery – scalable to large multicast networks – provide minimal control and identification functionality. � RTP is proposed by IETF in the RFC 1889 – Audio/video profile in RFC 1890 3

Why RTP � TCP cannot support the real time services – Why?? � UDP is used over IP as a better option – Pros: multiplexing and check sum services – Cons: does not support retransmissions upon packet loss � RTP counters drawbacks of UDP for multimedia � RTP may be used with suitable underlying network or transport protocols but with some expectations from lower level protocols – Length indication – Framing mechanism – Possibility of packing multiple RTP packets into one network/transport packet 4

RTP Features � RTP aids in – payload type identification – sequencing of the out-of-order packets – Timely play out of the media data using timestamps � RTCP – monitors the quality of service – conveys information about the participants in an on-going session � RTP is independent of the underlying protocol – can work on any type of network like TCP/IP, ATM, frame relay etc. � RTP supports multicast distribution if provided by the underlying network � RTP sequence numbers can also be used to determine the proper location of a packet – E.g. sequence numbers can be used in video decoding, without necessarily decoding packets in sequence 5

RTP Does Not � Provide any mechanism to ensure timely delivery, nor provides QoS guarantees – Relies on lower layer services to do so � Does Not Guarantee delivery, nor prevents out-of-order delivery – Does not assume that the underlying network is reliable nor that it delivers packets in sequence – Provides sequence numbers to determine the proper location of a packet 6

RTP � RTP is a protocol framework – As a protocol, it is deliberately not complete – RTP is tailored to applications through modifications, rather than by providing options � Complete specs for an application requires – A profile specs � Defines • Set of payload type codes • Mapping of payload types to payload formats – Payload format specs 7

RTP � RTP uses: – Application level framing – Integrated layer processing � Malleable to provide the information required by a particular application � Often integrated into application processing rather than being implemented as a separate layer 8

RTP & OSI PCMA audio MPEG2 video Application RTP RTP Transport UDP UDP I P I P Network Ethernet Frame Relay Data Link • Which layer does RTP reside in? 9

RTP Encapsulation RTP UDP RTP Video Payload Header IP Header Header RTP UDP RTP Audio Payload IP Header Header Header • Video and audio payloads are sent separately • Uses sequence number to synchronise audio and video once received 10

RTP Packet � RTP packet – Fixed RTP packet header – List of contributing sources (possibly empty) – Payload data � RTP payload – Data transported by RTP in a packet � E.g. audio samples, compressed video data, etc … 11

RTP Header V=2 P X CC M PT Sequence Number Time Stamp SSRC CSRC identifiers …… Payload (V) Version; 2 bits (P) Padding; 1 bit. (X) Extension; 1 bit. (CC) CSRC Count; 4 bits. (M) Marker; 1 bit. (PT) Payload Type; 7 bits. Sequence Number ; 16 bits. Time Stamp ; 32 bits. SSRC ; 32 bits. CSRC List ; 12

Header (cont) � Version (V): The field is of length 2 bits – indicates the current version of RTP. The current version of RTP is 2.0. � Padding (P): This field is of length 1 bit. – If P is set, the packet contains one or more additional padding octets at the end, which are not part of the payload. – Last octet of padding contains a count of how many padding octets are to be ignored – Padding is needed by some encryption algorithms, which require fixed block sizes, or for carrying several RTP packets in a lower-layer PDU. � Extension (X): This field is of length 1 bit. – If X is set, the fixed header is followed by exactly one header extension (defined by profile) 13

Header (cont) � CSRC count (CC): This field is of length 4 bits. – indicates the number of CSRC identifiers that follow the fixed headers. – the field has a non-zero value only if passed through a mixer. � Marker bit (M): This field is of length 1 bit. – If M is set, it indicates some significant events like frame boundaries to be marked in the packet stream. – For example, an RTP marker bit is set if the packet contains a few bits of the previous frame along with the current frame. � Payload type (PT): This field is of length 7 bits. – PT indicates the payload type carried by the RTP packet. – RTP Audio Video Profile (AVP) contains a default static mapping of payload type codes to payload formats. – Additional payload types can be registered with IANA. 14

Header (cont) � Sequence number : This field is of length 16 bits. – The number increments by one for each RTP data packet sent, with the initial value set to a random value. – The receiver can use the sequence number not only to detect packet loss but also to restore the packet sequence. � Time stamp: This field is of length 32 bits. – The time stamp reflects the sampling instant of the first octet in the RTP data packet. – The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations at the receiver. – The initial value should be random, so as to prevent known plain text attacks. – several packets may have equal timestamps (eg. same video frame), or even in disorder � E.g. interpolated frames in MPEG 15

Header (cont) � SSRC: This field is of length 32 bits. – This field identifies the source that is generating the RTP packets for this session. – The identifier is chosen randomly so that no two sources within the same RTP session have the same value. � CSRC list : – The list identifies the contributing sources for the payload contained in this packet. – The maximum number of identifiers is limited to 15, as is apparent from the CC field 16

Synchronization Source (SSRC) – Source of a stream of RTP packets – 32-bit numeric identifier, randomly chosen meant to be globally unique – Carried in RTP header (thus not dependent on network address) – Allows receiver to group packets from same synchronization source � To identify the use of the same timing & sequence number space – A participant need not use the same SSRC identifier for all RTP sessions in a multimedia session � Binding of identifiers is provided through RTCP – If a participant generates multiple streams in one RTP session (separate video cameras) each must be identified as a different SSRC 17

SSRC Identifier Allocation � 32 bit random number – Must not just pick IP address, or other local identifier – Must not just call random() without carefully initializing state � If done right, chance of collision is very small – For joining a 1000-user session, about 1 in 5 million � However, RTP requires collision detection and resolution code – If a source sees another with same SSRC, it sends a BYE and picks again – Receivers can temporarily supress a conflicting SSRC using transport address � Misconfigured translators/mixer can cause loops 18

Contributing Source (CSRC) � A source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer 19

RTP Use Scenarios � Simple multicast audio conference – A multicast group address is assigned – 2 UDP ports are assigned � One for RTP packaged audio data � One for RTCP – Address & port info distributed to intended participants – Encryption key is also distributed if privacy is required – Allocation and distribution mechanisms are outside the scope of RTP 20

RTP Use Scenarios (cont.) – Audio conferencing application at each participant sends audio data in small chunks (e.g. of 20 msec duration) � RTP header is appended to each chunk • Indicates type of encoding (e.g. PCM, ADPCM, LPC) Senders can change encoding during a conference. E.g. – To accommodate a new participant connected thru a low bandwidth link – To react to network congestion • Carries timing information (for playback purposes) – Performed separately for each source • Carries sequence number – To estimate how many packets are lost � RTP packet (header + data) encapsulated into a UDP packet 21

RTP Use Scenarios (cont.) � RTCP – Dynamic participant group � Useful to know: • Who is participating • How well they are receiving audio data – Audio application periodically multicasts: � A reception report • How well the current speaker is being received • Used to control adaptive encoding � The name of its user – RTCP BYE packet sent when participant leaves conference 22