Payload Working Group
Internet Engineering Task Force (IETF)                         J. Weaver
Internet-Draft
Request for Comments: 8450                                           BBC
Intended status:
Category: Standards Track                         August 29,                                   October 2018
Expires: March 2, 2019
ISSN: 2070-1721

         RTP Payload Format for VC-2 HQ High Quality (HQ) Profile Video
                    draft-ietf-payload-rtp-vc2hq-08

Abstract

   This memo describes an RTP Payload payload format for the High Quality (HQ)
   profile of Society of Motion Picture and Television Engineers
   Standard ST 2042-1 2042-1, known as VC-2.  This document describes the
   transport of HQ Profile VC-2 in RTP packets and has applications for
   low-complexity, high-bandwidth streaming of both lossless and lossy
   compressed video.

   The HQ profile of VC-2 is intended for low latency low-latency video compression
   (with latency potentially on the order of lines of video) at high
   data rates (with compression ratios on the order of 2:1 or 4:1).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 2, 2019.
   https://www.rfc-editor.org/info/rfc8450.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Conventions, Definitions Definitions, and Acronyms  . . . . . . . . . . . .   3
   3.  Media Format Description  . . . . . . . . . . . . . . . . . .   3
   4.  Payload format Format  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  RTP Header Usage  . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Payload Header  . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  The Choice of Parse Codes (Informative) . . . . . . . . .  13
     4.4.  Stream Constraints  . . . . . . . . . . . . . . . . . . .  13  14
     4.5.  Payload Data  . . . . . . . . . . . . . . . . . . . . . .  15
       4.5.1.  Reassembling the Data . . . . . . . . . . . . . . . .  15  16
   5.  FEC  Forward Error Correction (FEC) Considerations . . . . . . . . . . . . . . . . . . . . .  17  18
   6.  Congestion Control Considerations . . . . . . . . . . . . . .  18
   7.  Payload Format Parameters . . . . . . . . . . . . . . . . . .  18  19
     7.1.  Media Type Definition . . . . . . . . . . . . . . . . . .  18  19
     7.2.  Mapping to SDP  . . . . . . . . . . . . . . . . . the Session Description Protocol (SDP) . . . .  20  21
     7.3.  Offer/Answer Considerations . . . . . . . . . . . . . . .  20  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. RFC Editor Considerations . . . . . . . . . . . . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     11.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23  24

1.  Introduction

   This memo specifies an RTP payload format for the video coding
   standard Society of Motion Picture and Television Engineers ST
   2042-1:2017 [VC2] [VC2], also known as VC-2

   The VC-2 codec is a wavelet-based codec intended primarily for
   professional video use with high bit-rates and only low levels of
   compression.  It has been designed to be low-complexity, have a low level of complexity
   and potentially have a very low latency through both encoder and decoder:
   with some choices of parameters parameters, this latency may be as low as a few
   lines of video.

   The low level of complexity in the VC-2 codec allows for this low low-
   latency operation but also means that it lacks many of the more
   powerful compression techniques used in other codecs.  As such such, it is
   suitable for low compression ratios that produce coded data rates
   around half to a quarter of that of uncompressed video, at a similar
   visual quality.

   The primary use for VC-2 is likely to be in professional video
   production environments.

