9. Changes from RFC 1890
- Changes from RFC 1890
This RFC revises RFC 1890. It is mostly backwards-compatible with RFC 1890 except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile. Since this profile may be used without using any of the payload formats listed here, the addition of new payload formats in this revision does not affect backwards compatibility. The changes are listed below, categorized into functional and non-functional changes.
Functional changes:
o Section 11, "IANA Considerations" was added to specify the registration of the name for this profile. That appendix also references a new Section 3 "Registering Additional Encodings" which establishes a policy that no additional registration of static payload types for this profile will be made beyond those added in this revision and included in Tables 4 and 5. Instead, additional encoding names may be registered as MIME subtypes for binding to dynamic payload types. Non-normative references were added to RFC 3555 [7] where MIME subtypes for all the listed payload formats are registered, some with optional parameters for use of the payload formats.
o Static payload types 4, 16, 17 and 34 were added to incorporate IANA registrations made since the publication of RFC 1890, along with the corresponding payload format descriptions for G723 and H263.
o Following working group discussion, static payload types 12 and 18 were added along with the corresponding payload format descriptions for QCELP and G729. Static payload type 13 was assigned to the Comfort Noise (CN) payload format defined in RFC 3389. Payload type 19 was marked reserved because it had been temporarily allocated to an earlier version of Comfort Noise present in some draft revisions of this document.
o The payload format for G721 was renamed to G726-32 following the ITU-T renumbering, and the payload format description for G726 was expanded to include the -16, -24 and -40 data rates. Because of confusion regarding draft revisions of this document, some implementations of these G726 payload formats packed samples into octets starting with the most significant bit rather than the least significant bit as specified here. To partially resolve this incompatibility, new payload formats named AAL2-G726-16, -24, -32 and -40 will be specified in a separate document (see note in Section 4.5.4), and use of static payload type 2 is deprecated as explained in Section 6.
o Payload formats G729D and G729E were added following the ITU-T addition of Annexes D and E to Recommendation G.729. Listings were added for payload formats GSM-EFR, RED, and H263-1998 published in other documents subsequent to RFC 1890. These additional payload formats are referenced only by dynamic payload type numbers.
o The descriptions of the payload formats for G722, G728, GSM, VDVI were expanded.
o The payload format for 1016 audio was removed and its static payload type assignment 1 was marked "reserved" because two interoperable implementations were not found.
o Requirements for congestion control were added in Section 2.
o This profile follows the suggestion in the revised RTP spec that RTCP bandwidth may be specified separately from the session bandwidth and separately for active senders and passive receivers.
o The mapping of a user pass-phrase string into an encryption key was deleted from Section 2 because two interoperable implementations were not found.
o The "quadrophonic" sample ordering convention for four-channel audio was removed to eliminate an ambiguity as noted in Section 4.1.
Non-functional changes:
o In Section 4.1, it is now explicitly stated that silence suppression is allowed for all audio payload formats. (This has always been the case and derives from a fundamental aspect of RTP's design and the motivations for packet audio, but was not explicit stated before.) The use of comfort noise is also explained.
o In Section 4.1, the requirement level for setting of the marker bit on the first packet after silence for audio was changed from "is" to "SHOULD be", and clarified that the marker bit is set only when packets are intentionally not sent.
o Similarly, text was added to specify that the marker bit SHOULD be set to one on the last packet of a video frame, and that video frames are distinguished by their timestamps.
o RFC references are added for payload formats published after RFC 1890.
o The security considerations and full copyright sections were added.
o According to Peter Hoddie of Apple, only pre-1994 Macintosh used the 22254.54 rate and none the 11127.27 rate, so the latter was dropped from the discussion of suggested sampling frequencies.
o Table 1 was corrected to move some values from the "ms/packet" column to the "default ms/packet" column where they belonged.
o Since the Interactive Multimedia Association ceased operations, an alternate resource was provided for a referenced IMA document.
o A note has been added for G722 to clarify a discrepancy between the actual sampling rate and the RTP timestamp clock rate.
o Small clarifications of the text have been made in several places, some in response to questions from readers. In particular:
- A definition for "media type" is given in Section 1.1 to allow
the explanation of multiplexing RTP sessions in Section 6 to be
more clear regarding the multiplexing of multiple media.
- The explanation of how to determine the number of audio frames
in a packet from the length was expanded.
- More description of the allocation of bandwidth to SDES items
is given.
- A note was added that the convention for the order of channels
specified in Section 4.1 may be overridden by a particular
encoding or payload format specification.
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC
2119.
o A second author for this document was added.