CR on correction to animation samples transport
The current specification incorrectly implies that avatar animation samples should be carried on the metadata data channel, which is defined as text-only UTF-8 JSON. However, ARF (Avatar Representation Format) animation samples are binary data. This mismatch creates several issues:
Added clarification:
- Explicit NOTE stating that the metadata data channel (sub-protocol "3gpp-ar-metadata") is text-only and not intended for transport of binary data such as avatar animation samples
- Explicit statement that the metadata data channel shall not be used to transport ARF avatar animation samples
Major addition - dedicated binary transport channel:
a=dcmap:2 label="avatar-anim-1" subprotocol="3gpp-ar-animation" ordered max-time=150
Deleted specifications:
- Previous avatar animation message format using metadata channel (Table 6.3-1)
- Message type "urn:3gpp:avatar:v1:animation"
- Subtype field for different animation types (facial, joint, landmark, audio, video)
- Payload object structure for animation samples in JSON format
Retained control messages:
- Stopped message (urn:3gpp:avatar:v1:animation:control:stopped) - Table 6.3-2
- Resumed message (urn:3gpp:avatar:v1:animation:resumed) - Table 6.3-3
- These control messages continue to use the metadata data channel
This CR introduces a fundamental architectural correction by separating binary avatar animation sample transport from text-based metadata transport. It defines a new dedicated data channel with appropriate binary transport characteristics, preventing the need for inefficient text encoding of binary data and ensuring proper interoperability for avatar animation in AR-MTSI calls.