ALF and RTP
Ketan Mayer-Patel
CS294-9 :: Fall 2003
RTP Overview
• Multiparty multimedia conferencing
applications.
– Applicable to most continuous media types.
• Thin protocol
– As is, doesn’t 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.
CS294-9 :: Fall 2003
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?
CS294-9 :: Fall 2003
ALF cont’d
• Application Data Unit (ADU)
• Interface to the network and the service
model of protocols should be in terms of
ADU’s.
• Ex: TCP
– What does it provide now?
– What should it provide instead?
CS294-9 :: Fall 2003
FLA (ALF run backwards)
• Why don’t network mechanisms work in
terms of ADU’s?
• What can we do instead?
– Let the applications construct ADU’s that fit the
underlying network mechanism.
– RTP provides a framework for doing this for
continuous media streams.
– Most common case: fitting the MTU
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
RTP Packet Format
V=2 P X
CC
M
PT
Sequence Number
Timestamp
Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifier
Contributing Source (CSRC) Identifier
Data
CS294-9 :: Fall 2003
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
CS294-9 :: Fall 2003
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
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
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 won’t 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.
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
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
CS294-9 :: Fall 2003
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.
CS294-9 :: Fall 2003
RTP and Continuous Media
• Periodic
– Timestamp/Seq. no mechanism.
• Robust
– Media specific payload definitions that attempt
to define packet-sized ADU’s.
• Often large
– Marker bit, timestamp/seq. no
• Correlated
– No real support.
CS294-9 :: Fall 2003
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 API’s.
• Success of sockets
• Abstraction and encapsulation
• Tension between ALF and abstraction
– What to expose?
– How do we expose it?
CS294-9 :: Fall 2003