draft-ietf-avtext-framemarking-08.txt   draft-ietf-avtext-framemarking-09.txt 
Network Working Group M. Zanaty Network Working Group M. Zanaty
Internet-Draft E. Berger Internet-Draft E. Berger
Intended status: Standards Track S. Nandakumar Intended status: Standards Track S. Nandakumar
Expires: April 26, 2019 Cisco Systems Expires: September 29, 2019 Cisco Systems
October 23, 2018 March 28, 2019
Frame Marking RTP Header Extension Frame Marking RTP Header Extension
draft-ietf-avtext-framemarking-08 draft-ietf-avtext-framemarking-09
Abstract Abstract
This document describes a Frame Marking RTP header extension used to This document describes a Frame Marking RTP header extension used to
convey information about video frames that is critical for error convey information about video frames that is critical for error
recovery and packet forwarding in RTP middleboxes or network nodes. recovery and packet forwarding in RTP middleboxes or network nodes.
It is most useful when media is encrypted, and essential when the It is most useful when media is encrypted, and essential when the
middlebox or node has no access to the media decryption keys. It is middlebox or node has no access to the media decryption keys. It is
also useful for codec-agnostic processing of encrypted or unencrypted also useful for codec-agnostic processing of encrypted or unencrypted
media, while it also supports extensions for codec-specific media, while it also supports extensions for codec-specific
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019. This Internet-Draft will expire on September 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words for Normative Requirements . . . . . . . . . . . . 4 2. Key Words for Normative Requirements . . . . . . . . . . . . 4
3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4 3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4
3.1. Short Extension for Non-Scalable Streams . . . . . . . . 4 3.1. Short Extension for Non-Scalable Streams . . . . . . . . 4
3.2. Long Extension for Scalable Streams . . . . . . . . . . . 5 3.2. Long Extension for Scalable Streams . . . . . . . . . . . 5
3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 7 3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 7
3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 7 3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 7
3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 7 3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 7
3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 7 3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 8
3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 8 3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 8
3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 8 3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 8
3.3. Signaling Information . . . . . . . . . . . . . . . . . . 8 3.3. Signaling Information . . . . . . . . . . . . . . . . . . 8
3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 8 3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 9
3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9 3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9
3.4.2. Scalability Structures . . . . . . . . . . . . . . . 9 3.4.2. Scalability Structures . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Many widely deployed RTP [RFC3550] topologies [RFC7667] used in Many widely deployed RTP [RFC3550] topologies [RFC7667] used in
modern voice and video conferencing systems include a centralized modern voice and video conferencing systems include a centralized
component that acts as an RTP switch. It receives voice and video component that acts as an RTP switch. It receives voice and video
streams from each participant, which may be encrypted using SRTP streams from each participant, which may be encrypted using SRTP
[RFC3711], or extensions that provide participants with private media [RFC3711], or extensions that provide participants with private media
[I-D.ietf-perc-private-media-framework] via end-to-end encryption [I-D.ietf-perc-private-media-framework] via end-to-end encryption
where the switch has no access to media decryption keys. The goal is where the switch has no access to media decryption keys. The goal is
skipping to change at page 5, line 17 skipping to change at page 5, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=0 |S|E|I|D|0 0 0 0| | ID=? | L=0 |S|E|I|D|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following information are extracted from the media payload and The following information are extracted from the media payload and
sent in the Frame Marking RTP header extension. sent in the Frame Marking RTP header extension.
o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a
frame; otherwise MUST be 0. frame; otherwise MUST be 0.
o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame; o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame;
otherwise MUST be 0. Note that this SHOULD match the RTP header otherwise MUST be 0. SHOULD match the RTP header marker bit in
marker bit when the latter is reliable. payload formats with such semantics for marking end of frame.
o I: Independent Frame (1 bit) - MUST be 1 for frames that can be o I: Independent Frame (1 bit) - MUST be 1 for frames that can be
decoded independent of temporally prior frames, e.g. intra-frame, decoded independent of temporally prior frames, e.g. intra-frame,
VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP
[RFC7798]; otherwise MUST be 0. [RFC7798]; otherwise MUST be 0.
o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender
knows can be discarded, and still provide a decodable media knows can be discarded, and still provide a decodable media
stream; otherwise MUST be 0. stream; otherwise MUST be 0.
o The remaining (4 bits) - are reserved for future use for non- o The remaining (4 bits) - are reserved for future use for non-
scalable streams; they MUST be set to 0 upon transmission and scalable streams; they MUST be set to 0 upon transmission and
ignored upon reception. ignored upon reception.
3.2. Long Extension for Scalable Streams 3.2. Long Extension for Scalable Streams
The following RTP header extension is RECOMMENDED for scalable The following RTP header extension is RECOMMENDED for scalable
streams. It MAY also be used for non-scalable streams, in which case streams. It MAY also be used for non-scalable streams, in which case
TID, LID and TL0PICIDX MUST be 0. The ID is assigned per [RFC8285], TID, LID and TL0PICIDX MUST be 0 or omitted. The ID is assigned per
and the length is encoded as L=2 which indicates 3 octets of data. [RFC8285], and the length is encoded as L=2 which indicates 3 octets
of data when nothing is omitted, or L=1 for 2 octets when TL0PICIDX
is omitted, or L=0 for 1 octet when both LID and TL0PICIDX are
omitted.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID | LID | TL0PICIDX | | ID=? | L=2 |S|E|I|D|B| TID | LID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=1 |S|E|I|D|B| TID | LID | (TL0PICIDX omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=0 |S|E|I|D|B| TID | (LID and TL0PICIDX omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following information are extracted from the media payload and The following information are extracted from the media payload and
sent in the Frame Marking RTP header extension. sent in the Frame Marking RTP header extension.
o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a
frame within a layer; otherwise MUST be 0. frame within a layer; otherwise MUST be 0.
o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame
within a layer; otherwise MUST be 0. Note that the RTP header within a layer; otherwise MUST be 0. Note that the RTP header
marker bit MAY be used to infer the last packet of the highest marker bit MAY be used to infer the last packet of the highest
enhancement layer. enhancement layer, in payload formats with such semantics.
o I: Independent Frame (1 bit) - MUST be 1 for frames that can be o I: Independent Frame (1 bit) - MUST be 1 for frames that can be
decoded independent of temporally prior frames, e.g. intra-frame, decoded independent of temporally prior frames, e.g. intra-frame,
VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP
[RFC7798]; otherwise MUST be 0. Note that this bit only signals [RFC7798]; otherwise MUST be 0. Note that this bit only signals
temporal independence, so it can be 1 in spatial or quality temporal independence, so it can be 1 in spatial or quality
enhancement layers that depend on temporally co-located layers but enhancement layers that depend on temporally co-located layers but
not temporally prior frames. not temporally prior frames.
o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender
knows can be discarded, and still provide a decodable media knows can be discarded, and still provide a decodable media
stream; otherwise MUST be 0. stream; otherwise MUST be 0.
skipping to change at page 11, line 13 skipping to change at page 11, line 36
July 2017. July 2017.
[I-D.ietf-payload-vp9] [I-D.ietf-payload-vp9]
Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
Hong, "RTP Payload Format for VP9 Video", draft-ietf- Hong, "RTP Payload Format for VP9 Video", draft-ietf-
payload-vp9-06 (work in progress), July 2018. payload-vp9-06 (work in progress), July 2018.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-07 Conferencing", draft-ietf-perc-private-media-framework-09
(work in progress), September 2018. (work in progress), February 2019.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
 End of changes. 14 change blocks. 
20 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/