Subject: Protocol Action: 'RTP payload Format for H.264 Video' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 20 Dec 2004 16:07:28 -0500

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:
                          [email-masked]
                          IETF Audio/Video transport working group

NEW:
     Author:
                          [email-masked]
     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: [email-masked]
     Munich University of Technology
     D-80290 Munich
     Germany

NEW:
     Thomas Stockhammer                Phone: +49-89-28923474
     Institute for Communications Eng. Email: [email-masked]
                                              ^^^^^^^^^^^^^^^^^^^^
     Munich University of Technology
     D-80290 Munich
     Germany

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce