Summary

  • RFC 10034 defines RTP carriage for V3C atlas data and an SDP V3C group that associates atlas, occupancy, geometry and attribute media lines. The group names a representation; it does not prove that every necessary component arrived or was reconstructed.
  • Completion has to be established across signaling, parameter state, source authorization, packet loss, fragment assembly, decoding order, cross-stream timing, decoder outcome and an application canary. One marker bit, accepted offer or authenticated stream is narrower evidence.

Imagine a control room with four green counters. The atlas flow is receiving packets. Occupancy is current. Attribute video is inside its loss target. Geometry also appears healthy because its RTP session is active and its last packet carried the marker bit. The dashboard labels the V3C session complete.

The headset renders a torn surface.

One geometry NAL unit was split into three fragmentation units. The middle fragment never arrived. Later packets kept the flow alive, and the atlas stream legitimately closed its own access unit. None of those facts recreated the missing bytes. The monitoring system counted four active streams and mistook membership for a scene.

RFC 10034, published on the IETF Standards Track in August 2026, makes that mistake avoidable. Its contribution is not a magic volumetric channel. It defines an RTP payload format for V3C atlas sub-bitstreams, reuses the applicable video payload specifications for the video components, and gives SDP a way to bind the component media lines into one declared representation.

That is important coordination. It is also a deliberately bounded authority.

A scene is dismantled before it is sent

V3C compresses volumetric content by translating a three-dimensional frame into several two-dimensional representations and the atlas information needed to project them back into space. Occupancy can say which pixels contribute. Geometry can locate reconstructed points. Attributes can carry colour, reflectance, normals or other properties. The atlas describes patches and the inverse mapping that gives those video planes spatial meaning.

The public catalogue for ISO/IEC 23090-5:2026 identifies the V3C and V-PCC specification on which RFC 10034 relies. RFC 10034 reproduces enough of the architecture to expose the transport problem: the receiver is not waiting for one movie frame. It is joining components whose value depends on the others.

The separation persists on the wire. The atlas uses application/v3c over RTP with a 90 kHz clock. Occupancy, geometry and attribute components use the payload formats of their selected video codecs. An offer may therefore describe H.264 for one component, H.265 for another and H.266 for a third, while the atlas remains an application media line.

This is why the word “stream” is too coarse for operational reporting. Four streams can be alive while one representation is impossible. A lower-priority attribute may be expendable in one product and safety-critical in another. An atlas without usable geometry can be perfectly packetized and operationally useless.

The group is a relation, not a receipt

RFC 10034 extends the SDP grouping framework with:

a=group:V3C 1 2 3 4

The following tokens refer to mid values on the component media lines. RFC 5888 supplies the general grouping model. The new token tells an application that these descriptions belong to one V3C bitstream. It does not transport their media, authenticate their sources or report their decoder state.

The same media lines may also appear in a BUNDLE negotiation. Shared transport can reduce sockets, but it does not merge the component identities. A bundled packet still has to be associated with the right media description, V3C unit type, parameter-set ID, atlas ID and security context.

SDP also has two parameter scopes. a=v3cfmtp can appear at session or media level, and RFC 10034 makes the session-level value prevail where the two conflict. That rule prevents an implementer from inventing a local precedence. It does not prove that a cached offer, an in-band override and the bytes reaching the decoder all refer to the same session revision.

The IANA media-type record registers application/v3c, requires sprop-v3c-parameter-set and restricts this media type to RTP framing. The IANA SDP registries provide the shared namespaces for media, attributes and grouping semantics. Registration makes a label interoperable. It does not show that any named sender offers it, that any receiver supports it, or that a real session reconstructed anything.

The parameter set is a dependency, not capability proof

The required sprop-v3c-parameter-set carries base64-encoded parameter-set bytes. Those bytes describe resources and profile state relevant to reconstruction. RFC 10034 notes that out-of-band signaling is generally useful because discovering the requirements only after media starts may leave a receiver without the required capabilities and produce undefined behaviour.

Other fields identify the component type, active parameter-set ID, atlas, attribute partition, map and auxiliary-video role. A compact four-byte unit header may carry the same information as the separate parameters; both forms are forbidden together because they could disagree.

Out-of-band atlas, common-atlas and SEI NAL units can apply for the entire stream until an in-band unit of the same type overrides them. That creates a state transition, not a clerical detail. A receiver that keeps old out-of-band state while accepting new in-band media may authenticate every packet and still assemble the wrong representation.

In unicast offer/answer, the offerer lists the available components and says which should be consumed together. Under RFC 3264, the answerer can accept supported formats and reject a media line by setting its port to zero. RFC 10034 expressly permits a receiver that is partly ignorant of V3C to select a subset.

That flexibility is valuable. It also removes the possibility of a universal rule that “answer accepted” means “scene complete.” The product must define which subsets are meaningful. Declarative SDP makes the distinction sharper: its profile fields describe the bitstream, not receiver capability, and a receiver unable to support them must reject or stay out.

One marker closes one local access unit

RTP gives a stream sequence numbers, timestamps, source identifiers and a marker whose meaning is set by the payload format. In RFC 10034, the marker is placed on the last packet of the access unit carried in the current RTP stream. It helps playout-buffer handling. It is not a global commit across every member of the V3C group.

The atlas payload has three forms. A single-NAL packet carries one unit. An aggregation packet carries at least two small units and should remain below the local MTU. A fragmentation unit divides one NAL unit across consecutive RTP packets, without nesting and without interleaving another packet from the same stream between its first and last fragments.

The failure semantics are concrete. If one fragment is lost, the receiver should discard the later fragments of that NAL unit unless its decoder is known to handle incomplete units. A green packet counter after the gap is therefore especially misleading: it proves that bytes continued, not that the unit recovered.

Ordering adds another boundary. When sprop-max-don-diff is zero or absent, transmission order is decoding order. A nonzero value enables decoding-order numbers, and the receiver has to reorder before handing NAL units to the decoder. Depacketization must also consider the streams on which the current stream depends and may intentionally delay work for cross-stream synchronization.

The same separation between packet form and decoder input appears in the NAL-based precedent of RFC 7798. RFC 10034 adapts that family of mechanisms to V3C atlas data. Familiar packetization does not make the multi-component dependency disappear.

Integrity has to cover the set

RFC 10034 does not choose one security mechanism for every application. That follows the RTP architecture explained by RFC 7202: a payload format cannot decide the deployment's keying, identity, group, unicast or trust model. RFC 7201 surveys the available design space, while SRTP supplies confidentiality, authentication and replay-protection machinery for applicable sessions.

The V3C-specific duty is still strong. RFC 10034 says source authentication should be applied to all constituent sub-streams and that the RTP streams, SDP and RTCP have to be authentic to what the sender intended. Protecting only the atlas while accepting geometry from an unbound source would leave the representation open to composition attacks.

Even complete cryptographic success is not the final answer. Four valid streams can bind to different session revisions. A replay-protected attribute flow can be too late for the atlas frame. A trusted sender can misconfigure the atlas ID. Integrity proves that protected bytes survived under a key; cross-component consistency and application usefulness need separate evidence.

Congestion decisions can change meaning

RFC 10034 requires unicast users to monitor packet loss and apply RTP congestion control. A sender may adapt rate, a receiver may leave, or either side may use the RTP circuit breaker. The specification also allows less important sub-streams to be removed or reduced, provided the whole experience is considered.

“Less important” is not on the RTP wire. It is a product judgment. Removing colour might be acceptable for a geometric telepresence fallback and fatal for a material-inspection workflow. Dropping an auxiliary component may reduce fidelity or invalidate an analytic conclusion. Congestion action therefore needs a semantic status change: degraded geometry-only mode, not ordinary completion with a smaller bitrate.

The transport can tell an operator that a flow crossed a loss boundary. Only the application contract can say what that loss means.

Build a completion ledger, not a wall of green lights

For each session revision, preserve the hashes of the offer and answer, the mid membership of the V3C and BUNDLE groups, parameter-set and unit-header fingerprints, codec and component role, atlas ID, authorized source, SSRC and transport tuple. Then record first and last packet times, loss, jitter, reorder depth, completed fragments, decoding-order state and the access-unit boundary for every component.

Continue the ledger past RTP. Record which NAL units entered the decoder, decoder errors, the reconstructed-frame identity, the application render or analytic canary, any degradation decision, circuit-breaker action and final terminal state. “Accepted,” “receiving,” “depacketized,” “decoded” and “useful” must remain separate values.

This follows Heng Lu's running-code primacy: proof belongs to the executed path, not the standards label or declared group. His model of a minimum initial specification with localized decisions fits the design: the common syntax is narrow, while each participant retains capability and adoption choices. His distinction between formal and practical data control explains why a session creator can name the parts without controlling every network copy, receiver buffer or final output.

RFC 10034 gives distributed systems a better common language. Its discipline is strongest when no actor uses that language to claim a result it cannot observe.