rtprealtime.html

奉献给多媒体java编程者们。JMF2.1.1最新版本的用户指南。JMF是java用于基于实时多媒体的开发工具

<a name="998243"> </a><font  size="2" face="Palatino, Times New Roman, Times, serif">Figure 7-2:   RTP data-packet header format.<br></font>


<p>
  <a name="998458"> </a><font face="Palatino, Times New Roman, Times, serif">The header of an RTP data packet contains:</font>
</p>

<ul>
  <li><a name="998375"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>The RTP version number (V)</strong>: 2 bits. The version defined by the current specification is 2. </font>
  <li><a name="998379"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Padding </strong>(P): 1 bit. If the padding bit is set, there are one or more bytes at the end of the packet that are not part of the payload. The very last byte in the packet indicates the number of bytes of padding. The padding is used by some encryption algorithms.</font>
  <li><a name="998393"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Extension</strong> (X): 1 bit. If the extension bit is set, the fixed header is followed by one header extension. This extension mechanism enables implementations to add information to the RTP Header.</font>
  <li><a name="998394"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>CSRC Count</strong> (CC): 4 bits. The number of CSRC identifiers that follow the fixed header. If the CSRC count is zero, the synchronization source is the source of the payload.</font>
  <li><a name="998395"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Marker (M)</strong>: 1 bit. A marker bit defined by the particular media profile. </font>
  <li><a name="998396"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Payload Type </strong>(PT<strong>)</strong>: 7 bits. An index into a media profile table that describes the payload format. The payload mappings for audio and video are specified in RFC 1890.</font>
  <li><a name="998397"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Sequence Number</strong>: 16 bits. A unique packet number that identifies this packet's position in the sequence of packets. The packet number is incremented by one for each packet sent.</font>
  <li><a name="998418"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>Timestamp</strong>: 32 bits. Reflects the sampling instant of the first byte in the payload. Several consecutive packets can have the same timestamp if they are logically generated at the same time--for example, if they are all part of the same video frame.</font>
  <li><a name="998419"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>SSRC</strong>: 32 bits. Identifies the synchronization source. If the CSRC count is zero, the payload source is the synchronization source. If the CSRC count is nonzero, the SSRC identifies the mixer.</font>
  <li><a name="998440"> </a><font face="Palatino, Times New Roman, Times, serif"><strong>CSRC</strong>: 32 bits each. Identifies the contributing sources for the payload. The number of contributing sources is indicated by the CSRC count field; there can be up to 16 contributing sources. If there are multiple contributing sources, the payload is the mixed data from those sources. </font>
</ul>

<h5>
  <a name="998442"> </a><i><font color="#003366" face="Palatino, Times New Roman, Times, serif">Control Packets</font></i>
</h5>


<p>
  <a name="998249"> </a><font face="Palatino, Times New Roman, Times, serif">In addition to the media data for a session, control data (RTCP) packets are sent periodically to all of the participants in the session. RTCP packets can contain information about the quality of service for the session participants, information about the source of the media being transmitted on the data port, and statistics pertaining to the data that has been transmitted so far. </font>
</p>


<p>
  <a name="998297"> </a><font face="Palatino, Times New Roman, Times, serif">There are several types of RTCP packets:</font>
</p>

<ul>
  <li><a name="998298"> </a><font face="Palatino, Times New Roman, Times, serif">Sender Report</font>
  <li><a name="998306"> </a><font face="Palatino, Times New Roman, Times, serif">Receiver Report</font>
  <li><a name="998307"> </a><font face="Palatino, Times New Roman, Times, serif">Source Description</font>
  <li><a name="998308"> </a><font face="Palatino, Times New Roman, Times, serif">Bye</font>
  <li><a name="998309"> </a><font face="Palatino, Times New Roman, Times, serif">Application-specific</font>
</ul>

<p>
  <a name="998321"> </a><font face="Palatino, Times New Roman, Times, serif">RTCP packets are "stackable" and are sent as a compound packet that contains at least two packets, a report packet and a source description packet.</font>
</p>


<p>
  <a name="998366"> </a><font face="Palatino, Times New Roman, Times, serif">All participants in a session send RTCP packets. A participant that has recently sent data packets issues a <em>sender report</em>. The sender report (SR) contains the total number of packets and bytes sent as well as information that can be used to synchronize media streams from different sessions. </font>
</p>


<p>
  <a name="998328"> </a><font face="Palatino, Times New Roman, Times, serif">Session participants periodically issue <em>receiver reports</em> for all of the sources from which they are receiving data packets. A receiver report (RR) contains information about the number of packets lost, the highest sequence number received, and a timestamp that can be used to estimate the round-trip delay between a sender and the receiver. </font>
</p>


<p>
  <a name="998295"> </a><font face="Palatino, Times New Roman, Times, serif">The first packet in a compound RTCP packet has to be a report packet, even if no data has been sent or received--in which case, an empty receiver report is sent. </font>
</p>


<p>
  <a name="998335"> </a><font face="Palatino, Times New Roman, Times, serif">All compound RTCP packets must include a source description (SDES) element that contains the canonical name (CNAME) that identifies the source. Additional information might be included in the source description, such as the source's name, email address, phone number, geographic location, application name, or a message describing the current state of the source. </font>
