Summary

  • RFC 10034, co-authored by Lauri Ilola and Lukasz Kondrad, defines RTP carriage for V3C atlas NAL units and an SDP V3C group that identifies which atlas and video media lines constitute one representation.
  • A receiver may reject individual media lines or accept only a subset. Packet loss, fragment state, decoding order, parameter-set compatibility and inter-stream timing can each stop grouped components from becoming a reconstructed scene.
  • The payload format mandates no single security mechanism. Authenticity, integrity and confidentiality must cover every constituent stream and the signaling that joins them; an SDP group or packet counter cannot supply that proof.

An SDP offer can look complete at a glance. Four media identifiers follow a=group:V3C: one for an atlas, three for occupancy, geometry and attributes. Each line has a payload type. Each stream produces packets. A monitoring panel can turn green before a single volumetric frame has been reconstructed.

That is not a defect in RFC 10034. It is the boundary the document makes visible.

Published on the IETF Standards Track in August 2026, the RFC gives a transport grammar to visual volumetric video-based coding. Lauri Ilola and Lukasz Kondrad describe how atlas NAL units travel in RTP, how V3C-specific parameters appear in SDP, and how media lines belonging to one V3C representation are grouped. The standard coordinates pieces that were designed to remain distinct.

The distinction matters because volumetric video is not one ordinary picture stream. A V3C encoder converts a three-dimensional frame into several two-dimensional representations plus instructions for reversing that conversion. Occupancy identifies which pixels contribute. Geometry describes where reconstructed points belong. Attributes may supply colour or material properties. Atlas patches connect regions of those 2D components to locations in 3D space.

The atlas is therefore neither the scene nor decorative metadata. It is part of the reconstruction recipe. The video components are neither the scene nor interchangeable layers. They provide different inputs to the recipe. A group names their intended association. Only a receiver outcome can show whether the recipe ran.

Three packet forms, three different failure surfaces

RFC 10034 defines three ways to carry an atlas NAL unit. A single-NAL packet carries exactly one unit. An aggregation packet packs at least two small units together to reduce overhead. A fragmentation unit carries part of one unit across several RTP packets when the original is too large.

Those choices solve transport problems, but their success criteria differ.

An aggregation packet must fit inside one IP packet, and its size should avoid IP fragmentation. A fragmentation unit cannot contain another fragmentation unit, and an aggregation packet cannot itself be fragmented. The pieces of a fragmented NAL unit must be transmitted consecutively with ascending RTP sequence numbers. If one fragment is lost, the receiver should discard the following fragments that belong to the same unit.

A stream can therefore be alive while a required atlas unit is unusable. Counting packets received does not expose whether all fragments for a unit arrived. Counting bytes does not show whether an aggregation packet could be parsed. Seeing the last RTP sequence number does not show that the receiver retained a decodable NAL unit.

Ordering creates another receipt. When sprop-max-don-diff is zero, transmission order must match decoding order. When it is greater than zero, decoding-order numbers allow transmission and decoding order to diverge. The receiver then has to reconstruct the proper order before handing NAL units to the decoder. Arrival is evidence of carriage; the DON/DONL state and decoder trace are evidence of assembly.

Timing is similarly precise. The atlas payload uses a 90 kHz RTP clock. The receiver must use the RTP timestamp for display even when the bitstream also carries atlas-frame timing SEI messages. That rule aligns one time base. It does not prove that separately carried occupancy, geometry, attributes and atlas data arrived within a usable inter-stream synchronization window.

The group says “belongs with,” not “arrived with”

RFC 5888 supplies the general SDP grouping framework. RFC 10034 adds the V3C semantic. Tokens after a=group:V3C map to the mid values of media lines that form one V3C bitstream. An atlas line uses m=application and the v3c encoding name. Video components use m=video and the appropriate H.264, H.265, H.266 or other payload format.

This separation is useful. A sender can describe several atlases and multiple component streams without pretending they are one codec payload. A receiver can see which components belong together. The V3C parameter set can describe the resources needed to decode and reconstruct the associated content.

But grouping syntax is declarative. It says what the offerer intends. The offer/answer rules show why that statement cannot be promoted into a completion certificate.

For unicast, the offerer lists the available components and indicates which media lines should be consumed together. The answerer may accept that set—or reject undesired media lines by setting their ports to zero. RFC 10034 explicitly allows a subset when the answerer is fully or partially ignorant of the V3C coding scheme. A syntactically valid answer can therefore describe a deliberately incomplete receiver choice.

The parameter set has its own boundary. It may be conveyed out of band because it tells the receiver what resources are required. If it arrives dynamically after component traffic begins, and the receiver lacks a required capability, the RFC warns of undefined behaviour. Recording a parameter set proves that bytes were declared. A capability check proves whether the receiver could use them.

Declarative SDP is stricter in a different way: a receiver must support the advertised values or reject the session. Even there, participation is only an acceptance decision. It is not a rendered-scene checksum.

Every constituent stream needs its own trust receipt

The security section refuses another shortcut. RFC 10034 does not mandate one security mechanism for RTP. It points applications to the broader RTP security landscape and leaves them responsible for confidentiality, integrity and source authentication.

That responsibility is plural. A V3C session can use several RTP streams plus SDP and RTCP. The RFC says source authentication should apply to all constituent sub-streams and that decoded output depends on all streams and signaling being authentic to what the sender intended. Protecting the geometry stream while accepting an unauthenticated atlas would not produce a trustworthy whole. Authenticating RTP while accepting altered grouping or parameter signaling would leave the association itself exposed.

The multicast rule makes the provenance problem concrete: parameter sets must remain associated with their originating source and be used only to decode that source's bitstream. A matching identifier is not permission to mix state across senders.

RFC 7202 explains why an RTP payload format does not choose one universal security solution; applications have different environments. RFC 7201 catalogs options and trade-offs. The operational consequence is simple: a report must name the mechanism actually used, the components it covered, the keys or trust anchors involved and the verification result. “RTP received” and “V3C grouped” are not security statuses.

Kondrad's contribution is valuable because it stays bounded

Nokia's public profile describes Kondrad as a Principal Standardization Specialist working on immersive-media standards in ISO/IEC and the IETF. That context explains the bridge in RFC 10034: the V3C coding model comes from ISO/IEC 23090-5, while RTP, SDP, grouping and security conventions come from the IETF ecosystem.

The bridge is collective. Ilola shares authorship. ISO/IEC defines the coding system. Earlier RTP and SDP RFCs supply the transport framework. IANA records the application/v3c media type, v3cfmtp attribute and V3C grouping semantic. None of those records proves a product implementation, and Kondrad should not be made the sole inventor or operator of the resulting stack.

The narrow standard is the useful achievement. It tells packetizers when to aggregate or fragment, tells receivers how to find decoding order, tells session descriptions how to bind components, and states where capability and security remain outside the payload format. It creates interoperable questions without manufacturing operational answers.

Heng Lu's Running-Code Primacy supplies the final test. Retain the exact offer and answer, every mid, accepted and rejected media lines, payload formats, parameter-set digest, component mapping, RTP source identifiers, security associations, sequence gaps, DON/DONL state, AP and FU boundaries, loss response, inter-stream timing, decoder errors and reconstructed-frame checks. Then reproduce the result.

One receipt says the components were declared together. A second says their packets arrived. Others say the pieces were authentic, complete, ordered, synchronized and decodable. The final receipt belongs to the reconstructed scene. RFC 10034 makes the chain possible; it does not erase the links.

Sources