From: The IESG To: IETF-Announce Message-Id: Date: Mon, 20 Dec 2004 16:07:28 -0500 Subject: [AVT] Protocol Action: 'RTP payload Format for H.264 Video' to Proposed Standard The IESG has approved the following document: - 'RTP payload Format for H.264 Video ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This specification describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability supporting from simple low-bit rate conversational usage to Internet video streaming with interleaved transmission, all the way to high bit-rate video-on-demand applications. Congestion control can be supported by selective transition between rates, because the codec is so rate-agile. Working Group Summary The working group supported advancing this specification. The working group was made aware of an IPR disclosure by Nokia and determined that the standardization should proceed. Protocol Quality Allison Mankin reviewed the document for the IESG. RFC Editor Notes Section 8.1, at the end: OLD: Author/Change controller: stewe@stewe.org IETF Audio/Video transport working group NEW: Author: stewe@stewe.org Change controller: IETF Audio/Video Transport working group delegated from the IESG. [Addresses Media Type Review] ------- Section 9, second paragraph: OLD: Therefore the usage of authentication of at least the RTP packet is RECOMMENDED, for example with SRTP [29]. NEW: Therefore the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED, for example with SRTP [29]. Section 9, Fourth paragraph: OLD: As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [19] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. NEW: Remove the complete paragraph [Addresses Sam Hartman's Discuss] ------- Section 9 After the last paragraph Add the following new paragraph NEW: End-to-End security with either authentication, integrity or confidentiality protection will prevent a MANE from performing media-aware operations other than discarding complete packets. And in the case of confidentiality protection it will even be prevented from performing discarding of packets in a media aware way. To allow any MANE to perform its operations, it will be required to be a trusted entity which is included in the security context establishment. [Addresses AD Review] Section 10 First Paragraph OLD: Congestion control for RTP SHALL be used in accordance with RFC 3550 [4], and any applicable RTP profile, e.g. RFC 3551 [18]. This means that congestion control is required for any transmission over unmanaged best-effort networks. NEW: Congestion control for RTP SHALL be used in accordance with RFC 3550 [4], and any applicable RTP profile, e.g. RFC 3551 [18]. An additional requirement if best-effort service is being used are: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. [Addresses AD Review] Section 10, Second Paragraph OLD: Only if non- downgradable parameters, such as the profile part of the profile/level ID change, it becomes necessary to terminate and re- start the media stream, possibly using a different RTP payload type. NEW: Only if non-downgradable parameters, such as the profile part of the profile/level ID is required to be changed, will it become necessary to terminate and re-start the media stream. This may be accomplished by using a different RTP payload type. [Fixes ungrammatical sentence] Section 9, first paragraph: OLD: Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. NEW: Because the data compression used with this payload format is applied end-to-end, any encryption needs to be performed after compression. [Addresses Russ Housley's Discuss] Section "Author's Address" for the RFC editor to send Auth48 to the right addresses. OLD: Thomas Stockhammer Phone: +49-89-28923474 Institute for Communications Eng. Email: stockhammer@ei.tum.de Munich University of Technology D-80290 Munich Germany NEW: Thomas Stockhammer Phone: +49-89-28923474 Institute for Communications Eng. Email: stockhammer@nomor.de ^^^^^^^^^^^^^^^^^^^^ Munich University of Technology D-80290 Munich Germany