ALF and RTP Ketan MayerPatel CS 294 9

ALF and RTP Ketan Mayer-Patel CS 294 -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. CS 294 -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? CS 294 -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? CS 294 -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 CS 294 -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. CS 294 -9 : : Fall 2003

RTP Packet Format V=2 P X CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier Data CS 294 -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 CS 294 -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 CS 294 -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. CS 294 -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. CS 294 -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. CS 294 -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. CS 294 -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. CS 294 -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 20 ms minimum frame time. • Recommends that samples from multiple channels be sent together. • Defines PT for a number of different audio encoding types. CS 294 -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 CS 294 -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. CS 294 -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. CS 294 -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? CS 294 -9 : : Fall 2003