2.  Conventions, Definitions Definitions, and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Media Format Description

   The VC-2 specification defines a VC-2 stream Stream as being composed of one
   or more Sequences.  Each Sequence is independently decodable,
   containing all of the needed parameters and metadata for configuring
   the decoder.

   Each Sequence consists of a series of 13-octet Parse Info headers Headers and
   variable length
   variable-length Data Units.  The Sequence begins and ends with a
   Parse Info header Header, and each Data Unit is preceded by a Parse Info
   Header.  Data Units come in a variety of types, and the type of a
   Data Unit is signaled in the proceding preceding Parse Info Header.  The most
   important types are the Sequence Header, which contains configuration
   data needed by the decoder, and several types of Coded Picture, which
   contain the coded data for the pictures themselves.  Each picture
   represents a frame in a progressively scanned video Sequence or a
   field in an interlaced video Sequence.

   The first Data Unit in a Sequence as produced by an encoder is always
   a Sequence Header, but Header; however, Sequences can be joined in the middle, so this
   it should not be assumed. assumed that the first Data Unit received will
   always be a Sequence Header.

   The High Quality (HQ) profile for VC-2 restricts the types of Parse
   Info Headers which that may appear in the Sequence (and hence also the
   types of Data Unit) to only:

   o  Sequence Headers (which are always followed by a Data Unit),

   o  High Quality Pictures (which are always followed by a Data Unit),

   o  High Quality Fragments (which are always followed by a Data Unit),

   o  Auxiliary Data (which are always followed by a Data Unit),

   o  Padding Data (which are always followed by a Data Unit), and

   o  End of Sequence (which are never followed by a Data Unit).

   At the time of writing writing, there is currently no definition for the use of
   Auxiliary Data in VC-2, and Padding Data is required to be ignored by
   all receivers.

   Each High Quality Picture data unit Data Unit contains a set of parameters for
   the picture followed by a series of coded Coded Slices, each representing a
   rectangular region of the transformed picture.  Slices within a
   picture may vary in coded length, but all represent the same shape
   and size of rectangle in the picture.

   Each High Quality Fragment data unit Data Unit contains either a set of
   parameters for a picture or it contains a series of coded Coded Slices.  Fragments
   carry the same data as pictures, but broken up into smaller units to
   facilitate transmission via packet-based protocols such as RTP.

   This payload format only makes use of fragments, Fragments, not pictures.

4.  Payload format Format

   In this specification specification, each RTP packet is used to carry data
   corresponding to a single Parse Info Header and its following data
   unit Data
   Unit (if it has one).  A single packet MAY NOT contain data from more
   than one Parse Info header Header or data unit. Data Unit.  A single Parse Info Header
   and Data Unit pair MUST NOT be split accross across more than one packet,
   the packet.
   The sole exception to this rule is that an Auxiliary Data Unit MAY be
   split between multiple packets, using the B and E flags to indicate
   start and end.

   This specification only covers the transport of Sequence Headers
   (together with their accompanying data unit), Data Unit), High Quality Fragments
   (together with their accompanying data unit), Data Unit), Auxiliary Data
   (together with their accompanying data unit), Data Unit), and (optionally) End
   Sequence Headers and Padding Data (for which no data unit Data Unit it
   carried).

   High Quality Pictures can be transported by converting them into an
   equivalent set of High Quality Fragments.  The size of fragments Fragments
   should be chosen so as to fit within the MTU of the network in use.

   For this reason reason, this document defines six types of RTP packets in a
   VC-2 media stream:

   o  A  a VC-2 Sequence Header (Figure 1) (see Section 11 of the VC-2
      specification [VC2]),

   o  A  a Picture Fragment containing the VC-2 Transform Parameters for a
      Picture (Figure 2) (see Section 14 of the VC-2 specification
      [VC2]),

   o  A  a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a
      picture (see Section 14 of the VC-2 specification [VC2]),

   o  The  the end of a VC-2 Sequence (Figure 4)(see 4) (see Section 10.5.2 of the
      VC-2 specification [VC2]),

   o  The  the contents of an auxiliary data unit Auxiliary Data Unit (Figure 5)(see 5) (see
      Section 10.4.4 of the VC-2 specification [VC2]), and

   o  An  an indication of the presence of a padding data unit Data Unit (Figure 6)
      (see Section 10.4.5 of the VC-2 specification [VC2]).

   These six packet-types packet types can be distinguished by the fact that they use
   different codes in the "PC (Parse Code)" Parse Code ("PC") field, except for the two
   types of picture fragment which both Picture Fragment that use the same value in PC but have
   different values in the "No. of slices" Slices" field.

   The choices of options for PC codes is are explained in more detail in a following
   informative section (Section 4.3). Section 4.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |    Reserved   |   PC = 0x00   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   .                                                               .
   .               Variable Length               Variable-Length Coded Sequence Header           .
   .                                                               .
   +---------------------------------------------------------------+

             Figure 1: RTP Payload Format For for Sequence Header
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |  Reserved |I|F|   PC = 0xEC   |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                       Picture Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |       Slice Prefix Bytes      |        Slice Size Scaler      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |       Fragment Length         |         No. of Slices = 0     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   .                                                               .
   .         Variable Length         Variable-Length Coded Transform Parameters            .
   .                                                               .
   +---------------------------------------------------------------+

      Figure 2: RTP Payload Format For for Transform Parameters Fragment
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |  Reserved |I|F|   PC = 0xEC   |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                       Picture Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |       Slice Prefix Bytes      |        Slice Size Scaler      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |       Fragment Length         |          No. of Slices        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |        Slice Offset X         |         Slice Offset Y        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   .                                                               .
   .                          Coded Slices                         .
   .                                                               .
   +---------------------------------------------------------------+

        Figure 3: RTP Payload Format For for Fragment Containing Slices
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |    Reserved   |   PC = 0x10   |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

             Figure 4: RTP Payload Format For for End of Sequence

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |B|E|  Reserved |   PC = 0x20   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Data Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                      Uncoded Payload Data                     .
   .                                                               .
   +---------------------------------------------------------------+

              Figure 5: RTP Payload Format For for Auxiliary Data
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |P|X|   CC  |M|    PT       |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SSRC           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                 Optional Extension Header                     |
   |                             ....                              |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |   Extended Sequence Number    |B|E|  Reserved |   PC = 0x30   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Data Length                         |
   +---------------------------------------------------------------+

               Figure 6: RTP Payload Format For for Padding Data

   All fields in the headers longer than a single bit are interpreted as
   unsigned integers in network byte order.

