Summary of 3GPP CR to TS 26.114

Change Request Details

• CR Number: 0073
• Specification: TS 26.114 v19.2.0
• Category: F (Correction)
• Release: Rel-19
• Work Item: 5G_MEDIA_MTSI_ext, TEI19

Reason for Change

3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging). The existing constraint in TS 26.114 clause 6.2.10.1 requiring that a data channel SDP media description shall not be placed before the first SDP speech media description is therefore no longer applicable and needs to be removed to align with the new SA2 specifications.

Technical Changes

Clause 6.2.10.1 - General

Modified Text:

The CR updates the paragraph describing data channel SDP media descriptions to remove the ordering constraint. The changes are:

• Previous text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."

• Updated text: "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Deleted Constraint:

The following sentence is completely removed: - "A data channel SDP media description shall not be placed before the first SDP speech media description."

Impact

This correction enables: - Standalone data channel sessions without requiring MMTel media - Flexibility in SDP media description ordering - Alignment with SA2 Rel-19 specifications for data channel sessions

The change maintains all other requirements including: - Protocol identifier ("UDP/DTLS/SCTP") and media format ("webrtc-datachannel") specifications - Media feature tag requirements (+sip.app-subtype and g.3gpp.dc-mux) - Bandwidth limit determination procedures

Summary of 3GPP CR S4-260081 to TS 26.114

Change Request Details

• Document: TS 26.114 v19.2.0
• CR Number: 0073
• Category: F (Correction)
• Release: Rel-19
• Work Item: 5G_MEDIA_MTSI_ext, TEI19

Main Technical Contribution

Background and Rationale

This CR addresses an outdated constraint in TS 26.114 clause 6.2.10.1 regarding data channel SDP media descriptions. The constraint was introduced when data channels were only supported alongside MMTel media (audio, video, messaging). However, 3GPP R19 SA2 has now specified standalone data channel sessions that can establish data channels without requiring MMTel media.

Technical Changes to Clause 6.2.10.1 (General)

Removed Constraint

The CR removes the following restriction:

"A data channel SDP media description shall not be placed before the first SDP speech media description."

This constraint is no longer applicable given the support for standalone data channel sessions.

Modified Text

The clause describing data channel SDP media description placement has been updated from:

Before:

"One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."

After:

"One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Impact

This correction: - Aligns TS 26.114 with SA2 specifications for standalone data channel sessions - Removes an unnecessary ordering constraint on SDP media descriptions - Enables more flexible data channel deployment scenarios without mandatory MMTel media

Unchanged Elements

The CR maintains all other aspects of clause 6.2.10.1, including: - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - Support indication for bootstrap and application data channel multiplexing (g.3gpp.dc-mux) - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements

Summary of 3GPP Technical Document S4-260087

Document Information

• CR Number: 0604 rev 1
• Specification: TS 26.114 v19.2.0
• Category: F (Correction)
• Release: Rel-19
• Work Item: 5G_MEDIA_MTSI_ext, TEI19

Main Technical Contribution

Problem Statement

The current constraint in TS 26.114 clause 6.2.10.1 states that a data channel SDP media description shall not be placed before the first SDP speech media description. This constraint is no longer applicable because 3GPP R19 SA2 has specified standalone data channel sessions that can establish data channels without MMTel media (e.g., audio, video, messaging).

Proposed Change

Modification to Clause 6.2.10.1 (General)

The CR proposes to remove the restrictive placement constraint for data channel SDP media descriptions. Specifically:

Deleted Text: - "A data channel SDP media description shall not be placed before the first SDP speech media description."

Modified Text: The sentence describing data channel SDP media description inclusion is updated from: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be contained alongside other SDP media descriptions such as e.g. speech, video, and text."

To: - "One or more data channel SDP media descriptions formatted according to IETF RFC 8864 [172] may be added into the SDP independently, or to be added alongside other SDP media descriptions such as e.g. speech, video, and text."

Technical Impact

This correction enables: - Standalone data channel sessions without requiring MMTel media components - Flexible SDP ordering where data channel media descriptions can appear in any position within the SDP - Alignment with SA2 specifications for Rel-19 standalone data channel functionality

Unchanged Requirements

The following requirements remain intact: - Support for data channel media remains optional for MTSI clients - Media feature tag requirements (+sip.app-subtype with "webrtc-datachannel" value) - g.3gpp.dc-mux media feature tag for bootstrap and application data channel multiplexing - Protocol identifier and media format specifications (UDP/DTLS/SCTP and webrtc-datachannel) - Bandwidth limit determination requirements per clause 6.2.5

