RFC 10034: RTP Payload Format for Visual Volumetric Video-Based Coding (V3C)

3.1. Abbreviations

ACL:

atlas coding layer¶

AP:

aggregation packet¶

AU:

aggregation unit¶

CVS:

coded V3C sequence¶

DON:

decoding order number¶

DOND:

decoding order number difference¶

DONL:

decoding order number least significant bits¶

IRAP:

intra random access point¶

MTU:

maximum transmission unit¶

NAL:

network abstraction layer¶

NALU:

NAL unit¶

RBSP:

raw byte sequence payload¶

V3C:

visual volumetric video-based coding¶

VPS:

V3C parameter set¶

3.2. Definitions

4.1. Overview of the V3C Codec (Informative)

V3C encoding of a volumetric frame is achieved through a conversion of the volumetric frame from its 3D representation into multiple 2D representations and a generation of associated data documenting such conversions and transformations. The associated data, also known as the atlas data, provides information on how to reproject the 2D representations back into the 3D volumetric frame.¶

2D representations, known as V3C video components, of a volumetric frame are encoded using conventional 2D video codecs. A V3C video component may, for example, include occupancy, geometry, or attribute data. The occupancy data informs a V3C decoder which pixels in other V3C video components contribute to reconstructed 3D representation. The geometry data describes information on the position of the reconstructed voxels while attribute data provides additional properties for the voxels, e.g., color or material information. A voxel is the smallest discrete addressable element in a 3D space, analogous to a pixel in 2D.¶

Atlas data, known as V3C atlas component, provides information to interpret V3C video components and enables the reconstruction from a 2D representation back into a 3D representation of a volumetric frame. Atlas data is composed of a collection of patches. Each patch identifies a region in the V3C video components and provides information necessary to perform the appropriate inverse projection of the indicated region back into a 3D space. The shape of the patch region is determined by a 2D bounding box associated with each patch as well as their coding order. The shape of these patches is also further refined based on occupancy data.¶

To enable parallelization, random access, as well as a variety of other functionalities, an atlas frame can be divided into one or more rectangular partitions referred to as tiles. Tiles are not allowed to overlap and should be independently decodable. An atlas frame may contain regions that are not associated with any tile or patch.¶

The binary form of V3C video components, i.e., video bitstream, and V3C atlas components, i.e., atlas bitstream, can be grouped and represented by a single V3C bitstream. The V3C bitstream is composed of a set of V3C units. Each V3C unit has a V3C unit header and a V3C unit payload. The V3C unit header describes the V3C unit type for the payload. The V3C unit payload contains V3C video components, V3C atlas components, or a V3C parameter set. V3C video components, i.e., occupancy, geometry, or attribute components, correspond to video data units (e.g., NAL units defined in [ISO.IEC.23008-2]) that could be decoded by an appropriate video decoder. An example of a V3C bitstream consisting of a V3C parameter set, atlas bitstream, and three video component bitstreams (geometry, occupancy, attribute) is provided in Figure 1.¶

  +-------------------+------------------+-------------------+
  | V3C Unit(V3C_VPS) | V3C Unit(V3C_AD) | V3C Unit(V3C_GVD) |
  +-------------------+------------------++-----------------++---
  | V3C Unit(V3C_OVD) | V3C Unit(V3C_AVD) | V3C Unit(V3C_AD)| ...
  +-------------------+-------------------+-----------------+----

4.2. V3C Parameter Set (Informative)

This document specifies an encapsulation of V3C atlas data. Aspects related to signaling of V3C parameter set, defined in [ISO.IEC.23090-5], are also considered. A V3C parameter set is encapsulated in its own V3C unit, which allows decoupling the transmission of V3C parameter set from the V3C video and atlas components. The V3C parameter set can be transmitted by external means (e.g., as a result of the capability exchange) or through a (reliable or unreliable) control protocol. Section 9 of this document specifies how a V3C parameter set can be signaled using the Session Description Protocol (SDP).¶

Generally, it is useful to signal a V3C parameter set out of band, because it describes what overall resources are needed to decode and reconstruct the associated V3C bitstream. Signaling it dynamically as part of an RTP stream might result in undefined behavior when the receiver does not have the required capabilities to decode the received V3C video component sub-bitstreams or when reconstruction process relies on information that the receiver does not support.¶

4.3. V3C Atlas and Video Components (Informative)