4.1.  RTP Header Usage

   The fields of the RTP header have the following additional notes on
   their useage: usage:

   Marker Bit (M): 1 bit bit.  The marker bit MUST be set on any packet which that
         contains the final slice in a coded picture and MUST NOT be set
         otherwise.

   Payload Type (PT): 7 bits bits.  A dynamically allocated payload type
         field that designates the payload as VC-2 coded VC-2-coded video.

   Sequence Number: 16 bits bits.  Because the data rate of VC-2 coded streams VC-2-coded
         Streams can often be very high, in the order of gigabits rather
         than megabits per second, the standard 16-bit RTP sequence
         number can cycle very quickly.  For this reason reason, the sequence
         number is extended to 32-bits, 32 bits, and this field MUST hold the
         low-order
         16-bits 16 bits of this value.

   Timestamp: 32 bits bits.  If the packet contains transform parameters Transform Parameters or
         coded slice
         Coded Slice data for a coded picture picture, then the timestamp
         corresponds to the sampling instant of the coded picture.  A
         90kHz clock SHOULD be used.  A single RTP packet MUST NOT
         contain coded data for more than one coded picture, so there is
         no ambiguity here.

         A Sequence Header packet SHOULD have the same timestamp as the
         next
         picture which that will follow it in the stream. Stream.  An End of Sequence
         packet SHOULD have the same timestamp as the previous picture which
         that appeared in the stream. Stream.

   The remaining RTP header fields are used as specified in RTP
   [RFC3550].

