unicast and multicast UDP as well as TCP.  (This does not preclude      the use of these definitions when RTP is carried by other lower-      layer protocols.)   Transport mapping: The standard mapping of RTP and RTCP to      transport-level addresses is used.   Encapsulation: This profile leaves to applications the      specification of RTP encapsulation in protocols other than UDP.3.  Registering Additional Encodings   This profile lists a set of encodings, each of which is comprised of   a particular media data compression or representation plus a payload   format for encapsulation within RTP.  Some of those payload formats   are specified here, while others are specified in separate RFCs.  It   is expected that additional encodings beyond the set listed here will   be created in the future and specified in additional payload format   RFCs.   This profile also assigns to each encoding a short name which MAY be   used by higher-level control protocols, such as the Session   Description Protocol (SDP), RFC 2327 [6], to identify encodings   selected for a particular RTP session.   In some contexts it may be useful to refer to these encodings in the   form of a MIME content-type.  To facilitate this, RFC 3555 [7]   provides registrations for all of the encodings names listed here as   MIME subtype names under the "audio" and "video" MIME types through   the MIME registration procedure as specified in RFC 2048 [8].   Any additional encodings specified for use under this profile (or   others) may also be assigned names registered as MIME subtypes with   the Internet Assigned Numbers Authority (IANA).  This registry   provides a means to insure that the names assigned to the additional   encodings are kept unique.  RFC 3555 specifies the information that   is required for the registration of RTP encodings.   In addition to assigning names to encodings, this profile also   assigns static RTP payload type numbers to some of them.  However,   the payload type number space is relatively small and cannot   accommodate assignments for all existing and future encodings.   During the early stages of RTP development, it was necessary to use   statically assigned payload types because no other mechanism had been   specified to bind encodings to payload types.  It was anticipated   that non-RTP means beyond the scope of this memo (such as directory   services or invitation protocols) would be specified to establish aSchulzrinne & Casner        Standards Track                     [Page 6]RFC 3551                    RTP A/V Profile                    July 2003   dynamic mapping between a payload type and an encoding.  Now,   mechanisms for defining dynamic payload type bindings have been   specified in the Session Description Protocol (SDP) and in other   protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms   associate the registered name of the encoding/payload format, along   with any additional required parameters, such as the RTP timestamp   clock rate and number of channels, with a payload type number.  This   association is effective only for the duration of the RTP session in   which the dynamic payload type binding is made.  This association   applies only to the RTP session for which it is made, thus the   numbers can be re-used for different encodings in different sessions   so the number space limitation is avoided.   This profile reserves payload type numbers in the range 96-127   exclusively for dynamic assignment.  Applications SHOULD first use   values in this range for dynamic payload types.  Those applications   which need to define more than 32 dynamic payload types MAY bind   codes below 96, in which case it is RECOMMENDED that unassigned   payload type numbers be used first.  However, the statically assigned   payload types are default bindings and MAY be dynamically bound to   new encodings if needed.  Redefining payload types below 96 may cause   incorrect operation if an attempt is made to join a session without   obtaining session description information that defines the dynamic   payload types.   Dynamic payload types SHOULD NOT be used without a well-defined   mechanism to indicate the mapping.  Systems that expect to   interoperate with others operating under this profile SHOULD NOT make   their own assignments of proprietary encodings to particular, fixed   payload types.   This specification establishes the policy that no additional static   payload types will be assigned beyond the ones defined in this   document.  Establishing this policy avoids the problem of trying to   create a set of criteria for accepting static assignments and   encourages the implementation and deployment of the dynamic payload   type mechanisms.   The final set of static payload type assignments is provided in   Tables 4 and 5.Schulzrinne & Casner        Standards Track                     [Page 7]RFC 3551                    RTP A/V Profile                    July 20034.  Audio4.1  Encoding-Independent Rules   Since the ability to suppress silence is one of the primary   motivations for using packets to transmit voice, the RTP header   carries both a sequence number and a timestamp to allow a receiver to   distinguish between lost packets and periods of time when no data was   transmitted.  Discontiguous transmission (silence suppression) MAY be   used with any audio payload format.  Receivers MUST assume that   senders may suppress silence unless this is restricted by signaling   specified elsewhere.  (Even if the transmitter does not suppress   silence, the receiver should be prepared to handle periods when no   data is present since packets may be lost.)   Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence   insertion descriptor" or "comfort noise" frame to specify parameters   for artificial noise that may be generated during a period of silence   to approximate the background noise at the source.  For other payload   formats, a generic Comfort Noise (CN) payload format is specified in   RFC 3389 [9].  When the CN payload format is used with another   payload format, different values in the RTP payload type field   distinguish comfort-noise packets from those of the selected payload   format.   For applications which send either no packets or occasional comfort-   noise packets during silence, the first packet of a talkspurt, that   is, the first packet after a silence period during which packets have   not been transmitted contiguously, SHOULD be distinguished by setting   the marker bit in the RTP data header to one.  The marker bit in all   other packets is zero.  The beginning of a talkspurt MAY be used to   adjust the playout delay to reflect changing network delays.   Applications without silence suppression MUST set the marker bit to   zero.   The RTP clock rate used for generating the RTP timestamp is   independent of the number of channels and the encoding; it usually   equals the number of sampling periods per second.  For N-channel   encodings, each sampling period (say, 1/8,000 of a second) generates   N samples.  (This terminology is standard, but somewhat confusing, as   the total number of samples generated per second is then the sampling   rate times the channel count.)   If multiple audio channels are used, channels are numbered left-to-   right, starting at one.  In RTP audio packets, information from   lower-numbered channels precedes that from higher-numbered channels.Schulzrinne & Casner        Standards Track                     [Page 8]RFC 3551                    RTP A/V Profile                    July 2003   For more than two channels, the convention followed by the AIFF-C   audio interchange format SHOULD be followed [3], using the following   notation, unless some other convention is specified for a particular   encoding or payload format:      l  left      r  right      c  center      S  surround      F  front      R  rear      channels  description  channel                                1     2   3   4   5   6      _________________________________________________      2         stereo          l     r      3                         l     r   c      4                         l     c   r   S      5                        Fl     Fr  Fc  Sl  Sr      6                         l     lc  c   r   rc  S         Note: RFC 1890 defined two conventions for the ordering of four         audio channels.  Since the ordering is indicated implicitly by         the number of channels, this was ambiguous.  In this revision,         the order described as "quadrophonic" has been eliminated to         remove the ambiguity.  This choice was based on the observation         that quadrophonic consumer audio format did not become popular         whereas surround-sound subsequently has.   Samples for all channels belonging to a single sampling instant MUST   be within the same packet.  The interleaving of samples from   different channels depends on the encoding.  General guidelines are   given in Section 4.3 and 4.4.   The sampling frequency SHOULD be drawn from the set:  8,000, 11,025,   16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz.  (Older Apple   Macintosh computers had a native sample rate of 22,254.54 Hz, which   can be converted to 22,050 with acceptable quality by dropping 4   samples in a 20 ms frame.)  However, most audio encodings are defined   for a more restricted set of sampling frequencies.  Receivers SHOULD   be prepared to accept multi-channel audio, but MAY choose to only   play a single channel.4.2  Operating Recommendations   The following recommendations are default operating parameters.   Applications SHOULD be prepared to handle other values.  The ranges   given are meant to give guidance to application writers, allowing aSchulzrinne & Casner        Standards Track                     [Page 9]RFC 3551                    RTP A/V Profile                    July 2003   set of applications conforming to these guidelines to interoperate   without additional negotiation.  These guidelines are not intended to   restrict operating parameters for applications that can negotiate a   set of interoperable parameters, e.g., through a conference control   protocol.   For packetized audio, the default packetization interval SHOULD have   a duration of 20 ms or one frame, whichever is longer, unless   otherwise noted in Table 1 (column "ms/packet").  The packetization   interval determines the minimum end-to-end delay; longer packets   introduce less header overhead but higher delay and make packet loss   more noticeable.  For non-interactive applications such as lectures   or for links with severe bandwidth constraints, a higher   packetization delay MAY be used.  A receiver SHOULD accept packets   representing between 0 and 200 ms of audio data.  (For framed audio   encodings, a receiver SHOULD accept packets with a number of frames   equal to 200 ms divided by the frame duration, rounded up.)  This   restriction allows reasonable buffer sizing for the receiver.4.3  Guidelines for Sample-Based Audio Encodings   In sample-based encodings, each audio sample is represented by a   fixed number of bits.  Within the compressed audio data, codes for   individual samples may span octet boundaries.  An RTP audio packet   may contain any number of audio samples, subject to the constraint   that the number of bits per sample times the number of samples per   packet yields an integral octet count.  Fractional encodings produce   less than one octet per sample.   The duration of an audio packet is determined by the number of   samples in the packet.   For sample-based encodings producing one or more octets per sample,   samples from different channels sampled at the same sampling instant   SHOULD be packed in consecutive octets.  For example, for a two-   channel encoding, the octet sequence is (left channel, first sample),   (right channel, first sample), (left channel, second sample), (right   channel, second sample), ....  For multi-octet encodings, octets   SHOULD be transmitted in network byte order (i.e., most significant   octet first).   The packing of sample-based encodings producing less than one octet   per sample is encoding-specific.   The RTP timestamp reflects the instant at which the first sample in   the packet was sampled, that is, the oldest information in the   packet.Schulzrinne & Casner        Standards Track                    [Page 10]RFC 3551                    RTP A/V Profile                    July 20034.4  Guidelines for Frame-Based Audio Encodings   Frame-based encodings encode a fixed-length block of audio into   another block of compressed data, typically also of fixed length.   For frame-based encodings, the sender MAY choose to combine several   such frames into a single RTP packet.  The receiver can tell the   number of frames contained in an RTP packet, if all the frames have   the same length, by dividing the RTP payload length by the audio