v3c_unit_header( ) {
 unsigned int(5) vuh_unit_type;
 if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD ||
   vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
   vuh_unit_type == V3C_CAD || vuh_unit_type == V3C_PVD ) {
   unsigned int(4) vuh_v3c_parameter_set_id;
  }
  if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD ||
    vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
    vuh_unit_type == V3C_PVD ) {
    unsigned int(6) vuh_atlas_id;
  }
  if( vuh_unit_type == V3C_AVD ) {
    unsigned int(7) vuh_attribute_index;
    unsigned int(5) vuh_attribute_partition_index;
    unsigned int(4) vuh_map_index;
    unsigned int(1) vuh_auxiliary_video_flag;
  }
  else if( vuh_unit_type == V3C_GVD ) {
    unsigned int(4) vuh_map_index;
    unsigned int(1) vuh_auxiliary_video_flag;
    bit(12) vuh_reserved_zero_12bits;
  }
  else if( vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_AD ||
      vuh_unit_type == V3C_PVD) {
    bit(17) vuh_reserved_zero_17bits;
  }
  else if( vuh_unit_type == V3C_CAD ) {
    bit(23) vuh_reserved_zero_23bits;
  }
  else {
    bit(27) vuh_reserved_zero_27bits;
  }
}

nal_unit_header(){
    bit(1) nal_forbidden_zero_bit;
    bit(6) nal_unit_type;
    bit(6) nal_layer_id;
    bit(3) nal_temporal_id_plus1;
}
nal_unit(NumBytesInNalUnit){
    nal_unit_header();
    NumBytesInRbsp = 0;
    for( i = 2; i < NumBytesInNalUnit; i++ )
      bit(8) rbsp_byte[ NumBytesInRbsp++ ];
}

4.4. Systems and Transport Interfaces (Informative)

In addition to releasing specifications on V3C applications [ISO.IEC.23090-5] and [ISO.IEC.23090-12], MPEG conducted further systems-level work on file formats to encapsulate compressed V3C content. The seventh edition of the ISO Base Media File Format (ISOBMFF) specification [ISO.IEC.14496-12] introduces a new media handler 'volv', intended to support volumetric visual media. It also specifies other structures to enable development of derived specifications detailing how various volumetric visual media may be stored in ISOBMFF.¶

One of such derived specifications is [ISO.IEC.23090-10], which defines how V3C content can be stored in a file and streamed over DASH [ISO.IEC.23009-1]. To a large extent, ISO/IEC 23090-10 focuses on describing how ISOBMFF boxes and syntax elements may be used to store volumetric media, but in some cases, new boxes and syntax elements are introduced to accommodate the fundamentally different type of new media. While the specification is not directly relevant for defining RTP payload format for V3C atlas data, it is a useful resource that may be considered especially when designing ingestion of encoded V3C content into RTP streaming pipelines.¶

5.1. General

This section describes details related to V3C atlas RTP payload format definitions. Aspects related to the RTP header, RTP payload header, and general payload structure are considered. RTP payload format(s) for video components is defined in its respective RTP payload format specifications depending on the video codec used.¶

5.2. RTP Header

The format of the RTP header is specified in [RFC3550] and replicated in Figure 2 for convenience. V3C RTP payload format uses the fields of the RTP header in a manner consistent with [RFC3550]. Unless contextualized below, the meaning of the fields depicted in Figure 2 is the same as in Section 5.1 of [RFC3550].¶

   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=2|P|X|  CC   |M|     PT      |       sequence number         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           timestamp                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |            contributing source (CSRC) identifiers             |
  |                             ....                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker bit (M): 1 bit

Set for the last packet of the access unit and carried in the current RTP stream. This is in line with the normal use of the M bit in video formats to allow an efficient playout buffer handling.¶

Payload Type (PT): 7 bits

The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. The assignment of a payload type MUST be performed either through the profile used or in a dynamic way.¶

Timestamp: 32 bits

The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate MUST be used.¶

If the NAL unit has no timing properties of its own (e.g., parameter set and Supplemental Enhancement Information (SEI) NAL units), the RTP timestamp MUST be set to the RTP timestamp of the coded atlas of the access unit in which the NAL unit (according to Section 8.4.5.3 of [ISO.IEC.23090-5]) is included.¶

Receivers MUST use the RTP timestamp for the display process, even when the bitstream contains atlas frame timing SEI messages as specified in [ISO.IEC.23090-5].¶

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

5.3. RTP Payload Header

The first two bytes of the payload of an RTP packet are referred to as the payload header. The payload header consists of the same fields (F, NUT, NLI, and TID) as the NAL unit header as shown in Section 4.3.2, irrespective of the type of the payload structure. For convenience, the structure of RTP payload header is shown in Figure 3.¶

   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|    NUT    |    NLI    | TID |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F:

The nal_forbidden_zero_bit as specified in [ISO.IEC.23090-5] is equal to 0. A value equal to 1 indicates that the payload may contain errors or syntax violations.¶

Media processing elements in the network that are capable of deep packet inspection SHOULD set the F bit to 1 to indicate detected bit errors in the NAL unit(s). A receiver reaction to an RTP payload header in which the F bit is equal to 1 is to discard such RTP packet and to conceal the lost data in the discarded NAL unit(s).¶

NUT:

