# Summary of 3GPP CR on Correction to Animation Samples Transport

## Document Information
- **Specification:** TS 26.264 v19.1.0
- **CR Number:** 0017
- **Category:** F (Correction)
- **Release:** Rel-19
- **Work Item:** AvCall-MED
- **Source:** Qualcomm Inc.

## Problem Statement

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:

- Requires base64 encapsulation for binary data in text channel
- Introduces additional latency
- Creates interoperability problems
- Risk of incompatible proprietary workarounds and fragmentation

## Technical Changes

### 1. Metadata Data Channel Clarification (Clause 6.2)

**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

### 2. New Avatar Animation Data Channel (Clause 6.3.2)

**Major addition - dedicated binary transport channel:**

#### Channel Characteristics
- **Sub-protocol identifier:** "3gpp-ar-animation"
- **Purpose:** Binary transport for ARF avatar animation samples (clause 8 of TS 26.565)
- **Separation:** Distinct from metadata data channel
- **Content restriction:** Shall only carry avatar animation samples

#### Transport Parameters
- **Transmission order:** In-order
- **Reliability:** Should be reliable by default
- **Partial reliability:** May negotiate using data-channel parameters (max-time or max-retr) when supported by both endpoints
- **SDP signaling:** Included in dcmap attribute

#### Message Format
- Each message contains **exactly one** ARF animation sample
- No compression scheme defined for animation samples

#### Example SDP
```
a=dcmap:2 label="avatar-anim-1" subprotocol="3gpp-ar-animation" ordered max-time=150
```

### 3. Removed Content (Clause 6.3.2)

**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

## Impact

### Requirements for AR-MTSI Clients/MF
- **Shall** support exchange of avatar animation data over the new Avatar Animation Data Channel
- **Shall** establish or accept Avatar Animation Data Channel for animation sample exchange
- **Shall** support ARF sample formats per clause 8 of TS 26.565

### Consequences if Not Approved
- Incompatible implementations using workarounds (text/base64, proprietary channels)
- Fragmentation of implementations
- Interoperability failures between vendors

## Summary

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.