Multimedia Networking

7.4.1 RTP

Home
Introduction
7.1 Multimedia Networking Applications
7.1.1 Examples of Multimedia Applications
7.1.2 Hurdles for Multimedia in Today's Internet
7.1.3 How Should the Internet Evolve to Support Multimedia Better?
7.1.4 Audio and Video Compression
7.2 Streamimg Stored Audio and Video
7.2.1 Accessing Audio and Video Through a Web Server
7.2.2 Sending Multimedia from a Streaming Server to a Helper Application
7.2.3 Real-Time Streaming Protocol (RTSP)
7.3 Making the Best of the Best-Effort Service: An Internet Phone Example
7.3.1 The Limitations of a Best-Effort Service
7.3.2 Removing Jitter at the Receiver for Audio
7.3.3 Recovering from Packet Loss
7.4 Protocols for Real-Time Interactive Applications
7.4.1 RTP
7.4.2 RTP Control Protocol (RTCP)
7.4.3 SIP
7.4.4 H.323
7.5 Distributing Multimedia: Content Distribution Networks
7.6 Beyond Best Effort
7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP
7.6.2 Scenario 2: A 1 Mbps Audio Application and a High-Priority FTP Transfer
7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer
7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link
7.7 Scheduling and Policing Mechanisms
7.7.1 Scheduling Mechanisms
7.7.2 Policing: The Leaky Bucket
7.8 Intergrated Services and Differentiated Services
7.8.1 Intserv
7.8.2 Diffserv
7.9 RSVP
7.9.1 The Essence of RSVP
7.9.2 A Few Simple Examples
RTP

RTP can be used fro transporting common formats for sound and MPEG and H.263 for video.  It can also be used for transporting proprietary sound and video formats.  RTP enjoys widespread inplementation in hundreds of products and research prototypes.  It is also complementary to other important real-time interactive protocols.
 
RTP Basics
RTP typically runs on top of UDP.  The sending side encapsulates a media chunk within an RTP packet, then encapsulates the packet in a UDP segment, and then hands the segment to IP.  The receiving side extracts the RTP packet from the UDP segment, then extracts the media chunck from the RTP packet, and then passes the chunk to the media player for decoding and rendering.
 
If an application incorporate RTP--instead of a proprietary scheme to provide payload type, sequence numbers, of timestamps--then the application will more easily interoperate with other networked multimedia applications.
 
It should be emphasized that RTP does not provide any mechanism to ensure timely delivery of data or provide other quality-of-service (QoS) guarantwws; it does not even g;uarantee delivery of packets or prevent out-of-order delivery of packets.  RTP encapsulation is seen only at the end systems.  Routers do not distinguish between IP datagrams that carry RTP packets and IP datagrams that don't. 
 
RTP allows each source to be assigned its own independent RTP stream of packets.
 
RTP packets are not limited to unicast applications.  They can also be sent over one-to-many and many-to-many multicast trees.  For a many-to-many multicast session, all of the session's senders and sources typically use the same multicast group for sending their RTP streams.  RTP multicast streams belonging together belong to an RTP session.
 
RTP Packet Header Fields
The four main RTP packet header fields are the payload type, sequence number, timestamp, and the source identifier fields.
 
The payload-type field in the RTP packet is 7 bits long.  For an audio stream, the payload-type field is used to indicate the type of audio encoding that is being used.  If a sender decides to change the encoding in the middle of a session, the sender can inform the receiver of the change through this payload-type field.  The sender may want to change the encoding in order to increase the audio quality or to decrease the RTP stream bit rate.
 
Important fileds
  • Sequence numbers-The sequence number field is 16 bits long.  The sequence number increments by one for each RTP packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence.
  • Timestamp field-The timestamp field is 32 bits long.  It reflects the sampling instant of the first byte in the RTP data packet.

kurose_320719_c07f09.gif

  • Synchronization source identifier (SSRC).  The SRRC is 32 bits long.  It identifies the source of the RTP stream.  Each stream in an RTP session has a distinct SSRC.  The SSRC is not the IP address of the sender, but instead is a number that the source assigns randomly when the new stream is started.

Developing Software Applications with RTP

There are two approaches to developing an RTP-based networked application.  The first approach is for the application developer to incorporate RTP by hand to write the code that performs RTP encapsulation at the sender side and RTP unraveling at the receiver side.  The second approach is for the application developer to use existing RTP libraries and Java classes which performs the encapsulantion and unraveling for the application.

The UDP API requires the sending process to set, for each UDP segment it sends, the destination IP address and the destination port number before popping the packet into the UDP socket.  The UDP segment will then wander through the Innternet and will eventually arrive at the door of the receiving frocess for the application.  This door is fully addressed by the destination IP address and the destination port number.

An alternative approach is to use a Java RTP class to implement the RTP operations.  With this approach the application developer is given the impression that RTP is part of the transport layer, with an RTP/UDP API between the application layer and the transport layer.