The nal_unit_type as specified in [ISO.IEC.23090-5] defines the type of the RBSP data structure contained in the NAL unit payload. The NUT value could carry other meaning depending on the RTP packet type.¶

NLI:

The nal_layer_id as specified in [ISO.IEC.23090-5] defines the identifier of the layer to which an ACL NAL unit belongs or the identifier of a layer to which a non-ACL NAL unit applies.¶

TID:

The nal_temporal_id_plus1 minus 1 as specified in [ISO.IEC.23090-5] defines a temporal identifier for the NAL unit. The value of nal_temporal_id_plus1 MUST NOT be equal to 0.¶

5.4. Payload Structures

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      RTP payload header       |      DONL (conditional)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  |      v3c-tile-id (cond)       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                        NAL unit data                          |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RTP payload header (NUT=56)  |      v3c-tile-id (cond)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                  Two or more aggregation units                |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  DOND (cond)  /  DONL (cond)  |      v3c-tile-id (cond)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  |            NALU size          |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                            NAL unit                           |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RTP payload header (NUT=57)  |   FU header   |  DONL (cond)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  |  DONL (cond)  |    v3c-tile-id (cond)         |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
  |                                                               |
  |                          FU payload                           |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |S|E|    FUT    |
  +-+-+-----------+

   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=2|P|X|  CC   |M|     PT      |       sequence number         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           timestamp                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            contributing source (CSRC) identifiers             |
  |                             ....                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RTP payload header (NUT=57)  |1|0|    FUT    |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
  |                                                               |
  |                          FU payload                           |
  |                                                               |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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=2|P|X|  CC   |M|     PT      |       sequence number         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           timestamp                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            contributing source (CSRC) identifiers             |
  |                             ....                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RTP payload header (NUT=57)  |0|1|    FUT    |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
  |                                                               |
  |                          FU payload                           |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :...OPTIONAL RTP padding        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.5. Decoding Order Number

For each atlas NAL unit, the variable AbsDon is derived, representing the decoding order number that is indicative of the NAL unit decoding order. Let NAL unit n be the n-th NAL unit in transmission order within an RTP stream.¶

If sprop-max-don-diff is equal to 0 for all the RTP streams carrying the atlas bitstream, AbsDon[n], the value of AbsDon for NAL unit n, is derived as equal to n.¶

Otherwise (sprop-max-don-diff is greater than 0 for any of the RTP streams), AbsDon[n] is derived as follows, where DON[n] is the value of the variable DON for NAL unit n:¶

  If (n == 0)
    AbsDon[n] = DON[0]
  Else
    If (DON[n] == DON[n-1])
      AbsDon[n] = AbsDon[n-1]
    If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768)
      AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
    If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768)
      AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
    If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768)
      AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 - DON[n])
    If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768)
      AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])

For any two NAL units m and n, the following applies:¶

• AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit m in NAL unit decoding order.¶

• When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding order of the two NAL units can be in either order.¶

• AbsDon[n] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m in decoding order.¶

7.1. Media Type Registration

See Section 10.1 for information related to media type registration.¶

7.2. Required Parameters Definition

sprop-v3c-parameter-set:

sprop-v3c-parameter-set provides V3C parameter set bytes as defined in [ISO.IEC.23090-5]. The value contains a base64-encoded [RFC4648] representation of the v3c_parameter_set() syntax element.¶

7.3. Definitions of Optional Parameters

sprop-v3c-unit-header:

sprop-v3c-unit-header provides bytes corresponding to a V3C unit header as defined in [ISO.IEC.23090-5]. The value contains a base64-encoded [RFC4648] representation of the 4 bytes of V3C unit header. V3C unit header indicates the details of which V3C component the media corresponds to.¶

sprop-v3c-unit-header contains the same information as sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, and sprop-v3c-aux-video-flag combined. To avoid the potential of signaling conflicting information, the separate parameters MUST NOT be present when sprop-v3c-unit-header is present.¶

sprop-v3c-unit-type:

sprop-v3c-unit-type provides a V3C unit type value corresponding to vuh_unit_type defined in [ISO.IEC.23090-5], i.e., defines a V3C sub-bitstream type such as geometry, occupancy, atlas data, or attribute.¶

When sprop-v3c-unit-header is present, sprop-v3c-unit-type MUST NOT be present. When present, the value of sprop-v3c-unit-type SHALL be in the range of 1 to 31 inclusive.¶

sprop-v3c-vps-id:

sprop-v3c-vps-id provides a value corresponding to active vuh_v3c_parameter_set_id defined in [ISO.IEC.23090-5], i.e., defines the value of the active V3C parameter set id.¶

When sprop-v3c-unit-header is present, sprop-v3c-vps-id MUST NOT be present. When present, the value of sprop-v3c-vps-id SHALL be in the range of 0 to 15 inclusive.¶

