1 / 19

ALF and RTP

ALF and RTP. Ketan Mayer-Patel. 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.

noreen
Download Presentation

ALF and RTP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ALF and RTP Ketan Mayer-Patel CS294-9 :: Fall 2003

  2. 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

  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? CS294-9 :: Fall 2003

  4. 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

  5. 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

  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. CS294-9 :: Fall 2003

  7. V=2 P X CC M PT Sequence Number RTP Packet Format Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier Contributing Source (CSRC) Identifier Data CS294-9 :: Fall 2003

  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 CS294-9 :: Fall 2003

  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 CS294-9 :: Fall 2003

  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. CS294-9 :: Fall 2003

  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 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

  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. CS294-9 :: Fall 2003

  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. CS294-9 :: Fall 2003

  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. CS294-9 :: Fall 2003

  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. CS294-9 :: Fall 2003

  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 CS294-9 :: Fall 2003

  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. CS294-9 :: Fall 2003

  18. 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

  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 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

More Related