Summary of 3GPP Technical Document S4-260116

Document Information

• CR Number: 0014
• Specification: TS 26.113 v19.1.0
• Work Item: iRTCW-TEI (Interactive Real-Time Communication Work - Technical Enhancement and Improvement)
• Category: F (Correction)
• Release: Rel-19

Main Technical Contribution

Problem Statement

The JSON schema for the SWAP (Service and Workflow Adaptation Protocol) protocol contains inconsistencies that make it invalid and misaligned with the specification text. These issues could hinder proper implementation and interoperability.

Technical Changes to Clause 13.2.4.6 (JSON Schema)

The CR proposes a complete restructuring of the SWAP message JSON schema with the following key modifications:

1. Schema Structure Simplification

• Removed: Complex nested definitions section that defined matching_criteria_object as a reusable component
• Removed: Separate payload property with complex oneOf structures
• Changed: Flattened schema structure by moving payload definitions directly under the root oneOf

2. Matching Criteria Handling

• Before: Matching criteria was defined as a reusable object reference with type and value properties, allowing both predefined enums and custom strings via anyOf
• After: Simplified to a direct string enum without the flexible anyOf structure
• Impact: More restrictive but clearer definition - only allows predefined matching criteria types (ipv4, ipv6, fqdn, service, user, eas, app, location, qos, processing)

3. Message Payload Structure

• Before: Payloads were nested under a payload property with detailed descriptions for each message type (register, response, connect, accept, reject, application)
• After: Payloads are defined directly at the root level using oneOf, removing the intermediate payload wrapper
• Removed: Explicit descriptions for each payload variant
• Removed: Array structure for matching_criteria in connect payload

4. Required Fields

• Changed: "source" in required fields changed to "source_id" to match the actual property name defined in the schema

5. Data Type Corrections

• Reject/Error Payload: Changed request field type from "integer" to "number" for more flexibility

6. Extensions Object

• Before: Defined with type "object" and description
• After: Simplified to empty object {}

Impact Assessment

Positive Impacts

• Corrects schema validation errors
• Aligns JSON schema with specification requirements
• Ensures proper interoperability between implementations

Potential Concerns

• The simplified matching criteria structure is less flexible (removed anyOf allowing custom strings)
• Removal of array support for matching criteria in connect payload may limit functionality
• Loss of descriptive metadata for payload variants may reduce schema self-documentation

Affected Specifications

• Core Specification: TS 26.113 (SWAP protocol)
• Other Specifications: None directly affected
• Test Specifications: Not affected
• O&M Specifications: Not affected

Summary of 3GPP Technical Document S4-260117

Document Information

• Specification: TS 26.113 v19.1.0
• CR Number: 0015
• Category: F (Correction)
• Release: Rel-19
• Work Item: iRTCW-TEI (Interactive Real-Time Communication Web - Technical Enhancement and Improvement)
• Source: Qualcomm Inc.

Purpose and Rationale

The CR addresses an ambiguity in the SWAP (Streaming and WebRTC API) specification regarding the handling of the accept message in response to a close operation. Currently, the specification is unclear about whether the answer field (containing SDP answer) should be included in the accept message when responding to a close message, leading to potential implementation confusion.

Technical Changes

Accept Message Handling (Clause 13.2.4.4.5)

Description Updates (13.2.4.4.5.1)

• Previous behavior: Accept message always contains answer SDP when replying to connect or update requests
• Clarification added:
• Accept message shall contain answer SDP when responding to connect or update messages
• Accept message shall NOT contain SDP when responding to close messages
• Explicitly separates the two use cases for the accept message

Parameter Definition (13.2.4.4.5.2)

• answer parameter: Changed from mandatory to optional
• Modified to "This parameter, when present, shall contain the answer SDP"
• Makes it clear that answer is conditionally included based on the triggering message type

Update Message Clarification (13.2.4.4.6.1)

• Reinforces that update message is for partial media teardown (half-close)
• Distinguishes from close message which performs full session termination
• Note added emphasizing the use of close message for full session termination

Close Message Clarification (13.2.4.4.8.1)

• Explicitly states that accept message response shall be "without an SDP payload"
• Clarifies session teardown procedure: accept message triggers resource release
• Note added distinguishing close (full termination) from update (partial teardown)

Impact

The changes ensure proper protocol behavior by: 1. Removing ambiguity in accept message structure based on context 2. Preventing unnecessary SDP exchange during session termination 3. Clearly delineating between partial media teardown (update) and full session termination (close)

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.