sprop-v3c-atlas-id:

sprop-v3c-atlas-id provides a value corresponding to vuh_atlas_id defined in [ISO.IEC.23090-5]. When a V3C bitstream consists of multiple atlases, this parameter indicates the atlas id for the media component.¶

When sprop-v3c-unit-header is present, sprop-v3c-atlas-id MUST NOT be present. When present, the value of sprop-v3c-atlas-id SHALL be in the range of 0 to 63 inclusive.¶

sprop-v3c-attr-idx:

sprop-v3c-attr-idx provides a value corresponding to vuh_attribute_index defined in [ISO.IEC.23090-5]. An attribute in V3C determines a feature of a reconstructed volumetric primitive; for example, this could be texture (color), transparency, reflectance, or normal. The attribute index defines which type of attribute the media corresponds to.¶

When sprop-v3c-unit-header is present, sprop-v3c-attr-idx MUST NOT be present. When present, the value of sprop-v3c-attr-idx SHALL be in the range of 0 to 127 inclusive.¶

sprop-v3c-attr-part-idx:

sprop-v3c-attr-part-idx provides a value corresponding to vuh_attribute_partition_index defined in [ISO.IEC.23090-5]. In V3C, an attribute can be partitioned into multiple components. This may for example be useful, when an attribute consists of four dimensions but the video codec only supports coding three channels of data.¶

When sprop-v3c-unit-header is present, sprop-v3c-attr-part-idx MUST NOT be present. When present, the value of sprop-v3c-attr-part-idx SHALL be in the range of 0 to 31 inclusive.¶

sprop-v3c-map-idx:

sprop-v3c-map-idx provides a value corresponding to vuh_map_index defined in [ISO.IEC.23090-5]. Maps in V3C allow storing multiple layers of projected volumetric data.¶

When sprop-v3c-unit-header is present, sprop-v3c-map-idx MUST NOT be present. When present, the value of sprop-v3c-map-idx SHALL be in the range of 0 to 15 inclusive.¶

sprop-v3c-aux-video-flag:

sprop-v3c-aux-video-flag provides a value corresponding to vuh_auxiliary_video_flag defined in [ISO.IEC.23090-5]. Auxiliary video in V3C can be used to pack volumetric data directly in a video frame without projecting it into a 2D plane first.¶

When sprop-v3c-unit-header is present, sprop-v3c-aux-video-flag MUST NOT be present. When present, the value of sprop-v3c-aux-video-flag SHALL be either 0 or 1.¶

sprop-v3c-tile-id:

sprop-v3c-tile-id indicates that the RTP stream contains only portion of the tiles in an atlas. The value of sprop-v3c-tile-id contains a comma-separated (',') list of integer values, which indicate the tile ids that are present in the corresponding RTP stream.¶

When sprop-v3c-tile-id is not present, the RTP stream is expected to contain all tiles or only consist of a single tile.¶

sprop-v3c-tile-id-pres:

sprop-v3c-tile-id-pres indicates that the RTP packets contain v3c-tile-id field.¶

When present, the value of sprop-v3c-tile-id-pres SHALL be either 0 or 1. When not present, the default value of sprop-v3c-tile-id-pres is 0.¶

sprop-v3c-atlas-data:

sprop-v3c-atlas-data MAY be used to convey any atlas data NAL units of the V3C atlas sub-bitstream for out-of-band transmission. The value contains a comma-separated (',') list of base64-encoded [RFC4648] representations of the atlas NAL units as specified in [ISO.IEC.23090-5].¶

When present, the atlas NAL units stored in the sprop-v3c-atlas-data shall be applied for duration of the entire stream until an in-band atlas NAL unit with the same NAL unit type overrides it.¶

sprop-v3c-common-atlas-data:

sprop-v3c-common-atlas-data MAY be used to convey common atlas data NAL units of the V3C common atlas sub-bitstream for out-of-band transmission. The value contains a comma-separated (',') list of base64-encoded [RFC4648] representations of the common atlas NAL units (i.e., NAL_CASPS and NAL_CAF_IDR) as specified in [ISO.IEC.23090-5].¶

When present, the common atlas NAL units stored in the sprop-v3c-common-atlas-data shall be applied for duration of the entire stream until an in-band common atlas NAL unit with the same NAL unit type overrides it.¶

sprop-v3c-sei:

sprop-v3c-sei MAY be used to convey SEI NAL units of V3C atlas and common atlas sub-bitstreams for out-of-band transmission. The value is a comma-separated (',') list of base64-encoded [RFC4648] representations of SEI NAL units (i.e., NAL_PREFIX_NSEI and NAL_SUFFIX_NSEI, NAL_PREFIX_ESEI, NAL_SUFFIX_ESEI) as specified in [ISO.IEC.23090-5].¶