4.2.  Payload Header

   The fields of the extended headers are defined as follows:

   Extended Sequence Number: 16 bits bits.  MUST Contain contain the high-order
         16-bits 16
         bits of the 32-bit packet sequence number.  This is needed
         since the high data rates of VC2 VC-2 Sequences mean that it is
         highly likely that the 16-bit sequence number will roll-over roll over
         too frequently to be of use for stream synchronisation. Stream synchronization.

   B: 1 bit bit.  MUST be set to 1 if the packet contains the first byte of
         an Auxiliary Data Unit, Unit and otherwise MUST be 0.  If the
         recommendations of the Stream Contraints in Section of this
         specification (Section 4.4) 4.4 ("Stream Constraints") are followed
         followed, then every Auxiliary Data Unit will be small enough
         to fit in a single packet packet, and so this bit (where present) will
         always be 1.

   E: 1 bit bit.  MUST be set to 1 if the packet contains the final byte of
         an Auxiliary Data Unit, Unit and otherwise MUST be 0.  If the
         recommendations of the Stream Contraints in Section of this
         specification (Section 4.4) 4.4 ("Stream Constraints") are followed
         followed, then every Auxiliary Data Unit will be small enough
         to fit in a single packet packet, and so this bit (where present) will
         always be 1.

   I: 1 bit bit.  MUST be set to 1 if the packet contains coded picture
         paramaters
         parameters or slice data from a field in an interlaced frame,
         and frame.
         MUST be set to 0 if the packet contains data from any part of a
         progressive frame.

   F: 1 bit bit.  MUST be set to 1 if the packet contains coded picture
         paramaters
         parameters or slice data from the second field of an interlaced
         frame, and
         frame.  MUST be set to 0 if the packet contains data from the
         first field of an interlaced frame or any part of a progressive
         frame.

   Parse Code (PC): 8 bits bits.  Contains a Parse Code which that MUST be the
         value indicated for the type of data in the packet.

   Data Length: 32 bits bits.  For an auxiliary data unit Data Unit, this contains the
         number of bytes of data contained in the payload section of
         this packet.  If the recommendations of the Stream Contraints in Section of this specification (Section 4.4) 4.4 ("Stream
         Constraints") are followed followed, then no Auxiliary Data Unit will be
         large enough to cause a packet to exceed the MTU of the
         network.

   Picture Number: 32 bits bits.  MUST contain the Picture Number for the
         coded picture this packet contains data for, as described in
         Section 12.1 of the VC-2 specification [VC2].

         The sender MUST send at least one transform parameters transform-parameters packet
         for each coded picture and MAY include more than one as long as
         they contain identical data.  The sender MUST NOT send a packet
         from a new picture until all the coded data from the current
         picture has been sent.

         If the receiver receives Coded Slices packets for a picture but
         does not receive a transform parameters Transform Parameters packet for a picture that
         picture, then it this is an indication of either packet loss,
         joining a Stream mid-picture, or a non-compliant transmitter.
         In this case, the receiver MAY assume that the parameters are
         unchanged since the last picture, or it MAY discard the
         picture.  Choosing between these two options is left up to the
         implementation as it will be dependent on intended use, the use.  The
         former may result in malformed pictures, while the latter will
         result in dropped frames.  Such an occurance is an indication either
         of packet loss, joining a stream mid-picture, or of a non-
         compliant transmitter.

   Slice Prefix Bytes: 16 bits bits.  MUST contain the Slice Prefix Bytes
         value for the coded picture this packet contains data for, as
         described in Section 12.3.4 of the VC-2 specification [VC2].

         In the VC-2 specification specification, this value is not restricted to 16
         bits, but the constraints on streams Streams specified in this document
         (Section 4.4) do require this.

   Slice Size Scaler: 16 bits bits.  MUST contain the Slice Size Scaler value
         for the coded picture this packet contains data for, as
         described in Section 12.3.4 of the VC-2 specification [VC2].

         In the VC-2 specification specification, this value is not restricted to 16
         bits, but the constraints on streams Streams specified in this document
         (Section 4.4) do require this.

   Fragment Length: 16 bits bits.  MUST contain the number of bytes of data
         contained in the coded payload section of this packet.

   No. of Slices: 16 bits bits.  MUST contain the number of coded slices Coded Slices
         contained in this packet, which MUST be 0 for a packet
         containing transform parameters. Transform Parameters.  In a packet containing coded
         slices Coded
         Slices, this number MUST be the number of whole slices
         contained in the packet, and the packet MUST NOT contain any
         partial slices.

   Slice Offset X: 16 bits bits.  MUST contain the X coordinate of the first
         slice in this packet, in slices, starting from the top left
         corner of the picture.

   Slice Offset Y: 16 bits bits.  MUST contain the Y coordinate of the first
         slice in this packet, in slices, starting from the top left
         corner of the picture.

4.3.  The Choice of Parse Codes (Informative)

   The "PC" field in the packets is used to carry the Parse Code Code, which
   identifies the type of content in the packet.  This code matches the
   value of the Parse Code used to identify each data unit Data Unit in a VC-2
   stream,
   Stream, as defined in the VC-2 specification, and each packet
   contains the entire data unit.

   The table below Data Unit.

   Figure 7 lists all of the parse codes Parse Codes currently allowed in a VC-2
   Sequence.  The final column indicates whether the code in question
   can be present in a stream Stream transmitted using this specification.

   +----------+-----------+---------------------+---------------+
   | PC (hex) | Binary    | Description         | Valid         |
   +----------+-----------+---------------------+---------------+
   | 0x00     | 0000 0000 | Sequence Header     | Yes           |
   | 0x10     | 0001 0000 | End of Sequence     | Yes           |
   | 0x20     | 0010 0000 | Auxiliary Data      | Yes           |
   | 0x30     | 0011 0000 | Padding Data        | Yes           |
   +----------+-----------+---------------------+---------------+
   | 0xC8     | 1100 1000 | LD Picture          | No            |
   | 0xE8     | 1110 1000 | HQ Picture          | No            |
   | 0xEC     | 1110 1100 | HQ Picture Fragment | Yes           |
   +----------+-----------+---------------------+---------------+

                    Figure 7: Parse Codes and Meanings

4.4.  Stream Constraints

   There are some constraints which a

   A Sequence needs to conform to certain constraints in order to be
   transmissible with this specification.

   o  The sequence Sequence MUST NOT contain Parse Info Headers with a Parse Code
      which is not
      other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20
      (Auxiliary Data), 0x30 (Padding Data) and Data), or 0xEC (High Quality
      Picture Fragment).  Some other streams Streams MAY be convertible to meet
      this restriction (see below).

   o  Every High Quality Picture Fragment MUST be no longer than 65535
      bytes.  This can usually be ensured by splitting large fragments Fragments
      into several smaller fragments, Fragments, except in the case where an
      individual slice is too large, in which case see the notes below
      on conversion.

   o  Informative note: this requirement ensures that every High Quality
      Picture Fragment will always contain no more than 65535 slices.

   o  Every High Quality Picture Fragment SHOULD be small enough that
      the RTP packet carrying it will fit within the network MTU size.
      This can usually be ensured by splitting large fragments Fragments into
      several smaller fragments, Fragments, except in the case where an individual
      slice is too large, in which case see the notes below on
      conversion.

   o  Every High Quality Picture Fragment MUST be encoded using values
      for Slice Prefix Bytes and Slice Size Scaler no greater than
      65535.

   If a Sequence intended for tranmission transmission does not conform to these
   restrictions
   restrictions, then it MAY be possible to simply convert it into a
   form that does by splitting pictures and/or large fragments Fragments into
   suitably sized fragments. Fragments.  This can be done provided that the
   following (weaker) constraints are met:

   o  The sequence Sequence does not contain Parse Info Headers with a Parse Code
      which is not
      other than 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20
      (Auxiliary Data), 0x30 (Padding Data), 0xE8 (High Quality
      Picture), and or 0xEC (High Quality Picture Fragment).

   o  Every  None of the High Quality Picture Pictures or High Quality Picture Fragment
      contains no
      Fragments contain slices which that are individually longer than 65535
      bytes.  Note: When this is the case case, the values of Slice Prefix
      Bytes and Slice Size Scaler will necessarily also be smaller than
      65535.

   o  Every  None of the High Quality Picture Pictures or High Quality Picture Fragment
      contains no
      Fragments contain slices which that are individually so large that an
      RTP packet carrying a Fragment containing that single slice will
      fit within the network MTU size.

   Sending

   It is not possible to send a Stream which that does not meet the above
   requirements via this mechanism is not possible unless the stream Stream is re-encoded by a
   VC-2 Encoder so as to meet them.

   In addition addition, every Auxiliary Data Unit SHOULD be small enough that a
   single RTP packet carrying it will fit within the network MTU size.
   Since there is currently no specification for the format of Auxiliary
   Data in VC-2 VC-2, the mechanism for ensuring this with an encoder
   implementation that includes Auxiliary Data Units will be dependent
   upon the implementation's use for them.

   When encoding VC-2 video intended to be transported via RTP RTP, a VC-2
   profile and level which that ensures these requirements are met SHOULD be
   used.

