datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport
RFC 4571

Network Working Group                                         J. Lazzaro
Request for Comments: 4571                                   UC Berkeley
Category: Standards Track                                      July 2006

               Framing Real-time Transport Protocol (RTP)
                and RTP Control Protocol (RTCP) Packets
                  over Connection-Oriented Transport

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a method for framing Real-time Transport Protocol
   (RTP) and RTP Control Protocol (RTCP) packets onto connection-
   oriented transport (such as TCP).  The memo also defines how session
   descriptions may specify RTP streams that use the framing method.

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. The Framing Method ..............................................2
   3. Packet Stream Properties ........................................3
   4. Session Descriptions for RTP/AVP over TCP .......................3
   5. Example .........................................................5
   6. Congestion Control ..............................................6
   7. Acknowledgements ................................................6
   8. Security Considerations .........................................6
   9. IANA Considerations .............................................7
   10. Normative References ...........................................7

Lazzaro                     Standards Track                     [Page 1]
RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

1. Introduction

   The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport
   Protocol (RTP, [RFC3551]) does not define a method for framing RTP
   and RTP Control Protocol (RTCP) packets onto connection-oriented
   transport protocols (such as TCP).  However, earlier versions of
   RTP/AVP did define a framing method, and this method is in use in
   several implementations.

   In this memo, we document the framing method that was defined by
   earlier versions of RTP/AVP.  In addition, we introduce a mechanism
   for a session description [SDP] to signal the use of the framing
   method.  Note that session description signalling for the framing
   method is new and was not defined in earlier versions of RTP/AVP.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  The Framing Method

   Figure 1 defines the framing method.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    ---------------------------------------------------------------
   |             LENGTH            |  RTP or RTCP packet ...       |
    ---------------------------------------------------------------

        Figure 1: The bit field definition of the framing method

   A 16-bit unsigned integer LENGTH field, coded in network byte order
   (big-endian), begins the frame.  If LENGTH is non-zero, an RTP or
   RTCP packet follows the LENGTH field.  The value coded in the LENGTH
   field MUST equal the number of octets in the RTP or RTCP packet.
   Zero is a valid value for LENGTH, and it codes the null packet.

   This framing method does not use frame markers (i.e., an octet of
   constant value that would precede the LENGTH field).  Frame markers
   are useful for detecting errors in the LENGTH field.  In lieu of a
   frame marker, receivers SHOULD monitor the RTP and RTCP header fields
   whose values are predictable (for example, the RTP version number).
   See Appendix A.1 of [RFC3550] for additional guidance.

Lazzaro                     Standards Track                     [Page 2]
RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

3.  Packet Stream Properties

   In most respects, the framing method does not specify properties
   above the level of a single packet.  In particular, Section 2 does

[include full document text]