When present, the SEI NAL units stored in the sprop-v3c-sei shall be applied for duration of the entire stream until an in-band SEI NAL unit with the same SEI payload type overrides it.¶

v3c-ptl-level-idc:

v3c-ptl-level-idc provides a value corresponding to ptl_level_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-level-idc indicates the level to which the V3C bitstream conforms.¶

When present, the value of v3c-ptl-level-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-level-idc SHALL be in the range of 0 to 255 inclusive.¶

v3c-ptl-tier-flag:

v3c-ptl-tier-flag provides a value corresponding to ptl_tier_flag defined in [ISO.IEC.23090-5]. The value of v3c-ptl-tier-flag indicates the tier context necessary to interpret the value of v3c-ptl-level-idc.¶

When present, the value of v3c-ptl-tier-flag SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-tier-flag SHALL be either 0 or 1.¶

v3c-ptl-codec-idc:

v3c-ptl-codec-idc provides a value corresponding to ptl_profile_codec_group_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-codec-idc indicates the codec group profile component to which the V3C bitstream conforms.¶

When present, the value of v3c-ptl-codec-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-codec-idc SHALL be in the range of 0 to 127 inclusive.¶

v3c-ptl-toolset-idc:

v3c-ptl-toolset-idc provides a value corresponding to ptl_profile_toolset_idc defined in [ISO.IEC.23090-5]. The value of v3c-ptl-toolset-idc indicates the toolset combination profile component to which the V3C bitstream conforms.¶

When present, the value of v3c-ptl-toolset-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-toolset-idc SHALL be in the range of 0 to 255 inclusive.¶

v3c-ptl-rec-idc:

v3c-ptl-rec-idc provides a value corresponding to ptl_profile_reconstruction_idc as defined in [ISO.IEC.23090-5]. The value of v3c-ptl-rec-idc indicates the reconstruction profile component to which the V3C bitstream is recommended to conform.¶

When present, the value of v3c-ptl-rec-idc SHALL NOT conflict the corresponding value in the sprop-v3c-parameter-set. The value of v3c-ptl-rec-idc SHALL be in the range of 0 to 255 inclusive.¶

sprop-max-don-diff:

If the transmission order of NAL units in the RTP stream(s) is the same as the decoding and NAL unit output order, this parameter must be equal to 0.¶

Otherwise, if the decoding order of the NAL units of the RTP stream(s) is the same as the NAL unit transmission order but not the same as NAL unit output order, the value of this parameter MUST be equal to 1.¶

Otherwise, this parameter specifies the maximum absolute difference between the decoding order number (i.e., AbsDon) values of any two NAL units naluA and naluB, where naluA follows naluB in decoding order and precedes naluB in transmission order.¶

The value of sprop-max-don-diff MUST be an integer in the range of 0 to 32767 inclusive.¶

When not present, the value of sprop-max-don-diff is inferred to be equal to 0.¶

7.4. Mapping of Parameters to V3C Syntax

9.1. V3C Format Parameters "v3cfmtp" Attribute

This document defines a new attribute for SDP, intended to carry V3C-specific media format parameters. Its functionality is similar to "a=fmtp", with the exception that it SHALL be used without the fmt-token and that it can be used also on a session level. The attribute allows V3C-specific media format parameters to be associated with any media line in SDP. The detailed information on the new attribute (a=v3cfmtp) is provided in Section 10.2.¶

The value of the v3cfmtp attribute is a byte-string, as defined in [RFC8866], which contains at least one V3C-specific media format parameter as a "parameter=value" pair as defined in this document. Multiple semicolon-separated V3C media "parameter=value" pairs can be stored in the byte-string to be conveyed by SDP and given unchanged to the media tool that will use this format. Whitespace in the byte-string is ignored.¶

An example of the usage of the new attribute is shown below. The first line describes session-level usage of the attribute, signaling a V3C parameter set. The second line describes a media-level attribute, signaling a V3C unit header and profile tier level flag for the associated media line.¶

  a=v3cfmtp:sprop-v3c-parameter-set=AUH/AAAP/zwAAAAAACgIAtEAgQLAIAAUQ
  BACWAM5QEDgQCAIAAAAABP8CzwAAAAAAAAAQAAAtAE/wLPAAAAAAAg=;

  a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;v3c-ptl-tier-flag=1;