4.5.  Payload Data

   For the Sequence Header packet type (PC = 0x00) 0x00), the payload data
   MUST be the coded Sequence Header exactly as it appears in the VC-2
   Sequence.

   For the Transform Parameters packet type (PC = 0xEC and No. of Slices
   =
   0) 0), the payload data MUST be the variable length variable-length coded transform
   parameters. Transform
   Parameters.  This MUST NOT include the fragment Fragment header (since all
   data in the picture header is already included in the packet header).

   For the Auxiliary Data packet type (PC = 0x20) 0x20), the payload data MUST
   be a portion of the auxiliary data bytes contained in the Auxiliary
   data unit being
   Data Unit being transmitted.  The B flag MUST be set on the packet which
   that contains the first byte, the E flag MUST be set on the packet which
   that contains the last byte, the bytes MUST be included in order, and
   the packets MUST have contiguous sequence numbers.

   For the Picture Fragment packet type (PC = 0xEC and No. of Slices > 0)
   0), the payload data MUST be a specified number of coded slices Coded Slices in
   the same order that they appear in the VC-2 stream. Stream.  Which slices
   appear in the packet is identified using the Slice Offset X and Slice
   Offset Y fields in the payload header.

   For the End of Sequence packet type (PC = 0x10) 0x10), there is no payload
   data.

