The IESG has approved the following document:
- 'RTP payload Format for H.264 Video '
<draft-ietf-avt-rtp-h264-11.txt> 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
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