9.2. Mapping of Payload Type Parameters to SDP

  m=application 49170 RTP/AVP 98
  a=rtpmap:98 v3c/90000
  a=fmtp:98 sprop-v3c-tile-id=0,1
  a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;v3c-ptl-tier-flag=1;
    sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==

  m=video 49170 RTP/AVP 99
  a=rtpmap:99 H265/90000
  a=fmtp:99 sprop-max-don-diff=0;
  a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==

  m=video 49170 RTP/AVP 99
  a=rtpmap:99 H265/90000
  a=v3cfmtp:sprop-v3c-unit-header=KAAAAA==;
    sprop-v3c-parameter-set=AUH/AAAP/zwAAAAAACgIAtEAgQLAIAAUQBACWAM5Q
    EDgQCAIAAAAABP8CzwAAAAAAAAAQAAAtAE/wLPAAAAAAAg=;
    sprop-v3c-atlas-data=SAGAFAQBaKjuXgABQEKA,SgHmIA==,LgFoDOAFAABaAA
    AAAAA+;
    sprop-v3c-common-atlas-data=YAEHgFA=,YgEAMAAAC/B0qcvv/Dbr/pTvb8oq
    fhC5JQVS9jn7kAQT/As9EFyrjRBcmxEQe+j5DuGbTT9mZmZAQAAAoA==

9.3. Grouping Framework

Different V3C components MAY be represented by their own respective RTP streams, whose payload formats are defined in the respective specifications. V3C atlas data RTP payload format is defined in this document, whereas the video component RTP payload formats are defined for example in [RFC6184] or [RFC7798]. A grouping tool, as defined in [RFC5888], is extended to indicate which media lines constitute a V3C representation. Further details on the new grouping type provided in Section 10.3.¶

The group attribute with V3C type is provided to allow application to identify "m" lines that belong to the same V3C bitstream. Grouping type V3C MUST be used with the group attribute. The tokens that follow are mapped to 'mid'-values of individual media lines in the SDP.¶

    a=group:V3C <tokens>

The following example shows an SDP including four media lines: three describing V3C video components (PT:96=occupancy, PT:97=geometry, and PT:98=attribute) and one describing a V3C atlas component (PT:100). All of these media lines are grouped under one V3C group. The V3C parameter set is provided via a session-level V3C media format parameter attribute.¶

  ...
  a=group:V3C 1 2 3 4
  a=v3cfmtp:sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQ
    AADkA==
  m=video 40000 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==
  a=mid:1
  m=video 40002 RTP/AVP 97
  a=rtpmap:97 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=GAAAAA==
  a=mid:2
  m=video 40004 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=IAAAAA==
  a=mid:3
  m=application 40008 RTP/AVP 100
  a=rtpmap:100 v3c/90000
  a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;
  a=mid:4

The example below describes how content with two atlases can be signaled as separate streams. The V3C parameter set is carried in a session-level V3C media format parameter attribute and common atlas data are carried as part of the media-level V3C media format parameter attribute corresponding to atlas zero. PT values 96, 97, 98, and 100 correspond to the occupancy, geometry, and attribute video components, as well as the atlas data component, for atlas zero. PT values 101, 102, 103, and 104 correspond to the respective components for atlas one.¶

  ...
  a=group:V3C 1 2 3 4 5 6 7 8
  a=v3cfmtp:sprop-v3c-parameter-set=AAUH/AAAP/zwAAABAADwIAWhBwAAOADjg
    QAADgAA8CAFoQcAADgA44EAAA6AkAgABRIA=;
  m=video 40000 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=EAAAAA==
  a=mid:1
  m=video 40002 RTP/AVP 97
  a=rtpmap:97 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=GAAAAA==
  a=mid:2
  m=video 40004 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=IAAAAA==
  a=mid:3
  m=application 40008 RTP/AVP 100
  a=rtpmap:100 v3c/90000
  a=fmtp:100
    sprop-v3c-common-atlas-data=YAEHgFA=,YgEAMAAAa+96Z5v6VP1D+P7LzRsb
    WDJ/yz+ALzMZNfvCg2389Kjd+d6fZyM6QZBfhrDW3K0vaP2Rr8L+gLAq/ny3wAzs9
    veiXEjjS67MfH+H4xV/RgW4fkl/YkINe/OsWCOBwPAVLACCf4FnogwYZKIME6oiD9
    UCodqjLwCCf4FnogxqBiIMZNwiEBpJIduBUoCCf4FnogwOeSIMCaGiEA9VIdtGwwC
    Cf4FnogvB+aILvWIiEBB6IdqobKfmZmZoCmZmefmZmZoCmZmefmZmZoCmZmefmZmZ
    oCmZmdA=
  a=v3cfmtp:sprop-v3c-unit-header=CAAAAA==;
  a=mid:4
  m=video 40010 RTP/AVP 101
  a=rtpmap:101 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=EAIAAA==
  a=mid:5
  m=video 40012 RTP/AVP 102
  a=rtpmap:102 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=GAIAAA==
  a=mid:6
  m=video 40014 RTP/AVP 103
  a=rtpmap:103 H264/90000
  a=v3cfmtp:sprop-v3c-unit-header=IAIAAA==
  a=mid:7
  m=application 40018 RTP/AVP 104
  a=rtpmap:104 v3c/90000
  a=v3cfmtp:sprop-v3c-unit-header=CAIAAA==
  a=mid:8