4.5.1.  Reassembling the Data

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x42     |      0x42     |      0x43     |      0x44     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Parse Code   |                       Next Parse Offset
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                       Prev Parse Offset
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |
   +-+-+-+-+-+-+-+-+

                     Figure 8: VC-2 Parse Info Header

   To reassemble the data in the RTP packets into a valid VC-2 Sequence
   the receiver SHOULD: Sequence:

   o  Take  The receiver SHOULD take the data from each packet with a Parse
      Code of 0x00 and prepend a valid VC-2 Parse Info Header (Figure 8)
      with the same
      parse code to it. Parse Code (0x00).  The resulting Sequence Header
      Parse Info Header and data unit Data Unit MUST be included in the output
      stream before any coded pictures which that followed it the packet being
      processed in the RTP stream stream, unless an identical Sequence Header
      has already been included, and they MAY be repeated (with
      apropriate modfifications modifications to the next and previous header oddsets) offsets)
      at any point that results in a valid VC-2 stream. Stream.

   o  Take  The receiver SHOULD take the data from each packet with a Parse
      Code of 0xEC and No. of Slices set to 0 (which together indicates indicate
      that this packet contains the transform parameters Transform Parameters for a coded
      picture) and prepend with the same Parse Code a valid VC-2 Parse
      Info Header (Figure 8) followed by the picture number, fragment Fragment
      data length, and slice count (0) to it with the
      same parse code. (0).

   o  Take  The receiver SHOULD take the data from each packet with a Parse
      Code of 0xEC and No. of Slices not set to 0 (which together indicates
      indicate that this packet contains coded slices) Coded Slices) and prepend with
      the same Parse Code a valid VC-2 Parse Info Header (Figure 8)
      followed by the picture number, fragment Fragment data length, slice count,
      x offset and y offset taken from the packet header to
      it with the same parse code. header.

   o  A receiver MAY combine all fragment data units Fragment Data Units (with parse code Parse Code
      0xEC) and the same picture number into a single picture data unit Data Unit
      with parse code Parse Code 0xE8.  If the stream Stream is required to comply with
      major versions 1 or 2 of the VC-2 Spec specification, then this MUST be
      done.

   o  Take  The receiver SHOULD take the data from each packet with a Parse
      Code of 0x20 and the B bit set and prepend a valid VC-2 Parse Info
      Header (Figure 8) with the parse code 0x20 Parse Code 0x20, and then take each
      subsequent packet with
      parse code Parse Code 0x20 without the B bit set and
      append their its payload to the growing data unit. Data Unit.  When all packets for
      a particular data
      unit Data Unit have been received received, it SHOULD be included
      in the output stream.  The final packet for a data unit Data Unit will have
      the E bit set.

   o  Once a data unit Data Unit has been assembled, whether a Sequence Header,
      Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the
      next parse offset and previous parse offset values in its Parse
      Info Header SHOULD be filled with the offset between the start of
      the header and the start of the next or previous. previous header.

   o  An End of Sequence Parse Info Header MAY be inserted when a packet
      with parse code Parse Code set to 0x10 is encountered, or at any other time
      that is allowed in a valid VC-2 stream. Stream.  After an End of Sequence
      Parse Info Header is included in the output stream stream, either the
      stream
      Stream must end end, or it MUST be followed by a Sequence Header
      indicating the start of a new Sequence.  The next parse offset of
      the End of Sequence header MUST be set t to 0, and the previous
      parse offset SHOULD be filled with the offset from the start of
      the previous parse info header Parse Info Header in the stream. Stream.

   o  A Padding Data Parse Info Header MAY be inserted when a packet
      with parse code Parse Code set to 0x30 and the B bit set is encountered, or
      at any other time that is allowed in a valid VC-2 stream. Stream.  The
      length of the accompanying data unit Data Unit MAY have any value, and its
      contents MUST be set to a series of zero bytes.  The next parse
      offset and previous parse offset values in its Parse Info Header
      SHOULD be filled with the offset between the start of the header
      and the start of the next or previous. previous header.

