Real-Time Transport Protocol Tung Dao Manh Future Internet Class, 2007.04.15 1

Agenda Introduction Motivation RTP outline Fundamental design philosophies of RTP Application-level framing The end-to-end principle Flexibility Standard elements of RTP RTP Specification RTP Profile RTP Payload Format RTP Packet Format Potential further development of RTP Related Protocol RTCP Conclusion 2

Introduction Motivation Requirements for delivery of media stream Examples of real-time applications: Videoconferencing VoIP, IP telephone system Game online… Real-time data: interactive audio and video Receivers: playing out immediately and synchronously, rather than playing back Requirements for transport protocols: Predictable variation in network transit time Reliable delivery of all packets 8

Introduction Motivation Requirements drive the choice of transport protocols TCP/IP It favors reliability over timeliness, but these applications require timely delivery. Retransmissions can lead to high delay and cause delay jitter Does not support multicast Congestion control mechanism not suitable for audio-video (AV) media UDP/IP A UDP/IP-based should be suitable, provided that the variation in transit time of the network can be characterized and loss rates are acceptable. But it is: No defined technique for synchronizing Streams from different servers may collide A feedback channel must be defined for quality control 8

Introduction Motivation The standard real-time transport protocol was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 – A solution to these described problems. 8

Introduction Real-time data transport at glance 8 Encoded frames are produced They are assigned a timestamp and a sequence number Then, they are load into RTP packet and ready for transmission The sender also generates periodic status reports in the form of RTCP packets to participants The participants also send quality feedback to the sender. Collect packets from network, and insert them into a per-sender input queue. Packets then are passed to a channel- coding routine for loss correct. Next, they are put into a playout-buffer, and any variation in interpacket timing caused by the network has been smoothed. They are then grouped to form complete frames that are decoded to play out. 8

Introduction RTP Outline RTP: Defines a standardized packet format for delivering audio and video over the internet. Internet standard for real-time data Interactive and streamed audio and video Designed for multi-user multimedia conferencing Provides end-to-end transport functions for real-time applications Delay-oriented rather than loss-oriented (such as TCP) 8

RTP Fundamental design philosophies of RTP Application-Level Framing A transport protocol should accept data in application-meaningful units (ADUs) A transport protocol should expose the details of the data delivery as much as possible The end-to-end principle The system can pass responsibility for the correct delivery of data along that with data, meaning it relies on the lower protocols. Intelligence is at the endpoints, not within the network (smart, network-aware endpoints and a dumb network) Achieving flexibility Provides a unifying framework for real-time audio/video transport, satisfying most application directly. 8

RTP Standard elements of RTP Framework RTP specifications RTP profiles RTP payload formats Optional elements 8

Introduction RTP Outline A session consists of an RTP/RTCP pair of channels, containing two closely linked parts: Data + Control. RTP to transport real-time data RTCP: RTP control protocol QoS monitoring and feedback Session control Protocol architecture: usually works over UDP/IP Media Application RTP IP RTCP UDP 8

Introduction RTP Outline 8

Introduction RTP Outline RTP Issues: The protocol itself does not provide mechanisms to ensure timely delivery Relies on lower-layer protocols prevent out-of-order delivery of packets give any Quality of Service (QoS) Guarantee. RTP Timestamp (TS) and Sequence Number (SN) TS is used to order packets in correct timing order SN detect packet loss 8

RTP RTP Features Multicasting Payload type identification Time stamping Enable timing recovery Sequencing Loss detection Delivery monitoring 8

RTP RTP Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | timestamp | | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | (0~15 items).... | | Header extension (optional) | | Payload (real time data) | | | Padding (size X 8 bits) Padding size (8 bits) Version (V): Padding (P) Extension (X) CSRC Count (CC) Marker (M) Payload Type (PT) Sequence Number Timestamp Synchronization Source (SSRC) Contributing Source (CSRC) 8

RTP RTP header Version (V, 2 bits): indicate the version of the protocol (Current version is 2) Padding (P, 1 bit): if set, last byte of payload is padding size Extension (X, 1 bit): if set, variable-size header extension exists CSRC Count (CC, 4 bit): number of SCRC identifiers Marker (M, 1 bit): defined in profile, mark significant event Payload type (7 bits): audio/video encoding scheme Sequence number: random initial value, increase by one for each RTP packet; for loss detection and sequence restoration SSRC: identify source; chosen randomly and locally; collision needs to be resolved CSRC list: identifiers of contributing sources, inserted by mixer 8