9.4. Offer and Answer Considerations

  ...
  a=group:v3c 1 2 3 4
  a=v3cfmtp:v3c-ptl-level-idc=60;
    sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==
  m=video 40000 RTP/AVP 96 97 98
  a=rtpmap:96 H264/90000
  a=rtpmap:97 H265/90000
  a=rtpmap:98 H266/90000
  a=v3cfmtp:sprop-v3c-unit-type=2;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0
  a=sendonly
  a=mid:1
  m=video 40002 RTP/AVP 99 100 101
  a=rtpmap:99 H264/90000
  a=rtpmap:100 H265/90000
  a=rtpmap:101 H266/90000
  a=v3cfmtp:sprop-v3c-unit-type=3;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0
  a=mid:2
  a=sendonly
  m=video 40004 RTP/AVP 102 103 104
  a=rtpmap:102 H264/90000
  a=rtpmap:103 H265/90000
  a=rtpmap:104 H266/90000
  a=v3cfmtp:sprop-v3c-unit-type=4;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0
  a=mid:3
  a=sendonly
  m=application 40006 RTP/AVP 105
  a=rtpmap:105 v3c/90000
  a=v3cfmtp:sprop-v3c-unit-type=1;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0;
  a=mid:4
  a=sendonly

  ...
  a=group:v3c 1 2 3 4
  m=video 50000 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=recvonly
  a=mid:1
  m=video 50002 RTP/AVP 100
  a=rtpmap:100 H265/90000
  a=recvonly
  a=mid:2
  m=video 50004 RTP/AVP 104
  a=rtpmap:104 H266/90000
  a=recvonly
  a=mid:3
  m=application 50006 RTP/AVP 105
  a=rtpmap:105 v3c/90000
  a=recvonly
  a=mid:4

  ...
  a=group:BUNDLE 1 2 3 4
  a=group:v3c 1 2 3 4
  m=video 40000 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=v3cfmtp:sprop-v3c-unit-type=2;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0
  a=mid:1
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=video 40002 RTP/AVP 97
  a=rtpmap:97 H264/90000
  a=v3cfmtp:sprop-v3c-unit-type=3;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0;
  a=mid:2
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=video 40004 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=v3cfmtp:sprop-v3c-unit-type=4;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0
  a=mid:3
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=application 40006 RTP/AVP 99
  a=rtpmap:99 v3c/90000
  a=v3cfmtp:sprop-v3c-unit-type=1;sprop-v3c-vps-id=0;
    sprop-v3c-atlas-id=0;
    sprop-v3c-parameter-set=AQD/AAAP/zwAAAAAADwIAQ5BwAAOADjgQAADkA==
  a=mid:4
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

  a=group:BUNDLE 1 2 3 4
  a=group:v3c 1 2 3 4
  m=video 50000 RTP/AVP 96
  a=rtpmap:96 H264/90000
  a=mid:1
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=video 0 RTP/AVP 97
  a=rtpmap:97 H264/90000
  a=bundle-only
  a=mid:2
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=video 0 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=bundle-only
  a=mid:3
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
  m=application 0 RTP/AVP 99
  a=rtpmap:99 v3c/90000
  a=bundle-only
  a=mid:4
  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

9.5. Declarative SDP Considerations

When V3C content over RTP is offered with SDP in a declarative style, the parameters capable of indicating both bitstream properties as well as answerer capabilities are used to indicate only bitstream properties. For example, in this case, the parameters v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, and v3c-ptl-rec-idc declare the values used by the bitstream, not the capabilities for receiving bitstreams.¶

An answerer of the SDP is required to support all parameters and values of the parameters provided; otherwise, the answerer MUST reject or not participate in the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.¶

10.1. V3C Media Type Registration

IANA has registered the following media type in the "Media Types" registry.¶

Type name:

application¶

Subtype name:

v3c¶

Required parameters:

sprop-v3c-parameter-set¶

Optional parameters:

sprop-v3c-unit-header, sprop-v3c-unit-type, sprop-v3c-vps-id, sprop-v3c-atlas-id, sprop-v3c-attr-idx, sprop-v3c-attr-part-idx, sprop-v3c-map-idx, sprop-v3c-aux-video-flag, sprop-v3c-tile-id, sprop-v3c-tile-id-pres, sprop-v3c-atlas-data, sprop-v3c-common-atlas-data, sprop-v3c-sei, v3c-ptl-level-idc, v3c-ptl-tier-flag, v3c-ptl-codec-idc, v3c-ptl-toolset-idc, v3c-ptl-rec-idc, and sprop-max-don-diff.¶

Encoding considerations:

framed¶

Security considerations:

See Section 11 of RFC 10034.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 10034¶

Applications that use this media type:

Any application that relies on V3C-based media services over RTP.¶

