rtp

Real-time Transport Protocol (RTP)

Emil Diaz

VoIP Security COMS 4995 – 03

Dept. of Computer Science

Henning Schulzrinne

Columbia University

Fall 2008

Overview

Protocol goals & background

Real-time Transport Protocol (RTP)

RTP Control Protocol (RTCP)

Use Scenarios

04/08/23 Real-time Transport Protocol 2

Real-Time Transport Protocol


End-to-end delivery services for applications transmitting real-time data, such as audio and video Payload type identification Sequence numbering Time stamping Delivery monitoring

Goals lightweight flexible scalable

Origin of Protocol


Developed by the Audio-Video Transport Working Group of the IETF: H. Schulzrinne (Columbia University) S. Casner (Packet Design) R. Frederick (Blue Coat Systems Inc.) V. Jacobson (Packet Design)

First published as RFC 1889 in the year 1996

Superseded by RFC 3550 in the year 2003

Protocol Structure


Application layer protocol

Typically used on top of IP and UDP

Applications that use RTP are: Less sensitive to packet loss Very sensitive to packet delays

UDP provides key services: Multiplexing Checksum

RTP Does NOT


Define media data formats or encodings Need media specific profiles

Handle connection setups or tear-downs Need other protocols like SIP or H.323

Handle resource reservation Need other protocols like RSVP

Guarantee timely delivery or Quality of Service However, it does provide necessary data to application to

order packets and adjust signal quality

RTP Sample Packet


http://www.codeproject.com/KB/IP/Video_Voice_Conferencing.aspx

RTCP Sample Packet


http://developer.apple.com/documentation/QuickTime/QTSS/Concepts/chapter_2_section_13.html

5 main types:

Sender Report (SR)

Receiver Report (RR)

Source Description (SDES)

Bye Message (BYE)

Application-defined (APP)

Use Scenarios


Simple Multicast Audio Conference


1. Call connection established

2. Audio sampled at 20ms durations

3. Each data chunk is packaged with an RTP header

4. RTP packet is wrapped around UDP packet

5. Sent through network

6. Receiver receives and parses RTP header

7. Based on payload type, application reconstructs audio stream in 20ms chunks

Audio and Video Conference


Audio and Video has separate RTP/RTCP sessions Receiver can choose media type to use Encodings can change independently Network resource allocations per media basis

Mixers and Translators


Accommodate participant network resources Mixer – Low Bandwidth Mixer – Combining media streams Translator – Forward RTP packets to private networks

Quality & Data Distribution Feedback


Packet loss, congestion, jitter, delivery times Directly useful for control of adaptive encodings Identify if problems are local or global Short-term and long-term statistical analysis

Self-adjusting network Each participant eventually knows about the other members Source description dynamically identifies who is sending Active senders get more bandwidth Session bandwidth kept constant by adjusting transmission

rate based on the number of participants

Source Description Information


CNAME – Conical name ([email protected]) NAME – Display Name (Joe Smith) EMAIL – Email (different than CNAME) PHONE – International phone number LOC – Location information (City, Building, Room?) TOOL – Application (VideoView 2.0)

References


RFC 3550 - http://tools.ietf.org/html/rfc1889 RFC 3551 - http://tools.ietf.org/html/rfc3551 RTP News - http://www.cs.columbia.edu/~hgs/rtp/ Wikepedia:

RTP - http://en.wikipedia.org/wiki/Real-time_Transport_Protocol RTCP - http://en.wikipedia.org/wiki/RTCP

Summary


Services: payload type identification sequence numbering time stamping delivery monitoring mixers & translators

Goals : lightweight flexible protocol-neutral scalable separate control/data secure

rtp

Documents