</p>


<p>
  <a name="998354"> </a><font face="Palatino, Times New Roman, Times, serif">When a source is no longer active, it sends an RTCP BYE packet. The BYE notice can include the reason that the source is leaving the session.</font>
</p>


<p>
  <a name="998359"> </a><font face="Palatino, Times New Roman, Times, serif">RTCP APP packets provide a mechanism for applications to define and send custom information via the RTP control port.</font>
</p>


<h4>
  <a name="998051"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">RTP Applications</font>
</h4>


<p>
  <a name="998472"> </a><font face="Palatino, Times New Roman, Times, serif">RTP applications are often divided into those that need to be able to receive data from the network (RTP Clients) and those that need to be able to transmit data across the network (RTP Servers). Some applications do both--for example, conferencing applications capture and transmit data at the same time that they're receiving data from the network.</font>
</p>


<h4>
  <a name="998473"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Receiving Media Streams From the Network</font>
</h4>


<p>
  <a name="998474"> </a><font face="Palatino, Times New Roman, Times, serif">Being able to receive RTP streams is necessary for several types of applications. For example:</font>
</p>

<ul>
  <li><a name="998475"> </a><font face="Palatino, Times New Roman, Times, serif">Conferencing applications need to be able to receive a media stream from an RTP session and render it on the console. </font>
  <li><a name="998476"> </a><font face="Palatino, Times New Roman, Times, serif">A telephone answering machine application needs to be able to receive a media stream from an RTP session and store it in a file.</font>
  <li><a name="998477"> </a><font face="Palatino, Times New Roman, Times, serif">An application that records a conversation or conference must be able to receive a media stream from an RTP session and both render it on the console and store it in a file. </font>
</ul>

<h4>
  <a name="998484"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Transmitting Media Streams Across the Network</font>
</h4>


<p>
  <a name="998485"> </a><font face="Palatino, Times New Roman, Times, serif">RTP server applications transmit captured or stored media streams across the network.</font>
</p>


<p>
  <a name="998490"> </a><font face="Palatino, Times New Roman, Times, serif">For example, in a conferencing application, a media stream might be captured from a video camera and sent out on one or more RTP sessions. The media streams might be encoded in multiple media formats and sent out on several RTP sessions for conferencing with heterogeneous receivers. Multiparty conferencing could be implemented without IP multicast by using multiple unicast RTP sessions. </font>
</p>


<h3>
  <a name="998666"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">References</font>
</h3>


<p>
  <a name="998697"> </a><font face="Palatino, Times New Roman, Times, serif">The RTP specification is a product of the Audio Video Transport (AVT) working group of the Internet Engineering Task Force (IETF). For additional information about the IETF, see <code>http://www.ietf.org</code>. The AVT working group charter and proceedings are available at <br><code>http://www.ietf.org/html.charters/avt-charter.html</code>. </font>
</p>


<p>
  <a name="998667"> </a><font face="Palatino, Times New Roman, Times, serif"><em>IETF RFC 1889, RTP: A Transport Protocol for Real Time Applications</em> <br>Current revision:<code> http://www.ietf.org.internet-drafts/draft-ietf-avt-rtp-new-04.txt</code></font>
</p>


<p>
  <a name="998668"> </a><font face="Palatino, Times New Roman, Times, serif"><em>IETF RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control<br></em>Current revision:<code> http://www.ietf.org.internet-drafts/draft-ietf-avt-profile-new-06.txt</code></font>
</p>


<p>
  <a name="998726"> </a><font face="Palatino, Times New Roman, Times, serif">Note:  These RFCs are undergoing revisions in preparation for advancement from Proposed Standard to Draft Standard and the URLs listed here are for the Internet Drafts of the revisions available at the time of publication.</font>
</p>


<p>
  <a name="998705"> </a><font face="Palatino, Times New Roman, Times, serif">In addition to these RFCs, separate payload specification documents define how particular payloads are to be carried in RTP. For a list of all of the RTP-related specifications, see the AVT working group charter at: <code>http://www.ietf.org/html.charters/avt-charter.html</code>.</font>
</p>


  <a href="#997764"><sup>1</sup></a>
<a name="997807"> </a><font  size="2" face="Palatino, Times New Roman, Times, serif">In the seven layer ISO/OSI data communications model, the transport layer is level four. For more information about the ISO/OSI model, see <font  face="Palatino, Times New Roman, Times, serif">Understanding OSI</font>. Larmouth, John. International Thompson Computer Press, 1996. ISBN 1850321760.<br></font>
</blockquote>
<br clear="all">
<hr>
<a href="JMFTOC.html">CONTENTS</a> | 
<a href="Part2.html">PREV </a> |
<a href="RTPArchitecture.html">NEXT</a> |
<a href="JMFIX.html">INDEX</a></td>
<br>
<hr>
<em>
<a href="copyright.html">Copyright</a> &copy;
1998-1999 Sun Microsystems, Inc. All Rights Reserved.
</em>
</body>
</html>