Internet Telephony Lecture Notes

12 June 2008 • Real-Time Transport Protocol

Outline

Introduction

• Audio and video.

• Streaming data.

• Streaming-data transport.

Streaming Service

• Streaming data is continuous and potentially infinite.

  • No limits on size nor duration.

• Live audio or vide.

Real-Time Delivery

• Useful delivery of real-time treams must be reliable, ordered, and timely.

  • Reliable: data sent arrives.

  • Ordered: Order received is order sent.

  • Timely: The receiver's rate (data/time) matches the sender's.

Corrupting Real-Time Delivery

• IP semantics support none of reliability, order, or timeliness.

  • Best effort can drop packets (no relibility).

  • Routers can use different routes (no order).

  • Buffering between sender and receiver (no timeliness).

• TCP isn't going to help.

Ordered Delivery

• Each data block has a sequence number.

  • The data block is the protocol's choice.

    • Byte (TCP), arbitrary, stream dependent (MPEG).

  • As is the sequence number.

Timely Delivery

• The receiver's clock approximates the sender's.

• Jitter is disagreement between successive deltas.

Sequence Numbers

• Sequence numbers are not a good clock approximation.

  • Concurrent data sends.

    • A stereo audio feed over in the same stream.

    • Synchronizing separate streams (audio + video over separate streams).

  • Ticks are not real-time.

    • Silence suppression.

Reliability

• Retransmission is not a good technique for real-time streams.

  • Unbounded queue length.

  • Coundfounds timeliness.

• Alternatives for real-time stream reliability:

  • Redundancy (forward error correction).

  • Fake it (substitute for missing data).

Real-time Transport Protocol

• UDP and TCP can provide transport for real-time streams.

  • TCP does too much, UDP does too little.

• It's easier to add than remove.

  • Start with UDP and add mechanisms to provide missing support.

• The Real-Time Transport Protocol (RTP), rfc 3550.

RTP Implementation

• RTP is layered over UDP.

  

• Each RTP packet is a payload in a UDP packet.

  

RTP Sequence Number

• Each RTP packet has a 16-bit sequence number.

  • Initial random choice by the sender.

  • Increased by one for each successive packet in the data stream.

• Enables ordering.

RTP Timestamp

• Sequence numbers aren't trustworthy as clocks.

• Each RTP packet has a 32-bit timestamp.

  • The timestamp is continually updated by the sender.

  • Rate fixed by the sender (or the application).

  • Initial value is randomly selected by the sender.

RTP Identifiers

• An RTP packet contains several 32-bit identifiers.

  • The synchronization source id is the sender of the packet.

• RTP streams may be manipulated (split or merged, for examle) during transport.

  • The manipulator becomes the new source.

  • The previous source becomes one of the contributing source ids.

  • A four-bit CC field to indicate the number of contributors.

Other RTP Fields

• Payload type: seven bits; determined by mutual agreement.

• Marker bit: available for application-level signaling.

• Padding bit: indictes padding to suitable block size.

  • The last pad byte contains the padding size.

• Version number: two bits; currently 2.

RTP Payload

• The rest of the RTP packet is payload, dependent on the application using RTP.

• Application framing is indepdnent of (but not separate from) RTP framing.

  • An RTP packet may contain more than one, exactly one, or a part of an application frame (if there is one).

RTP and Ordering

• Sequence numbers provide ordering in the usual fashion.

  • Receiver keeps track of the next expected (or last received) sequence number.

  • Re-order buffer is required to hold out of order packets.

  • Sequence numbers can wrap around, which has to be handled.

RTP and Timeliness

• Timestamps provide a measure of timeliness for the receiver.

• The re-order buffer can be used to buffer for timely playback too.

• There's an interaction between sequence numbers and timestamps.

  • Missing timestamps may expire missing sequence numbers.

RTP and Reliability

• RTP doesn't do much for reliability.

  • The presentation or application layer have more responsibility.

RTP and Buffering

• RTP itself doesn't specify or need buffering.

• Re-order buffering.

• Playback buffering.

  • Unsynchronized timestamp clocks cause playback problems.

    • Playing back payloads on arrival isn't too useful.

    • Building up a reserve of continuous playback works better.

Reliability Again

• Sender-receiver feedback is important to providing reliability.

  • Accurate (or any) information allow each side can react better to the other side.

    • The sender can slow down or speed up in response to receiver conditions.

• Useful sender-receiver information includes

  • To the sender: packet loss, playback rate, arrivals and departures.

  • To the receiver: possible encodings, session meta information.

RTP Information Transport

• RTP (and UDP) is a taciturn protocol.

  • RTP packets disappear without a trace.

• Usurping the RTP payload isn't a good idea.

  • It complicates the protcol and data-stream handling.

Real-Time Control Protocol

• The Real-Time Control Protocol (RTCP) conveys information about a data-stream being provided by RTP.

• RTCP provides two-way datagram service between senders and receivers.

• The RTCP packet types are

  • Sender report; transmission information (time and data count).

  • Receiver report; packet loss, jitter, timing and round-trip estimates.

  • Source report; information about the source (information provider).

  • Goodbye; receiver leaving.

  • Application report; application specific.

RTP Sessions

• A RTP stream originates from a single source.

  • A single source may provide several streams.

• A RTP stream terminates at a UDP endpoint (an IP address, port number) pair.

  • The IP address may be multicast.

References

• RFC 3550, RTP: A Transport Protocol for Real-Time Applications by Henning Schulzrinne, Stephen Casner, Ron Frederick, and Van Jacobson, Network Working Group, Internet Engineering Task Force, July 2003.