ALF and RTP

1
ALF and RTP

• Ketan Mayer-Patel

2
RTP Overview

• Multiparty multimedia conferencing applications.
• Applicable to most continuous media types.
• Thin protocol
• As is, doesnt specify everything you need.
• Serves as a skeleton that can be filled out.
• Provides a handle on a few basic dimensions of a
  CM stream.
• Allows functionality without full knowledge.

3
Application Level Framing

• THE primary design principle behind RTP.
• Clark and Tennenhouse, 1990
• Data should be organized into units that make the
  most sense for the application.
• What makes sense for a video application?
• What makes sense for a stock ticker?
• What makes sense for an audio application?

4
ALF contd

• Application Data Unit (ADU)
• Interface to the network and the service model of
  protocols should be in terms of ADUs.
• Ex TCP
• What does it provide now?
• What should it provide instead?

5
FLA (ALF run backwards)

• Why dont network mechanisms work in terms of
  ADUs?
• What can we do instead?
• Let the applications construct ADUs that fit the
  underlying network mechanism.
• RTP provides a framework for doing this for
  continuous media streams.
• Most common case fitting the MTU

6
RTP Session Architecture

• Multiple participants.
• Possibly using multicast.
• Multiple streams per participant.
• Dynamic membership.
• Participants come and go.
• No assumption of central control.
• Participants may not know about each other.

7
RTP Packet Format
Timestamp
Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifier
Contributing Source (CSRC) Identifier
Data
8
RTP and the Network Stack

• Network protocols are layered.
• What does RTP require from the layers underneath
  it?
• Best effort delivery.
• Length of packet.
• Multiplexing among data types
• What provides this?
• UDP

9
SSRC

• Identifies the stream.
• Not just the participant.
• All packets with the same SSRC go together.
• Picked at random.
• Why do we need this?
• No assumption of stream association from
  underlying network mechanism.
• Possible problems?
• Collision

10
Timestamp vs. Sequence No.

• Timestamp relates packet to real time.
• Timestamp values sampled from a media specific
  clock.
• Sequence number relates packet to other packets.
• Allows many packets to have the same timestamp
  but different sequence numbers.

11
MPEG example

• How does the timestamp/seq. no mechanism support
  MPEG?
• Out of order transmission.
• Sequence numbers increase monotonically.
• Timestamps reflect reference relationships.
• Large frames.
• Natural ADU frame. But that wont work.
• One video frame likely to be split into parts and
  packed into multiple RTP packets.
• Timestamps associate packets together as part of
  the same frame, while seq. no distinguish packets
  from each other.

12
Audio silence example

• Consider audio data type.
• What do you want to do during silence?
• Not send anything.
• Why might this cause problems?
• Other side needs to distinguish between loss and
  silence.
• How does the timestamp/seq. no mechanism help?
• After receiving no packets for a while, next
  packet received will reflect a big jump in
  timestamp, but have the correct next seq. no.
  Thus, receiver knows what happened.

13
RTP Profiles

• Associated with a media type.
• Provides association between PT field and
  specific media format.
• Defines sampling rate of timestamp.
• May also define or recommend a definition for the
  marker bit.

14
Video Profile

• Marker bit recommended to mean last packet
  associated with a timestamp.
• Timestamp clock 90000 Hz
• Defines PT mapping for a number of different
  video encoding types.

15
Audio Profile

• Marker bit set on the first packet after a
  silence period where no packets sent.
• Timestamp equals sampling rate.
• Recommends 20ms minimum frame time.
• Recommends that samples from multiple channels be
  sent together.
• Defines PT for a number of different audio
  encoding types.

16
RTP Payloads

• Value of PT field given a particular profile
  identifies a payload type.
• Each payload type associated with format specific
  definition for the rest of the packet.
• Typically
• Format specific header.
• Data

17
Payload Design Goals

• Overall goal is to apply ALF principle as much as
  possible
• Each packet should be as independently
  processable as possible.
• Loss
• Out of order
• Duplications
• Payload definition should allow the application
  to fit RTP packets to the MTU.

18
RTP and Continuous Media

• Periodic
• Timestamp/Seq. no mechanism.
• Robust
• Media specific payload definitions that attempt
  to define packet-sized ADUs.
• Often large
• Marker bit, timestamp/seq. no
• Correlated
• No real support.

19
ALF vs. Abstraction

• Main message of the ALF paper
• Network should work in terms most congruent with
  what the application is trying to do.
• Main obstacle to ALF
• Design of network mechanisms wants to hide
  details and provide general-purpose APIs.
• Success of sockets
• Abstraction and encapsulation
• Tension between ALF and abstraction
• What to expose?
• How do we expose it?