Real-Time Transport Protocol (RTP) : Tung Dao Manh

Real-Time Transport Protocol (RTP)
Tung Dao Manh
Future Internet Class, 2007.04.15

Pohang University of Science and Technology (POSTECH)
Copyright 2007 SE Lab. Dept. of CSE POSTECH, R.O. Korea
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
POSTECH
Introduction
Requirements for delivery of media stream
Examples of real-time applications:
Videoconferencing VoIP, IP telephone system Game online
Motivation
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
POSTECH
Introduction
Requirements drive the choice of transport protocols
TCP/IP
Motivation
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
POSTECH
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.
POSTECH
Introduction
Real-time data transport at glance

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 channelcoding routine for loss correct. Next, they are put into a playout-buffer, a nd any variation in interpacket timing c aused by the network has been s moothed. They are then grouped to form complete frames that are decoded to play out.
POSTECH
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)
POSTECH
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, networkaware endpoints and a dumb network)
Achieving flexibility
Provides a unifying framework for real-time audio/video transport, satisfying most application directly.
POSTECH
RTP
RTP specifications RTP profiles RTP payload formats Optional elements
Standard elements of RTP Framework
POSTECH
Introduction
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
RTP Outline
Protocol architecture: usually works over UDP/IP

Media Application RTCP RTP UDP IP
POSTECH
Introduction
RTP Outline
POSTECH
Introduction
RTP Issues: The protocol itself does not
provide mechanisms to ensure timely delivery
Relies on lower-layer protocols
RTP Outline
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
POSTECH
RTP
Multicasting Payload type identification Time stamping
Enable timing recovery
RTP Features
Sequencing
Loss detection
Delivery monitoring
POSTECH
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 Padding size | | X 8 bits) (8 bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (V): Payload Type (PT) Padding (P) Sequence Number Extension (X) Timestamp CSRC Count (CC) Synchronization Source (SSRC) Contributing Source (CSRC) POSTECH Marker (M)
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
POSTECH
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
POSTECH
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
POSTECH
RTP
Some examples (RFC 1890)
Payload type 0 8 26 32 33 Encoding name PCMU (mu-law G.711) PCMA (A-law G. 711) JPEG MPV (MPEG-I a nd MPEG II)
RTP header: Payload types
Audio/Video (A/V) A A V V
Clock rate 8000 8000 90000 90000 90000
MP2T (MPEG- II AV transport stream)
POSTECH
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
POSTECH
RTP
RTP is part of the application and lies above the UDP socket
Application RTP
Socket UDP
IP
Data Link
Physical
POSTECH
RTP
RTP can be viewed as a sub-layer of the transport layer
Application RTP
UDP
IP
Transport
Data Link
Physical
POSTECH
RTCP
Scenario

Introduction RTP Control Protocol
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
POSTECH
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.
Canonical Name QoS feedback Identify and keep track of participant
Minimal session control information
RTCP
POSTECH
RTCP
Bye: End of session APP: Application specifics SDES: Source Description RR: Receive report SR: Sender report
Packet Types
RTCP packet types
POSTECH
RTCP
Compound RTCP Packet
POSTECH
RTCP
Compound RTCP Packet
POSTECH
RTCP
Sender report (SR)

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 Senders packet count: Total number of packets sent since the start of session Senders 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
POSTECH
RTCP
Receiver report (RR)

SSRC: identifies source whose data this block is about (whos 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
POSTECH
RTCP
Round-trip delay estimation
POSTECH
RTCP
Intermedia synchronization
POSTECH
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
POSTECH
RTCP
Analyzing sender and receiver reports
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.
POSTECH
RTP/RTCP
Collision detection and resolution
Two sources use the same SSRC
Other issues
Loop detection Security Header compression RFC 2508
POSTECH
RTP/RTCP
Program AOL instance messenger iSoftPhone Capability
Video, file transfer, PC to phone, phone to PC Address Book Integration, Daylite CRM Integration, Call Recording, IM, Conferencing, Mulitple Providers, Simple Setup, Call transfer, 5 lines Video, voice, chat, text messaging, PC to Phone Video, file transfer, PC to phone, phone to PC
Applications using RTP

Protocols SIP, RTP SIP, STUN, RTP
Windows Live Messenger Yahoo! Messenger
SIP, RTP SIP (using TLS) and RTP (media)
SightSpeed
video, voicemail, phone in, phone out, multiparty calling, conference recording, text messaging, NAT t raversal, video mail
SIP,RTP,Proprietary P2P protocol
POSTECH
RTP/RTCP
Questions
& Question?
POSTECH

Real-Time Transport Protocol (RTP) : Tung Dao Manh

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Real-Time Transport Protocol (RTP) : Tung Dao Manh

Uploaded by

Copyright:

Available Formats

Real-Time Transport Protocol (RTP)

Tung Dao Manh

Future Internet Class, 2007.04.15

Real-time data: interactive audio and video

Requirements for transport protocols:

Real-time data transport at glance

Provides end-to-end transport functions for real-time applications

Fundamental design philosophies of RTP

The end-to-end principle

Standard elements of RTP Framework

Protocol architecture: usually works over UDP/IP

RTP Timestamp (TS) and Sequence Number (SN)

RTP Packet Format

RTP header: SSRC and CSRC

RTP header: Timestamp

RTP header: Payload types

Clock rate 8000 8000 90000 90000 90000

MP2T (MPEG- II AV transport stream)

RTP-based networking application

RTP-based networking application

RTP-based networking application

RTP can be viewed as a sub-layer of the transport layer

Introduction RTP Control Protocol

Minimal session control information

RTCP packet types

Compound RTCP Packet

Compound RTCP Packet

Sender report (SR)

Receiver report (RR)

Round-trip delay estimation

SDES Packet Type

Analyzing sender and receiver reports

Loop detection Security Header compression RFC 2508

Applications using RTP

Windows Live Messenger Yahoo! Messenger

SIP, RTP SIP (using TLS) and RTP (media)

SIP,RTP,Proprietary P2P protocol

You might also like