5.  FEC  Forward Error Correction (FEC) Considerations

   VC-2 provides no underlying protection against data loss, so it may
   be useful to employ forward error correction Forward Error Correction to the stream. Stream.  A
   mechanism for doing this to a generic RTP stream is specified in
   RFC5109 RFC
   5109 [RFC5109].  If making use of this mechanism to provide multi-
   level protection
   multilevel protection, then the packets SHOULD be assigned to layers
   based upon their packet type, with the packet types being, in order
   of importance
   being: importance:

   1.  Sequence Headers

   2.  Fragments constaining containing Transform Parameters

   3.  Fragments containing coded slices Coded Slices

   4.  Auxiliary Data and end of Sequence

   5.  Padding

   It is RECOMMENDED that if multi-level multilevel protection is to be used used, then
   one layer will protect all Sequence Header packets, and a second will
   protect Sequence Headers and all Fragments.  If desired desired, a third
   layer MAY protect Auxiliary Data and End of Sequence packets.
   Padding data SHOULD NOT be protected by FEC.

6.  Congestion Control Considerations

   Congestion control for RTP SHALL be used in accordance with RFC 3550
   [RFC3550],
   [RFC3550] and with any applicable RTP profile; profile -- e.g., RFC 3551 [RFC3551].
   An additional requirement if best-effort service is being used is:
   users of this payload format MUST monitor packet loss to ensure that
   the packet loss rate is within acceptable parameters.  Circuit
   Breakers [RFC8083] is are an update to RTP [RFC3550] that defines
   criteria for when one is required to stop sending RTP Packet Streams,
   and applications implementing this standard MUST comply with it.  RFC
   8085 [RFC8085] provides additional information on the best practices
   for applying congestion control to UDP streams.

   In particular particular, it should be noted that the expected data rate for RTP
   sessions which that use this profile is likely to be in the range of
   gigabits per second.  If used on a closed network which that has been
   correctly provisioned for the expected data rates rates, this might not
   pose a problem, but there is always the risk of data getting out onto
   the open internet.

7.  Payload Format Parameters

   This RTP payload format is identified using the video/vc2 'video/vc2' media type
   type, which is registered in accordance with RFC 4855 [RFC4855] and [RFC4855],
   using the template of RFC 6838 [RFC6838].

7.1.  Media Type Definition

   Type name:

      video

   Subtype name:

      vc2

   Required parameters:

      rate: The RTP timestamp clock rate.  Applications using this
      payload format SHOULD use a value of 90000.

      profile: The VC-2 profile in use, the use.  The only value currently
      allowed value is "HQ".

   Optional parameters:

      version: the VC-2 specification version in use.  The only
      currently allowed value is "3" since all Sequences transported
      using this mechanism will contain HQ Picture Fragment data units, Data Units,
      which the VC-2 specification [VC2] defines as requiring version 3.

      level: The VC-2 level in use.  Any integer may be used.

   Encoding considerations:

      This media type is framed and binary, binary; see section Section 4.8 in RFC6838 RFC 6838
      [RFC6838].

   Security considerations:

      Please see the security consideration considerations in RFCXXXX RFC 8450.

   Interoperability considerations: N/A

   Published specification:

      RFC XXXX 8450

   Applications that use this media type:

      Video Communication.

   Fragment Identifier Considerations: identifier considerations: N/A

   Additional information: N/A

   Person & email address to contact for further information:

      james.barrett@bbc.co.uk

      James P. Weaver <james.barrett@bbc.co.uk>

   Intended usage:

      COMMON

   Restrictions on usage:

      This media type depends on RTP framing, framing and hence is only defined
      for transfer via RTP [RFC3550].  Transport within other framing
      protocols is not defined at this time.

   Author:

      James P. Weaver <james.barrett@bbc.co.uk>

   Change controller:

      IETF Payload working group PAYLOAD Working Group delegated from the IESG.

   Provisional registration? (standards tree only):

      No