Fragment identifier considerations:

N/A¶

Additional information:

N/A¶

Person & email address to contact for further information:

Lauri Ilola (lauri.ilola@nokia.com) or Lukasz Kondrad (lukasz.kondrad@nokia.com)¶

Intended usage:

COMMON¶

Restrictions on usage:

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

Author:

See the Authors' Addresses section of RFC 10034.¶

Change controller:

IETF¶

10.2. V3C Format Parameters SDP Attribute

IANA has registered the following SDP attribute in the "attribute-name (formerly 'att-field')" registry under the "Session Description Protocol (SDP) Parameters" registry group.¶

Contact name:

See the Authors' Addresses section of RFC 10034.¶

Contact email address:

See the Authors' Addresses section of RFC 10034.¶

Attribute name:

v3cfmtp¶

Attribute syntax:

  v3cfmtp-value = byte-string

¶

Notes:¶

• The V3C format parameters are V3C media type parameters and need to reflect their syntax.¶
• "byte-string" is as defined in [RFC8866].¶
• ABNF grammar is as defined in [RFC5234].¶

Attribute semantics:

"v3cfmtp-value" is a byte-string, as defined in [RFC8866], that contains at least one V3C-specific media format parameter as a "parameter=value" pair, as defined in this document. Multiple semicolon-separated V3C media "parameter=value" pairs can be stored in the byte-string to be conveyed by SDP and given unchanged to the media tool that will use this format. Whitespace in the byte-string is ignored.¶

Attribute value:

v3cfmtp-value¶

Usage level:

session, media¶

Charset dependent:

No¶

Purpose:

This attribute allows parameters that are specific to a V3C format to be conveyed in a way that SDP does not have to understand them. It allows associating V3C-specific parameters with a session or with any media line. Parameters signaled as part of session-level attributes take effect when conflicting parameters are signaled as media-level attributes.¶

O/A procedures:

The v3cfmtp attribute can be present both in offers and answers.¶

Mux Category:

NORMAL¶

Reference:

RFC 10034¶

10.3. V3C Grouping Type Extension

The SDP Group attribute is extended to establish relationships between sub-streams of a V3C representation. IANA has registered the following in the "Semantics for the 'group' SDP Attribute" registry under the "Session Description Protocol (SDP) Parameters" registry group:¶

12.1. Normative References

[ISO.IEC.23090-5]

ISO/IEC, "Information technology -- Coded representation of immersive media -- Part 5: Visual volumetric video-based coding (V3C) and video-based point cloud compression (V-PCC)", ISO/IEC 23090-5:2026, 2026, <https://www.iso.org/standard/91546.html>.

[ISO.IEC.23090-12]

ISO/IEC, "Information technology -- Coded representation of immersive media -- Part 12: MPEG Immersive video (MIV)", ISO/IEC 23090-12:2025, 2025, <https://www.iso.org/standard/87643.html>.

[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>.

[RFC3264]

Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, July 2002, <https://www.rfc-editor.org/info/rfc3264>.

[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>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5888]

Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.

[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>.

[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>.

[RFC8866]

Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.

[RFC9143]

Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, <https://www.rfc-editor.org/info/rfc9143>.

12.2. Informative References

[BCP195]

Best Current Practice 195, <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:

Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.

[ISO.IEC.14496-10]

ISO/IEC, "Information technology - Coding of audio-visual objects - Part 10: Advanced video coding", ISO/IEC 14496-10:2025, 2025, <https://www.iso.org/standard/87574.html>.

[ISO.IEC.14496-12]

ISO/IEC, "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", ISO/IEC 14496-12:2026, 2026, <https://www.iso.org/standard/85596.html>.

[ISO.IEC.23008-2]

ISO/IEC, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding", ISO/IEC 23008-2:2025, 2025, <https://www.iso.org/standard/90502.html>.

[ISO.IEC.23009-1]

ISO/IEC, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2022, 2022, <https://www.iso.org/standard/83314.html>.

[ISO.IEC.23090-3]

ISO/IEC, "Information technology - Coded representation of immersive media - Part 3: Versatile video coding", ISO/IEC 23090-3:2024, 2024, <https://www.iso.org/standard/86516.html>.

[ISO.IEC.23090-10]

ISO/IEC, "Information technology - Coded representation of immersive media - Part 10: Carriage of visual volumetric video-based coding data", ISO/IEC 23090-10:2022, 2022, <https://www.iso.org/standard/78991.html>.

[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>.

[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>.

[RFC4303]

Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[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>.

[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>.

[RFC6184]

Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <https://www.rfc-editor.org/info/rfc6184>.

[RFC6190]

Wenger, S., Wang, Y.-K., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <https://www.rfc-editor.org/info/rfc6190>.

[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>.

[RFC7296]

Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7798]

Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M. M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, <https://www.rfc-editor.org/info/rfc7798>.