RTP RTP header: SSRC and CSRC All packets from a given synchronizing source (with a given SSRC identifier) will use the same timing and sequence number space to allow receivers to recreate the packet sequence A mixer receives RTP packets from multiple sources, combines packets, makes timing adjustments, and forwards new RTP packets with a new timing sequence All packets in the new sequence will have mixer SSRC as their synchronization source The mixer inserts in each RTP packet header a CSRC list of the sources that contributed to this combined stream 8

RTP RTP header: Timestamp Reflects sampling instance of the first byte in payload Clock frequency depends on data type; specified in profile Random initial value Example: CBR audio, clock increment by 1 for each sample Consecutive RTP packets may have same timestamp (logically generate at same instant): video packets that belong to the same frame Timestamps of consecutive RTP packets may not increase monotonically if the data is not transmitted in the order in which it was sampled: MPEG interpolated video frames 8

RTP RTP header: Payload types Some examples (RFC 1890) 8 Payload type Encoding name Audio/Video (A/V) Clock rate PCMU (mu-law G.711) A 8000 8 PCMA (A-law G.711) 26 JPEG V 90000 32 MPV (MPEG-I and MPEG II) 33 MP2T (MPEG- II transport stream) AV 8

RTP RTP-based networking application RTP implementation is expected to be integrated into the application rather than as a separate module. The use of RTP for a particular application requires other documents Profile specification documents defines sets of payload type codes, and their mapping to payload formats Payload format specification documents define how to carry a specific encoding Example: MPEG2 video or ADPCM audio RFC 1890: payload types; RFC 2250: MPEG 8

RTP RTP-based networking application Application RTP Socket UDP IP RTP is part of the application and lies above the UDP socket Application RTP Socket UDP IP Data Link Physical 8

RTP RTP-based networking application Application RTP Transport UDP IP RTP can be viewed as a sub-layer of the transport layer Application RTP Transport UDP IP Data Link Physical 8

RTCP Introduction – RTP Control Protocol Scenario Receivers send reports Report contains number of packets lost at receiver, inter-arrival jitter, etc. This allows senders to adjust date rate Jitter is an early indicator of congestion Senders also send reports 8

RTCP Introduction - Goals The control protocol, RTCP, provides for periodic reporting of reception quality, participant identification and other source description information, notification on changes in session membership, and the information needed synchronize media streams. Identify and keep track of participant Canonical Name QoS feedback Minimal session control information RTCP 8

RTCP Packet Types Bye: End of session APP: Application specifics SDES: Source Description RR: Receive report SR: Sender report RTCP packet types 8

RTCP Compound RTCP Packet 8

RTCP Compound RTCP Packet 8

RTCP Sender report (SR) 8 SSRC: identifies source of data Sender information blocks: NTP timestamp: absolute time identifying when report was sent RTP timestamp: time when packet is sent according to the clock used to send RTP data packet timestamps; used for synchronization Sender’s packet count: Total number of packets sent since the start of session Sender’s octet count: Total number of bytes sent since the start of session Multiple receiver report blocks, one for each source from which this host receives packets 8

RTCP Receiver report (RR) 8 SSRC: identifies source whose data this block is about (who’s being reported on) Loss fraction: fraction of packets lost since last report was sent Cumulative number of packets lost: long-term loss since the beginning of reception Highest sequence number received: compare losses, disconnect Interarrival jitter: smoothed interpacket distortion LSR: The NTP timestamp of the last sender report received from the source DLSR: Delay between receiving the last SR from this source and sending this RR 8

RTCP Round-trip delay estimation 8

RTCP Intermedia synchronization 8

RTCP SDES Packet Type Source description (SDES): provide participant identification and supplementary details, such as location, emai address, etc. The standard items are: CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and PRIV. Constant for a user, unique among all users Providing binding across multiple medias sent by a user Example: user@postech.ac.kr 8

RTCP Analyzing sender and receiver reports 8 Sender may modify its transmissions based on the feedback Receivers can determine whether problems are local, regional or global Network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance od their networks for multicast distribution. 8

RTP/RTCP Other issues 8 Collision detection and resolution Two sources use the same SSRC Loop detection Security Header compression – RFC 2508 8

RTP/RTCP Applications using RTP Program Capability Protocols AOL instance messenger Video, file transfer, PC to phone, phone to PC SIP, RTP iSoftPhone Address Book Integration, Daylite CRM Integration, Call Recording, IM, Conferencing, Mulitple Providers, Simple Setup, Call transfer, 5 lines SIP, STUN, RTP Windows Live Messenger Video, voice, chat, text messaging, PC to Phone Yahoo! Messenger SIP (using TLS) and RTP (media) SightSpeed video, voicemail, phone in, phone out, multiparty calling, conference recording, text messaging, NAT traversal, video mail SIP,RTP,Proprietary P2P protocol 8

RTP/RTCP Questions 감사합니다 & Question? 8