7.2.  Mapping to SDP the Session Description Protocol (SDP)

   The mapping of the above defined above-defined payload format media type and its
   parameters SHALL be done according to Section 3 of RFC 4855
   [RFC4855].

   o  The type name ("video") goes in SDP "m=" as the media name.

   o  The subtype name ("vc2") goes in SDP "a=rtpmap" as the encoding
      name, followed by a slash ("/") and the rate parameter.

   o  The required parameter profile and the optional parameters version
      and level, when present, are included in the "a=fmtp" attribute
      line of SDP as a semicolon-separated list of parameter=value
      pairs.

   Version and level SHALL be specified in decimal when present.

   For example, a sample SDP mapping for VC-2 could be as follows:

             m=video 30000 RTP/AVP 112
             a=rtpmap:112 vc2/90000
             a=fmtp:112 profile=HQ;version=3;level=0

   In this example, a dynamic payload type 112 is used for vc-2 data.
   The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line
   after the subtype.  In the "a=fmtp:" line, profile HQ, version 3, and
   level 0 (unknown or non-standard level) are specified.

7.3.  Offer/Answer Considerations

   All parameters are declarative.

8.  IANA Considerations

   This memo requests that

   IANA registers video/vc2 has registered 'video/vc2' as specified in Section 7.1.  The
   media type is also requested to be has been added to the IANA registry for "RTP Payload
   Format MIME types"
   (http://www.iana.org/assignments/rtp-parameters). Media Types"
   <https://www.iana.org/assignments/rtp-parameters>.

9.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] [RFC3711], or RTP/
   SAVPF
   RTP/SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework: Why
   RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
   discusses, it is not an RTP payload format's responsibility to
   discuss or mandate what solutions are used to meet the basic security
   goals like confidentiality, integrity integrity, and source authenticity for
   RTP in general.  This responsibility lies with anyone using RTP in an
   application.  They can find guidance on available security mechanisms
   and important considerations in Options "Options for Securing RTP Sessions Sessions"
   [RFC7201].  Applications SHOULD use one or more appropriate strong
   security mechanisms.  The rest of this security consideration section discusses the security impacting
   security-impacting properties of the payload format itself.

   This RTP payload format and its media decoder do not exhibit any
   significant non-uniformity in the receiver-side computational
   complexity for packet processing, processing and thus are unlikely to pose a
   denial-of-service threat due to the receipt of pathological data.
   Nor does the RTP payload format contain any active content.

   To avoid buffer overruns when processing these packets packets, the receiver
   MUST consider both the reported fragment Fragment length and the actual
   received size of a packet containing slice data.

   In some cases cases, the transmitter may need to decode variable length variable-length
   coded headers in order to extract some data from the VC-2 bitstream
   before assembling packets.  This process is potentially subject to
   buffer overruns if not implemented carefully.

10.  RFC Editor Considerations

   Note to RFC Editor: This section may be removed after carrying out
   all the instructions of this section.

   RFCXXXX is to be replaced by the RFC number this specification
   receives when published.

11.  References

11.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <https://www.rfc-editor.org/info/rfc3551>.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
              <https://www.rfc-editor.org/info/rfc4855>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion Control:
              Circuit Breakers for Unicast RTP Sessions", RFC 8083,
              DOI 10.17487/RFC8083, March 2017,
              <https://www.rfc-editor.org/info/rfc8083>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/info/rfc8085>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [VC2]      Society of Motion Picture and Television Engineers, "VC-2      SMPTE, "SMPTE Standard - VC-2 Video Compression", Society of Motion Picture and
              Television Engineers Standard
              ST 2042-1, 2042-1:2017, DOI 10.5594/SMPTE.ST2042-1.2017, June
              2017,
              <http://ieeexplore.ieee.org/document/7967896/>.

11.2. <https://ieeexplore.ieee.org/servlet/
              opac?punumber=7967894>.

10.2.  Informative References

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <https://www.rfc-editor.org/info/rfc3711>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              DOI 10.17487/RFC4585, July 2006,
              <https://www.rfc-editor.org/info/rfc4585>.

   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, DOI 10.17487/RFC5109, December
              2007, <https://www.rfc-editor.org/info/rfc5109>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <https://www.rfc-editor.org/info/rfc5124>.

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
              <https://www.rfc-editor.org/info/rfc7201>.

   [RFC7202]  Perkins, C. and M. Westerlund, "Securing the RTP
              Framework: Why RTP Does Not Mandate a Single Media
              Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
              2014, <https://www.rfc-editor.org/info/rfc7202>.

Author's Address

   James P. Weaver
   BBC

   Email: james.barrett@bbc.co.uk